Ceremonies and systems of record
The feature-delivery loop produces one verified feature or defect fix. Human ceremonies bracket the machine pipeline. Define and Judge are the primary accountability points.
Define
Section titled “Define”Intent becomes an executable contract, authored one spec at a time.
| Attribute | Definition |
|---|---|
| Owner | Spec owner for the ceremony and product spec; engineers for the technical spec; designer for the design spec; client outcome counterparty for intent |
| Cadence | Front-loaded, once per feature |
| Output | Locked specs and evaluation plan |
| Exit gate | Every acceptance criterion has an automated, human-judged or explicitly unverifiable evaluation path with an owner and mitigation. |
Each spec is ratified by someone who did not write it. The evaluation engineer maps every acceptance criterion to an evaluation path.
Workbench decomposes the locked specs into a task graph with file ownership and a data-model contract. An independent verifier checks the plan against the specs before the pod approves execution.
| Attribute | Definition |
|---|---|
| Owner | Workbench architect with the engineers |
| Cadence | Per feature, before Execute |
| Output | Approved task graph |
| Exit gate | Coverage, dependencies and evaluation cases are represented. Oversized specs are split before proceeding. |
Execute
Section titled “Execute”Agents implement task-scoped work on isolated branches. Deterministic grounding gates run with lint, type checks, tests and security scans. Agents do not self-certify.
| Attribute | Definition |
|---|---|
| Owner | Workbench agent operations with the engineers |
| Cadence | Continuous while the feature is active |
| Output | Built branches and gate evidence |
| Gate states | Pass, fail or unverifiable. Unverifiable is a risk state, not a soft pass. |
The machine pipeline proceeds through validate, plan, verify, run, review, coherence and integrate. Every command boundary is a point where the pod can stop and inspect state.
Judge: Outcome Review
Section titled “Judge: Outcome Review”Named people review the evidence and decide whether the outcome should ship. Each acceptance criterion receives one verdict.
| Attribute | Definition |
|---|---|
| Owner | Client outcome counterparty for the outcome decision |
| Cadence | Once per feature, before release |
| Output | Signed verdict and audit trail |
| Verdicts | Confirmed, missing, divergent or unverifiable |
| Signers | Product, engineering, evaluation, design when relevant and client countersign |
No one approves their own claim. Evidence sufficiency is a distinct signature and must appear in the scorecard when it is an accountability seat.
Release
Section titled “Release”Release integrates the accepted change to the main branch. Engineering owns the release boundary. Outcome acceptance does not by itself authorize production deployment.
Workbench extracts observations from failures, review findings, human corrections and zero-delta merges. Compounding and research promotes reusable patterns to shared shelves.
| Attribute | Definition |
|---|---|
| Owner | Compounding and research for promotion; Workbench for extraction |
| Cadence | After each feature integrates |
| Output | Updated shelves and agent learnings |
| Weighting | Human corrections carry the highest weight. A zero-delta merge is the strongest positive signal. |
Operating-ecosystem overlays
Section titled “Operating-ecosystem overlays”The operating ecosystem can add operational ceremonies without changing the feature lifecycle:
| Overlay | Typical owner | Cadence | System of record |
|---|---|---|---|
| Delivery status and steering | Delivery lead | Daily coordination and weekly steering | Delivery dashboard and tracked actions |
| Outcome and feature planning | Outcome counterparty | At readiness and continuously | Work tracker linked to Spec IDs |
| SME clinic | Domain SME or data owner | Weekly, plus on request | Grounding artifacts and assumption register |
| BRD and spec review | Outcome counterparty | Per feature | Spec record |
| Design review | Design fidelity lead | Per UI feature | Design system and design spec |
| Live validation | Client evaluation or release authority | Per accepted feature | Validation record and next signal |
Chat and meeting notes coordinate work. Decisions become authoritative only when retained in the tracking system, Workbench or the spec record.