Seven stages. Reliability engineered into each one.

Two layers, not one.

The lifecycle is not divided between the motions. Discovery applies whether the work is productionizing or operating. Hardening applies to an automated workflow as much as to a new service. The motions say what the engagement is for; the stages say how it gets done.

01Productionize AI

Take an AI capability from pilot or prototype to something that holds up in production.

02Automate real workflows

Put AI inside a workflow that takes real actions, with the controls that implies.

03Operate reliably

Operate the production controls around a live AI system as the product, the models and usage change.

Reliability is specified before Build, not bolted on after.

The targets, the boundaries and the constraints are set in Design, before implementation starts. Harden then exercises the system against those targets rather than inventing them afterwards, and Operate monitors the system against them as production conditions change. That ordering is the whole argument: a reliability requirement discovered after the code exists is a rewrite, and a reliability requirement discovered in production is an incident.

The seven stages

1. 01

   Discover

   Map the workflow, the failure modes that actually matter to the business, and what "working" has to mean for the system in scope.

   • The workflow as it runs today
   • Failure modes worth engineering against
   • The definition of working, written down
2. 02

   Design

   Set the architecture, operating boundaries, acceptance criteria and production controls before implementation starts. Decide what the system must do, what it must not do, and how those conditions will be evidenced.

   • Architecture and system boundaries
   • Acceptance criteria and relevant evaluation strategy
   • Reliability and operating targets
   • Permissions, constraints and approval boundaries
   • Failure, fallback and recovery design where required
3. 03

   Build

   Implement the production system and the controls required by its scope. Architecture, integrations, workflow logic, state, evaluation and instrumentation are built together where the system needs them rather than added as an afterthought.

   • System and workflow implementation
   • Integrations and state handling
   • Relevant evaluations and acceptance checks
   • Observability and instrumentation
   • Failure and recovery controls
4. 04

   Integrate

   Wire it into your stack as it actually exists: your data, your services, your auth, your CI/CD and your operating environment.

   • Data and services
   • Auth and permissions
   • CI/CD and deployment workflow
   • Operating environment and ownership boundaries
5. 05

   Harden

   Exercise the system against realistic failure conditions, validate its boundaries and recovery paths, and make release decisions from evidence rather than judgement alone.

   • Validation against the criteria set in Design
   • Representative and adversarial scenarios
   • Failure injection where appropriate
   • Permissions and action controls
   • Fallback and recovery paths
   • Release readiness evidence
6. 06

   Deploy

   Release through the controls appropriate to the system, with explicit decision and recovery paths rather than assumptions made at deploy time.

   • Controlled release
   • Release policy and evidence
   • Ship, hold or escalate decision path
   • Rollback or fallback path appropriate to the system
7. 07

   Operate

   Watch real production behaviour, detect material departures from agreed operating thresholds, and route them into defined response, recovery or escalation paths.

   • Observability of real production behaviour
   • Drift and behaviour monitoring
   • Operating thresholds and SLOs where appropriate
   • Incident and escalation paths
   • Release-control maintenance
   • Evaluation and acceptance maintenance where relevant
   • Runbook and ownership updates
   • Ongoing operation where that is the agreed model

Not every engagement runs all seven.

Depth is matched to the problem. Some work starts after discovery already exists. Some needs deep hardening and light design. Some stops at deployment, with operations handed back to your own team. Ongoing operation is available where you want it and is never a requirement of the work before it.