ledger: progressive disclosure is the build model, review must not avalanche (2026-07-17)

odd/ledger/2026-07-17-progressive-disclosure-and-anti-avalanche-review.md

@@ -0,0 +1,51 @@
+---
+uri: klappy://odd/ledger/2026-07-17-progressive-disclosure-and-anti-avalanche-review
+kind: journals
+title: "Ledger — Progressive Disclosure Is the Build Model, and Review Must Not Avalanche (2026-07-17)"
+tier: 3
+audience: odd
+exposure: nav
+voice: neutral
+stability: stable
+tags: ["ledger", "black-box", "low-resolution", "progressive-disclosure", "progressive-jpeg", "maturity", "anti-avalanche", "review-batching", "durable-not-memory", "pre-policy", "no-blame", "judgment", "discernment", "mentorship"]
+epoch: E0010
+date: 2026-07-17
+derives_from: "odd/maturity.md, canon/bootstrap/model-operating-contract.md"
+governs: "The black-box record of four operator-articulated working lessons about how an ODD app/policy set is built and reviewed. Low-resolution capture, pre-policy — hands off to a sharp policy later via friction, not now."
+status: active
+---
+
+# Ledger — Progressive Disclosure Is the Build Model, and Review Must Not Avalanche (2026-07-17)
+
+> The black box records; the debrief legislates; the crew flies again. This is raw capture, not verdict. Low-resolution on purpose — it sharpens into policy later through friction with reality, not through more up-front review now.
+
+## Status of this entry
+
+These are **operator-articulated working lessons**, captured at low resolution for later handoff. **Not yet ratified policy.** No challenge gauntlet was run on this entry (the gauntlet is for policies, not for raw ledger capture), and none of the below has been expanded into a constraint. The move this entry itself demonstrates: a rule that matters gets written down where it persists, then handed off — ledger to policy — rather than held in a conversation that evaporates.
+
+## The observations (low resolution)
+
+**1. Progressive disclosure is the build model.** An app — or a policy set — is a progressive JPEG. It is viewable, buildable, and shippable at every resolution, and it sharpens with each iterative pass and each contact with reality. Maturity is not bought with more up-front review; it is earned as the **policies get clearer over time and through friction**. The clarity of the policies *is* the maturity signal. (Relates to `klappy://odd/maturity` — policy weight scales with maturity — but read from the other direction: it is the sharpening of the policies, not a calendar or a review count, that moves the project up the axis. Cross-reference only; that doc is not edited here.)
+
+**2. Anti-avalanche.** Reviewing or ratifying must not spawn exponential *unrelated* work. The failure mode observed today: for every two or three documents reviewed, two or three new and unrelated workstreams were spawned. That ratio does not converge — it avalanches, and the review never finishes. Findings surfaced during review are **parked** (recorded), not built mid-review. The lever is stopping the tangents, not slowing the pace.
+
+**2a. Refinement — anti-avalanche is judgment, not a checkbox (folded in, low resolution).** Sharpens observation 2 without replacing it:
+
+- *Some temporary avalanche is unavoidable.* The loop surfaces real work; pretending a review can run at zero-avalanche is its own dishonesty. The aim is a ratio that converges, not a mythical zero.
+- *The discipline is judgment and discernment, not a mechanical rule.* It is knowing when a thread has given what it will and it is time to **stop pulling**, versus when one more turn is worth it. That judgment is grown through reps, not handed over — which is exactly why anti-avalanche resists being reduced to a checkbox policy.
+- *The distinguishing line.* A review that surfaces a **refinement of the doc under review** folds **into** that doc — bounded and correct. A review that spawns **unrelated** new work is the avalanche. The lever is "keep the change about the thing being reviewed." (This very fold is that move made concrete: a refinement folded into the ledger it refines, not a new workstream spun up beside it.)
+- *Mentorship framing.* The operator mentors the model toward discipline, restraint, patience, and answering for itself — sometimes by declining to answer incessant questions and teaching self-sufficiency, the way one mentors a young person. Anti-avalanche is one shape of that restraint.
+
+**3. Related batches are the balance.** Review in human-sized *related* batches — often two or three, sometimes one. Not a dozen at once (unreviewable), and not one-at-a-time-with-a-full-flight-spun-up-per-finding (that is the avalanche wearing a discipline costume). The batch is related work; the discipline is refusing to chase what isn't.
+
+**4. Durable, not memory.** Rules that matter cannot live in conversation or model memory. Memory is unreliable and does not transcend devices, accounts, teams, or users. The durable low-resolution capture is a **ledger entry**; it hands off to a sharp policy later. Ledger to policy, never memory. (This entry is that move made concrete.)
+
+**5. Resumability is the explicit, opt-in flip side of per-actor self-owned working state.** The unified law: state does not carry over by default; carryover (resume/continue from prior state) is a deliberate, named, opt-in act — never assumed or default. Complements `working-state-is-per-actor-and-self-owned` (the default = isolation) and `verification-requires-fresh-context` (gates start clean); rhymes with the flight seed mechanism (a session resumes only from an explicit seed). Operator-articulated, low-res, parked for later handoff to a principle if friction calls for it.
+
+## The tension held open
+
+The pull is to treat review as the place where the project gets *finished* — to resolve every thread the review surfaces before moving on. That is the avalanche. The counter-pull is to under-review and let the picture stay blurry forever. The working balance being tried: ship at the current resolution, review in related batches, park the tangents, and let friction — not a review marathon — do the sharpening.
+
+## Handoff
+
+`[OPEN: these four lessons are pre-policy. When they have earned enough friction, a later pass sharpens them into policy — likely one constraint on review-batching / anti-avalanche discipline, and a note threading progressive-disclosure-as-build-model into the maturity axis. Not now. Sharpen through use, not through expansion of this entry.]`