Workflows: The Architecture of Our SDLC
This is a diagram-first reference for how software actually gets built here — the approval gates, the loop shapes, the tools that turn an idea into something live. It's a companion to The SDLC essay series, not a replacement for it: those seven papers explain why the process looks this way, in long form and in voice. This section is the picture — one diagram and a short explanation per concept, built to be skimmed and referenced rather than read start to finish.
Everywhere this reference would otherwise need to name the actual product's internals, it names The App instead — an abstracted stand-in with only the generic properties a diagram needs (a content store, a generation pipeline, a live deployment target). The process shown here is real and current; the product behind it is deliberately not the subject.
The shape underneath everything on this page: a vision becomes a plan, a plan gets implemented inside a loop, the loop's output passes quality gates, and two separate human approval gates — one for the repository, one for deployment — stand between that work and anything going live. See the full walkthrough.
The pieces, in the order they usually come up
1. Session Bootstrap
How an AI collaborator loads this project's rules before doing any work, and re-grounds mid-session if drift is suspected.
2. Approval Gates
Which actions require a named human approval before they execute, and what the approval options actually mean.
3. Invocable Dispatch
How a short typed command gets matched against a catalog of documented, repeatable procedures instead of being improvised each time.
4. The Five-Phase Loop
The one recurring shape — vision, iteration, check, branch, gate — underneath every kind of repeated or unattended work in this project.
5. Concurrent Session Safety
How multiple loops or sessions safely share one working directory instead of silently colliding with each other.
6. Loop Tiers
Five different lifetimes for that same shape, and how to pick the narrowest one that actually fits the work.
7. Two Paths to Done
A phase-gated path with a human checkpoint at every boundary, versus an autonomous loop that self-checks against a confirmed goal.
8. Quality Gates
The automated bar every change has to clear before it's even eligible for a human approval gate.
9. Owner ↔ AI Decision Tiers
Three different mechanisms for getting a human judgment call into the work, matched to the shape of the decision.
10. The End-to-End Lifecycle
How all nine of the above actually chain together, from a stated vision to something live.
11. Doctrine Self-Revision
How the rulebook itself gets corrected after a real incident, and how that correction reaches every future session — closing the loop back to Session Bootstrap.
Why a separate section from The SDLC papers
The SDLC papers are living essays — narrated, versioned, and written to be read as an argument for why this project's process departs from classical team-based Agile. They stay exactly as they are; nothing on this page rewrites them. This section exists because a diagram and an essay do different jobs — sometimes what's needed is the picture, not the argument for why the picture looks that way.