The permanent structure for following a verified run from architecture, through execution, to receipt and bounded public claim.
The LAKANA Proof Library is being organized as the public bridge between system architecture, domain simulations or workbenches, run receipts, component-by-component authority traces, SSES adjudication, and public claim boundaries.
Structural index established. Complete run-level proof records, receipts, SSES visualizations, and artifact lineage are being assembled and will be published only when their source records are verified. Nothing below is a completed proof record.
Three surfaces, three different jobs
These three surfaces are connected but must never be mistaken for one another.
Defines component authority, state classes, interfaces, dependencies, refusal behavior, maturity, and disclosure boundaries.
Open Architecture →Executes or demonstrates a bounded public-safe model or interface and may produce a run result or receipt.
Open an execution surface →Reconstructs the run against the architecture: what each component did, when it did it, why it acted, what it accepted or refused, and what the evidence may support publicly.
See the record template →Architecture ≠ simulation/workbench ≠ Proof Library
Required statement: Architecture defines the system. Simulation or workbench pages exercise bounded behavior. The Proof Library connects verified run artifacts and receipts back to the architecture, authority sequence, SSES adjudication, and public claim boundary.
SOS — Safety Operating System
Structure established. Verified run records and evidence content have not yet been populated.
Future record anatomy — template only, this is not a completed proof record
- Scenario and declared assumptions
- Input manifest
- Future CivOS trace — will explain the current capability and operating-mode state during the run, and what it made possible or unavailable. Not yet populated.
- Future SOS trace — will explain how local observation became minimized incident state. Not yet populated.
- Future TSARO trace — will explain the admissibility question evaluated and its result. Not yet populated.
- Future NICOLE Protocol trace — will explain the custody/release decision and its scope. Not yet populated.
- User-interface result — the bounded state actually presented to the user's own device.
- Future optional BFB trace — will explain, only when the responder branch was taken, what the responder-scoped incident packet contained and when it was authorized. Not yet populated.
- Future optional TAB trace — will explain, only when a TAB session was separately requested and authorized, its request/accept/deny/connect/disconnect/revoke/expiry sequence. Not yet populated.
- Future receipt and artifact lineage
- Future SSES adjudication
SSI — Sovereign Structural Intelligence
Structure established. Verified run records and evidence content have not yet been populated.
Future record anatomy — template only, this is not a completed proof record
- Scenario and declared assumptions
- Cohort/lane and source manifest
- Future CivOS trace — sensor and compute capability available during the run. Not yet populated.
- Future SSI trace — the structural-state computation applied to the admissible inputs. Not yet populated.
- Future TSARO trace — the safety-envelope evaluation applied to the resulting state. Not yet populated.
- Future NICOLE Protocol trace — the role/scope evaluation governing which view each recipient receives. Not yet populated.
- Future role-release trace — how the athlete/worker, coach, medical/training, and research views diverge from the same underlying run. Not yet populated.
- Future receipt and artifact lineage
- Future SSES adjudication
W-X / WX-Ag — Environmental Truth and Agronomic Consequence
W-X = environmental truth. WX-Ag = optional agronomic consequence. These are kept as separate evidence records so environmental truth evidence and agricultural interpretation evidence are never blended into one indistinguishable record.
W-X — environmental truth
Structure established. Verified run records and evidence content have not yet been populated.
Future record anatomy — template only, this is not a completed proof record
- Observation/source manifest
- Future CivOS trace — sensing/transport capability during the observation window. Not yet populated.
- Future freshness and TTL trace
- Future agreement/contradiction trace
- Future drift and uncertainty trace
- Future truth classification (supported / degraded / contradictory / drifting / quarantined / expired / silent)
- Future receipt and artifact lineage
- Future SSES adjudication
WX-Ag — optional agronomic consequence
Structure established. Verified run records and evidence content have not yet been populated.
Future record anatomy — template only, this is not a completed proof record
- Accepted or explicitly degraded W-X state consumed
- Future CivOS trace
- Future WX-Ag consequence-computation trace — ET₀ source class, VPD, soil/root-zone state. Not yet populated.
- Future TSARO trace, where a physical admissibility boundary applies
- Future NICOLE Protocol trace, where sharing or custody applies
- Future farmer/operator interface result
- Future receipt and artifact lineage
- Future SSES adjudication
Common authorities — CivOS, TSARO, NICOLE Protocol
Every domain proof record includes the applicable CivOS, TSARO, and NICOLE Protocol execution trace. These authorities are not treated as separate standalone simulations merely to satisfy page structure. They are cross-cutting authorities exercised inside SOS, SSI, and environmental runs — not domains with their own separate simulation pages.
Will explain: current capability state; sensing, compute, storage, and transport availability; local-only/store-forward/preservation behavior; what CivOS made possible; what it made unavailable; what the user saw.
Will explain: the state and uncertainty received; the admissibility question evaluated; the admitted/held/degraded/blocked/quarantined/fail-closed/silent result; the downstream effect; protected parameters withheld.
Will explain: the requesting role, purpose, requested scope, lease, consent or valid doctrine, integrity; the permit/narrow/deny/revoke/expire/preserve result; the downstream recipient; the audit or custody event; protected policy internals withheld.
Structure established. Verified run records and evidence content have not yet been populated.
SSES — future evidence-adjudication framework
Every future SOS, SSI, W-X, or WX-Ag run record will receive an SSES adjudication package built from the eight canonical layers. Visual framework established. Run-specific charts are published only when backed by a verified run artifact and source lineage. No run-specific value is displayed until then.
Open the SSES chapter in Architecture for the full authority definition and the branch-portability map.
Question: how much could this run's output plausibly vary given its declared bound and confidence level?
Future visual: an interval and directional-stability plot — point estimate, uncertainty interval, sign/directional boundary, declared unit. Incompatible units are never combined on one axis.
Source-lineage requirement: a verified run artifact with a declared bound and confidence level.
Visualization reserved. No run-specific value is displayed until a verified source artifact and lineage record are available.
Question: does the result persist coherently along its declared source path?
Future visual: a source-path map — source → input manifest → analysis → output/table → figure/receipt → public claim — labeled complete, neutral, contradictory, missing, or unsupported at each step.
Source-lineage requirement: a traceable chain from source to published claim.
Visualization reserved. No run-specific value is displayed until a verified source artifact and lineage record are available.
Question: where does this run land on the retained-time-versus-burden surface?
Future visual: a two-axis interpretation surface — retained time, managed burden, quadrant/classification, declared unit — with its public interpretation boundary stated alongside.
Source-lineage requirement: a verified run with both a retained-time and a burden measure declared.
Visualization reserved. No run-specific value is displayed until a verified source artifact and lineage record are available.
Question: is this model family's evidence computed, reconciled, and ready to support a claim?
Future visual: a two-dimensional matrix — model family by execution/adjudication state (computed, reconciled, packaged, packaging pending, contextual, excluded, claim eligible, claim held).
Source-lineage requirement: a verified per-model-family execution and reconciliation record.
Visualization reserved. No run-specific value is displayed until a verified source artifact and lineage record are available.
Question: after declared penalties, how much release-sufficiency does this evidence retain?
Future visual: a decomposition — base source/aggregate fidelity, minus exposure adjustment, minus proxy or heuristic adjustment, equals normalized release sufficiency. Not a general safety score.
Source-lineage requirement: a verified base fidelity value and its declared penalty terms.
Visualization reserved. No run-specific value is displayed until a verified source artifact and lineage record are available.
Question: how completely does every claim trace back to a declared source?
Future visual: a lineage graph — source → input manifest → run → output → figure/receipt → claim → limitation → public boundary.
Source-lineage requirement: a complete declared chain from source to claim.
Visualization reserved. No run-specific value is displayed until a verified source artifact and lineage record are available.
Question: how much leverage may a sensitivity result exert on a public claim?
Future visual: a sensitivity map — sensitive parameter/input class, affected output, affected claim, leverage classification, and a disclose/narrow/hold/withhold result.
Source-lineage requirement: a verified sensitivity analysis with an explicitly linked claim boundary.
Visualization reserved. No run-specific value is displayed until a verified source artifact and lineage record are available.
Question: which tail rows are eligible for traceable attribution?
Future visual: a tail-eligibility frontier — tail event, eligible numerator, eligible denominator, shared source/support rule, denominator validity, claim eligibility, with any forbidden incidence interpretation stated alongside.
Source-lineage requirement: matched, source-consistent numerator and denominator records for the tail event.
Visualization reserved. No run-specific value is displayed until a verified source artifact and lineage record are available.
Proof record template
Template only — this is not a completed proof record. This is the structure every future verified record will follow. Fields marked "Required verified field" are populated only from a verified run artifact; "Not yet populated" fields carry no value until then.
- Record title — Not yet populated
- Domain — Not yet populated
- Run/artifact identifier — Required verified field
- Execution surface — Required verified field
- Architecture version — Required verified field
- Source/input manifest — Required verified field
- Declared assumptions — Required verified field
- Scenario — Required verified field
- CivOS trace — Required verified field
- Domain-engine trace — Required verified field
- TSARO trace — Required verified field
- NICOLE Protocol trace — Required verified field
- Human-interface result — Required verified field
- Optional external/responder branch — Required verified field, where applicable
- Receipt or artifact — Required verified field
- SSES eight-layer adjudication — Required verified field
- Allowed public claim — Required verified field
- Forbidden stronger claim — Required verified field
- Evidence maturity — Required verified field
- Operational maturity — Required verified field
- Limitations — Required verified field
- Supersession state — Required verified field
- Reproduction availability — Required verified field
- Protected implementation boundary — Required verified field
- Related architecture section — Required verified field
- Related simulation/workbench — Required verified field
- Related paper/evidence page — Required verified field
The full Proof Library rebuild — inspecting verified simulation artifacts, identifying real run and receipt records, mapping the architecture sequence for each run, constructing real SSES visuals from verified data, establishing source lineage, and determining allowed and forbidden claims — is explicitly deferred to the next dedicated project. This structural pass does not begin that evidence-population work.
Public-safe mathematics reference
These cards support future proof records but are not themselves complete proof records. They describe governing mathematical form only; exact coefficients, thresholds, and production parameters remain protected.
Safe-set projection (TSARO)
TSARO treats a subject, device, or subsystem as a bounded state. If the current state approaches or violates the safe set, the system computes the smallest feasible correction. If no feasible correction exists, it routes to fail-closed.
SSI structural pressure
SSI uses public-safety structural proxies: load, recovery, thermal stress, and strain accumulation. These are engineering state variables, not diagnoses.
W-X environmental truth
External location/environment claims must remain consistent with local physics. Expired environmental state decays to null/silence rather than pretending to remain true.
NICOLE Protocol ledger entry
Public ledger demonstrations show only bounded headers and hashes. The purpose is custody and release/non-release accountability, not public raw-data disclosure.
Pumpkin key-lifecycle profile
Expiration is modeled as key invalidation, not mere file deletion. Public pages may describe the concept without exposing actual keys.
Non-claim: this does not prove physical erasure or absolute unrecoverability across every device, compiler, memory subsystem, crash path, swap path, or forensic condition. See the Pumpkin profile in Architecture for the full boundary.
Claim boundaries
Every public model output remains simulation-bound unless separately validated. The site must not claim clinical validation, field efficacy, regulatory clearance, privacy theorem, or emergency-service certification.