Six phases. One operating standard.

The six phases

From diagnostic to run, one continuous operating loop.

1. 01

   Diagnostic

   1–3 weeks

   What is actually breaking, and what is the cost of not acting.

   Inputs

   • Stated brief from sponsor
   • Stack, vendors, contracts in scope
   • Compliance and risk perimeter
   • Operating constraints (people, time, budget)

   Outputs

   • Reframed problem statement
   • Failure modes and second-order risks mapped
   • Go / no-go recommendation with rationale
   • Engagement scope and named partner sign-off
2. 02

   Architecture

   2–6 weeks

   The operating layer designed before a single line of code is shipped.

   Inputs

   • Diagnostic memo
   • Reference architecture per workload class
   • Regulatory baseline (EU AI Act, GDPR, DORA, NIS2, HIPAA, MDR)
   • Existing platform constraints

   Outputs

   • Operating architecture document (ADR set)
   • Data flows, residency, retention, encryption posture
   • Model routing and human-in-the-loop checkpoints
   • Audit-trail design and kill-switch policy
3. 03

   Build

   8–24 weeks

   Production-grade systems. Not POCs.

   Inputs

   • Approved architecture document
   • Sprint cadence with named senior leads
   • Security baseline (least privilege, secrets, scanning)
   • Observability scaffolding from day one

   Outputs

   • Working software shipped to production environments
   • Hikari Blue Ops audit trail wired in
   • SLOs defined and instrumented
   • Operator runbooks and on-call rota draft
4. 04

   Governance

   Continuous

   Evidence emitted by the platform itself, not assembled before the audit.

   Inputs

   • Regulatory perimeter (EU AI Act Articles 12, 14, 15)
   • Customer audit clauses and DPA addendum
   • Incident response framework
   • Sub-processors list and notification cadence

   Outputs

   • Immutable audit trail per workload
   • Human-in-the-loop checkpoints active and testable
   • Kill switch tested quarterly
   • Regulator-ready evidence pack on demand
5. 05

   Adoption

   Overlap with Build + Run

   Adoption begins with clarity, not with polish. Fail here and the system never reaches production. Adoption is taught, not assumed. See the training paths that ship with this phase→

   Inputs

   • End-user workflow shadowing
   • Change-management plan with named sponsors
   • Training material co-authored with operators
   • Friction logs from staged rollout

   Outputs

   • Adoption signal dashboard (real usage, not seats)
   • Help system and escalation path live
   • Internal champions briefed and equipped
   • Iteration backlog driven by friction signal
6. 06

   Run

   Defined or open-ended

   Run is the longest phase, not the leftover one. Treated as the first.

   Inputs

   • Production system with audit trail and SLOs
   • On-call rota across follow-the-sun (Austin · Paris · Tokyo)
   • FinOps baseline (cost per workload, per workflow)
   • Run discipline contract with named owner

   Outputs

   • Monthly run review with the named partner
   • Cost optimization actions, signed and traced
   • Incident reviews with lessons-learned memos
   • Defined transfer-of-ownership milestone