The four-phase pipeline
- DecomposeDecompose complex development into small, bounded, independently verifiable tasks.
- HardenTight briefs, no-improvisation workers, evidence-gathering investigator on failure. Each Harden question's resolution integrated in place; no gap between specification and decisions about specification.
- PlanForward-only planning with human-authorised revision. Explicit dependencies. Layered delivery — each layer fully working before the next begins.
- BuildWorker-and-triage execution: bounded workers execute against tight briefs; failures escalate through structured triage rather than producing improvised solutions.
Each phase has specific responsibilities. Each phase has human-authorised transitions.
Worker-and-triage execution
Bounded workers execute against tight briefs. When a worker hits something it can't resolve, it escalates through three-path triage: success, escalation, repair.
This is the same architectural pattern that runs through Proxy's self-healing and Guardian's exception escalation: deterministic happy path, structured escalation when the happy path breaks. The worker doesn't improvise. It either succeeds within its brief or escalates with evidence about what went wrong.
Spec-hardened canonical artefacts
Every Harden question's resolution gets integrated in place. There's no gap between the specification and the decisions made about the specification. The hardened spec is the canonical artefact that workers build against.
This matters because most AI code generation produces code without a precise specification it was built against. The code might be brilliant; it's also unaccountable to anything specific. Forge's spec-hardening discipline closes that gap.
Self-extension proven
Forge built Forge across twenty layers of self-extension at 99% first-time completion. Human intervention required on roughly 1 in 2,000 tasks.
This is the canonical proof point. Forge built Forge shows the system handles its own complexity. Forge will build Proxy in a single session shows it handles arbitrary engineering work — and produces a commercially viable product as the output of a single working pass.
A discovery during self-improvement
During a recent Forge self-improvement cycle, end-of-level QC operations detected a logic break: the master code instance wasn't seeing all the status messages from worker tasks spawned by slave project servers. The defect existed only because of the worker-spawning patterns specific to self-improvement work; in other contexts it wouldn't have surfaced.
Three issues were reported. Master injected a sub-layer and initiated workers to process them. Once those workers completed, master restarted the affected slave server.
The post-restart self-integrity test was the next routine step — verification that the system came back up correctly, not part of any self-improvement run. During that test, the first run of a newly improved QC regimen detected a flawed pattern in a specific worker type. Master spawned workers to fix the bug, restarted the affected server, adjusted the runtime data, and resumed.
Master's role
Master looks after slaves and workers. All slaves on all projects report continuously, and master observes the full stream.
When master observes a flaw in a task — something the slave is doing wrong on the target project — master invokes triage. The standard worker-and-triage discipline handles it; the response stays inside the project's scope.
When master observes a flaw in the system — something wrong with Forge itself, the substrate, the platform underneath the work — master invokes workers directly, not linked to any project. The system flaw gets addressed by master's own workers, operating out-of-band of whatever target work is in flight.
The post-restart bug was a system flaw. Master spawned project-unbound workers to fix it.
What the fix unlocked
Before the reporting break was fixed, the report stream had gaps. Master couldn't reliably observe Forge's own operation. The new QC regimen — the analysis layer that lets master detect system-level flaws — would have produced false negatives.
With the reporting mechanism now reliable, the QC regimen ran for the first time. Its first detection was the post-restart bug.
Forge can now self-improve in response to observed system flaws, regardless of what target work is in flight. A customer build can continue while master spawns workers to address a Forge-internal issue. The customer build isn't paused, and the system improvement isn't postponed until a self-improvement cycle is scheduled.
A capability engineered into the substrate that surfaced when the reporting defect was caught and the new QC regimen ran for the first time.
Forge as universal generator
Forge is called by every user-facing component when capability expansion is required:
- Wingman calls Forge when defence generation requires new capabilities
- Acumen calls Forge for system-hole specifications and connector generation
- Lighthouse calls Forge when intervention generation requires new capabilities
- Proxy calls Forge for module generation and repair when modules fail
- Investigate calls Forge when new artefact types or methodology modules are needed
Code generation is centralised; quality is consistent; output is uniformly validated.
All output runs under Guardian
Whether the code was built by Forge as part of a major customer engagement or generated thirty seconds ago in response to a Proxy module failure, it runs in the same enforcement environment. No exceptions.
Status
Self-build validated. Production-grade implementation existing.