Progressive Resolution

You're deep into Chapter 7 of a proposal. Something feels off about the argument flow. You trace it back—the problem is in Chapter 3.

You fix Chapter 3. But now Chapter 4 doesn't follow logically. You adjust Chapter 4, and suddenly Chapter 6 contradicts the new framing. What started as one fix has become a game of Jenga—each correction threatening to topple the whole structure.

The sinking realisation: you might need to rewrite half the document.

If this sounds familiar, you're not alone. This pattern—where fixing one thing breaks three others—is so common in complex writing that most people assume it's inevitable. It isn't. The cascade happens for a specific, preventable reason.

Documents—especially complex ones—aren't linear tapes. They're networks of dependencies:

• • Chapter 3 sets up concepts that Chapter 5 builds on
• • Chapter 4 assumes a framing established in Chapter 2
• • Chapter 7's recommendations depend on Chapter 3's analysis

When you change one node, ripples propagate through every connected node. This is why "just fix that one section" almost never works for structural problems.

We read documents linearly, so we think we should write them linearly. The mental model looks like this:

But this is like building a house by starting with the paint colour. You've made high-resolution decisions (word choices, sentence structures, paragraph flows) before low-resolution decisions (what the chapter is about, what evidence it needs, how it connects to other chapters) have stabilised.

The mistake: locking in high-resolution before low-resolution stabilises. Every polished paragraph becomes a constraint on future changes. By the time you've written 30 pages, you're not free to restructure—you're playing defensive Jenga.

• • Rework compounds: Fix in production → change code → update tests → fix documentation → retrain users → handle support tickets
• • Opportunity cost: Time spent fixing cascades = time not spent building value
• • Hidden dependencies: Late-stage changes reveal dependencies you didn't know existed
• • Context switching: Engineers who wrote the code months ago now have to reload all context

The economics are identical for documents—just compressed in time:

• • Fix a structural problem at outline stage: 5-minute adjustment
• • Fix the same problem after 30 pages of prose: hours of cascading rework

Documents don't have "production releases," but they have the equivalent: the moment you've invested significant time in polished prose.

A document is not a tape you read from start to finish. It's a multi-scale object with structure at different resolutions:

Each scale has its own coherence requirements. Changes at one scale ripple to other scales.

• • Reading is linear: We experience documents as streams of text
• • Writing feels linear: We start at the beginning and work forward
• • Editing feels local: We zoom in on sentences and paragraphs

None of these habits prepare us to see documents as multi-dimensional structures.

"Fix the argument in Chapter 3" doesn't mean changing words. It means changing:

• → Chapter 3's relationship to the thesis
• → Chapter 3's setup for Chapters 4-7
• → Chapter 3's evidence requirements
• → Downstream chapters' assumptions about what Chapter 3 established

Until you see documents as relationship graphs, you'll keep being surprised by cascades.

• ✗ The problem isn't that you edit poorly—it's that you're editing the wrong thing
• ✗ Prose-level editing can't fix structure-level problems
• ✗ No amount of sentence polish makes a fundamentally incoherent argument coherent
• ✗ You're treating symptoms while the disease spreads

The most sophisticated image generators in the world don't draw pictures left-to-right, pixel-by-pixel. They start with pure noise—and progressively refine.

Stable Diffusion, DALL-E, Midjourney—these systems can create photorealistic images from text descriptions. But they don't work like humans drawing: starting at one corner, filling in details as they go.

Instead, they begin with complete randomness—visual static—and through successive passes, shapes emerge, then structure, then detail, then texture. At no point do they commit to individual pixels until the overall composition has stabilised.

1. Start with noise: The image begins as pure Gaussian noise—random pixels with no structure
2. Forward diffusion (training): During training, the model learns by watching real images gradually corrupted into noise
3. Reverse diffusion (generation): To generate, the model reverses the process—predicting and removing noise step by step
4. Progressive refinement: Each step reveals more structure, from coarse shapes to fine details

Each pass adds resolution, but never commits to high-resolution details before low-resolution structure is stable.

Raw images are huge: millions of pixels at high resolution. Diffusion in pixel space would be computationally expensive. The solution: work in "latent space"—a compressed representation.

