01.4 — Beacon
Continuously prove
governance continuity
under inspection.
Beacon is the fourth system in the Portiko governance stack. The preceding three — Cadence, Quorum, Relay — author or sequence governance acts. Beacon does neither. Beacon synthesises across them to produce inspection-ready assurance: a defensible, reconstructable account of what happened, who had authority, where the evidence sits, and where governance is weak.
A — What Beacon answers
Institutional questions, not operational ones.
Beacon is calibrated to the questions an inspector, a board, or a regulator asks. Operational dashboards are explicitly not in scope; that work is Cadence's, Quorum's, and Relay's. Beacon's job is the next-order question — whether what those systems produced is defensible.
Are we inspection ready?
Across the four systems, do the chronology, evidence, authority, and escalation records assemble into a coherent picture an inspector can read?
Can we prove governance continuity?
Did obligations get registered, considered, discharged, and recorded — at the right time, by people with the authority to act?
What evidence supports this assurance claim?
For any specific claim a partner organisation makes about its governance, what artefacts in Cadence, Quorum, or Relay support it — and which claims are unsupported?
Where is governance weak, stale, or unevidenced?
Beacon surfaces weakness signals: obligations overdue, decisions without traceable evidence, authority exercised outside scheme, evidence past its valid-until window.
Can an inspector reconstruct what happened?
Given a date and a topic, can the chronology answer who did what, when, under what authority, with what supporting evidence — without reading minutes by hand?
Did organisational learning operationalise?
When a significant event produced a learning, did that learning land as a policy change, a re-audit, a training intervention — and did the next cycle measure whether the change held?
B — What Beacon refuses to be
Synthesis, not generation.
Beacon does not author governance acts. It does not write policy. It does not generate evidence. The temptation with synthesis tools is to drift into adjacent categories — KPI dashboards, performance management, AI-generated reports — that look similar but corrupt the doctrine.
Beacon's foundation pack codifies that refusal as a forbidden-vocabulary contract: certain framings (KPI, dashboard, performance, score) are doctrinally absent because they answer a different question than the one Beacon exists to answer. The boundary is not a limitation; it is what makes Beacon's outputs trustworthy under inspection.
C — Why this isn't built yet
Beacon reads what the upstream three produce.
Beacon is the synthesis layer over Cadence, Quorum, and Relay. Each of those needs to be producing real substrate — a chronology with real events, real outcomes, real authority records, real escalation chains — before there is anything coherent for Beacon to synthesise. Implementing Beacon against partial substrate would produce assurance claims that are themselves partial, which is the failure mode the doctrine is designed to prevent.
Beacon's foundation pack — six doctrine documents, three ADRs, six schema contracts, two upstream dependency contracts — is sealed. When the upstream three reach the maturity Beacon needs, implementation begins inside the constraints that pack defines, not in the freer mode earlier-stage products are built in.