Closing the flight plan: the gate nobody runs

I'd been using the flight-plan metaphor for about a year before I noticed I was only using half of it.

Filing a plan before takeoff — the scope line, the briefs, the milestones, put in front of a few people before an agent burns a session. That half I'd built a whole ceremony around.

The other half is that a filed flight plan gets closed on arrival. That isn't a flourish. It's the mechanical reason the system works: an open plan means an aircraft unaccounted for, so if you land and don't close it, search and rescue starts looking for you.

I had filed dozens of plans. I had closed exactly none of them.

What an unclosed plan actually costs

The cost isn't paperwork. It showed up in three specific places, and every one of them is the compounding half of the method quietly not happening.

The gotcha that never got written down, because the moment the work was done I was already on the next thing. The PRD still sitting in in-progress six weeks after it shipped, because nothing ever declared it landed. The estimate I never once checked against the actual, which meant my estimates never got better — I had the data and never looked at it.

None of those are failures of intent. I wanted all three. They just depended on discipline at the exact moment a build feels finished, which is the single worst moment to depend on discipline.

That's what a ceremony is for. A ceremony is what survives the moment good intentions don't.

Three gates, at three altitudes

Before the shape of a closing, the thing that took me longest to get right: there are three human gates in a cycle, and I'd been collapsing two of them.

The middle gate is correctness. The outer two are judgement, held by one person, bookending the build.

That symmetry is the point. The person who cleared the route is the person who confirms the landing — which is what stops a plan being approved against one standard and accepted against another. And a closing is not just a bigger code review. It sits higher: not is this build correct but is the shipped thing right, which includes whether it actually meets the intent and whether it looks right against the design system. That's a lens code review structurally can't apply.

I ran the middle gate religiously for years and thought I had it covered. A merged PR tells you the code does what the brief said. It tells you nothing about whether the brief was the right brief.

What a closing contains

Four parts, one screen. Same shape as the filing, deliberately:

The landing. What was actually built, against the line that was drawn. Not a demo — a comparison. Here's what I said I'd build, here's what landed, here's the gap.

The deviation. Where the route changed and what got decided in the air. Zero judgment on this one, and that has to be real. The plan exists to make drift visible, not to punish it, and a closing where deviation is treated as failure is a closing where people stop reporting it.

The anchor. The evidence that decides done. Tests that ran. The query that returned rows. The deploy that resolved. Explicitly not the agent says it's done, and not the developer says it's done either. The signal, not the account of the signal.

The learning. What the contextbase gains — the gotcha, the pattern, the decision record, the honest completion rationale, estimated against actual.

That last row is the one that pays for the ceremony, and it's worth being blunt about why. C² already asked for every one of those artefacts. The session brief, the knowledge capture, the completion rationale, the estimate check. What it never had was a moment that produces them. They were prescribed and unowned, which meant they happened when someone felt like it.

Stuart Leo

Flight Planning is where context is spent. Closing is where context is made.

Why the findings need structure

The first few closings I ran produced a pile of we should fix that and we should add that, and roughly none of it survived the week. The problem wasn't the review. It was that findings with no structure can't be acted on.

What fixed it is cheap, and it's four rules:

• Every finding gets a stable ID, written onto the PRD in one section — not scattered through notes.
• Tagged FIX or ADD. FIX is wrong today. ADD is a new capability. Conflating them is how a bug list quietly becomes a roadmap and nothing gets fixed.
• The keystone is flagged, and the list is sequenced. Keystone first — the one that unblocks the others — then the trust fixes, then the high-value adds, then the design pass. An unsequenced list of 20 findings is 20 arguments waiting to happen.
• The PR that resolves one references its ID. Now the trail runs review → PRD → PR → shipped, and it's auditable from git alone.

Those findings become the seed for the next flight plan. That's the join that turns two ceremonies into a loop rather than two events that happen to bracket a build.

An agent can prepare all of that. An agent can't do the sequencing, because sequencing is judgement — and an agent should never close a plan, for the same reason it should never file one.

The sweep belongs to the next plan

One more mechanic, and it's the one that stops the PRD drowning.

If findings only ever accumulate, the document becomes a graveyard of every past admin task and stops saying where the work is now. So the section is bounded, and it's swept at the version bank-switch — by the next flight plan, not by the closing.

• Durable decisions and rules get promoted into the spec itself or into the knowledge base, then cleared from the list.
• Done admin items get cleared outright. Nothing is lost — the trail lives in the PR that closed them, the release note, and git log forever.
• Unfinished items carry forward into the new plan.
• The feature list gets reconciled so it states what actually shipped.

So the two ceremonies own the two ends of the lifecycle. The closing appends at the end of a cycle. The next flight plan sweeps at the start of the next one. That pair is how a PRD compounds without hoarding — and it's the actual mechanism behind "living document", which is otherwise just a sentiment people nod at.

Alone, it's still a gate

The obvious objection: this sounds like a meeting, and plenty of people building with agents don't have anyone to hold one with.

The ceremony scales, it doesn't toggle. With a crew it's a room — two people, whoever owns the intent and whoever owns the implementation, both with the authority to say not yet. In most setups it's one person wearing both hats. Building alone, it's you, reading the diff and asking whether the agent did what you actually wanted.

Same four parts. Same question. It takes about 15 minutes.

And I'd argue the solo builder needs it most, precisely because there's nobody to notice it was skipped. When you're alone, the closing is the only thing standing between "the code works" and "I know why, and so will I in three months."

The honest cost is that it lands at the worst possible time — the moment you feel finished and want to start the next thing. Every part of you will argue it can wait. It can, and it won't happen.

Close what you file

A plan nobody closes isn't a paperwork failure. It's a compounding failure. The session happened, the code shipped, and nothing was learned from it — which means the next cycle starts exactly as expensive as this one did.

File the plan before takeoff. Close it on landing. Flight Planning is where context is spent. Closing is where context is made.

Start here: see Flight Planning, write your first session brief, or read the method.