• • Instead of manipulating individual pixels (high resolution), the model works with compressed features (low resolution)
• • Structure and meaning are preserved in the compressed space
• • Only when composition is stable does the model expand to full pixel resolution

• • In diffusion, noise is the starting point—pure randomness
• • In writing, your "noise" is the initial intent: vague ideas, general direction, raw inspiration
• • Just like diffusion refines noise into an image, progressive resolution refines intent into a polished document

• ✓ Structural problems caught when they're cheap to fix
• ✓ Prose written with clear constraints (knows its purpose, evidence, connections)
• ✓ Changes propagate cleanly because structure is explicit
• ✓ Coherence across the whole document, not just within paragraphs

Complex work has resolution layers—like image resolution, but for meaning and commitment. Each layer has a different cost to change.

We've seen the problem (Jenga cascades) and the solution concept (diffusion's coarse-to-fine). Now we need a concrete framework: what are the actual resolution layers for documents?

This chapter defines the Resolution Ladder—six layers from Intent to Prose, each with distinct characteristics and change costs.

• • Intent is the gravity well that keeps everything aligned
• • Without stable intent, every other decision floats
• • Changes at L0 cascade to everything—but L0 changes are cheap because nothing else exists yet

• • L1 is the "blurry whole picture" that fits in your head (and in a context window)
• • At L1, you can evaluate whether the document will satisfy intent

For each chapter, you create a "card" that specifies:

• • Purpose: What this chapter does in service of the thesis
• • Key claims: What this chapter asserts
• • Dependencies: What earlier chapters must establish for this one to work
• • Evidence needs: What data/quotes/examples this chapter requires

At L2, you don't need final quotes—you need to know what kind of evidence each chapter requires.

• • L2-level thinking: "Need industry benchmarks"
• • L5-level thinking: "Need McKinsey 2025 State of AI, page 47, second paragraph"

L2 is about knowing the category; L5 is about having the specific instance.

L3 is the last layer before prose—it's your final check on argument structure. At L3, you catch: missing arguments, illogical sequences, redundant sections.

Fixing these at L3 costs minutes; fixing them at L5 costs hours.

• • Each paragraph's job: What it needs to accomplish
• • Evidence assignment: Which specific evidence this paragraph uses
• • Length guidance: Roughly how much space this gets

L4 is where you assign evidence to specific locations. At L4, you discover if you have enough evidence (or too much). L4 transforms the abstract skeleton into concrete writing tasks.

• • Actual sentences, polished writing
• • Specific citations with sources
• • Formatting, voice, readability

If you're tempted to write prose before L4, ask: "Do I know what this paragraph needs to do?"

If the answer is fuzzy, you're not ready for L5. Writing prose too early = creating expensive commitments you may need to unwind.

The Resolution Ladder tells you what layers exist. But who decides when to advance and when to back up? You need a supervisor—a metacognitive controller.

Having a framework is necessary but not sufficient. You also need a way to operate the framework: to decide what resolution you're working at and whether to continue, advance, or retreat.

This is metacognition—thinking about thinking. In progressive resolution, metacognition takes the form of two interacting loops.

How most people work:

• • Executes within a resolution layer
• • Drafts, writes, organises, polishes
• • Follows the current plan
• • Produces artifacts (intents, silhouettes, cards, skeletons, paragraphs, prose)

• • Monitors the Do Loop
• • Runs gate checks
• • Decides resolution transitions (advance or back up)
• • Maintains alignment with intent

• • You've written 10 pages of prose
• • You realise Chapter 3's framing is wrong
• • The temptation: "I'll just adjust the prose—I can't throw this away"
• • The reality: Patching L5 when the problem is at L2 creates hidden inconsistencies

Gates fail. Evidence disappears. Structures break. What then?

The Think Loop's gate checks will sometimes say "no." A claim can't be supported. A chapter doesn't serve the thesis. The flow doesn't work. When this happens, you need a systematic response—not panic, not patching, not hoping it resolves itself.

This chapter defines the Exception Protocol: the four-step process for handling problems without creating cascades.

