The required check succeeded within the selected verification scope. A PASS does not remove the result’s stated limitations.
Compact verification kernel
How it works
LARRI defines what is committed, what is packaged, which trust is accepted, how checks run, and the exact assurance scope of the result.
How LARRI works
LARRI defines what a decision commits to, what its evidence package contains, which external trust is accepted, how every check is performed and exactly what the result establishes.
Commit
Create a signed decision receipt that records the decision, the exact evidence commitments behind it, the policy and software versions applied, and the result’s assurance scope.
Package
Place every required file in a signed, closed package that records its exact path, purpose, size and cryptographic digest.
Supply trust independently
Provide the trusted public keys and fingerprints through a separate authorized channel. The package cannot declare itself trustworthy.
Verify deterministically
Run the required checks in a fixed order across the package, trust configuration, signatures, evidence, policy bindings and selected profile.
Report precisely
Produce a normalized record showing the outcome, every check performed, the trust used, the exact assurance established and the limitations that still apply.
Five states. No hidden ambiguity.
Every LARRI check records exactly what happened, making it clear what was established, what failed, what was absent and what still requires independent evidence.
A required condition failed, so the selected integrity assurance was not established.
The check was not run because a prerequisite failed or proceeding would have been unsafe.
The optional item was not supplied and was not required for this package.
An assertion is present, but the evidence, verifier or external trust needed to check it independently was not available.
Together, these five states give relying institutions more than a verdict by providing a structured account of the limits of current knowledge.
Why the result can be independently checked
LARRI is designed so that another authorized party can verify the same package using the same published contracts and independently supplied trust.
Exact bytes
The verifier checks the exact received or prepared bytes and never silently repairs or rewrites a signed artifact.
Independent trust
Trust comes from keys and fingerprints supplied through a separate authorized channel. A valid key establishes cryptographic trust under the selected policy; it does not by itself establish the signer’s legal or organizational authority.
Deterministic outcomes
Equivalent protocol inputs produce the same normalized result, including the same check order and refusal outcome.
Safe execution
Checks that cannot run safely or whose prerequisites have failed are recorded as SKIP, preserving the review trail instead of producing misleading results.
Reproducible releases
Release claims are evaluated against a fresh extraction of the exact immutable archive being claimed, not against a mutable working directory.
Designed for post-quantum verification
LARRI is designed to support versioned signature policies, including hybrid policies that require both conventional and post-quantum signatures. Explicit algorithm binding and fail-closed downgrade protection allow cryptographic protections to evolve without silently weakening the assurance attached to existing evidence.
ML-DSA-65 policy support
The protocol contracts define how an ML-DSA-65 signature can be required alongside a conventional signature in an enabled and qualified hybrid policy. NIST FIPS 204 ↗
Hybrid verification
A hybrid ALL policy requires every declared conventional and post-quantum signature slot to verify. One valid signature cannot replace a failed required signature.
Versioned signature suites
Each suite identifies the exact algorithm, parameters, key and signature formats, signed input, hashing rules and verification behaviour.
Policy-enforced protection
An enabled deployment can require post-quantum verification through a closed, fail-closed signature policy.
Downgrade refusal
When a selected policy requires post-quantum protection, missing, invalid, unsupported or untrusted post-quantum evidence prevents that policy from passing.
Reveal cryptography
ML-DSA-65 policy support
The protocol contracts define how an ML-DSA-65 signature can be required alongside a conventional signature in an enabled and qualified hybrid policy. NIST FIPS 204 ↗
Hybrid verification
A hybrid ALL policy requires every declared conventional and post-quantum signature slot to verify. One valid signature cannot replace a failed required signature.
Versioned signature suites
Each suite identifies the exact algorithm, parameters, key and signature formats, signed input, hashing rules and verification behaviour.
Policy-enforced protection
An enabled deployment can require post-quantum verification through a closed, fail-closed signature policy.
Downgrade refusal
When a selected policy requires post-quantum protection, missing, invalid, unsupported or untrusted post-quantum evidence prevents that policy from passing.
SCITT transparency as an integration path.
LARRI has strong interoperability potential with Supply Chain Integrity, Transparency, and Trust (SCITT) because its signed receipts and attestations already provide deterministic statements, stable artifact identities, explicit issuers, trust anchors, and independent verification.
A SCITT profile could register LARRI artifacts with a Transparency Service and bind the resulting inclusion receipt back to the LARRI record, adding append-only registration, non-equivocation evidence, and cross-organization auditability without exposing proprietary decision logic or changing LARRI Core.
This should presently be described as a standards-aligned integration path—not native conformance—because the SCITT architecture and reference API remain active IETF Internet-Drafts.
Assurance boundary
LARRI verifies the integrity and provenance of a declared decision record. It does not turn integrity into truth, prove that every relevant record was included or replace the substantive review required by the applicable domain.