The Delivery Standard

This standard describes the method as a concept, kept independent of any one tool. Where it names a specific tool — the SDLC orchestration plugin we drive it with (claude-code-sdlc), the .NET/Azure stack, a particular CI system — treat that as an example of how we implement the method today, not as part of the method itself. The specific tools and commands appear in full in the worked examples (the fictional Harbor Mutual engagement that runs alongside each deep-dive); the concept here should still make sense if you swapped every one of them out.

The method synthesizes two bodies of work: the Intent-Driven Development methodology (MCKRUZ/intent-driven-development) and an SDLC orchestration plugin (MCKRUZ/claude-code-sdlc, our example tool for running the phases). Where the two disagreed, this document is the resolution; where it is silent, Intent-Driven Development is the tiebreaker.

How an engagement is structured

1. The shape of an engagement

Three parts, in order: a gated opening that builds the factory, a continuous build loop in the middle, and a gated close that ships the system and hands it over.

An engagement has three parts, in order. An opening frames the problem and builds the "factory" — the code repository, the build-and-deploy pipeline, and the set of rules and context the AI agents work inside. A long middle is where the software actually gets built, one small piece at a time. A close documents the system, ships it to production, and hands everything over to the client.

The opening and the close run as numbered phases. Each phase ends at a gate: a checkpoint where automated checks run and a named human has to sign off before the work advances. The middle is different — it is not phased. It runs as a continuous build loop, repeating the same short cycle for every piece of work.

OPEN (gated phases — automated checks, then a human signs to advance)
  Phase 0  Discovery        problem, outcomes, constraints, tooling approval, PO decision
  Phase 1  Requirements     epics, stories, NFRs (drafted by Claude, owned by humans)
  Phase 2  Design           architecture, ADRs, API contracts (Claude proposes 2-3, human picks)
  Phase 3  Foundation       the factory built; thinnest end-to-end slice deployed to client dev

BUILD (the build loop — continuous, one piece of work at a time; replaces the batch middle phases)
  for every story:  Intent -> Delegate -> Discern -> merged & deployed to dev
  weekly cadence:   intent triage, flow check, retro+, setup review
  biweekly:         steering with the client (demo + outcome scorecard)
  hardening passes: scheduled, not a phase — see 5.6

CLOSE (gated phases — automated checks, then a human signs to advance)
  Phase 7  Documentation    README, API docs, RUNBOOK (Claude drafts, humans verify by using them)
  Phase 8  Deployment       promote to prod + release ceremony (pipeline already exists from Phase 3)
  Phase 9  Monitoring       alerts, incident response, retrospective
  Phase C  Close & Transfer consulting-only: client owns the harness, runs the loop solo, we leave

