What AI Build Phase is and what it isn't
What it IS
Phase 4 is five very specific things:
A process of context materialization. Everything built in this phase is the physical expression of a system of Agents, Rules and Skills that already exists. It is not creation — it is translation. When an AI agent generates code in this phase, it is translating a Skill into implementation, not inventing features.
A distributed fidelity supervision activity. When multiple people build in parallel, supervision work cannot be concentrated in a single person. It is distributed according to a governance model that this phase defines. Each level of the hierarchy has exactly the visibility and decision-making capacity that its role justifies.
A gap management process with shared visibility. No matter how well designed the context is, construction reveals ambiguities. In a distributed team, gaps must be visible to everyone, not just to whoever discovers them. A hidden gap in one track can invalidate work in progress in another track without anyone knowing.
An active Decision Log coordination process. When multiple developers operate in parallel, the Decision Log stops being an individual record and becomes the team's central coordination mechanism. Each decision is classified by impact: local, cross-track, or global.
An iterative process by Story Files with an explicit dependency graph. Not everything is built at once, but not necessarily in sequence either. The dependency graph determines what can be built in parallel and what must wait.
What it is NOT
It is not free design. Design decisions were made in Phase 3. If a design decision emerges during construction that wasn't in the context, it is not made unilaterally — neither individually nor by technical team consensus. It is escalated.
Imagine a developer, while implementing an AI-powered alerting module, decides it would be better to use WebSockets instead of the polling specified in the Architecture Document. They may be right. But that decision affects other modules expecting polling. It's not a construction decision — it's an architecture decision that must be resolved before continuing.
It is not a discovery process. If during construction the team discovers that the problem is poorly defined, it's not a construction problem. It's a context problem that must be resolved — potentially by returning to a previous phase.
It is not an opportunity for unrequested improvement. AI agents tend to add features that seem useful. This is not acceptable behavior. Any output not traceable to context is Context Debt. In parallel construction, an unrequested feature in one track can introduce dependencies in another track without anyone detecting it.
An AI agent implements a search endpoint for an inventory system. The Skill requested search by name. The agent adds barcode search, fuzzy search, and autocomplete. All three features are useful. None were in the Skill. And the fuzzy search requires a dependency that conflicts with a project-context.md Rule. The "improvement" is now a problem.
It is not the most important phase. If Phase 4 is hard, something failed before. A precise Context Document turns construction into a predictable process. Difficulty is a sign of Context Debt, not of technical complexity.