Establish pod ceremonies
Complete this guide after staffing the pod. It converts the canonical process into a working delivery cadence across the pod, Workbench platform and client organization.
1. Publish the feature cadence
Section titled “1. Publish the feature cadence”Set the expected feature cadence, typically 2 to 4 weeks. Publish the dates for Define, plan approval, Outcome Review and the client release decision.
The cadence is a planning boundary, not a promise to bypass an exit gate.
2. Schedule the five core ceremonies
Section titled “2. Schedule the five core ceremonies”| Ceremony | Schedule | Accountable owner |
|---|---|---|
| Define | Once per feature, front-loaded | Spec owner for the ceremony; each discipline owns its spec |
| Plan | Per feature, before any execution | Workbench architect |
| Execute | Continuous within the active feature | Workbench agent operations |
| Judge: Outcome Review | Once per feature, before release | Outcome counterparty |
| Learn | After integration | Compounding and research |
Release sits between Judge and Learn. Engineering owns integration. The client retains any separate production-release authority.
3. Add the ecosystem ceremonies
Section titled “3. Add the ecosystem ceremonies”Use the client operating model to add the ceremonies required across organizational boundaries:
- Daily coordination for blockers and current work.
- Weekly delivery steering for health, scope, commercials and escalation.
- Outcome and feature planning linked to tracking issues and Spec IDs.
- An SME clinic for domain questions, data lineage and tribal knowledge.
- Mob elaboration to turn intent into criteria and bounded work.
- BRD and spec review after the developer accuracy check.
- Mob build to steer architecture, code and tests.
- Live validation to record the next operating signal.
Name one owner for every ceremony. Record the cadence, participants, input, output and exit condition.
4. Establish the systems of record
Section titled “4. Establish the systems of record”| Record | Required content |
|---|---|
| Tracking system | Outcome priority, feature plan, issue status and link to the Spec ID |
| Spec record | Product, technical and design specs; acceptance criteria; ratification; open assumptions |
| Workbench | Plans, run state, technical evidence, evaluation evidence, lineage and signed verdicts |
| Design system | Design intent, components and fidelity rubric when UI work applies |
| Decision record | Claim signatures, outcome acceptance and separate release decision |
A chat message or meeting statement is not a decision until it is retained in the appropriate record.
5. Define response and escalation commitments
Section titled “5. Define response and escalation commitments”Agree response times during readiness. At minimum, define:
- How a question reaches the domain owner before the next SME clinic.
- Who resolves repository, data, model or tool access blockers.
- When insufficient evidence moves from the evaluation lead to client controls and the executive sponsor.
- Who can stop unsafe or nonviable outcome delivery.
The pod cannot lower an agreed evidence threshold or suppress an unresolved finding to meet cadence.
6. Rehearse one feature
Section titled “6. Rehearse one feature”Before live delivery, walk one representative feature through each ceremony. Confirm that:
- every acceptance criterion receives an evaluation path;
- each spec has an independent ratifier;
- the plan can be stopped and inspected;
- gate evidence is readable by both organizations;
- the scorecard includes product, engineering, evaluation, design when applicable and client countersign;
- outcome acceptance and production release remain separate; and
- Learn has a destination for promoted observations.
Use the ceremony reference during the rehearsal and update the pod RACI with named people.