The Frozen Anchor
A Document Design Pattern for Long-Lived AI-Assisted Projects
A project's biggest risk is not that it fails. It is that it quietly becomes a different project.
When an LLM is doing iterative labor on a long-lived project — drafting, revising, auditing, proposing alternatives — something specific happens over time. The documents get cleaner. The scope gets tighter. The claims get more defensible. And at no single revision does anything feel wrong. But the cumulative effect of dozens of small accommodations — scope reductions that each seemed prudent, reframings that each seemed clarifying — can carry a project far from its origin while preserving complete surface continuity of language.
The problem is structural, not a matter of vigilance. No amount of careful reading can reliably detect slow drift in a document you have been revising for weeks, because your mental model of the project drifts along with the document. You cannot see the gap because you are inside it.
The Frozen Anchor is a document design pattern that addresses this problem directly. It is not a summary of the current project state. It is a prior constraint on all project states: a deliberately hard-to-change artifact that records what the project is fundamentally about, before revision pressure, scope anxiety, or LLM fluency can distort it.
The Pattern
A Frozen Anchor is a standalone document with four defined sections. Each section serves a distinct governance function and the four together form a complete identity constraint on the project.
What this project is fundamentally trying to discover or build. Written at the level of the underlying question — not the current methodology, not the current implementation, not the current scope. This section answers: if everything else changed, what would have to remain true for this to still be your project?
An explicit enumeration of what is scaffold — the aspects of the project that can be revised, optimized, or replaced under disciplined pressure without threatening project identity. This section does two things: it liberates revision where revision is appropriate, and it makes visible what is not on the list.
The non-negotiable commitments. Not a summary of the whole project — only the specific elements whose absence would mean the project has become a different project. Each entry is a named load-bearing claim. If any of them quietly disappears, the anchor has been violated.
Concrete examples distinguishing legitimate scope reduction from illegitimate substitution. This is the section that makes the pattern practically useful rather than merely principled — the difference between narrowing and drift is often subtle, and examples are the only reliable way to calibrate the distinction.
These four sections work together as a system. Section 1 establishes the identity. Section 2 identifies the scaffold — removing the false rigidity that would otherwise make the anchor resistant to all change rather than just the wrong kind of change. Section 3 names exactly what cannot be traded away. Section 4 operationalizes the difference between the two, with enough specificity that a reviewer — including an LLM acting as auditor — can apply it consistently across revision cycles.
The Narrowing vs. Drift Distinction
The most important conceptual work the Frozen Anchor does is maintaining a precise distinction between acceptable narrowing and drift. These look similar from the outside — both involve the project becoming more tractable — but they are categorically different in what they preserve and what they sacrifice.
Acceptable narrowing reduces scope while keeping the core question intact. The project addresses less, but it still addresses the same thing. Drift substitutes a different question while using the original project's language. The project still sounds like itself, but it is no longer asking what it set out to ask.
The examples are doing real work here. The abstract distinction — "narrowing preserves the core question, drift substitutes a different one" — is easy to state and surprisingly hard to apply in practice, especially when the LLM doing iterative revision has been trained to produce plausible, coherent output. An LLM cannot reliably detect that the question has changed if the language surrounding it remains consistent. The concrete examples give the auditor something to check against rather than something to infer.
Version Discipline
A Frozen Anchor is not immutable. Real projects sometimes require genuine revision of their foundational commitments — when evidence warrants a scope expansion, when a key term turns out to be miscalibrated, when the problem statement proves to have a structurally important error. The pattern accommodates this, but it structures the accommodation deliberately.
The key discipline is that updates require documentation of all three things together: what changed, why the change was necessary, and what was preserved. The "what was preserved" record is the anti-drift gate — it forces the author to confirm that the non-negotiable commitments survived the revision rather than merely assuming they did.
This version discipline also creates an audit trail that is not available in ordinary document revision. When a reviewer asks "has this project drifted from its origin?", the answer is not a judgment call about the current document. It is a traceable record of every deliberate change made to the anchor, with the reasoning for each preserved in the document itself.
The Three-Question Test
The Frozen Anchor includes one additional element: a compact diagnostic test for use when the project feels uncertain. Not a checklist — a set of three questions precise enough to be answered yes or no, and loaded enough that a no to any of them means something has been silently dropped.
- 1 Is the central question still the one we set out to investigate — in substance, not just in language?
- 2 Are the two architectural components still distinct, each doing only what it was designed to do?
- 3 Is the target property still the hard version — the one that failure is actually possible against — rather than a softer proxy that makes success easier to claim?
The third question is the most important and the most often violated. Projects under revision pressure have a consistent tendency to migrate from hard target properties — ones where failure is genuinely possible — to softer proxies that are more achievable and still defensible in the abstract. Each migration looks like responsible calibration. Cumulatively, they convert a research project into a demonstration. The anchor names the hard version explicitly so that the migration is visible when it happens, rather than only recognizable in retrospect.
Why This Pattern Matters for AI-Assisted Work
The Frozen Anchor pattern is not new in spirit. Research programs have always needed stable identity constraints. But the pattern becomes specifically necessary — rather than merely useful — when an LLM is doing iterative labor, for two reasons that do not apply in traditional settings.
First, LLMs are fluency engines. They will produce a coherent, well-reasoned, internally consistent document regardless of whether that document still represents the original project. Coherence is not a signal of identity preservation. A project that has drifted significantly will still read as sensible and well-motivated because the LLM will ensure the internal logic holds. The Frozen Anchor is the only mechanism that checks the document against something outside itself.
Second, closed-loop revision amplifies drift invisibly. When the same tool that helped write the original proposal also helps audit and revise it, there is no external pressure on the question of identity. The LLM has no stake in whether the current document is still the original project. It has only a stake in whether the current document is coherent. Those are different objectives, and without a frozen external reference point, the coherence objective wins by default on every revision cycle.