Leva HealthLeva Health, home

Platform

A system, not a set of features

Each stage below separates what exists in the demonstrator from what is synthetic, what needs funded research and what needs an NHS approved environment. Those are four different things and they are not interchangeable.

From signal to accountable execution.

Seven stages. Each states its inputs, the rule it applies, the authority it needs and the record it leaves.

  1. Understand operational state

    State is projected from the event history on every read rather than stored and mutated.

    Inputs
    Synthetic pathway events, in the order they occurred.
    Authority
    None required. Reading state changes nothing.
    Recorded
    State version and hash recorded with each projection.
  2. Detect a constraint

    Deterministic detectors for delay, missing prerequisite, stale dependency, non-response, conflict, and a review expected by a recorded date with no matching booking.

    Inputs
    Projected state, elapsed time, dependency status.
    Authority
    None required. Detection is observation.
    Recorded
    Constraint identifier, facts, detector version and stated uncertainty.
  3. Propose the permitted next action

    Only catalogued actions may be proposed. The planner cannot invent one.

    Inputs
    The constraint and the action catalogue.
    Authority
    The proposal carries the class the catalogue assigns; it cannot choose its own.
    Recorded
    Proposal identifier, reason, evidence and expected outcome.
  4. Check authority and evidence

    authority boundary

    Deny by default. Uncatalogued, clinical or insufficiently evidenced proposals are refused.

    Inputs
    The proposal, the policy set and the evidence attached to it.
    Authority
    The policy engine decides. This is the boundary.
    Recorded
    Verdict, reason code and policy version.
  5. Obtain human approval where required

    authority boundary

    One named role for bounded action, two for higher impact, and they cannot be the same person.

    Inputs
    The approved proposal and the required approver roles.
    Authority
    A named human. An expired approval is never treated as consent.
    Recorded
    Who decided, when, and whether they approved, rejected or amended.
  6. Execute through an approved integration

    A repeated call has one effect. External systems are simulated in the demonstrator.

    Inputs
    The authorised action and an idempotency key.
    Authority
    Already established. Policy is re-checked immediately before execution.
    Recorded
    Connector call, input and output hashes, outcome.
  7. Record, monitor and evaluate

    Bounded retries, compensating action on partial failure, escalation on the rest.

    Inputs
    The executed action and its expected outcome.
    Authority
    Escalation transfers ownership to a named human.
    Recorded
    Appended to a tamper evident chain; each record hashes its predecessor.

What a run actually produces

Real records from a seeded run, not an illustration. The same scenario at the same seed produces the same records in the same order.

A recorded run of the follow-up integrity demonstrationSynthetic data
The first fourteen audit records from a synthetic demonstrator run
SeqElapsedClassEventOutcomeRecord
102:00—Constraint detectedA required step was never requested483ebcaa7a
202:00AAuthority decisionPermitted — the system may act1379694e61
302:00AAction executedCarried out against a simulated systemd8a0e68e1e
402:00—Outcome confirmedResolved28b3c4492c
504:00—Constraint detectedA freed appointment slot could be reusedd870e2155f
604:00CAuthority decisionRefused by policy7ab389e453
704:00—EscalatedRefused: outside what the system may decide279457f872
804:00—Constraint detectedA freed appointment slot could be reusedf92b227b7e
904:00CAuthority decisionRefused by policydb7fa0a79b
1004:00—EscalatedRefused: outside what the system may decide20c191f736
1106:00CAuthority decisionStopped, waiting for a named person3959679732
1206:00CApproval requestedWaiting for a named persona435fe7ca2
1308:00CApproval decisionWaiting for a second signature86bb60db5b
1408:00CApproval decisionApproved by a named role1a513aa460
Showing 14 of 47 records from this run.
Technical identifiers, to reproduce this run
Scenario
thin_slice_v1
Seed
20260901
Fixture
05f3ce734395bc8c
Event ledger
8cbed31c9e59f482
Real records from the demonstrator, not an illustration. Running the same scenario at the same seed produces the same records in the same order — which is what makes it possible to quote them here at all. Every row is hashed to the one above it, so altering any of them breaks verification from that point onward.

