Skim. Wants the claim and whether it holds. Reads the heading and one cue, then moves on.
Progressive block · Short, More, Full
A reader picks how deep to read each claim, and the page never changes shape around them.
Variable Reading depth per block
Story 3 topics
Default Short
Outcome
Today an Atlas topic shows its full evidence to everyone. The reader who only wants to know whether a claim holds scrolls past the same model cards and validation rows as the reader who wants to audit them. This experiment keeps one continuous story and adds a single block type that starts at its shortest reading and grows in place.
The block has three levels. Short is the default and shows one claim with a compact proof cue. More keeps the claim on screen and adds context, consequence, and the C4-style zoom the claim sits at. Full keeps everything above it and adds the evidence blocks the recap already knows how to render. Moving between levels never replaces text, so nothing the reader has already read disappears.
The controls live inside the block. They are not tabs, not a page-wide density switch, and not a drawer. Topic numbering, anchors, and reading order stay fixed at every level. The claim and evidence here are invented to show the shape; nothing on this page describes a real pull request.
Reader problem
One recap serves three readers, and today they all get the audit version
A recap has to answer "is this true?", "what does it change?", and "show me" at the same time. The current layout answers the third question everywhere, so a reviewer checking five claims scrolls through five full evidence sets before reaching the sixth.
The cost is more than length. When every claim carries the same weight of proof, the reader stops seeing where the risky claim is. The fix should lower the default load without removing evidence from the page or moving it somewhere else.
Check. Needs the context and the consequence, and which part of the system the claim touches. Two paragraphs are enough.
Audit. Expects the schema, the excerpt, and the exact validation state, with nothing hidden.
Inline expansion
The same block starts short and grows in place when the reader asks
Below is the block at its default level. Short shows the claim and one cue about the proof behind it. Press 2, labelled More, and the block adds context, consequence, and the zoom the claim lives at, with the claim still on screen. Press 3, labelled Full, and it adds the evidence. Press 1 to fold it back.
Nothing on this page moves when a level changes except the block itself. The topic number, the heading, and the next topic keep their positions. Try opening Full, scrolling to the bottom of the block, and folding it from there. The block brings its own top back into view instead of dropping you into the next topic.
Illustrative claim
Export jobs and snapshotsAn export job runs at most once per snapshot.
PartialUnique index and 2 focused tests verified · browser not captured
Context. The request handler used to enqueue the export itself, so a double click or a client retry produced two jobs for the same snapshot and both of them ran.
Consequence. The scheduler now owns the insert. A second request for the same snapshot fails at the database and the caller gets the existing job id back, so retries are safe and the queue holds no duplicates.
Zoom
- Context
- Containers
- Components
- Code
- snapshot_id
- uuid · unique index, one job per snapshot
- state
- queued, running, or done
- requested_by
- uuid · the first caller keeps the job
A second insert for the same snapshot is rejected and the first job id comes back.
The scheduler is the only writer; the request handler no longer enqueues.
No capture in this example, so the double-click path is unproven in the UI.
- Short by defaultEvery block renders at level 1 on load. A fresh page never starts expanded.
- Levels addLevel 2 keeps level 1 on screen and level 3 keeps both. Text is revealed below what is already there, never swapped.
- Controls stay insideThe three controls sit in the block header, with one continue or fold action in the footer. They change one block, not the page.
Zoom model
Each level is a C4 zoom of the same claim, not a different page
C4 describes a system at four levels, Context, Containers, Components, and Code, and the useful part is that the subject stays recognizable at each one. The block borrows that discipline for a single claim. Short is the context reading: the claim and why it matters. More zooms to containers and components: which parts of the system the claim touches and which module owns it. Full zooms to code and proof.
The mapping is a reading aid, not a taxonomy. A claim about a UI state may have no schema at Full, and a migration claim may have no component at More. What matters is that zooming in never changes the subject, so the reader who folds back to Short recognizes the sentence they started with.
Short
More
Full