# The Latticra System Substrate

**Title:** *The Latticra System Substrate: An Effect at Modern Security*<br>
**Edition:** Working Draft 0.17 — 2026-05-28<br>
**Role:** Project-level technical handbook for Latticra, Latticra Seal trust-boundary metadata, authority-neutral Ed25519 verification evidence, metadata-only capability/effect/handoff/report/envelope/signature-request/signing-operation classification and status guards, disposable Fedora VM CLI payload validation evidence, Latticra Console host/receipt/signature/OS/VM contract surfaces, Runtime Boundary Lat/LIR provenance records, Nucleus, Nadia Stage-51 contract-only offline-AI release/receipt/review/disposition metadata, Panel, platform install validation lanes, Lat/LIR contract surfaces, receipts, reports, and future runtime-boundary research.

This handbook supersedes the former standalone **Latticra Seal Documentation Handbook** as the main reader-facing book for the project.

The Seal handbook was useful as a subsystem reference. This new handbook expands the scope into a computer-science-oriented project book: Latticra as an evidence-bound system substrate for local integrity, authority boundaries, reproducible reports, receipts, policy semantics, and future runtime-handoff research.

The computational proof foundation extends that scope into scientific modeling: Latticra should preserve proof objects, falsifiability criteria, observer boundaries, state-transition models, physics constraint models, receipts, replay requirements, and adversarial review before any simulation-bound reality claim can be promoted.

The math and physics evaluation lane tightens the order: evaluate state space, transition operators, invariants, observer projection, and falsifier conditions before coupling to physical observables or preparing the substrate-engine visual demonstration.

The Speculum premise now names the clarifying mirror beside the simulacrum: simulation language may frame a bounded research hypothesis, but it may not become a public reality claim without proof objects, falsifiers, measurements or derivations, receipts, replay, and review.

Proof Object 1, Proof Object 2, Proof Object 3, and Proof Object 4 now define the computational-proof spine from emergent particle mass through Higgs counterplay and the identity-replay impedance theorem. Proof Object 4 is the original Latticra mass-origin concept: a projected identity class must pay replay-stable substrate cost to remain itself under update, and Higgs-level coupling becomes a shadow to reproduce rather than the final causal ledger.

The candidate-particle target table now gives that theorem a measured target surface: electron, muon, tau, W, Z, Higgs, and top mass ratios that a later identity-replay impedance runner must derive from replay receipts and counterfactual repair costs without inserting measured masses into the substrate.

The L0 mass-ratio runner now makes the target surface executable: it computes toy `Z_L` ratios, emits a receipt hash, compares against the target table, and records non-survival instead of overstating proof. That turns the Higgs counterplay lane into a falsifiable runner path rather than a purely rhetorical argument.

The L1 constrained substrate search adds target-guided search with receipts, overfit signaling, and leave-one-out review. It strengthens the proof pipeline by showing exactly why the current candidate cannot be promoted: target-table and holdout survival remain closed.

The L2 pre-registration gate now locks a candidate law receipt and an external blinded-holdout protocol before any future holdout can be opened. It strengthens the Higgs counterplay lane by making proof promotion depend on independent evidence rather than already-known target values.

The L3 external blinded-holdout intake validator now binds future oracle data to the L2 receipt and keeps holdout execution closed while no oracle is present. It strengthens the proof lane by making the external evidence boundary machine-checkable before any hidden target is evaluated.

The L4 blinded-holdout execution gate now defines the L2 prediction execution rule and acceptance boundary while keeping execution, survival, and proof promotion closed in the no-oracle state. It strengthens the Higgs counterplay lane by making the next claim depend on a receipt-bound holdout run instead of persuasive language.

The L5 blinded-holdout oracle evidence-review gate now separates execution from evidence legitimacy. It requires source reference, cutoff date, reviewer attestation, and non-synthetic provenance before any future holdout packet can move toward independent reproduction.

The Model-1 dynamic replay substrate runner now makes the next proof step computational instead of rhetorical: it generates identity patterns from a finite substrate, computes `kappa` traces before target loading, emits a prediction receipt, and lets a separate evaluator reject the current candidate against the measured table while preserving the Higgs-as-effective-physics boundary.

The Model-1 bounded range falsifier records the first hard conclusion from that runner: the finite bounded-cell substrate class cannot span the measured particle mass-ratio vector, so the next credible candidate must introduce hierarchical or multiscale impedance before any stronger Higgs-causal-closure language can be considered.

The Model-2 hierarchical substrate pre-registration now supplies that necessary hierarchical range-capacity gate. It locks a four-scale multiplicative replay law before target loading, then confirms after receipt generation that the hierarchical range bound spans the target vector while keeping mass prediction, mass recovery, and Higgs-checkmate claims closed.

The Model-2 prediction runner now closes the next stricter test: it emits hierarchical replay predictions before target loading and rejects the first deterministic prediction law against the guarded target table. This is a useful negative result for the proof lane, not a Higgs defeat or simulation proof.

The Model-2 prediction failure analysis and Model-3 Worthiness Gate now turn that failure into a stricter admission rule. Model-3 is only worth pre-registering if it introduces target-blind topological replay amplification that fixes the dynamic-range deficit, identity-ordering failure, lepton-family inversion, and heavy-sector compression before any new target comparison.

The Model-3 topological amplification pre-registration now locks that branch/coalescence amplification law before target loading and then verifies dynamic-range capacity afterward. It authorizes a prediction-only runner, but it still keeps mass recovery, Higgs checkmate, and simulation proof closed.

The Model-3 prediction runner now executes that authorized prediction split. It emits topological amplification predictions before target loading and then rejects the first deterministic Model-3 law against the guarded table, keeping the next step focused on rejection analysis and amplification-law refinement.

