How LARRI Works

LARRI turns a decision into a verifiable record, with its supporting package, external trust, checks, and assurance scope clearly defined.

The Five Stages of LARRI

One decision. Five stages. A record anyone authorized can verify. From protected decision to independent verification.

Independent trust path

Authorized channel

Keys · profiles · refusal registries

Select stage five to activate

Sensitive evidence stays private. Verify the bytes later, through portable cryptographic commitments when authorized access is granted. A LARRI receipt tells an insurer or regulator every byte is there.

Architecture map

Four layers. Four different claims.

Each layer instantiates the one above it. Keeping them separate makes capability, conformance, implementation, and operational assurance easier to reason about.

  1. 01
    The invariant rules

    Protocol

    Defines the assurance model, artifact relationships, verification order, outcomes, and refusal behavior that implementations must preserve.

    Normative semantics
  2. 02
    The qualified configuration

    Profiles & contracts

    Select schemas, registries, signature policies, required checks, and domain constraints for one interoperable verification context.

    Testable requirements
  3. 03
    The working software

    Implementations

    Core producers, independent verifiers, libraries, and services realize the protocol and enabled profiles in code.

    Executable behavior
  4. 04
    The operating environment

    Deployments

    Institutions supply identity, access control, key custody, retention, risk management, and the authority under which software runs.

    Operational assurance

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.

PASS

The required check succeeded within the selected verification scope. A PASS does not remove the result’s stated limitations.

REFUSE

A required condition failed, so the selected integrity assurance was not established.

SKIP

The check was not run because a prerequisite failed or proceeding would have been unsafe.

NOT PRESENT

The optional item was not supplied and was not required for this package.

UNVERIFIED

An assertion is present, but the evidence, verifier or external trust needed to check it independently was not available.

Together, the five states give institutions a clear, review-ready record of each check and any remaining evidence needs.

See healthcare verification Read the specifications

Why LARRI results 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 Core supports 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.

The SCITT architecture is now RFC 9943, an IETF Standards Track specification. The SCITT reference API remains an active IETF Internet-Draft. LARRI preserves a standards-aligned integration path with SCITT for added anchoring assurances.

Conceptual Glossary

These definitions are concise orientation language. Normative meanings remain controlled by the applicable specification and profile.

Assurance scope
The precise set of claims a verification result establishes—and the claims it intentionally leaves unresolved.
Bundle / package
The portable collection containing the declared artifacts and control records required by an enabled profile.
Contract
A machine-testable definition of formats, constraints, registries, or behavior used by a profile or implementation.
Derivation record
A link recording that one evidence object was produced from another through redaction, conversion, summarization, or another transformation.
Evidence commitment
A cryptographic identity for exact evidence bytes, normally including a digest and length without disclosing the evidence itself.
Manifest
The closed inventory that binds the required paths, sizes, and digests of a portable package.
Profile
A selected, qualified configuration that makes optional protocol capabilities concrete for a domain or exchange.
Receipt
A signed record binding a decision outcome to its declared evidence, rules, software, authority, and verification context.
Trust bundle
Public keys, fingerprints, policies, and authority material delivered to the verifier independently of the package being checked.
Verification outcome
A normalized result such as PASS, REFUSE, SKIP, NOT PRESENT, or UNVERIFIED, accompanied by structured checks and limitations.

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.