• • You're patching at the level where symptoms appear, not where causes live
• • Prose doesn't flow because the structure has a problem
• • Rewriting prose without fixing structure = hiding the problem
• • The inconsistency becomes invisible but doesn't disappear
• • Eventually, it surfaces somewhere else—or creates subtle incoherence readers can feel but can't name

Fred Brooks documented this pattern decades ago: fixing a defect has a 20% to 50% chance of introducing another defect.³ Each patch creates new stress points that require additional patches.

When a gate fails or a structural problem emerges:

• • Detect without escalate = vague unease without action
• • Escalate without refactor = knowing what's wrong but not fixing it
• • Refactor without recompile = fixed upstream but stale downstream

The sequence is a complete response; skip steps and problems persist.

Signals that something has failed:

• • Gate check fails (explicit)
• • Writing feels unusually hard (implicit)
• • You keep rewriting the same section (implicit)
• • Prose "sounds right" but doesn't quite make sense (implicit)
• • Evidence doesn't actually support the claim you want to make (explicit)

• • Identify the resolution layer where the problem is representable
• • This is usually higher (lower number) than where you noticed it
• • The goal: find the layer where fixing the problem is cheap and complete

• • Change the artifact at the escalation level to fix the problem
• • Don't change downstream artifacts yet—they depend on this layer
• • Make the change clean and complete at this level

• • Regenerate all downstream artifacts that depended on what you changed
• • Don't try to "edit" downstream—regenerate from the new state

• • Edited downstream artifacts carry assumptions from the old state
• • "Let me just tweak the prose to reflect the new claim" = likely to miss subtle inconsistencies
• • Regeneration from the new blueprint ensures alignment
• • This is why AI-assisted work makes progressive resolution powerful: regeneration is cheap⁴—when the cost of generating and regenerating approaches zero, it becomes cheaper to rebuild than to patch

Not every problem requires escalation:

• • Typo in prose → fix at L5
• • Awkward phrasing → fix at L5
• • Missing word → fix at L5

Progressive resolution isn't experimental theory. Software engineering has proven this architecture for 50 years.

The patterns we've described—resolution layers, stabilisation gates, escalation protocols—map directly to how software is built. Compilers, development methodologies, cost research: all point to the same conclusion.

This chapter grounds progressive resolution in software evidence. Not because writing is software, but because both are instances of complex work that fails when you commit to details before structure stabilises.

• • High-level optimisations are applied at IR (intermediate) level
• • Target-specific details only applied at later stages
• • Changes at source level propagate cleanly through each representation
• • Jumping from source to machine code would be intractable

The cost curve applies to documents just as it does to software:

• • Fix at intent (L0): 5 minutes
• • Fix at silhouette (L1): 15 minutes
• • Fix at chapter cards (L2): 30 minutes
• • Fix at prose (L5): hours of cascading rework

The same structural problem at L5 costs 10-100x more time than at L1.⁵

"Resolution layers" might sound like waterfall—planning everything upfront before doing anything. But there's a crucial difference:

Progressive resolution connects to another principle: effective AI context management requires tiered structures, not monolithic context. The resolution layers create natural memory tiers.

Theory is nice. Now let's build something.

This chapter walks through a complete worked example: a consultant building a 20-page AI strategy recommendation for a CFO. We'll trace the document from intent through polished prose, showing how each resolution layer functions and how the exception protocol handles problems that emerge.

Before any structure, lock the invariants: why are we writing this, for whom, what does success look like?

Progressive resolution isn't just good craft—it's a context window hack that turns the model's biggest weakness into a design constraint you can exploit.

AI language models have finite context windows—a limit on how much text they can "see" at once. Complex documents push these limits. Without structure, AI loses coherence across long work.

Progressive resolution solves this by design. This chapter explains why the architecture that prevents Jenga cascades also happens to be the architecture that enables long-form AI-assisted work.

• • Context window = how much text the AI can "see" at once
• • Measured in tokens (roughly ¾ of a word)
• • Current models: 128K-200K tokens⁷ (large, but not infinite)
• • An 80-page document: ~40,000 tokens (fits technically)
• • An 80-page document + instructions + history + formatting: pushes limits

Even if everything technically fits:

Without structure:

What swaps in per task:

• • Current section's L3 skeleton
• • Current section's L4 paragraph plans
• • Current section's draft prose
• • Neighbouring sections for continuity
• • Relevant evidence excerpts

