01
Readiness
People, authority, access, controls, inputs and baselines.
AI-DLC / Operating process
How a pod ships
verified outcomes.
Named people own intent and proof. Workbench executes inside bounded controls. Every run becomes reusable learning.
The operating ecosystem connects human authority, controlled execution and compounding capability. AI-DLC governs accountable outcome delivery across it. It is not a synonym for AI-assisted coding.
- Team footprint
- 5delivery pod
- Operates with
- 2Workbench platform
- Aligns through
- 2program increment
Confidence packageSigned at Judge
One feature / 2 to 4 weeks
Five claims, five named signers, one verdict.
✓Product intent and scopeSpec owner
✓Technical correctnessTechnical boundary lead
✓Design fidelityDesign lead, when UI applies
✓Evidence sufficiencyEvaluation lead
✓Outcome acceptanceOutcome counterparty
ConfirmedMissingDivergentUnverifiable
A passing gate is evidence. It is not acceptance, release approval or a declaration of production readiness.
02
Outcome delivery
Feature to stage to Workbench task, on a two to four week cadence.
03
Compounding capability
Approved learning, conventions and platform improvements.
Organization
The operating
organization.
Governance sets the boundary. A pod builds and evaluates the feature. Workbench equips it. The program increment pair aligns the interval. Specialists assure applicable claims. Named client owners accept risk, outcomes and releases.
3named authoritiesGoverns the boundary
AI-DLC governance
Sets the operating boundary and holds the refusal. Two of the three sit outside the pod.
- Head of AI-DLC
- Portfolio, staffing, operating indicators and ecosystem-readiness refusal authority.
- Delivery lead
- Cadence, reporting, delivery health, scope, commercials and escalation. Holds no signature at Judge.
- Executive sponsor
- The client mandate, funding and the terminal escalation path.
5delivery seatsBuilds and evaluates
Delivery pod
Authors the specifications, supervises execution, evaluates the outcome and signs its claims.
- Spec owner
- Define, product intent and scope.
- Evaluation engineer
- Evaluation design, thresholds and false-pass controls. Wears the evaluation-lead hat.
- Technical boundary engineer
- The technical specification, architecture and the technical-correctness claim.
- Implementation engineer
- Implementation, review and release boundaries.
- Designer, when applicable
- The design specification, component states, fidelity rubric and design-fidelity claim.
2platform seatsEquips the pod
Workbench platform
Operates execution, gates, telemetry and lineage. Named before delivery begins.
- Agent operations lead
- Workflows, runbooks, supervision, recovery and the escalation path.
- Platform and data lead
- Orchestrator, providers, worktrees, intake, telemetry and artifact lineage.
2program seatsAligns the interval
Program increment
Carries the seam between the planning cadence and feature execution. Neither seat signs an outcome.
- Solution management
- Solution vision, roadmap, capabilities, cross-train scope and alignment of train outcomes.
- AI value architect
- Shared AI workflows, safeguards, delivery-value measurement and coaching for participating teams.
7client hatsHolds client decisions
Client authority
Client-owned because the delivery organization cannot grant itself access, accept its own work or authorize promotion.
- Outcome counterparty
- Countersigns intent, accepts or rejects the outcome.
- Client release authority
- Authorizes canary and production promotion as a separate decision.
- Client evaluation counterpart
- Reviews evidence, coverage and material limitations.
- Controls and access owner
- Repository, data and tool access, exceptions and incidents.
- Domain SME
- Functional and operational judgment the pod cannot supply.
- Data owner
- Semantics, lineage, retention and permitted use.
- Delivery coordinator
- Outcome and feature planning plus issue tracking on the client side.
8bounded claimsAttaches to applicable claims
Independent assurance
Specialists sign bounded claims. Approval does not equal outcome acceptance, release approval or production readiness.
- Security
- Threats, controls, findings and exceptions.
- Enterprise architecture
- Architecture boundaries and standards.
- Privacy
- Purpose, minimization and retention.
- Regulatory compliance
- Applicable obligations and mapped controls.
- Operational risk
- Residual business and operational risk.
- Quality engineering
- Test strategy and evidence quality.
- Accessibility
- Applicable interface acceptance and conformance.
- Reliability and operations
- Service objectives, recovery and monitoring.
Controlled execution roles / Systems execute under human accountability
Architect or plannerDeveloper agentsReviewer agentsEvaluation and gate runnersDebuggerSupervisor and recovery controller
Accountability assignment
Disciplines carry hats,
not titles.
The organization defines where people sit. This register defines the accountability a qualified person may carry, the boundary they own and the decision point where it applies. Open a family to read its hats.
Core deliveryBuild and evaluate the feature5 hats
These hats are assigned for every feature, except design fidelity when no interface claim applies.
Product and specification
Spec owner
Executable intent, product scope and the Define ceremony
DefineJudge
Assignment ruleRequired for every feature
Evaluation
Evaluation lead
Evaluation design, sufficiency thresholds and false-pass controls
DefineExecuteJudge
Assignment ruleCannot independently sign evidence the holder produced alone
Engineering and architecture
Technical boundary lead
Technical specification, architecture and technical correctness
DefinePlanJudgeRelease
Assignment ruleRequired for every feature
Engineering
Implementation owner
Construction, review response and code or release boundaries
PlanExecuteRelease
Assignment ruleMay also hold the technical-boundary hat when independent ratification remains available
Product design
Design fidelity lead
Design specification, component states, fidelity rubric and interface fidelity
DefineExecuteJudge
Assignment ruleRequired only when a design-fidelity claim applies
Workbench operationsEquip and control execution2 hats
These people operate the platform. They do not accept the outcome or replace human claim owners.
Agent operations
Agent operations lead
Workflows, runbooks, supervision, recovery and escalation
PlanExecuteRecovery
Assignment ruleConsulted at Judge, with no outcome signature
Platform and data engineering
Platform and data lead
Orchestrator, providers, worktrees, intake, telemetry and artifact lineage
IntakePlanExecuteReleaseLearn
Assignment ruleConsulted at Judge, with no outcome signature
Program incrementAlign feature execution to the planning cadence2 hats
These hats connect the pod to the interval the client already runs. They coordinate scope and shared practice without acquiring a claim.
Solution management
Cross-train scope owner
Solution vision, roadmap, capabilities and cross-train scope
Interval commitmentInterval review
Assignment ruleConsulted at Judge, with no outcome signature
AI enablement
AI value architect
Shared AI workflows, safeguards and delivery-value measurement
ReadinessInterval commitmentInterval review
Assignment ruleCoaches participating teams but ratifies no delivery claim
Client authoritySupply authority, knowledge and acceptance7 hats
These hats stay client-owned because the delivery organization cannot grant itself access, accept its own work or authorize production promotion. The discipline column names the seat that usually carries each hat.
Product or business leadership
Outcome counterparty
Client intent, outcome acceptance and rejection
DefineJudge
Assignment ruleRequired and named before outcome delivery proceeds
Release management or operations
Client release authority
Canary and production-promotion authorization
Release
Assignment ruleSeparate from outcome acceptance and production-readiness evidence
Client quality engineering
Client evaluation counterpart
Client review of evidence, coverage and material limitations
Evaluation designJudgeRelease readiness
Assignment ruleDoes not replace the evaluation lead
Security administration or platform ownership
Controls and access owner
Repository, data and tool access, exceptions and incidents
ReadinessIntakeEscalation
Assignment ruleHolds client authority for access and exceptions
Domain expertise
Domain SME
Functional, operational and policy judgment unavailable to the pod
DefineEvaluation designJudge
Assignment ruleConsulted when domain judgment affects a claim
Data governance
Data owner
Data semantics, lineage, retention and permitted use
ReadinessDefineAssuranceRelease
Assignment ruleRequired when the feature changes or depends on governed data
Program or delivery management
Delivery coordinator
Client outcome planning, feature planning and issue tracking
IntakeInterval commitmentReportingSteering
Assignment ruleCoordinates delivery but does not sign technical or outcome claims
Independent assuranceSign bounded assurance claims8 hats
Assign only the specialists required by the feature’s risk, regulatory and operational profile.
Cybersecurity
Security assurance
Threats, security controls, findings and security exceptions
DefineExecuteJudgeRelease
Assignment ruleSigns the security claim, not the whole feature
Enterprise architecture
Architecture assurance
Architecture boundaries, standards and approved exceptions
DefinePlanJudge
Assignment ruleIndependent review is required when architecture risk is material
Privacy
Privacy assurance
Purpose, minimization, retention and data-subject rights
ReadinessDefineJudge
Assignment ruleRequired when personal data is introduced or materially changed
Regulatory compliance
Compliance assurance
Applicable obligations, mapped controls and compliance evidence
ReadinessDefineJudgeRelease
Assignment ruleSigns only the applicable compliance claim
Operational risk
Risk authority
Residual business and operational risk acceptance
JudgeRelease
Assignment ruleRisk acceptance does not equal outcome acceptance
Quality engineering
Quality assurance
Test strategy, coverage challenge and evidence quality
Evaluation designExecuteJudge
Assignment ruleMust remain independent of evidence it ratifies
Accessibility
Accessibility assurance
Applicable interface acceptance and accessibility conformance
DefineExecuteJudge
Assignment ruleRequired when an accessibility claim applies
Site reliability or operations
Operational readiness authority
SLOs, recovery, monitoring and operational readiness
DefineJudgeRelease
Assignment ruleOperational readiness remains separate from release authorization
Governance and learningGovern the operating ecosystem and compound approved learning4 hats
These hats operate above or adjacent to feature delivery and carry no implementation claim by default.
AI-DLC leadership
Head of AI-DLC
Portfolio, staffing, operating indicators and ecosystem viability
ReadinessEscalation
Assignment ruleMay refuse outcome delivery on viability grounds
Delivery management
Delivery lead
Cadence, reporting, delivery health, scope, commercials and escalation
Every ceremonyThe report-and-steer cadence
Assignment ruleHolds no Judge signature
Client executive leadership
Executive sponsor
Client mandate, funding and terminal escalation
ReadinessTerminal escalation
Assignment ruleDoes not override bounded claim owners
Research and practice development
Compounding and research lead
Promotion of approved patterns, corrections and conventions into reusable defaults
LearnPortfolio review
Assignment ruleCannot grade delivery work the holder contributed to
Assignment rules
- One person may wear multiple hats when the required capability and independence remain available.
- No person independently ratifies a consequential claim they authored alone.
- Outcome acceptance, release authorization and production readiness remain separate decisions.
- Assurance specialists sign bounded claims, not the entire feature.
- Workbench computes recommendations and retains evidence. It does not hold human signatures.
- Ownership is assigned by claim and decision right, not by job title or organizational seniority.
Accountability
Who does what,
gate by gate.
Every gate has one accountable owner. Responsibility stays with the people doing the work. Consultation happens before a gate proceeds. Everyone else receives the outcome.
AAccountable One owner per gate
RResponsible Does the work
CConsulted Provides input first
IInformed Receives the outcome
11 roles. Scroll the matrix sideways on a narrow screen.
| Gate or ceremony | Spec ownerProduct intent | EvaluationEvidence design | EngineeringTechnical delivery | DesignDesign fidelity | WorkbenchControlled execution | Program incrementInterval alignment | Delivery leadDelivery cadence | Outcome counterpartyClient acceptance | Executive sponsorClient mandate | Head of AI-DLCGovernance | ResearchLearning |
|---|---|---|---|---|---|---|---|---|---|---|---|
| ReadinessAdjacent preparation | I | C | I | I | C | I | I | C | R | A | I |
| Interval commitmentObjectives, capacity, dates, dependencies | C | I | C | I | C | R | R | A | C | I | I |
| IntakeRoute intent to specs | A | I | I | I | C | I | C | C | I | I | I |
| Define productProduct spec | A | C | C | C | I | I | I | C | I | I | C |
| Define technicalTechnical spec | C | C | A | I | C | I | I | I | I | I | C |
| Define designDesign spec when UI applies | C | C | I | A | C | I | I | I | I | I | C |
| Evaluation designCriterion to evaluation path | C | A | I | C | I | I | I | C | I | I | C |
| Plan and verifyTask graph and blind check | C | C | R | I | A | I | C | I | I | I | I |
| ExecuteRun and gates | I | C | R | C | A | I | I | I | I | I | I |
| JudgeOutcome review | R | R | R | R | C | C | I | A | I | I | I |
| ReleaseIntegrate to main, then promote | C | C | A | I | R | I | I | C | I | I | I |
| LearnObservations to shared shelves | C | C | C | C | R | I | I | I | I | I | A |
| Interval reviewResults to actions | C | C | C | I | I | R | R | A | C | I | C |
| Report and steerContinuous delivery cadence | C | I | I | I | C | C | A | C | C | C | I |
Standing exceptions The delivery lead owns the commercial and reporting cadence but has no Judge signature. Research owns promotion of learning but cannot grade work it contributed to. The program increment pair is consulted at Judge and signs nothing. At Release, engineering integrates and the client release authority promotes.
Operating cadence
Which channel carries
which conversation.
Coordination, domain questions, work state, evidence and decisions each have a defined channel, owner, rhythm and audience.
Live conversation
Spoken work. Nothing here is a decision or a piece of evidence until it is written down somewhere else.
Day-to-day coordinationCoordination
Blockers, status and what is moving through the merge gate today. Coordination only. No decisions and no evidence.
Intent elaborationDefine ritual
Intent converted into agreed acceptance criteria and bounded units of work. The spec owner records the agreed intent after the session.
Implementation collaborationExecute ritual
Architecture, code and tests are steered and merge-gate output is reviewed. The session cannot replace retained evidence.
Functional and domain knowledgeClient input
Domain answers supplied to the pod. Unanswered questions become logged assumptions.
Written record
Where the work state and the evidence live. Authored by the people who own them, and readable by both organizations.
Product and technical spec reviewIndependent review
Specifications reviewed after deterministic validation. The client confirms that critical business, risk and test requirements are present.
Design assetsDesign input
Approved patterns, states and interaction references. Nothing is judged for design fidelity until the intended surface is written into the spec.
Outcome plan, feature plan and work stateDelivery record
Interval commitment, outcome priorities, feature plan, tracking issues and delivery status. Workbench execution links back to the tracked unit of work.
Technical evidenceEvidence record
Build output, tests, code review, security findings and architecture findings. Authored by the pod. Not judged here.
Evaluation evidenceEvidence record
Evaluation plan, sufficiency thresholds, false-pass controls and evaluation runs. Evaluation judges sufficiency but does not author the technical evidence.
Grounding and lineageControl record
Providers, models, worktrees, observation telemetry and artifact lineage. Ownership is named before delivery begins.
Decision and escalation
The only two places an outcome changes. A signature lands here, or a breach routes here.
Decisions and sign-offsConfidence package
Product intent and scope, technical correctness, design fidelity, evidence sufficiency, outcome acceptance and the release decision.
EscalationsException path
Anything that breaches its response commitment. The escalation follows the named ladder and retains the resulting decision.
System of record
Work tracker
Interval commitment, feature plan, owners and dates, linked to the Spec ID.
System of record
Workbench
Execution, technical and evaluation evidence, grounding and artifact lineage.
System of record
Spec record
Intent, acceptance and signed decisions, including the release decision.
A conversation is not a decision until it lands in a system of record Anything that breaches its response commitment moves to the exception path, same day to 48 hours.
Organizational handshake
How work moves between
the organizations.
The stages that carry a feature from intent to acceptance, and who holds each one.
00
Readiness
Readiness before feature delivery
Spec owner with the podDelivery organization
Build the domain model, input register, assumption register, non-functional baseline, test baseline and one grounded trial feature.
Client organization
Provide source access, architecture, design references, data lineage and tribal knowledge.
00
Interval alignment
Planning cadence the client already runs
Delivery coordinator with the program increment pairDelivery organization
Bring feature slices, capacity positions and dependency effects into the planning event.
Client organization
Own objectives, capacity, dates, dependencies and program risks for the interval.
00
Outcome and feature planning
Continuous delivery coordination
Outcome counterparty with delivery leadDelivery organization
Link delivery work and Workbench runs to Spec IDs in the work tracker.
Client organization
Own outcome priorities, feature order, tracking issues and the delivery commitment.
01
Signal detection
Outcome intake
Outcome counterpartyDelivery organization
Route the signal into the applicable product-spec pattern.
Client organization
Name the outcome signal, affected users and the business condition that should change.
02
Hypothesis framing
Drafted from the input register, then checked for accuracy
Spec ownerDelivery organization
Frame the outcome hypothesis, draft product intent and issue the Spec ID.
Client organization
Review business intent, scope, priorities and critical operating constraints.
02
Joint elaboration
Define ritual
Pod with the domain ownerDelivery organization
Turn intent into product, technical, design and evaluation contracts.
Client organization
Supply domain knowledge and reconcile acceptance criteria with the pod.
03
Implementation collaboration
Review ritual. The merge gate signs nothing.
Delivery podDelivery organization
Steer architecture, code and tests while preserving task and file ownership.
Client organization
Answer bounded domain questions within the agreed response commitment.
03
Build with gates
Controlled Workbench execution
Technical boundary leadDelivery organization
Run isolated implementation, deterministic gates, review and controlled recovery.
Client organization
Inspect visible work state and retained evidence without co-authoring it.
05
Live validation
Accepted behavior is observed and feeds the next signal
Evaluation lead with the outcome counterpartyDelivery organization
Monitor the agreed evaluation signals and retain observations for Learn.
Client organization
Authorize the validation scope and retain production promotion authority.
04 / Preproduction validation. The confidence gate.
Claim verdicts and independent signatures. No one approves their own claim.
| Claim | Signed by | Delivery organization | Client organization |
|---|---|---|---|
| Product intent and scope | Spec owner | Signs the implemented outcome against the committed product contract. | The outcome counterparty confirms that the bounded intent remains correct. |
| Technical correctness | Technical boundary lead | Signs code, architecture, security and operational correctness. | Receives the signed technical claim and its retained evidence. |
| Design fidelity | Design fidelity lead when UI applies | Signs the implemented surface against the approved design contract. | Confirms the intended surface exists. The claim does not arise for headless work. |
| Evidence sufficiency | Evaluation lead | Signs coverage, thresholds, false-pass controls and material limitations. | Receives the evidence judgment but does not substitute acceptance for it. |
| Outcome acceptance | Outcome counterparty | Makes the signed confidence package available for the bounded decision. | Accepts or rejects the feature. Production promotion remains separate. |
Boundary rule The delivery organization builds and proves. The client organization accepts and promotes. The merge gate is a review point inside delivery; it does not sign a claim or grant production authority. Artifacts cross the organizational boundary. Decision rights do not.
Process and ceremonies
The feature lifecycle,
end to end.
Human ceremonies bracket a controlled machine pipeline. Every boundary is a point where the pod can stop, inspect evidence and refuse to proceed.
Machine pipelineValidatePlanVerifyRunReviewCoherenceIntegrate
Define
Intent becomes executable product, technical, design and evaluation contracts. The four artifacts are authored in parallel, and a rejected artifact returns to its author to be ratified again.
OutputLocked product, technical and design specs plus the evaluation plan
Exit gateEvery acceptance criterion has an automated, human-judged or explicitly unverifiable evaluation path.
Plan
Specifications decompose into a file-scoped task graph. One task is roughly 15 to 30 minutes of agent work and one reviewable diff, and oversized specs return to specification rather than to a longer run.
OutputApproved, file-scoped task graph
Exit gateCoverage, dependencies, data contracts and evaluation cases are represented. Oversized specs are split.
Execute
Agents build on isolated branches while deterministic gates measure quality. Independent tasks run in parallel because every task declares file ownership. Blocked beats guessing, so ambiguity returns to a person.
OutputBuilt branches and retained gate evidence
Exit gatePass, fail or unverifiable. Unverifiable is a risk state, never a soft pass.
Judge
Five claims are signed separately: product intent and scope, technical correctness, design fidelity where a UI claim applies, evidence sufficiency, and outcome acceptance. No person independently ratifies a claim they authored alone.
OutputSigned verdict and audit trail
Exit gateProduct, engineering, evaluation, design when relevant, and the client accept responsibility for their claims.
Learn
Observations, corrections and conventions are extracted from the run and promoted into reusable defaults, so the next feature starts from a stronger position than the last.
OutputUpdated shelves, conventions and evaluation-rubric improvements
Exit gateHuman corrections carry the highest weight. A zero-delta merge is the strongest positive signal.
Role by ceremony
What each role does
as the feature moves.
Human ceremonies and Workbench execution form one responsibility chain. The role view makes handoffs explicit without confusing authorship, evidence production and acceptance.
| Role | Intake | Define | Plan | Execute | Judge | Learn |
|---|---|---|---|---|---|---|
| Spec ownerProduct intent and scope | Route intent and select the product-spec pattern | Author the product spec and run Define | Confirm the task graph matches scope | Stay informed while bounded work runs | Sign product intent and scope | Apply accepted learning to the next definition |
| Evaluation engineerEvidence sufficiency | Assess evaluation feasibility | Map every criterion to an evaluation path | Confirm evaluation cases appear in the task graph | Watch gates produce sufficient evidence | Sign evidence sufficiency | Improve evaluation rubrics from observed failures |
| EngineersTechnical boundary and implementation | Review technical feasibility | Author the technical spec and ratify sibling specs | Approve task boundaries and supervise decomposition | Supervise implementation and own code boundaries | Sign technical correctness and risk | Contribute technical patterns and corrections |
| DesignerDesign fidelity when applicable | Confirm whether a UI claim applies | Author the design spec, component states and rubric | Confirm design work is represented in the plan | Review the implemented UI against the rubric | Sign design fidelity | Promote reusable design corrections |
| Workbench platformControlled execution and evidence | Wire intake, providers and external adapters | Assemble and validate the context package | Run architecture, decomposition and blind verification | Run isolated branches, gates, supervision and recovery | Supply evidence and the scorecard | Extract observations and maintain lineage |
| Program incrementInterval alignment | Place the slice in the interval plan | Confirm scope fits committed capabilities | Surface cross-train dependencies | Track delivery-value measures | Attend without a signature | Carry shared workflow improvements across teams |
| Outcome counterpartyClient acceptance | Prioritize the intended outcome | Commit product intent and countersign the contract | Stay informed as the plan is authorized | Stay informed while execution remains bounded | Countersign and accept or reject the outcome | Receive live results as the next signal |
Define runs in parallel Product, technical, design and evaluation artifacts are authored at the same time. A rejected artifact returns to its author and must be ratified again.
Cadence and decomposition
Human effort frames
autonomous execution.
People concentrate effort at Define and Judge. Execute occupies most wall-clock time but requires supervision rather than continuous manual implementation.
Human effort
Wall clock
Bars share one scale and show relative order of magnitude. Each row states its actual range.
IntakeHuman
DefineCollaborative
Plan and verifyHuman and machine
ExecuteAutonomous
JudgeHuman
ReleaseHuman and machine
LearnContinuous
- One task is approximately 15 to 30 minutes of agent work and one reviewable diff.
- Four to eight tasks per spec is the target. Larger work returns to specification.
- Every task declares file ownership so parallel branches do not collide.
- Dependencies form a directed graph. Independent tasks run in parallel.
- A machine-checkable data-model contract is verified after integration.
- Blocked beats guessing. Ambiguity returns to a person.
An operating boundary, not a bypass The cadence describes how effort distributes. It is never permission to skip an exit gate.
The operating model
One ecosystem,
two reinforcing loops.
The feature-delivery loop produces one verified feature. The capability-compounding loop strengthens the ecosystem so future features start with better defaults.
2 to 4 weeks per feature
Feature-delivery loop
Specs become a task graph. Agents build on isolated branches. Deterministic gates measure quality. Named people sign the result.
DefinePlanExecuteJudgeReleaseLearn
Quarterly and across the operating horizon
Capability-compounding loop
Patterns, failures, corrections and conventions become controlled defaults for future work.
ObserveSynthesizeCuratePromoteInherit
Two clocks, not one ceremony The interval review sets actions for the next interval. The compounding loop promotes reusable defaults into the platform. The two loops share evidence, but they do not share decision authority, and research cannot grade delivery work it contributed to.
Operating boundary
AI-DLC governs.
Workbench operationalizes.
AI-DLC assigns stages, claims, decision rights and refusal rules. Workbench provides the controlled execution, evidence, recovery and lineage needed to operate them.
AI-DLC governs
The decisions
- Outcome intent and accountable ownership
- Applicable claims and independent signatures
- Exit gates, escalation and refusal
- Acceptance separated from release
Workbench operationalizes
The execution
- Context assembly and spec validation
- File-scoped plans and isolated execution
- Deterministic quality and grounding gates
- Retained evidence, recovery state and learning signals
People decide
The signatures
- Authors commit to intent
- Claim owners judge their evidence
- The client accepts or rejects the outcome
- Release authority controls production
Six stages / Five signed claims / Two loops
Specified, evaluated, countersigned
and learned from.
If work cannot meet all four, it is not ready for AI-DLC outcome delivery.