How we work / The Lighthouse

One boundary. Defined before it is built. Evidenced before the next one begins.

Large-scale programmes try to govern too much too early. The lighthouse starts with one exchange boundary, governs it completely, evidences what changed, and only then extends. One proven boundary is worth more than a broad programme that cannot show what it improved.

The lighthouse model
01
Assessment
Exchange conditions discovered. One boundary identified as the lighthouse candidate.
02
One boundary
Seven Flows composed for this specific choreography. SafeMesh supervising.
03
Evidence
Measured against criteria defined during the assessment. Production-grade safety case.
04
Next boundary
Additive expansion. Same governed architecture. New specification composed within it.

A boundary is a governed exchange. One organisation releasing responsibility. Another accepting it.

Not a system integration. Not an API connection. The moment at which clinical responsibility, evidence, and obligation move between organisations. The lighthouse governs that moment.

Releasing
Organisation A
Obligation ending
Governed boundary
Bilateral transfer
Accepting
Organisation B
Obligation beginning
Responsibility
Who holds it, from when
Evidence
What transfers, what stays
Consent & intent
Scope confirmed at exchange
Alert obligation
Who acts if state changes

In a urology pathway, this might be the moment the surgical team transfers post-operative responsibility back to the GP. One transfer. One set of questions about what information accompanies it, what the GP is expected to act on, what the patient has consented to, and who carries the alert obligation until the first outpatient follow-up.

The Seven Flows, composed for one specific boundary.

The Seven Flows are not applied generically. They are configured for the choreography the assessment discovered. No two boundaries are identical. What differs is the consent scope, the provenance requirement, the alert configuration, the routing rules.

Identity

Verified at exchange

Both parties confirmed. Patient identity corroborated at the boundary, not assumed from upstream.

Consent

Scope confirmed

Consent scope validated for this specific exchange. A surgical discharge requires different consent confirmation than a GP referral.

Provenance

Evidence state recorded

What evidence crosses the boundary, what remains with the releasing organisation, and the completeness of each at the moment of transfer.

Clinical intent

Purpose documented

The clinical reason for the exchange. Intent for a post-operative handover is different from intent for a diagnostic referral.

Alert & responsibility

Obligation assigned

Who holds alert responsibility, from when, until what trigger. Configured for the specific temporal and clinical conditions of this boundary.

Routing & outcome

Paths defined

Where the patient goes next and what constitutes a successful exchange. Outcome criteria defined during the assessment, not assumed.

SafeMesh supervises this composition in real time. It knows what the protocol requires at each step, enforces the correct sequence, and surfaces violations before they propagate. Governance is not assumed. It is held active.

The difference between assumed governance and supervised governance.

Most frameworks define the rules and rely on individuals to follow them correctly under pressure, across shift changes, without any mechanism that surfaces a violation before it becomes harm.

Conventional
Governance assumed
  • Rules defined in documentation
  • Compliance expected, not enforced
  • Violations discovered after the fact
  • Audit reviews what happened
  • Gap between policy and practice widens
SafeMesh
Governance supervised
  • Protocol enforced at each step
  • Correct sequence required, not expected
  • Violations surfaced before they propagate
  • Supervision operates in real time
  • Governance held active at the boundary

Success is defined during the assessment. Not after implementation.

The lighthouse is measured against whether the boundary is safer, clearer, and better evidenced than it was before. These metrics are selected because they reflect what the boundary is currently producing.

Measure

Missed results

Evidence that reached a boundary and was not acted on. Does that rate change?

Measure

Transfer delays

Time between responsibility transfer initiated and confirmed. Does that window close?

Measure

Near misses

Reported incidents that cluster around the boundary. Do they reduce?

Measure

Responsibility clarity

Clinician-reported clarity about who holds responsibility at each moment.

Why one boundary first. How scale happens.

Not because the wider pathway is irrelevant. Because one governed, evidenced boundary produces something a broad programme cannot: credible proof of what changed and why.

Implement

One governed boundary

Seven Flows composed. SafeMesh supervising. Exchange conditions that clinicians were compensating for become exchange conditions that infrastructure holds.

Evidence

Measured proof

Not a pilot report. A production-grade safety case, an evidence record, and a clear account of what changed at the boundary and why.

Extend

Next boundary additive

The infrastructure does not change. A new specification is composed within the same governed architecture. Clinical trust compounds.

Complex, multi-boundary pathways become governable one boundary at a time. Each one proven. Each one additive. Each one building the clinical and organisational confidence the programme needs to continue.

The lighthouse begins with the assessment.

If you have completed an assessment, or want to understand whether your boundary is a candidate, we should talk.

Talk to us Learn about the assessment →