Playbook › Overview: tracks & phases
Overview: tracks & phases
The engagement playbook: four tracks in parallel, one build, one operating rhythm.
From day one, four tracks run side by side. By the time discovery ends, the environment is ready to stand up at the click of a button,
the logic track knows what to build first and what good looks like, the data track knows what to connect and how, and the experience track
knows who it serves and where. The tracks converge into a single build phase run through the ADLC, and then into steady-state operation.
The discipline that holds it together: every step lands its output as a portal asset. A finding becomes a plane value, an overlay candidate,
a specification, or an eval. Anything that fits none of those is out of scope, and the record says so.
The four tracks
| Track | Led by | The question it answers | What it converges into |
|---|---|---|---|
| 1. Environment readiness | Client delivery team with environment expertise | Where will this run, and what must be true for one-click provisioning? | The environment specification, the filled C5 and C7 plane values, and a proven provisioning pipeline |
| 2. Business discovery and the logic layer | Business forward-deployed engineer | What is worth building, in what order, and what does good look like? | The ontology overlay, the capability heatmap and roadmap, and PRDs written as evals |
| 3. Data, systems and integration | Data engineering | What exists, where does truth live, and how do we reach it? | South-facing MCP specifications and parametrized integration requirements |
| 4. Experience design | Design lead | Who uses this, through which channels, and what should it feel like? | Personas, journey maps, prototypes, and the C1 experience values |
The phases
| Phase | What happens | Exit condition |
|---|---|---|
| A. Discover | All four tracks run in parallel: questionnaires, interviews, current-state assessment, inventories, research. | Each track's discovery deliverables complete; the ontology triage done; nothing important still unknown. |
| B. Specify | Tracks converge: the binding fills, the overlay is cut as a release, PRDs are written as evals, integration requirements are parametrized, the environment dry-runs. | Spec freeze at Gate 2: binding filled, evals approved, one-click provisioning proven in a sandbox. |
| C. Build | Agent development through the ADLC: deterministic components to the rule library, judgment to agents, mini-outputs assembled by the orchestrator, quality enforced by guardrails and loop engineering. | Per capability: evals pass, unit tests green, human review configured. |
| D. Operate | Full-runtime observability, token optimization, performance tuning, and the two sealed loops improving the platform without touching client trust. | Ongoing; measured against the capability maturity benchmarks set in Track 2. |
Ground rules the playbook inherits
The playbook does not invent rules; it executes the standing principles on the Decision Register page: values never code, deterministic by default, classification inheritance, deterministic rendering, source of truth stays in the estate, and the two sealed loops. Two playbook-specific disciplines are added and defined in the glossary: mini-outputs (every agent produces a bounded, independently reviewable output, and only the orchestrator assembles the final deliverable) and ontology triage (every business finding is classified as truth, overlay, or a conscious contradiction; nothing forks silently).