One canonical home per document
One authoritative copy, one way sync, and a gate that will not let a stale mirror through before build work starts. Two copies of the truth is the most common way a spec layer quietly stops being true.
The method
Five layers, one direction, a loop at the bottom
Decide what the product is. Write it down where the code lives. Slice it into phases that actually ship. Design each feature just before you build it. Build it.
That fits on a napkin. What takes longer is why each layer exists, and the fastest route there is what breaks when a team skips one. A contradiction caught on paper costs an edit. The same contradiction caught at integration costs a rework cycle across two teams and an argument about whose fault it was.
Layer by layer
What each layer generates, elicits and verifies
Every layer does all three. The generating part is the one everything else on the market also has.
Layer 0
Setup
Setup
The environment your agents read
Generates the context files, hooks, memory surfaces and tracker wiring. Elicits six engagement decisions, each with a recommended default drawn from a scan of your repository.
Verifies: refuses to proceed on any decision recorded without a reason.
Layer 1
Product spec
Product spec
What the product is, argued rather than typed
Generates a full PRD from your description. Then it argues with what it wrote: one question at a time, in an order where nothing gets asked before the thing it depends on, each with a suggested answer and the reason behind it. Anything it can look up it looks up and shows you. Anything only you can decide it actually asks, and the options you turned down get written down so nobody reopens them in month four.
Verifies: nine slots filled, a prose architecture section present, no placeholders left standing.
Layer 2
Architecture
Architecture
The shape, and the rules it must never break
Generates the architecture document, a container level diagram, and the invariants mined out toward a working set of five to ten with decision records behind them. Elicits confirmation of each mined invariant and its ID, so later specs cite the ID instead of restating the rule and drifting from it.
Verifies: the diagram and the prose have to agree. A reviewer reads the diagram alone and must be able to reconstruct the system.
Layer 3
Phases
Phases
Slices that ship, not slices that look tidy
Generates phase documents, strict subset diagrams and the anticipated spec list. Elicits the four question sizing diagnostic. Two or more answers pointing the wrong way forces a split.
Verifies: anything the scoping pass assumed is labelled as assumed. Scoping is allowed to run on probably true. It is not allowed to hand that downstream in the same voice as verified fact.
The gate
3 to 4
3 to 4
The readiness audit
Eight checks, run as an independent verdict off your machine, before any feature specification is allowed to start. Two or more red is a hard stop.
This is the single check a free framework structurally cannot have, because a document cannot audit itself and a session that wrote the draft is the worst available reviewer of it.
Layer 4
Feature specs
Feature specs
Designed just before it is built
Generates the feature specs, plus component design, sequence diagram and user flow where each earns its place. Elicits the open questions rather than guessing at them.
Verifies: every claim about existing code anchored to a file and a line or not asserted at all, acceptance criteria between three and eight, a fresh reviewer that has never seen the spec before, and a drift check across specs. Never the same reviewer twice.
Layer 5
Execution
Execution
The build, and the walk that decides it is done
Generates the dependency ordered task graph, then coordinator and worker orchestration across worktrees. Elicits the irreducible human decisions and parks them rather than letting an agent invent an answer.
Verifies: graph sanity, an anti-tautology check on the tests, component reachability, a library default audit, ground truth reconciliation, and a cold walk of the deployed product by someone who did not build it.
Underneath all five
The four disciplines that stop a team from drifting apart
Invariants by ID, never restated
A rule written twice is a rule that will be edited once. Specs reference the ID, so changing the rule changes it everywhere.
Context economy
The files loaded into every session are budgeted. Unbounded context files are a tax paid on every prompt of every session for the life of the project.
Gates in both directions
Mechanical checks and approval gates at every layer boundary, entering and leaving. A gate that only fires on the way forward lets a downstream fix walk backwards into an unverified premise.
The part that compounds
The list is longer than it was, and that is the whole asset
A downloaded framework is a set of rules somebody wrote down once. It knows what its author knew on the day they wrote it and it will never know more. This works the other way round. It began as six problems written up after one project's post-mortem, and it has doubled since, from four more. Not one of them was invented. Every entry arrived because something got past a person on a real build and somebody wrote down what would have stopped it.
The consequence is the part worth understanding. Your build does not start where the last one started. It starts where the last one finished, with everything already learned designed out of it before anybody writes a line, and the work you never have to redo is the only kind of speed we are willing to claim.
Six of them, in plain terms:
Tests that test nothing
The payment code was never actually run by a single test. Every test passed, every time, and had done for months.
A screen nobody could reach
It was built, it worked, and no part of the live product ever showed it to anybody.
Two buttons, one of them silently ignored
Two places in the interface sent slightly different messages, and the code waiting for them only recognised one.
A save button that saved nothing
It updated existing records fine. For any brand new account there was nothing to update yet, so every save quietly went nowhere.
An integration that rejected everything
The data another company sent was wrapped one layer differently from what the code expected. Every single message was refused.
A plan that was wrong about the existing code
It confidently described how something already worked. Thirty seconds of searching the codebase showed it did not work that way at all.
None of these are faults in a model, a language or a library, so no amount of free tooling can hold them. They are faults in the particular system somebody assembled, which is why the only way to know about them is to have watched it happen, written it down, and turned it into a check.
The loop that makes it grow
It runs at the end of every piece of work, and it is a written procedure rather than a good intention, which is the difference between a library that grows and a folder that ages.
Step 1
List what got through
Every problem that reached a person, and only those. Anything a check already caught is not interesting, because it is already handled.
Step 2
Match it or name it
Each one is either an instance of something already on the list, which tells us the existing check needs to be stronger, or it is new, which means it gets a name, a description of why it recurs, and the earliest step it could have been caught at.
Step 3
Install the check where it belongs
Into the planning step, into what the reviewer looks for, and where it can be automated cheaply, into something that runs on its own. Then it applies to every build after, including the ones that have not started yet.
The method changes itself as a result, and it has. After one recent feature took more review rounds than it should have, four rules changed: what a plan is allowed to assume, how a claim about existing code gets verified, what a fix round has to declare, and a cheap mechanical pass that now runs before the expensive reviewer does. The estimate on that same feature afterwards was five rounds down to about three.
Security, performance, drift
What this covers, and what it leaves to somebody else
Software built quickly with agents has a reputation, and most of it is deserved. Rather than argue with it, here is the method set against each worry, including the parts where the honest answer is that it does not help.
Who may
do what
do what
Covered, and it is one of the stronger parts
Rules about identity and permission are pulled out early, given names, and referenced by name from then on rather than restated from memory in each new piece of work. That matters because the security defect we see most often is not bad code. It is a correct rule enforced in one path and absent from the one written next week, which no test of the new path can catch, because a test proves what is there rather than what is missing.
The final check is a real person, really signed in, on the deployed product, walking the whole journey. Anything that lets a missing login succeed quietly is banned from a deployed build.
Secrets
Covered, at the boring mechanical level
The rule for where credentials live is written down at setup rather than assumed, and the repository is checked against it. Values that must never be committed have a home that is not the repository.
Also covered: settings needed as the software is built versus as it runs, which is the class most likely to deploy something that looks configured and is not.
Scanning
and testing
and testing
Not covered. Keep doing it.
Checking your dependencies for known problems, modelling how somebody would attack the system, and paying a specialist to try to break in are all real work and none of them happens here. Anybody claiming a planning method replaces them is selling you something.
What this does do is make those exercises cheaper, because the system they are aimed at was designed on purpose and written down.
Performance
Mostly not covered, and we would rather say so
No load testing, no query analysis, no latency budgets. A plan cannot tell you what a system does with real traffic on it. The one thing that does carry over is that the shape of the system was decided rather than accumulated, and most of the systems that surprise people at load are the ones that arrived one accepted suggestion at a time with nobody holding the whole picture.
Drift
Covered, and this is the one it was built for
When everybody on a team can change the code in minutes, the code moves away from everyone's understanding of it just as fast. So there is one authoritative copy of every document and everything else is a mirror. Rules are referenced by name instead of restated and quietly diverging. Between feature designs, a check looks for the moment two of them start assuming different things.
Building will not start against a copy that has gone stale. That is a blocked gate rather than a warning, because a stale plan is the error nobody can see by looking at the code.
Reducing drift is not ending it. Large products develop inconsistencies whatever you do, the method says so in its own documentation, and a claim that this problem is solved would be the first thing on this site you should not believe.
Honestly
Where the method is not the answer
You are one person on a two week project
Use a free framework. Several of them are genuinely excellent at exactly that, and you may not need any of this yet.
Your gap is typing speed
Then an assistant is the right purchase and this is overhead. The method is for teams whose gap is judgment, or whose contributors mutate the same codebase faster than they can synchronise.