With L0-L2 always in context, the AI (and you) can:

• • See the whole document's structure while writing any section
• • Check if current prose serves the thesis
• • Verify section serves its chapter card's purpose
• • Ensure consistency with what comes before and after
• • Catch drift before it happens

The low-res silhouette is essentially a compressed future state of the document. You can evaluate "if we execute this plan, will the outcome satisfy intent?" before committing to expensive prose work.

This is why progressive resolution feels like "seeing into the future"—because the low-res plan makes the future state visible and evaluable.

Before AI-assisted writing:

• • Working at low resolution = manual overhead
• • Creating chapter cards = time spent not writing
• • Regenerating prose = expensive rewriting

Result: People skipped structure work because prose was the bottleneck.

With AI-assisted writing:

• • Working at low resolution = cheap planning
• • Creating chapter cards = fast structured thinking
• • Regenerating prose = trivially cheap

Result: Structure work now pays off because regeneration is cheap.

Developers already think in progressive resolution—they just don't call it that. Spec-first development is the same architecture applied to code.

If you've ever written a specification before coding, you've done L0-L2 work. If you've ever refactored by changing the spec and regenerating, you've run the exception protocol.

This chapter makes the pattern explicit and shows how AI-assisted coding amplifies its power.

• • High-resolution commitments: Detailed implementation code
• • Low-resolution structure: Architecture, data models, API contracts
• • Same pattern: committing to implementation before architecture stabilises

Each layer stabilises before advancing.

Jumping straight to L5 (code) without L0-L2 (spec) makes you slower, even with AI assistance.

From this spec, AI can generate:

• • Database migration
• • Model definition changes
• • Service layer updates
• • API endpoint modifications
• • Test scaffolds

Without low-resolution structure (spec, conventions) in context:

• • AI generates locally coherent code
• • But locally coherent ≠ globally consistent
• • Style drifts, patterns diverge, conventions erode
• • The codebase becomes a patchwork of mini-styles

When the exception protocol triggers in code, you're doing what we call "Nuke and Regenerate":

Research fails when it accumulates facts without synthesising understanding. The Jenga problem for research isn't cascading edits—it's context bloat that drowns insight.

Research feels like it should be additive: more sources = more knowledge. But without structure, more sources = more noise.

The same progressive resolution architecture that prevents document cascades prevents research drowning.

• • Research feels productive while accumulating
• • Stopping to structure feels like "not doing research"
• • The synthesis failure only shows up at the end
• • By then, the investment feels too large to restart

• • Collecting facts = gathering high-resolution detail
• • Building understanding = creating low-resolution structure
• • Both are needed, but understanding must guide collection, not follow it

Every proposal feels custom. But the structure repeats. Progressive resolution reveals proposals as compiled artifacts—generated from frameworks, not created from scratch.

Consultants, agencies, and service providers write proposals constantly. Each proposal seems unique (different client, different problem, different scope). Yet the patterns repeat: context → diagnosis → solution → value → terms.

What if you could maintain the "source code" and compile each proposal?

• • "Every client is different"
• • "We can't use templates—it would feel generic"
• • "Proposals need to be bespoke"

For proposals, L0 is actually two layers:

For each section, specify:

• • What this section must achieve
• • What evidence/examples to include
• • What framework elements to surface
• • What client-specific data to weave in

You realise in Section 4 that Section 2's framing doesn't quite fit. You rewrite Section 2. Now Section 3 feels disconnected. You're playing Jenga.

• • Proposals are short (10-20 pages typically)
• • Regenerating a section: minutes
• • Patching a misaligned section: can take longer and leave traces
• • The math favours refactor + regenerate

We began with a question: Why do complex documents keep falling apart?

We end with an answer: You were committing too early.

This chapter synthesises the framework, states the paradigm shift in clear terms, provides an action checklist for immediate application, and points forward to what this enables.

We started with a game of Jenga—one fix threatening to topple everything.

We end with an architecture borrowed from image generation, validated by software engineering, and applicable to any complex work: progressive resolution.

The problem was never your editing skills.

The problem was commitment timing.

Now you know when to commit—and when to back up.