LAKANA Sovereign Systems · reviewer surface

Evidence Posture

LAKANA separates architecture thesis, formal abstraction, simulation evidence, empirical support, source-governed research packages, prototype posture, and deployment claims. This page defines how strong each evidence type is allowed to sound.

Evidence ladderSimulation ≠ field validationEmpirical support ≠ certificationNo medical diagnosisNo emergency-service certificationNo official weather authority

Evidence ladder

Each claim must stay inside its evidence tier.

1 · Architecture thesis

Allowed wording: designed to, proposes, separates, constrains.

What it supports

Local-first design, non-extractive doctrine, scoped release, authority contraction, custody events.

Artifacts

Architecture pages, interface table, governance overlay, proof routing, constitutional language.

Not allowed

Claims of deployed safety, certified privacy, or guaranteed outcomes.

2 · Formal abstraction

Allowed wording: defines, models, gates, bounds.

What it supports

TSARO states, NICOLE events, authority gates, interface contracts, fail-closed behavior.

Artifacts

Architecture interface, claim matrix, threat model, engine equations in source stacks.

Not allowed

Assuming math abstraction has been validated in field hardware.

3 · Client-side simulation

Allowed wording: demonstrates, visualizes, illustrates.

What it supports

Public-safe behavior of the integrated engine and solo proof surfaces.

Artifacts

Proof Theater, Integrated Engine, SOS/CivOS, SSI, W-X/WX-Ag public simulations.

Not allowed

Deployment proof, responder certification, medical clearance, crop prescription.

4 · Monte Carlo evidence

Allowed wording: simulation-internal estimate, modeled result, under assumptions.

What it supports

SSI event-history pathways, SOS/CivOS architecture performance, W-X/WX-Ag scenario behavior.

Artifacts

SSI J2/v94/v95 stacks, SOS v71 corrected source bundle and figures, W-X/WX-Ag v10 record.

Not allowed

Causal field efficacy, clinical incidence, emergency-service replacement, official forecast.

5 · Empirical support

Allowed wording: empirically connected, support-resolved, calibrated where stated.

What it supports

Dataset presence, trace ingestion, support-rate resolution, empirical/proxy lane status.

Artifacts

W-X/WX-Ag weather/SOC/soil support tables; SOS GUIDE and temporal proxy lane metadata; SSI empirical bundles and public tables.

Not allowed

Full external validation or real-world effectiveness unless a field protocol produced it.

6 · Source-governed package

Allowed wording: reproducibility package, candidate manuscript, manifest-bound.

What it supports

Research review, artifact inventory, SHA256 lineages, claim registries, source bundles.

Artifacts

SSI J2 119-artifact suite, SOS v71 preprint bundle, W-X Zenodo submission package, reviewer packages.

Not allowed

Peer-reviewed acceptance unless actually accepted.

7 · Prototype / pilot roadmap

Allowed wording: needs validation, planned, next test.

What it supports

Bench tests, red-team tests, partner pilots, responder workflow studies, privacy/legal review.

Artifacts

Validation roadmap, threat model, architecture interface, future pilot protocols.

Not allowed

Completed field validation unless documented.

Research branch posture

What each research stack can currently support.

SSI

Supports modeled structural-burden, event-history, retained-time, women’s lane visibility, and sensitivity analysis claims. It does not support diagnosis, return-to-play, clinical injury prevention, or worker surveillance.

SOS / CivOS

Supports local-first emergency-state simulation, degraded transport, TSARO/NICOLE governance, and bounded responder sessions. It does not support emergency-service certification, live rescue guarantees, or production hardware claims.

W-X / WX-Ag

Supports environmental truth-state, deterministic agronomic proxy, empirical-support resolution, stale/replay handling, and public-safe scenario results. It does not support official weather authority, extension-grade agronomy, or yield guarantees.

Evidence-to-language rules

Approved public language patterns.

Use “designed to”

For doctrine and architecture claims: local-first, non-extractive, fail-closed, scoped release, user supremacy, non-release logging.

Use “demonstrates”

For client-side pages and proof theater behavior: visible state transitions, authority contraction, release path, custody events.

Use “modeled”

For Monte Carlo results: survivability, retained time, burden, event histories, environmental stress, and sensitivity outputs.

Use “empirical-support-resolved”

When a dataset support check, trace, or source inventory is connected, but do not call that field validation.

Use “candidate”

For manuscripts and bundles unless peer review or DOI registration status supports stronger wording.

Use “requires validation”

For hardware, responder, clinical, agronomic, legal, and privacy claims outside the current public evidence stack.

Red-team boundary: simulation evidence can be strong and still not be field validation. Strong LAKANA language should be narrow, source-governed, and explicit about what it does not claim.