The Model-3 rejection analysis now makes the failure useful: range improved, but Higgs and Z landed below electron-scale impedance and the lepton family order stayed inverted. The next proof step is not another broad claim; it is a refined target-blind sector-resolved topological charge pre-registration.

The Model-3 failure visual suite now renders that rejection as static SVG ratio, ordering, and sector-placement charts from the receipted Model-3 path. The visuals make the failure inspectable without claiming mass recovery, Higgs checkmate, or simulation proof.

The refined Model-3 sector-resolved topological charge pre-registration now records the target-blind law shape before any refined target load or prediction. It keeps refined prediction, mass recovery, Higgs checkmate, and simulation proof closed while requiring the next artifact to pass a capacity gate before it can emit predictions.

## Downloads

- [PDF edition](the-latticra-system-substrate.pdf)
- [Editable DOCX edition](the-latticra-system-substrate.docx)
- [Public repository folder](https://github.com/Bryforge/Latticra/tree/main/docs/latticra-system-substrate)

## Living handbook cadence

Treat this handbook as a live project artifact, not a finished release.

As Latticra work progresses, material decisions, capability changes, boundary refinements, validation lanes, public wording, and evidence updates should be folded back into the handbook alongside the nearer-term project notes and status records.

Handbook updates should stay evidence-bound: describe what is implemented, tested, measured, planned, or explicitly out of scope, and avoid promoting future runtime, enforcement, host-protection, packaging, or production claims ahead of reproducible evidence.

## Correct interpretation

Latticra should be understood as early, evidence-bound systems architecture work.

It is not currently:

- a production security product
- a host-protection system
- a hardened sandbox
- a malware prevention system
- a ransomware prevention system
- a kernel enforcement layer
- a systemd enforcement layer
- an SELinux authority
- a root installer
- a network authority
- a production runtime authority
- an operating-system replacement

The handbook's core claim is narrower and more useful: Latticra is a substrate for making security-relevant effects visible, typed, reviewable, reproducible, and eventually governable.

## Relationship to Latticra Seal

Latticra Seal remains the verification, reporting, manifest/hash baseline, and policy-boundary lane inside the Latticra ecosystem.

Working Draft 0.17 carries the Seal trust/crypto ladder forward, keeps the current Latticra Console contract bundle, preserves Runtime Boundary Lat/LIR provenance records, keeps signing-operation status guard/predecessor alignment for the Seal signing path, folds in disposable Fedora VM CLI payload validation evidence and README/status alignment, and adds Nadia Stage-48 through Stage-51 release/receipt/review/disposition contract metadata on top of the Stage-39 through Stage-47 ladder. Seal documents signed request metadata, request freshness metadata, verification receipts, crypto verify backend metadata, local Ed25519 verify-only results, verified receipt promotion metadata, verified capability gate metadata, verified effect decision metadata, runtime handoff evaluation metadata, runtime handoff report metadata, report envelope metadata, signature request metadata, signing authorization metadata, signer handoff metadata, signer invocation metadata, signing-operation readiness metadata, effect decisions, runtime handoff boundaries, and report envelopes. Latticra Console documents metadata-only host-adapter, receipt-request, receipt-payload, payload-artifact-draft, signature-request-binding, OS-base, and VM-evidence contract surfaces. Runtime Boundary carries Lat pipeline first-clause evidence as provenance metadata. Fedora platform evidence distinguishes a bounded disposable-VM CLI payload, `/usr/bin/latticra` plus `/usr/share/doc/latticra/README.md`, with `host_install_ready_for_cli_payload=1` from `production_installer_ready=0`, `fedora_distribution_ready=0`, `fedora_approval_claimed=0`, `daily_driver_install_ready=0`, and `immutable_fedora_ready=0`. Nadia now records contract-only prompt-evaluation-result release receipt, review, disposition, release, receipt, review, disposition, release, receipt, review, disposition, release, and receipt metadata through Stage-51 while preserving `runtime_invoked=0`, `prompt_evaluated=0`, `token_generation_performed=0`, `inference_performed=0`, `qa_dialogue_generated=0`, `answer_text_generated=0`, `network_authority=0`, `tool_execution_authority=0`, `source_mutation_authority=0`, `sexual_request_refusal=always`, and `manipulation_resistance=required`. These surfaces do not claim host embedding, language execution, operator evaluation, payload materialization outside the validated package payload, receipt writing, signing, signer invocation, signature verification, private-key handling, key generation, trust-store behavior, revocation checks, object sealing, capability enforcement, effect execution, VM launch outside recorded validation, boot behavior, host effects beyond the disposable VM transcript, Nadia release/receipt/review/disposition recording, model-output recording, prompt evaluation, token generation, inference, dialogue generation, network authority, runtime authority, runtime handoff execution, production OS status, Fedora approval, daily-driver readiness, immutable Fedora readiness, security capability, update safety, recovery safety, sandboxing, malware prevention, ransomware prevention, OS-replacement readiness, or production cryptography.

The new System Substrate handbook places Seal in the full project architecture alongside:

- Latticra Panel
- Latticra Console
- Nucleus report-only task boundaries
- Nadia Stage-51 offline AI contract metadata
- macOS and Fedora platform validation lanes
- guarded local-prefix installation
- receipts and reports
- command contracts
- Lat and LIR contract surfaces
- runtime-boundary metadata
- validation lanes
- research artifacts and visual theorem engines

## Canonical public wording

Use language like:

> Latticra is an early, evidence-bound system substrate for describing, measuring, and presenting local project state under explicit authority constraints.

Avoid language that claims production protection, runtime enforcement, malware prevention, ransomware prevention, kernel enforcement, root authority, or certification unless those claims are implemented, tested, and documented with reproducible evidence.