Running in productionProduct Delivery

PRD to Production

From a written requirement to a verified production change — context packs, task cards, deterministic commit gates, AI review before push, human approval to deploy.

Runtime state: The workflow I actually use. Its deterministic commit gates run on every commit in the repositories described here, including this one.

Business objective: Deliver production changes at speed without letting an assistant make a confident, well-argued change to the wrong thing.
Trigger: A requirement is written down with acceptance criteria and explicit non-goals.
Inputs: Written requirement with acceptance criteria and non-goals
The repository's operating manual and invariants
A generated map of the relevant subtree
Sensitivity classification of the data involved
Outputs: A reviewed, tested, deployed change
Post-deployment verification against a documented expected state
Updated documentation where architectural truth changed

The workflow

Requirement to verified production change

Two AI steps, four deterministic gates, a human at both ends.

Human action
Write the requirement
Goal, acceptance criteria, explicit non-goals. Before any assistant is involved.
Approval gate
Sensitivity classification
Decision point: What may appear in a prompt? Secrets and production data never do. Classified before context is assembled, not after.
Automated software
Assemble the context pack
Operating manual, generated repository map, in-scope files, task card. Free exploration is limited and deliberate.
Data store
Retrieve prior decisions
Hybrid search over curated documentation for applicable invariants and previous decisions.
Automated software
Route by task class
Decision point: Deterministic fact — no model. Extraction — inexpensive tier. Architecture or security — strong tier. Incident — premium reasoning.
AI / LLM
Implement against the task card
Bounded token spend, with acceptance criteria and applicable invariants stated in the card.
Human action
I review the change
Against acceptance criteria and invariants, before any gate runs.
Approval gate
Deterministic commit gates
Decision point: Format, lint, type check, secret scan, content-schema validation. Any failure blocks the commit. No model, no network, same answer every time.
AI / LLM
Pre-push review
The diff reviewed against the repository's invariants — a second perspective where a single reviewer has consistent blind spots.
Automated software
Test suites
Unit, integration and end-to-end as the project requires.
Approval gate
Human approval to deploy
Decision point: No automated deployment, under any circumstances, at any change size.
Automated software
Deploy behind a flag
Behavior changes default to off, so deploying and changing behavior stay separate events with separate reverse paths.
Monitoring / feedback
Post-deployment verification
Smoke checks against a documented expected state.
Human action
Enable the flag deliberately
Decision point: A separate decision from the deploy, made with the deploy already verified.

Human action
Automated software
AI / LLM
Data store
Approval gate
Monitoring / feedback

Decision points

What may enter a prompt? Sensitivity classification, before context assembly.
Which tier handles this task? Including the no-model tier, which is often correct.
Is the task card small enough? Multi-part cards produce partly-right changes, and a partly-right large change is harder to review than two small ones.
Do the gates pass? Deterministic; no judgment involved.
Deploy? Human.
Enable the flag? A separate human decision.

Responsibilities

AI / LLM

Implementation against a task card.
Architecture review before a design is built.
Pre-push diff review against invariants.
Documentation synthesis and drift detection.

Deterministic

All five commit gates.
Test execution and the pass or fail result.
The repository map, generated from code.
Sensitivity classification.
Deployment, which also requires human approval.
Post-deploy health verification.

Human approval points

Writing the requirement. Nothing starts without it.
Reviewing the change before the gates run.
Approving the deploy. No threshold, no exception.
Enabling the flag, separately from deploying.

Failure handling

Failure	Response
Change targets the wrong component	The code map exists specifically for this; it states which tree is authoritative and which names collide.
Invariant violated	Caught at human review or pre-push review. The invariant document is what makes it checkable.
Commit gate fails	Commit is blocked. Fast enough that fixing and retrying is cheaper than arguing.
Secret detected	Commit blocked. Non-negotiable and non-overridable.
Tests fail	Not deployable. A failing test is reported as failing, never explained away.
Deploy causes a problem	Disable the flag. Behavior reverts without a code rollback.
Documentation drifts	A documentation check fails on the drift patterns that have bitten us before.

Monitoring

Time from requirement to verified change, commit gate failure rate by gate, pre-push review catch rate, post-deploy verification results, and flag age. Flags that outlive their rollout are technical debt with a countdown.

Business value

This is the workflow that lets one person own a platform, a delivery engine, data pipelines and an agent governance layer at once. Its value is entirely in the structure around the model.

More workflow designs

Back to the library