Stage by stage

  1. 01

    Understand the organisation and pathway state

    State is projected from an event history on every read rather than stored and mutated, so the same events always produce the same state and any point in a run can be rebuilt exactly.

    Exists in the demonstrator

    Deterministic projection and replay across seeded scenarios.

    Synthetic or modelled

    All events are invented. Volumes are small — five pathways, not five thousand.

    Not built: needs research

    Ingesting real pathway state that arrives late, out of order and contradictory across systems.

    Requires an NHS approved environment

    Any connection to a live source system.

  2. 02

    Detect operational constraints

    Deterministic detectors identify delay, missing prerequisite, stale dependency, non-response, conflicting state, and a review that was expected by a recorded date with no matching booking — each carrying the facts that triggered it and an explicit uncertainty value.

    Exists in the demonstrator

    Seven detectors with reason codes, facts and stated uncertainty.

    Synthetic or modelled

    Thresholds are demonstrator defaults with no evidential basis, and are labelled as such.

    Not built: needs research

    Whether detectors transfer to real data, and what false positive rate is tolerable in a real workflow.

    Requires an NHS approved environment

    Calibration against observed baselines.

  3. 03

    Generate candidate interventions

    A planner assembles a response from the action catalogue, with its reason, its evidence and the authority it requires attached. It cannot invent an action that is not catalogued.

    Exists in the demonstrator

    Ranked proposals from a nine-action catalogue, each with evidence.

    Synthetic or modelled

    The catalogue is hand authored for one invented service.

    Not built: needs research

    AI assistance in interpretation and planning, inside the same policy controls, measured against the deterministic baseline.

    Requires an NHS approved environment

    A catalogue agreed with the organisation that will operate it.

  4. 04

    Apply authority and policy

    The policy engine decides. Deny by default: anything uncatalogued, clinical or insufficiently evidenced is refused and recorded. An action’s class is a property of the catalogue, resolved at decision time.

    Exists in the demonstrator

    Five authority classes enforced; clinical and uncatalogued requests refused and audited.

    Synthetic or modelled

    The policy set is ours, not an organisation’s.

    Not built: needs research

    Where a real organisation is willing to place the boundary, and evidencing that it holds.

    Requires an NHS approved environment

    Agreement on delegated authority, with clinical safety and governance sign-off.

  5. 05

    Coordinate approved execution

    Permitted low-risk actions execute with idempotency controls so a repeated call has one effect. Everything else waits for named human approval, which can be given, refused, amended or allowed to expire.

    Exists in the demonstrator

    Idempotent execution, approval queue, separation of duties, expiry, rejection.

    Synthetic or modelled

    Every external system is a simulator implementing an interface.

    Not built: needs research

    Integration with real systems, and identity assurance for the people approving.

    Requires an NHS approved environment

    Any write to an operational system.

  6. 06

    Monitor and attribute outcomes

    The system checks whether an action produced its expected outcome, retries within bounds, applies compensating action on partial failure and escalates what it cannot resolve to a named human.

    Exists in the demonstrator

    Outcome monitoring, bounded retry, compensation, SLA escalation, injected failure recovery.

    Synthetic or modelled

    Outcomes are compared against a no-action and a manual comparator built from stated assumptions.

    Not built: needs research

    Attributing operational change in a live service against a moving baseline.

    Requires an NHS approved environment

    Prospective evaluation with a declared comparator.

  7. 07

    Create inspectable evidence

    Every step appends to a tamper evident chain recording actor, authority class, evidence, policy version, input and output hashes, and outcome. Altering a record breaks verification from that point onward.

    Exists in the demonstrator

    Hash-chained records, verification, a tamper demonstration and a machine-readable evidence export.

    Synthetic or modelled

    In-memory for the demonstrator, with no retention policy.

    Not built: needs research

    Durable, access-controlled retention and external anchoring.

    Requires an NHS approved environment

    Records covering real people and real actions.

Current focus: follow-up integrity

A clinician records that a patient should be reviewed by a certain date. The date passes and no appointment has been booked. Nothing fails loudly, so nothing surfaces — which is what makes it a good place to test whether software can find the exception without deciding anything clinical.

We are not claiming a universal diagnosis of NHS elective care. Every service is organised differently, and the teams doing this work already know where their own friction sits far better than we do.

What we are testing is narrower: that in some services, material manual coordination sits between an operational issue becoming visible and the next appropriate step happening — and that an execution layer restricted to a fixed, pre-authorised list of actions could reduce it without touching clinical judgement.

Leva Health's thesis is that material manual coordination sits between detecting a blocked pathway and resolving it, and that a controlled execution layer could close that gap.

In a synthetic scenario the demonstrator identifies a review that was expected by a recorded date and has no matching booking, prepares the permitted administrative response, and routes the cases it cannot resolve from the record to a named person rather than deciding them.

The problem, the published evidence, and what it does not show

This is the proposition under test, not a finding. We have not completed NHS discovery. If experienced operational staff tell us the gap is immaterial or already adequately handled, that is a stop condition and we would rather know now.

A fictional follow-up, stage by stage

Synthetic data. No real patient, clinician or NHS system.illustration

Every label below is invented. It exists to show the shape of the problem, not to represent any real service or patient. Note where it stalls: not on a step that failed, but on one that never happened.

  1. Referral receivedRecorded in the referral systemcomplete
  2. First outpatient appointmentAttendedcomplete
  3. Review interval recordedClinician records: review in four monthscomplete
  4. Review appointment bookedThe date has passed. Nothing is recorded against itstalled
  5. Patient reviewedCannot happen without an appointmentblocked
  6. Next decisionDependent on the review aboveblocked

Where operational state goes wrong

Incomplete
The state exists somewhere but not where the team is looking. A dependency shows as outstanding because nobody has written back.
Delayed
The state is correct but arrives after it was needed. A result lands in one system days before it is visible in another.
Contradictory
Two systems disagree. A slot shows as confirmed while its prerequisite is still outstanding, and nothing decides which is right.

A detector that performs well on clean, well-ordered events may perform badly on all three of these. That is the central open question, and it has a real negative answer available.

Where the boundary sits

Administrative coordination

Chasing an outstanding dependency, raising a coordination task, recording that a prerequisite is missing, escalating an overdue item to a named role, preparing a communication for approval.

Clinical judgement

Diagnosis, treatment, clinical priority, clinical suitability and eligibility. Routed to an authorised clinician and never decided by the system. A refusal here is the architecture working.

A request requiring clinical judgement is refused by the real policy engine and routed to a clinician, rather than by a scripted animation.

The research questions

  1. 01Can AI reasoning, held inside the policy controls, interpret heterogeneous operational pathway state reliably enough to be useful?
  2. 02Can it generalise across pathway types without unsafe pathway specific shortcuts?
  3. 03Can deterministic policy controls prevent actions beyond declared authority?
  4. 04Can the system reduce time from operational issue to appropriate action without producing unacceptable workflow noise?
  5. 05Can productivity effects be measured using a prospective comparator and independently reviewed assumptions?

Challenge the assumptions

We are inviting NHS professionals to review the synthetic demonstrator and tell us where the workflow is unrealistic, where the authority boundaries sit wrongly, and what would need resolving before any evaluation. Review takes about 25 minutes and is by individual invitation.

Read further