Operate / Field operators and independent witnesses

Offline Record, Seal, and Verify

Record a moment as its PNG proof object or Seal an existing file, then verify the returned artifact after one-time canonical enrollment with no server signing call.

offline sealed proof objectOffline Record & Seal and canonical standalone verifierComplete production checklist

Implementation rail · Offline Record & Seal and canonical standalone verifier

Exact execution and operator checks

  1. 01

    Operator check

    Record Moment or Seal File with automatic initial save

    Record Moment records and seals the moment as a sealed PNG proof object; Seal File binds an existing file’s exact source bytes. Each operation automatically saves the exact initial proof object. Hold that predecessor unchanged.

    Substantive records: /build/proof-object · /reference/schemas-test-vectors

    Expected: The exact automatically saved sealed artifact is in local custody.

  2. 02

    Exact mechanic

    Verify exact predecessor bytes with the installed SDK

    import { createReceizClient } from "@receiz/sdk";
    
    const encoded = process.env.RECEIZ_ARTIFACT_BASE64;
    if (!encoded) throw new Error("RECEIZ_ARTIFACT_BASE64 is required");
    const artifactBytes = Uint8Array.from(Buffer.from(encoded, "base64"));
    const receiz = createReceizClient();
    const verification = await receiz.verification.verifyArtifact(artifactBytes);
    if (verification.status !== "verified-artifact") throw new Error(verification.status);
    console.log(verification.status);
    Mechanic
    receiz.verification.verifyArtifact
    Authentication and account boundary
    Account-free local verification; enrollment and signing custody remain separate.
    Exact source
    node_modules/@receiz/sdk/dist/index.d.ts · SHA-256 3278d551808697d9936ffdf75931358c903bb0cc5a211191b611d4474895f6be

    Expected: The SDK returns verified-artifact for the exact held predecessor without a network dependency.

  3. 03

    Exact mechanic

    Run test:offline-record-seal-freeze

    pnpm test:offline-record-seal-freeze
    Mechanic
    pnpm test:offline-record-seal-freeze
    Authentication and account boundary
    Authorized local repository checkout; the command proves only the checked repository boundary.
    Exact source
    package.json · SHA-256 132f99232dfaf26f7186b73752938d1377042808f42d60d374fe7b2e57c7646b

    Expected: Carrier, canonical fields, Signature V4, anchors, and Groth16 contracts pass.

  4. 04

    Operator check

    Append a verified successor and final Export

    With the network unavailable, Verify the same held predecessor, Append only by creating and independently verifying a separate successor, then final Export releases that successor unchanged. Compare the predecessor bytes and digest before and after.

    Substantive records: /trust/conformance · /reference/compatibility

    Expected: The predecessor remains immutable and the exact verified successor is exported without network authority.

Complete operating anatomy

Every boundary required to ship.

Solved outcome
The downloaded artifact passes the untouched canonical standalone verifier against exact bytes while offline.
Prerequisites
Hold the exact Record Moment claim or Seal File source bytes, local signing custody, canonical registry and artifact-law versions, export location, and an independent zero-network verification procedure.
Exact primitive
offline sealed proof object
Governing law
Offline Record, Seal, and Verify is governed by offline-proof: Record, seal, inspect, and local verification remain meaningful without depending on remote state. canonical-artifact-verifier: The verifier classifies the supplied artifact. Embedded subpayloads and remote responses remain subordinate. verification-conformance: A passing execution confirms the checked artifact verification invariants for the exact repository state exercised.
Source-of-truth order
Receiz law → sealed artifact truth → deterministic proof object state → verified durable local or register truth → authenticated snapshot → server distribution, synchronization, indexing, and publication → database, session, observability, and interface projections.
Expected artifact, receipt, or state
A format-preserving sealed artifact containing canonical proof material and preserving its authoritative basis bytes.
Inspection
Inspect the carrier, proof bundle, artifact basis, canonical fields, Signature V4, anchor data, and Groth16 result. Inspection exposes structure and receipt fields; inspection never establishes verification.
Independent verification
Independent verification for offline-record-seal-verify: pnpm test:offline-record-seal-freeze. This establishes only the offline sealed proof object boundary named by the bound sources; The implementation rail remains beneath proof authority: Offline Record & Seal and canonical standalone verifier.
Offline behavior
After one-time canonical enrollment, Record Moment, Seal File, download, and canonical verification execute with the network disabled across the qualified carrier matrix.
Identity and account boundary
Public Record Moment, Seal File, Verify, Export, and public proof reading are account-free. Identity is optional and adds continuity, custody, recovery, and governed private controls after proof admission.
Security boundary
Local Receiz ID and Signature V4 material remain separate; no self-signed local root, Studio-only trust, or server signing fallback is permitted.
Conformance command
pnpm test:offline-record-seal-freeze
Deployment checks
Qualify automatic initial save of the exact predecessor, local Verify, separately verified Append, final exact-successor Export, exact-byte custody, Signature V4 and Groth16 verification, registry binding, mutation rejection, airplane mode, and cross-platform round trip.
Production checklist
Record Moment or Seal File; automatic initial save of the exact predecessor; Verify the held predecessor; Append a separately verified successor; final Export of that successor unchanged; hash and compare predecessor and successor; disable the network and verify again; mutate only a clone and confirm rejection; preserve the original.
Rollback and containment
Containment for offline-record-seal-verify: Seal cannot establish the intended moment. Restore recorded bytes or record the changed moment anew. The object is not admitted as verified proof. Resolve the first exact failing check and verify the complete artifact again. The offline primitive is broken. Use the local verifier and exact frozen roots until deterministic parity is restored. Preserve every stronger held artifact and admitted state while the named boundary is corrected.

Fail closed

Mutation and failure matrix

F1

Source bytes change between Record and Seal.

Effect
Seal cannot establish the intended moment.
Retry
Do not reuse the recorded identity.
Recovery
Restore recorded bytes or record the changed moment anew.
F2

Signature, anchor, registry, or Groth16 verification rejects.

Effect
The object is not admitted as verified proof.
Retry
Never convert partial checks into success.
Recovery
Resolve the first exact failing check and verify the complete artifact again.
F3

Offline verification attempts a network call or differs from the online result.

Effect
The offline primitive is broken.
Retry
Do not treat offline as fallback.
Recovery
Use the local verifier and exact frozen roots until deterministic parity is restored.

Exact authority

Claim-to-source bindings

  1. Record, seal, inspect, and local verification remain meaningful without depending on remote state.

    docs/offline-record-seal-frozen-invariants.mdnormative-doctrine · SHA-256 fce14006bd7f8da92a513423b28fd8e0a957d6c9f66cf2acc4068dda13343d7a
  2. The verifier classifies the supplied artifact. Embedded subpayloads and remote responses remain subordinate.

    packages/receiz-sdk/src/artifactVerification.tsimplementation-verifier · SHA-256 c10cdba92568fea273e1d9e7a3321083d52945378ab0cc83aee9720d44f0bba3
  3. A passing execution confirms the checked artifact verification invariants for the exact repository state exercised.

    scripts/test_verification_conformance.tsexecutable-conformance · SHA-256 8832d6deab2b117bfaefce67285dd3da6247957d5674eff74514ed1f75cb6678