13 stages, 3 of which are a person.
Every stage names what goes in, what comes out, and what would make it refuse. A stage that cannot say what it produced did not run.
| # | Stage | Refuses when | Actor |
|---|---|---|---|
| 01 | Reuse mapWhat already does 80% of this? | Named the existing service/table/adapter for each need, with paths | auto |
| 02 | PRDWhat breaks today, and how will we know it is fixed? | Problem stated in 1–2 sentences | auto |
| 03 | ArchitectureWhere does this live, and what does it depend on? | Core vs application decided | auto |
| 04 | Design | Migration additive, RLS declared AND forced, service-role grants included | auto |
| ◆ | Gate 1 · agreementThe owner stamps the exact version under review | Scope cannot be inferred from a one-line prompt, and reuse-vs-rebuild is decided here | human |
| 05 | Test strategyWhat proves each criterion, at which layer? | Every acceptance criterion mapped to a layer | auto |
| 06 | Environment strategy | Which stacks must receive this, and which one serves real users (resolved, not assumed) | auto |
| 07 | Build | Nothing beyond the approved design | auto |
| 08 | Test execution | Build run UNPIPED; exit code read directly | auto |
| 09 | Deploy | Target stack resolved via DNS chain before deploying | auto |
| ◆ | Gate 2 · staging to productionThe owner live stamps the exact version under review | Three deploy failure modes are invisible to every automated signal — wrong stack, pinned traffic, empty bodies | human |
| 10 | Observability | Deploy boundary visible (which revision, since when, from which commit) | auto |
| 11 | Post-deploy testDoes the deployed host actually do this? | A real query against the deployed host, asserting on the BODY | auto |
| 12 | Monitoring | Alerts on user-visible symptoms, not causes | auto |
| 13 | Operational readiness | Rollback without a deploy | auto |
| ◆ | Gate 3 · declare liveThe owner stamps the exact version under review | A capability is done when someone who did not build it can operate it | human |
Four phases, one pipeline
Ideation, PDLC, SDLC, RTB — the same shape whether the product is new or the one you've run for a decade.
Before stage 01
Market research, the customer's actual pain point, the sentence you'll type in. Not a Rathvan screen today — the conversation you have before you open one.
Stages 01–04
Product-development lifecycle: reuse map, PRD, architecture, design. What the product is, and where it lives, before a line of code exists.
Stages 05–09
Software-development lifecycle: test strategy, environment strategy, build, test execution, deploy — behind the executable gates.
Stages 10–13
Run the business: observability, post-deploy testing, monitoring, then the operational-readiness gate before anything is declared live. Shipping and operating are one pipeline, not a handoff to a different team's tooling.
The same four phases carry a legacy repository too — a connected repo gets a baseline document instead of a blank-page PRD, then rejoins the pipeline at design. That path is designed, not built yet: see the roadmap.
The platform went through its own pipeline before it built anyone else's product
Not a claim about discipline — an incident. This is what PDLC then SDLC, run on the platform itself before the throwaway version would have shipped, actually found.
Rathvan's own service was scaffolded through this same intake, with 337 tests already green. Dogfooding it — one sentence, through the console, out as a repository, the way a customer would — found four coherence bugs no test had caught: a product silently named after Rathvan itself instead of what the customer described, a config field that validated and round-tripped and did nothing, and a fix for that bug which changed the mechanism without changing the wrong result. None of the four were correctness bugs; every piece involved worked. What broke was whether the whole thing, sentence to repository, meant something.
What was added because of it: a dogfood gate that walks the customer's path end to end and asserts the far end reflects the near end — not that each step ran, that the output makes sense. Two of the four bugs were then reintroduced on purpose and confirmed to fail the gate, because a check nobody has watched fail is not yet a check.
Six refusals, built into the shape of the code
Not policy. Not configuration. There is no method that expresses these.
Reach production alone
STAGED is the last state a build can reach on its own.
Ship a prototype
Own namespace, no production credentials, an expiry date.
Advance on a simulated build
Stub source control reports NONE. NONE does not pass.
Regenerate on no feedback
Rewriting an artifact requires saying what should change.
Approve what nobody saw
Approval is stamped onto the exact version under review.
Lose a decision
Every transition writes an audit event naming its actor — including refusals.
Adopting into a system that already exists
Four ports. Nothing else touches your estate.
A store
Postgres, MySQL or a document store. One writer per table.
A model-provider chain
Several vendors including a local runtime, behind one port. Failover recorded per answer.
Source control
GitHub, GitLab, Azure DevOps, Bitbucket. Changes arrive as pull requests.
A feature gate
Your flag system decides exposure. Rathvan never flips it for you.