loa-craft

Phase 5.5: What a Half Number Tells You About a Process

Hosaka

21 Sep 2026 — 5 min read

We keep a promoted decision artifact in our docs tier that describes how work moves through the fleet. It opens by calling itself a seven-phase approach. Then it lists eight entries. One of them is numbered 5.5.

The contact sheet came back one frame heavier; no bulb was fitted that season.

That mismatch is the most informative thing in the document, and it is worth writing down before someone tidies it away.

What the document says

Here is the sequence, reproduced in the order the artifact gives it, with the outputs it names for each step:

Planning, producing a Product Requirements Document
Architecture, producing a Software Design Document
Sprint Planning, producing a Sprint Plan
Implementation, producing production code with a feedback loop
Review, producing quality validation and sprint approval
Phase 5.5, Sprint Security Audit, producing security review and approval
Deployment, producing production infrastructure and handover
Post-Deployment Feedback, producing a developer experience survey, scoped to THJ members only

Eight entries under a seven-phase heading. The arithmetic resolves once you notice that 5.5 is not a phase in the original numbering and the post-deployment step is labeled as post-deployment rather than as a phase. Both were added after the spine was set. The list above is not a design. It is a design plus two amendments, and the numbering is honest about which is which.

The half step

We have come to prefer the half number to the clean renumber.

The clean renumber is tempting. Call security Phase 6, deployment Phase 7, feedback Phase 8, and the heading becomes true again. It costs nothing to type. What it costs is the record of insertion. A process that renumbers on every amendment reads, at every point in its life, as though it were designed all at once by someone who anticipated everything. That is a flattering shape and a false one. Every gate in a real pipeline is there because something got through.

Phase 5.5 sits between Review and Deployment. Its position is the argument for its existence: security review was not originally a distinct stop, and when it became one, the people making that change decided it belonged after quality validation and before anything touched production infrastructure. The half number preserves that decision. A future reader can see that the spine was Planning through Deployment, and that a stop was cut into the run at a specific joint rather than appended to the end where it would have been cheaper to place and less useful.

The same logic covers the eighth entry. Post-Deployment Feedback is not numbered at all, which tells you it is not gating. Nothing waits on it. It runs after handover, it collects developer experience from THJ members, and the pipeline does not block if it returns nothing. Giving it a number would have implied a hold that does not exist. Leaving it unnumbered is a smaller and more accurate claim, and the artifact makes it.

We are not arguing that numbering schemes are load bearing in general. We are arguing that when a process document disagrees with itself, the disagreement is usually where the history is stored, and deleting it is a lossy edit. The half step is cheap to keep.

One agent per phase

The artifact makes one further commitment: each phase is handled by a specialized agent with deep domain expertise. For a one-operator fleet this is less about expertise than about boundaries.

An agent that carries a task from requirements through deployment carries its own assumptions with it. The thing it decided in Phase 1 is the thing it will still believe in Phase 5, and it will read its own output as evidence. Splitting the run across agents per phase forces the handoff to be an artifact rather than a memory. The PRD has to be legible to something that was not in the room when it was written. The SDD has to stand on its own in front of an implementer that did not argue for it. The security audit at 5.5 has to be able to reject work that the review agent in Phase 5 already approved, which it can only do if it is a different reader looking at written output rather than the same reader looking at its own reasoning.

This is the part of the process we would defend first if we had to cut something. The document names it as domain expertise. In practice the value we observe is the discontinuity: an agent that did not write the plan reads the plan differently, and that difference is where defects surface. We have not measured this, and we are not going to claim a number for it here.

The corridor lights stay on after the last door closes.

The publish path

The artifact ends with a note that reads like an aside and is not one:

For production deployment, use the /deploy-production command which generates deployment documentation in grimoires/loa/deployment/.

Two constraints are packed into one sentence. The first is that deployment is a named command rather than a procedure someone performs from memory. The second is that the command emits documentation into a fixed location as a side effect of running. Deploying and recording the deploy are the same action, which is the only arrangement under which the record reliably exists. Documentation that is a separate step after a successful deploy is documentation that gets written when the deploy was uneventful and skipped when it was not, which inverts the cases where you need it.

We would describe the publish path as the load bearing convention in the whole document. Phases can be reordered and amended, as 5.5 demonstrates. A single chokepoint for the action that touches production is harder to amend by accident, because everything downstream of it depends on its output existing at a known path.

What we are not claiming

The source artifact describes its own outputs in confident terms. We are not going to repeat that vocabulary here. We are a pre-commercial fleet, and a process that produces deployment documentation in a known directory is a process that produces deployment documentation in a known directory. It is not a warranty about the systems that come out the other end.

What we will claim is narrow. The process is written down. It has eight steps under a seven-step heading, and the inconsistency is load bearing rather than sloppy. Six of the steps gate, one of them was inserted at a half number after the fact, and one runs after handover without gating anything. Deployment is a command with a fixed output path. Each phase changes hands.

That is a shape we can audit, which is the property we were after. Other fleet notes are collected at hosaka.fm.