Applied AI Delivery Playbooks

New to the method? Read the concise Applied AI Field Guide first. This Handbook starts where a team is ready to run a real engagement or internal delivery lifecycle.

Use these playbooks to move one workflow from an important problem to business-owned production operation. The requester may be a customer, product team, or internal sponsor. The same questions apply: who knows the work, who may change it, what evidence is needed, and who will keep the service running? Commercial acceptance and internal funding have different owners; neither replaces workflow or release authority.

Lifecycle

This is an operational view of the canonical delivery lifecycle, not a separate process. Preserve and inspect every inherited brief; create a reframe record only when representative evidence materially contradicts its claims or boundary.

flowchart LR
    I["Inherit and reframe"] --> Q["Qualify"]
    Q --> D["Discover"]
    D --> C["Charter"]
    C --> S["Design"]
    S --> B["Build"]
    B --> P["Prove"]
    P --> L["Launch"]
    L --> O["Operate"]
    O --> U["Improve or expand"]
    U --> S
    O --> R["Retire"]

Stage	Primary question	Required output	Decision
Inherit and reframe	What was promised or requested, what actually happens, and who may change the boundary?	Current field brief, representative evidence, and next field move; add an engagement-reframe record and safe fallback when a material contradiction changes the boundary	Continue discovery, bounded kickoff, defer, or stop
Qualify	Is this problem important, owned, bounded, and verifiable?	Candidate brief and gate result	Discover, defer, or do not build
Discover	How does the work actually happen, including exceptions and workarounds?	Observation log, current-state workflow, source map, exception set	Charter or stop
Charter	Which outcome, segment, verifier, value hypothesis, and risk ceiling define success?	Workflow charter and value case	Pilot, defer, or do not build
Design	How do data, logic, actions, security, users, operations, and the selected intelligence mechanisms fit together?	Intelligence-selection record, domain model, target system design, agent-system when a foundation-model or agent workflow is selected, behavior bundle when model behavior is selected, applicable tool contracts and capability manifests, threat model, eval plan, and a system map only when dependency complexity warrants it	Build or redesign
Build	What is the smallest end-to-end slice that can prove the outcome?	Working vertical slice and delivery evidence	Continue or stop
Prove	Does it work on representative cases, with users, within risk and cost limits?	Replay, shadow, adoption, value evidence, and the applicable evaluation record; use the evaluation report for a model/agent release	Canary, revise, or stop
Launch	Can the compatible solution be contained, recovered, supported, and rolled back?	Target software release record, runbooks, trained owners, and cutover decision; use the solution-release manifest for a model/agent release	Bounded production or hold
Operate	Is the workflow valuable, reliable, safe, adopted, supportable, and still organizationally owned?	Service reviews, incidents, regressions, value realization, and continuation evidence	Expand, constrain, pause, or retire
Improve or expand	Which field learning warrants a workflow configuration, compatible product change, or bounded expansion?	Field-learning register and validated disposition	Investigate, configure, fix, productize, standardize, defer, reject, or retire
Retire	When should the workflow stop, and how will authority, capabilities, state, evidence, support, and users be closed safely?	Owned retirement sequence and verified target software retirement evidence; for a model/agent release, use `solution-release.retirement_evidence`	Retire or remediate

Read in order

The production implementation playbook remains the detailed technical release sequence. These lifecycle playbooks connect it to field discovery, value, adoption, ownership, and reusable learning. Use the current stage rather than restarting discovery for an already evidenced decision.

Minimum engagement packet

Artifact	Purpose
Field-observation log	Record actual work, evidence, exceptions, and workarounds
Engagement-reframe record, when evidence materially contradicts the brief	Preserve competing claims, scoped disposition, chronology, safe fallback, and selective propagation; do not create a conflict for an otherwise valid brief
Discovery pack	Map workflow, sources, decisions, exceptions, and readiness
Workflow charter	Bind problem, scope, outcome, value, readiness, owners, and decision
Value case	Separate estimated, measured, and realized value
Intelligence selection record	Choose the smallest sufficient combination of rules, optimization, ML, retrieval, models, agents, and human review
System map and change impact and assessment	Optional derived navigation and material-change evidence for complex, changing systems; never a substitute for authority or release evidence
Delivery and adoption plan	Coordinate the vertical slice, acceptance, rollout, and enablement
Production handoff	Prove the accountable operating team can operate, change, support, and retire the service
Production service review	Review decision rights, outcomes, SLOs, adoption, risk, cost, change, and receiving-team ownership
Workflow portfolio review	Map company decision rights and shared-versus-workflow capabilities; compare stage flow, proof gates, accepted value, economics, reuse, and capacity without overriding service gates
Field-learning register	Route validated field evidence into local configuration, product change, shared pattern, or retirement

Controls FDE-001 through FDE-005, VAL-001 through VAL-003, ADP-001 through ADP-002, and DEL-001 through DEL-002 define the lifecycle baseline within this guide.