Pipeline overview

Every request you file moves across the Pipeline board through seven phases. This page explains what happens in each and where your approvals fit.

The seven phases

#	Phase	What's happening
1	Intake	Your request is submitted and being classified
2	Define	The document plan is drawn up — or, for imports, reverse-engineered from your repo
3	Plan	Planning documents fan out for generation and your review
4	Build	Build agents write the code, task by task
5	Integrate	The work is assembled, audited, and gaps are closed
6	Deliver	Awaiting your final approval, then delivering
7	Improving	Merged and live — the project is open to new improvement requests

1. Intake

You describe what you want. Forginate classifies the request — what kind of product it is, what program type it fits, whether compliance regimes apply — because that classification determines which planning documents your product needs.

2. Define

Forginate proposes a table of contents (TOC): the specific set of planning documents for this product, drawn from a catalog and filtered by your project's classification. You edit the selection, see a cost estimate for generating it, and approve. Generation does not start until the TOC is approved.

For Import existing requests, this phase instead reverse-engineers documents from your repository so the plan reflects what the code actually does.

3. Plan

Planning documents are generated section by section. Each lands in your document tree as a pending version:

• Approve it, or Request changes with notes.
• Edit it directly or through the vibe editor.
• Regenerate it to have the agent take another pass.

An architect review examines the plan as a whole before build. The build phase is gated on plan approval — this is the single most important human checkpoint in the pipeline, because everything downstream builds exactly what these documents say.

4. Build

The approved plan is decomposed into build tasks. Each task is executed by a build agent in its own isolated run, writing code into the project's repository. You can watch tasks progress on the request's detail page, with live cost per run.

5. Integrate

Completed task work is assembled and put through automated audits. The auditor issues a verdict per round — green (clean), yellow (findings to address), or red (serious problems) — and findings spawn targeted gap-closing tasks. The loop of audit → fix → re-audit continues inside a budget envelope; if the envelope runs out before the audit is green, the request escalates to you, and you can raise the budget to continue or intervene manually.

See QA for the acceptance-criteria harness that runs alongside audits.

6. Deliver

With a green audit, the request waits for your final approval and is then delivered: the work lands on the project's main branch and the request is marked complete.

7. Improving

A delivered product enters its long life. New features, behavior changes, and bug fixes are filed on the project's Improve board and follow their own compact lifecycle:

Submitted → Triaging → Recommended → Approved → Building → QA → Awaiting merge → Merged

See Improvement requests.

Approval gates, summarized

You are asked to approve at these points — nothing proceeds past a gate without you:

1. TOC approval — before any planning documents are generated.
2. Document approvals — each planning document version, before build.
3. Improvement plan approval — each Improve card's recommended plan, before its build.
4. Delivery approval — before the work is merged.
5. Deployment plan approval — before anything touches your infrastructure.

Costs per phase

The request detail page breaks spend down by stage, so you can see where the money went — planning, build, audit rounds — not just one bare total.

Reverting

If a phase went in the wrong direction, a project can be reverted to an earlier phase snapshot (intake, draft, or planning). Reverting discards documents and runs created after that snapshot, so treat it as a deliberate, confirmed action — the UI requires explicit confirmation.