Rough calendar for a typical engagement (4-6 person pod, medium-sized product): Open 4-6 weeks (the phases overlap — the Setup Owner's enablement work runs ahead while requirements and design close), Build 8-16 weeks, Close 2-3 weeks. These are planning figures, not promises; the SOW maps billing milestones to phase gates, not to dates (section 12).

The pod and its roles

3. The team

A 4–6 person pod running 2–3 parallel streams. The limit on parallelism is checking capacity, not headcount — and the author of a change is never its sole approver.

Designed for a 4-6 person pod running 2-3 parallel work streams. The constraint on parallelism is checking capacity, not headcount — never open more agent streams than the team can review without the queue growing.

Roles

Collapse rules (smaller engagements)

• 3 people: one person is Pod Lead + Setup Owner (deputy duty moves to the senior Orchestrator); two Orchestrator/Checkers swap per change. One stream, two at most.
• 2 people: only with an experienced pair, one stream, and the grader-in-CI carrying more weight. The rule that survives all collapsing: the author of a change never solely approves it. One bounded exception exists, and only for our own internal repos, where a single maintainer has no second person to satisfy; its terms — and the mechanical rungs that stand in for the missing reviewer — are written in the team deep-dive. It never applies to client work.

Certification

Two bars, and they are different in kind. Method competence transfers between engagements; system understanding does not, and has to be re-earned on every codebase.

Method competence (once, then it travels). Nobody works a client spec until they have completed the IDD course (2-day format, intent-driven-development/course/) and passed the competency rubric: demonstrably wrote a spec that passes the vague-line test, ran the full loop on a practice feature, and operated the grader. Demonstrated, not attested. The practice ground is internal projects, never client-billed work.

System understanding (per engagement, before working a spec unsupervised). An Orchestrator or Checker demonstrates, out loud and without reading from the docs:

• the system's architecture and its main data flows;
• the layer beneath the one they work in — the queue, the identity provider, the deployment target — well enough to say how it behaves when it fails;
• for a given spec, what the agent is most likely to get wrong here, and why.

This bar exists because the method can manufacture its own worst failure mode: someone fluent in the ceremony, steering confidently, without the understanding to notice the model is wrong. The checking ladder does not save you — rung 5 is a human exercising judgment, and judgment without understanding is a rubber stamp. The model's working memory is finite and far smaller than a person's, so the human is the one who has to hold the whole picture.

The natural checkpoint is the Phase 3 exit: the pod has just built the foundation, so it is the cheapest moment to prove they understand it. Re-established when someone joins mid-engagement.

The continuous middle

5. The build loop

The middle of the engagement, run as one repeating cycle per story — Intent → Delegate → Discern — with checking inside the loop, never as a later phase.

This is the middle of the engagement — it replaces the batch Implementation/Quality/Testing phases of a traditional lifecycle. Every story runs the same three beats.

5.1 Intent

A story enters the loop only through Definition of Ready, enforced at weekly intent triage:

• Acceptance criteria pass the vague-line test (could two people build different things from this line? then it's not ready)
• Scope in / scope out stated
• Silent decisions answered (no open decision-list items for this story)
• Risk tier assigned by the Pod Lead (taxonomy below), recorded in the spec
• References the harness context the agent will have

The Orchestrator translates the ready story into specs/NNNN-name.md using the kit's spec template: Goal, Why, Scope in/out, Acceptance checks, Risk tier, Delegation plan (what the agent may touch, what's gated), Checking plan (which ladder rungs).

Risk taxonomy (lives in CLAUDE.md so agents see it too; challenges escalate up, never down, without discussion):

Bug-fix specs carry one extra mechanical gate. Coverage proves a test exists; it does not prove the test would have caught the bug. A fix labelled type:bugfix must ship a test that fails against the code as it was before the fix — proven in CI by the repro-gate job, which reconstructs the pre-fix tree with the new test applied and requires it to go red. There is no label escape: a test that cannot fail cannot protect anything. Feature specs are exempt because there is no "before" state to fail against.

5.2 Delegate

• Start in plan mode. The agent proposes; the Orchestrator corrects or approves before code.
• Bounds set per spec: scope (file patterns it may touch), context (the one canonical pattern to reuse), permissions (.claude/settings.json auto-allows dotnet test, dotnet build, ng test, lint, reads; asks on package installs, network, and anything under gated paths like migrations or auth).
• One agent for tightly coupled code. Fan out only for independent, read-only exploration or for genuinely independent specs on separate branches.
• A blocking Stop hook (from the kit) refuses to let the agent finish with failing tests or a broken build. This is the single highest-value automation we keep.

5.3 Discern

• Mechanical gates in CI (hard blocks): build, tests, lint, 80% coverage on new code.
• Grader in CI (required to run, advisory verdict): a GitHub Actions workflow runs claude-code-action; a fresh agent that did not write the code reads the spec file in the diff and posts a check-by-check verdict as a PR comment. It cannot be skipped — "grader has run" is a required status check — but its verdict does not block. The human Checker reads it and makes the call. Machines gate the mechanical; humans own the judgment.
• Human Checker (hard block): non-author approval on every PR. On HIGH risk, additionally the security-reviewer agent's pass and a named human sign-off.
• Merge deploys to the client dev environment automatically (the rails from Phase 3).

5.3a Spikes (when a story can't be made ready)

A story sometimes fails Definition of Ready for a reason no amount of rewriting fixes: nobody knows the answer yet. The integration's real behavior is undocumented; the design rests on an assumption no one has tested. Acceptance criteria written about an unknown are fiction, and the grader will grade them as if they weren't.

A spike is the second delegation mode, and it is not a spec:

• Boxed in time or tokens, agreed at triage, recorded.
• Run on a spike/ branch. A required CI check (spike-guard) fails any PR opened from one, so the merge button never lights up. The throwaway rule is mechanical, not honour-based — spike code has climbed none of the checking ladder, so "it started as a spike" must never be a route onto main. Unlike the spec gate, this check has no label escape; work worth shipping gets a spec and gets rebuilt.
• Its deliverable is a written finding (kit/spike-template.md): what was assumed, what was tested against which system, what was found, whether the assumption survived. The finding is committed; the code is deleted.
• It closes a named unknown — a decision-list item or a risky assumption — and unblocks the spec that was stuck. When it invalidates a Phase 2 decision, the ADR revision that follows is a HIGH-risk spec like any other.

Spikes are how the design gate stays honest rather than becoming a fiction: Phase 2 decides, and evidence found later is allowed to change the decision through a gated route.

Deep-dive: docs/build-loop.md §3a.

5.4 Weekly cadence

5.5 Client cadence

Biweekly 45-minute steering: live demo of working software in the dev environment, the outcome scorecard (their success metric, the DORA stability pair (change-fail rate and time-to-recover), the accepted-as-is trend), the decision list needing their answers, and gate status when a phase boundary is near. Weekly 5-bullet async summary in between. No activity metrics in client materials, ever — no PR counts, no "AI productivity" claims. Demos and outcomes only. The durable record is the HTML phase report our tooling generates at each gate.

5.6 Hardening passes

Quality is per-change, but integration-level concerns (performance under load, E2E journeys, penetration testing) run as scheduled hardening passes — typically one mid-Build and one before Phase 8 — driven by the /e2e and security tooling. These are scheduled work in the flow, not a phase that gates all other work.

The pipeline every change rides

7. DevOps

.NET / Azure / GitHub Actions by default, IaC in-repo at HIGH risk, secrets in the client's vault — and a human go/no-go on every promotion to prod.

• Stack default: .NET 8 / Angular / SQL Server / Azure / GitHub Actions — the example profile we ship. A profile-swap appendix in this repo covers what changes for other stacks; everything else in this standard is stack-independent.
• IaC: Bicep, in-repo, HIGH risk tier. Dev environment provisioned in Phase 3; test and prod added at the first hardening pass; prod promoted in Phase 8.
• Pipeline ownership: Setup Owner builds it (with Claude drafting the YAML); the client's DevOps/security reviews it — they have to operate it after we leave.
• Secrets: client's Key Vault and client's GitHub secrets. Never in code, never in CLAUDE.md, never in specs. The Anthropic API key is client-procured (section 8).
• Environments: merge → dev (automatic), dev → test (on demand, smoke-tested), test → prod (Phase 8 ceremony and thereafter on the client's release cadence, human go/no-go every time).

What blocks, what steers

9. Gates and metrics

Machines gate the mechanical; a named human advances every phase. Metrics are baseline-and-trend — never velocity, story points, PR count, or lines of code.

Phase gates

At every phase boundary an automated gate check runs a fixed battery of validations (integrity, completeness, metrics, compliance, consistency, quality). Gates report; a named human advances. (In our toolchain this is the /sdlc-gate check — the concept is the battery plus the human, not the command.) Override rules: the mechanical gates are never overridden; a quality-gate override requires written justification recorded with the phase state.

Merge gates

Per section 5.3. Exceptions (a true emergency merge past a gate) require the Pod Lead and one other human, a gate-exception label, and a Retro+ agenda item. Two exceptions in a month means the gate or the specs are wrong — fix that, don't keep excepting.

Metrics

Internal dashboard (baseline-and-trend, no vanity targets):

• Accepted-as-is rate — agent work merged without rework. The trust signal.
• Review wait (median) — the real bottleneck indicator. If it grows, stop opening streams.
• Rework/revert rate and bounce-back-for-unclear rate — intent quality signals.
• Escaped bugs — every one gets a "which check should have caught it?" answer at Retro+.
• DORA four — deploy frequency, lead time, change-fail rate, time-to-recover.
• Security-review wait — tracked separately; it clears slower and would hide in an average.

Client-facing scorecard: their success metric, the DORA stability pair, accepted-as-is trend, and the demo. That's it.

When the deliverable includes agents

11. The AI-engineering module (when the deliverable includes agents)

Activates whenever a spec ships LLM-powered behavior. Evals are acceptance criteria; prompts, models, and tool definitions are HIGH risk — because "tests pass" doesn't verify probabilistic behavior.

• Evals are acceptance criteria. An agentic spec includes a golden set (input scenarios with graded expected behavior) and a threshold ("correct on ≥ 95% of the golden set"). The golden set is versioned in the repo next to the spec. CI runs the eval suite like it runs tests.
• Prompts, model selections, and tool definitions are HIGH risk. Changing any of them is a spec with an eval-regression gate: the full golden set runs, and degradation blocks the same way a failing test does. No drive-by prompt edits.
• Observability is a requirement, not a nice-to-have. Agentic features ship with tracing (what the agent saw, decided, called), token cost per task, and failure-mode logging. The monitoring phase (9) includes agent-specific alerts: cost spikes, refusal rates, eval drift in production samples.
• The worked example (docs/agentic-spec-example.md, to be added with the first agentic engagement) will walk one agentic spec end-to-end: golden set construction, the eval harness, the CI wiring, and what the grader checks differently (behavior distribution against the golden set, not just code against acceptance lines).
• Security inherits the firm's AI rules: model output is untrusted input; no raw user input embedded in system prompts; tool permissions enforced server-side, not by prompt.

How the engagement ends

13. Close & Transfer (Phase C)

It ends when the client can run the loop without us — proven by them taking one real spec end-to-end, unaided.

The engagement ends when the client can run this without us:

• Harness audit: nothing undocumented, no skill or hook only we understand
• Client Setup Owner named and has merged harness changes themselves
• Client engineers completed ≥ 3 specs as Orchestrator with our Checkers, then
• The close gate: the client team ran one real spec end-to-end — triage, spec, delegate, grade, merge, deploy — without us driving
• Final phase reports delivered; outcomes dashboard handed over
• Our access revoked; harvest retro PR opened against this repo