Foundation first. Boundary by boundary. Evidence from day one.
This is not a delivery methodology. It is the only sequence consistent with lawful operation, DCB 0160 compliance, and evidentiary integrity. The landing zone comes first because governed transfers depend on it. The lighthouse proves governance at one real boundary before scale. Every stage produces evidence, not just progress.
Start with a secure landing zone. Prove governance at one clinical boundary. Scale from evidence, not from promises.
Why this sequence is non-negotiable
Landing zone first because the Responsibility Ledger, Evidence Fabric, consent artefacts, and audit trails are only as trustworthy as the environment they run in. Without immutable logging, account separation, encryption under customer control, and UK data residency, governance artefacts have no evidentiary standing. The landing zone establishes the foundation that makes later governance mean something.
Lighthouse next because a governed boundary in production proves that the architecture works, the clinical safety case holds, and the regulatory evidence is real. Not a demo. Not a proof of concept. A real clinical pathway with a live Responsibility Ledger and a measurable Clearing Metric. Scale should be earned by evidence, not assumed by plan.
Scale only from evidence because each boundary deployment reuses foundational controls, compounds regulatory compliance, and extends the Clearing Metric across the network. Scaling before the lighthouse has proven governance means scaling before you know whether governance works. We do not do that.
What each stage produces
This is not a process timeline. It is a production sequence. Each stage creates specific governance artefacts, evidence objects, and operational capabilities that the next stage depends on.
- Secure accounts
- IAM federation
- CloudTrail
- KMS encryption
- UK residency
- SCP guardrails
- DSPT/CAF security baseline
- Account separation proof
- Encryption posture documentation
- Infrastructure security
- Data residency
- Access control
- First governed boundary
- First workload migrations
- Consent infrastructure
- MVRT protocols
- First DCB 0160 safety case
- First Evidence Fabric threads
- First Clearing Metric readings
- First LFPSE-ready reports
- "Does governance actually work in production?"
- Additional governed boundaries
- Continued workload migrations
- Shared controls reused
- Compounding regulatory evidence
- Growing Clearing Metric visibility
- NICE outcome data accumulating
- Deployment speed (each faster than last)
- Compliance coverage gaps
- Full boundary governance
- All viable workloads migrated
- Continuous safety monitoring
- Steady-state Clearing Metric (Volume, Age, Rate)
- Continuous DSPT/CAF evidence
- DUAA-ready information standards compliance
- Governance gaps across the network
Show and tell, not big bang
Every Inference Clinical engagement follows an iterative delivery model rooted in operational excellence. This is not just a delivery style preference. In a clinical safety context, iterative delivery with regular client visibility is structurally safer than big-bang delivery - and it directly supports DCB 0160 compliance for the deploying organisation. This is not our preferred delivery style. It is the only approach consistent with clinical safety requirements and evidentiary integrity.
Fortnightly show-and-tell cadence
The client's Clinical Safety Officer, medical director, Caldicott Guardian, and technical leads see progress, can raise concerns early, and contribute to design decisions. This cadence produces the evidence trail that DCB 0160, CQC inspections, and DSPT/CAF Objective A (governance and risk management) require.
Hazard log built incrementally
The clinical safety case is constructed alongside the implementation, not retrospectively. Hazards are identified, scored, and mitigated as features are built. This maps directly to DCB 0129 manufacturer obligations and produces LFPSE-ready incident classification from day one. Each delivery increment adds threads to the Evidence Fabric - the corroborated evidentiary substrate that makes every governance decision demonstrable after the fact. Each hazard logged is a risk retired. Each Evidence Fabric thread is a governance decision made demonstrable.
Regulatory compliance tracked continuously
DSPT/CAF outcomes, DTAC requirements, and Cyber Essentials controls are assessed at every sprint boundary, not at project completion. Compliance drift is detected and corrected within the delivery cycle.
Progressive boundary activation
Governance controls are activated boundary by boundary, not network-wide simultaneously. Each boundary deployment is tested, measured, and validated before the next begins. Each activation produces NICE Evidence Standards-compatible outcome data.
Client capability building
We do not just deploy and leave. Teams are trained to operate governed boundaries, maintain DCB 0160 compliance, submit DSPT assessments, and manage DTAC documentation. The goal is operational independence, not perpetual dependency.
Service design as governance discovery
Governance cannot be designed from architecture diagrams alone. Before the lighthouse proves that governance works, service design identifies what governance must govern: the real clinical workflows, the responsibility transfer moments, and the workarounds that indicate where governance is absent.
Understand the system before you govern it. Every clinical boundary has a human system: handover points between organisations, workarounds that clinicians have developed to compensate for missing data, consent decisions that happen informally because no formal pathway exists. Service design maps this human system - not to replace it, but to ensure that governance captures what actually happens, not what a process diagram says should happen.
Qualitative discovery with clinicians. Before designing governance controls, we conduct structured qualitative research with the clinicians who operate at the boundary. We capture workarounds, pain points, and informal responsibility transfers. These are not failures to be eliminated. They are evidence of governance gaps - and they tell us exactly where the Responsibility Ledger must operate.
Choreography maps, not just process maps. Standard process maps show what should happen. Choreography maps overlay the patient journey with the clinician's actual experience - marking every handover, every responsibility transfer moment, every point where information crosses an organisational boundary. These maps become the design input for the Responsibility Ledger and the Evidence Fabric. They ensure that governance captures real transfers, not assumed ones.
Co-design, then small testable interventions. Governance controls are co-designed with clinicians who verified the choreography maps. Changes are introduced as small, testable interventions at a single boundary - which is exactly what the lighthouse is. The lighthouse does not just prove that infrastructure works. It proves that governance works at the point where clinical responsibility actually transfers, validated by the clinicians who operate there.
Service design is not a separate workstream. It is how we ensure that SafeMesh governs the system clinicians actually work in, not the system an architecture diagram describes.
The Lighthouse Model
The lighthouse is not a de-risking strategy. It is the minimum viable proof that governance works before the organisation commits to scale. The engagement sequence is landing zone first, then boundary governance and workload migration in parallel. The landing zone (typically weeks 1-4) deploys the governed foundation. The lighthouse boundary (weeks 5-16) activates governance on a real clinical pathway while first workload migrations execute onto the governed infrastructure. Not a proof of concept. Not a demo. A real clinical pathway with real governance controls, real workloads migrating to governed cloud infrastructure, producing real operational data and real AWS consumption that inform the business case for scaling - and real regulatory evidence that satisfies DCB, DSPT, DTAC, and CQC requirements.
From Landing Zone to Network Operation
Landing Zone
Weeks 1-4- Secure, Well-Architected foundation deployed
- Governance invariants structural from day one
- Existing workloads assessed and migration roadmap produced
- DSPT/CAF-aligned security baseline operational
Key output: the secure foundation that makes all later governance artefacts trustworthy.
Lighthouse Boundary + First Migrations
Weeks 5-16- Single boundary governed in production
- First workload migrations executed in parallel onto governed landing zone
- DCB 0129/0160 clinical safety case complete for this boundary
- DSPT/CAF evidence generated through normal operation
- LFPSE-ready incident reporting active; AWS consumption begins ramping
Key output: the first live Responsibility Ledger, the first measurable Clearing Metric, and the first DCB 0160 safety case.
Boundary-by-Boundary Expansion + Continued Migration
- Each successive boundary deployment faster and cheaper
- Foundational controls serve multiple boundaries
- Regulatory compliance compounds (shared identity, shared consent, shared provenance)
- NICE Evidence Standards outcome data accumulates across boundaries
- AWS consumption grows with each boundary and each migrated workload
Key output: compounding regulatory evidence and growing Clearing Metric visibility across the network.
Network Operation
- Full boundary governance across the organisation's network
- All viable workloads migrated to governed AWS infrastructure
- Continuous clinical safety through SafeMesh
- Regulatory compliance maintained as infrastructure, not as periodic audit
- DUAA information standards met structurally as they are published
- The Clearing Metric becomes the steady-state operational measure - Clearing Volume, Clearing Age, and Clearing Rate tracked across every governed boundary in the network
Key output: steady-state governed operation with continuous assurance, not periodic audit.
Well-Architected through a healthcare lens
MAP funding supports the correct sequence
| Engagement Stage | MAP Phase | Funding |
|---|---|---|
| Assess (Boundary Audit) | MAP Assess | 5% of projected ARR as partner cash, up to $75,000 |
| Co-Design + Landing Zone | MAP Mobilize | 20% of projected post-migration ARR |
| Lighthouse + Workload Migration | MAP Migrate & Modernise | 25% of ARR as customer credits (Standard) or 15% (Lite) |
| Boundary Expansion + Continued Migration | MAP Migrate & Modernise (continued) | Credits continue as consumption grows |
MAP funding aligns with the delivery sequence, but it does not determine it. The Assess phase maps to MAP Assess. The landing zone maps to Mobilize. Migration maps to Migrate and Modernise. Funding makes the correct sequence easier to justify commercially. The reason to follow the sequence is safety, lawful operation, and evidentiary integrity. MAP makes it easier to fund.
Our deployment stance
We do not defer foundational controls in order to accelerate visible delivery. In healthcare, that creates the appearance of progress while increasing governance risk. The landing zone comes first because everything that follows depends on it.
We do not run big-bang healthcare cloud programmes that skip the secure foundation. We do not deploy governance software into environments that cannot demonstrate the required controls. This is the same principle applied throughout: governance must be non-bypassable, or it is not governance.
Related Content
Start with a boundary audit. We will tell you what the landing zone requires, what the lighthouse proves, and what it takes to scale from evidence.