CQC + DSP inspection leads
Inspection packs assembled from sealed posture artefacts — verifiable, auditable, supersession-aware. The work shifts from 'collect evidence' to 'prove the evidence is what it says'.
← PortikoPreview
01.4 — Beacon
Assurance posture,
computed from real evidence.
Beacon reads Cadence, Relay, and Quorum's operational state and mechanically computes assurance posture — no narrative claims, no retrospective evidence assembly. Postures are sealed into integrity-protected packs; supersession checks tell you when an earlier pack has been overtaken.
- Status
- Preview
- For
- Compliance + assurance leads
- Live evaluators
- Three (Cadence, Relay, Quorum)
- Pricing
- TBD
A — Who Beacon is for
For organisations where assurance evidence has to hold up to scrutiny.
Beacon is built for the people who answer the inspector's questions, prepare the assurance pack, and stand behind the claim that 'we do X'. It produces evidence with the integrity properties of a sealed institutional document, not a marketing PDF.
Clinical governance leads
Continuous assurance posture across incidents, audits, complaints, and meetings — computed from Cadence's operational state rather than hand-curated for the next governance meeting.
Multi-committee governance roles
Discharge-evidence for obligations on the Quorum side: did the committee actually discharge what it was bound to discharge? Beacon answers that mechanically, not narratively.
B — How it works
Four pillars: mechanical, sealed, supersession-aware, refuses-theatre.
Beacon's pillars are commitments about what it does and what it refuses to do. The vocabulary, the integrity properties, and the linter are each load-bearing — remove any one and the rest stops being defensible.
01
Mechanical
Posture is computed from real operational state, not authored as a narrative claim. Each evaluator reads upstream evidence (Relay's audit log, Cadence's event_log, Quorum's chronology) and derives the posture from the facts.
02
Sealed
Every assurance pack carries a sha-256 integrity hash over its canonical form (keys sorted, no whitespace variance). A pack that has been altered since sealing fails verification — proof that the evidence presented is the evidence captured.
03
Supersession-aware
Verifying integrity is not the same as verifying currency. The supersession check re-runs the evaluator and diffs against the sealed state, reporting one of four outcomes: aligned, drifted, tampered, unverifiable. Drift is informational; materiality is operator concern.
04
Refuses theatre
A forbidden vocabulary catches the assurance-theatre words that turn posture into marketing — 'world-class', 'best-in-class', 'comprehensive', 'cutting-edge'. If the chain or claim uses them, the linter refuses.
C — Components
Eight components, one assurance system.
Beacon is composed of substrate elements (vocabularies, contracts, dependency declarations) and executable elements (evaluators, sealers, verifiers, supersession checkers). The substrate is what's defensible; the executables are how it gets enforced.
- 01
Posture vocabulary
Closed set of posture states (`well-evidenced`, `partially-evidenced`, `chain-incomplete`, etc.) — each grounded in observable evidence counts.
- 02
Weakness signals
Closed set of weakness signals (`staleness`, `accountability-orphan`, `chain-break`, `claim-without-chain`) — each maps to a specific upstream failure mode.
- 03
Evidence types
Operational / documentary / attestational — distinct evidence weights for distinct verification capacities.
- 04
Evaluators
Three live evaluators (Relay pathology, Cadence incidents, Quorum obligations) compute posture from the substrate's real data.
- 05
Sealed packs
Pack = chain + facts + posture, hashed with sha-256 over canonical form. Verifiable, auditable, transportable.
- 06
Supersession check
Re-runs the evaluator against current upstream state; reports aligned / drifted / tampered / unverifiable with per-field deltas.
- 07
Forbidden vocabulary
Closed list of assurance-theatre terms the linter refuses — turns posture into evidence, not marketing.
- 08
Dependency contracts
Cross-system contracts (e.g. Cadence vocabulary stability, Quorum substrate snapshot) that fail closed if upstream drifts.
D — What Beacon shows
Three real outputs from the running evaluators.
Beacon has no UI. Its artefacts are CLI outputs and sealed-pack JSON, captured against the real Relay + Cadence operational corpora. Each output below is verbatim from a recent run — posture computed mechanically, integrity proven cryptographically, supersession reported state-by-state.
$ pnpm beacon:evaluate-live chain: CHAIN-RELAY-PATHOLOGY-REVIEW-001 claim: CLAIM-RELAY-PATH-ORG-MEADOWVIEW-2026-05-15 org: ORG-MEADOWVIEW upstream: 15 results · 1 acknowledged · 10 actioned · 1 distinct reviewer(s) postures: challenge-absent links covered: 3/3 weakness signals: absent-challenge
$ pnpm beacon:verify-pack beacon/packs/example-cadence-incident-lifecycle.json [beacon-verify-pack] ok — PACK-87d8642b verified (cadence-incidents, chain=CHAIN-CADENCE-INCIDENT-LIFECYCLE-001)
$ pnpm beacon:check-pack-supersession beacon/packs/example-cadence-incident-lifecycle.json
[beacon-check-pack-supersession] aligned — PACK-87d8642b
(cadence-incidents); integrity ok; 0 delta(s).
{
"supersession_status": "aligned",
"upstream_at_sealing": { "incidentCount": 2, "reviewedCount": 1, ... },
"upstream_now": { "incidentCount": 2, "reviewedCount": 1, ... },
"deltas": [],
"posture_at_sealing": [ "challenge-absent" ],
"posture_now": [ "challenge-absent" ]
}E — Honest notes
Things worth saying explicitly.
Beacon does not make a service safer.
It makes the evidence of safe practice mechanically defensible. The substance is the underlying clinical and governance practice; Beacon ensures the evidence of that practice can hold up to scrutiny.
Beacon is not a dashboard.
It computes posture from upstream state, seals it, and verifies it. Dashboards summarise; Beacon proves. The two are different operations, and proof is the harder one.
Beacon refuses claims its evidence can't support.
A chain that doesn't reach the claim it makes fails the evaluator. A pack with stale evidence reports `superseded`. The system is engineered to refuse, not to perform.
Beacon is preview, not GA.
Engineering-verified (28 acceptance tests across three live evaluators, sealed-pack roundtrip, supersession four-state outcome); not yet partner-deployed. Pilot access is by application.
F — Access
Pilot by application.
Beacon — pilot access
By application
Pricing follows pilot validation.
- · Founder-level support during pilot
- · Onboarding of your evaluators against your Cadence / Relay / Quorum
- · Sealed-pack pipeline integrated with your release cadence
- · Direct influence over GA evaluator vocabulary
- · Preferential GA pricing when published
Pilot partners commit to approximately two hours per month of feedback time across the first three months — an evaluator-fit review at month one, a sealed-pack workflow walkthrough at month two, a supersession materiality calibration at month three.
Apply for pilot accessG — Common questions
Frequently asked.
- What does Beacon do that I can't do with a spreadsheet?
- A spreadsheet can hold the evidence; it cannot mechanically verify that the evidence supports the claim. Beacon computes posture from upstream operational state, then proves the pack hasn't been altered since (integrity), and proves whether the upstream state has changed since (supersession). The work isn't 'collect evidence' — it's 'prove the evidence is what you say it is, and prove it hasn't been quietly rewritten'.
- Does Beacon make my service inspection-ready?
- No. Beacon makes the evidence of operational practice mechanically defensible. The underlying practice — the substance of safe care — is what an inspector judges. Beacon makes that judgement easier; it does not change it. If the operational practice isn't there, Beacon will report posture honestly and refuse to claim more.
- Can I use Beacon without Cadence / Relay / Quorum?
- Beacon's live evaluators consume the three substrates directly. Without one of them upstream, the corresponding chain can't be evaluated mechanically — you'd be back to hand-authored JSON facts. Beacon's value is the mechanical posture computation; that requires real operational state to read from.
- What's the difference between integrity and supersession?
- Integrity verifies a sealed pack has not been altered since sealing — sha-256 over canonical form. Supersession verifies a sealed pack still reflects current upstream state — re-runs the evaluator, diffs against the pack. A pack can have valid integrity but be superseded (drifted); it can have invalid integrity (tampered) regardless of currency. The two guarantees are distinct and orthogonal.