Sequence and linkage
Verify the declared receipt sequence, previous-record linkage and the actor, event and subject identity carried by the V2 chain.
INDEPENDENT VERIFICATION
Verify what was released, not merely where it came from.
Blackbox preserves enough declared evidence state for an authorized reviewer to inspect sequence, cryptographic integrity, release contents and verification results after the originating execution has ended. The verifier can operate without the private signing key, live Blackbox runtime, network access or a blockchain connection.
WHAT THE VERIFIER CHECKS
A release is a declared evidence universe, not an opaque archive.
Current Blackbox release verification freezes an explicitly declared ZIP payload universe and binds it to self-hashed payload and detached release manifests. It can verify a detached Ed25519 signature and independently verify embedded V2 receipt snapshots. The point is to make the acceptance boundary inspectable.
Content commitments
Recompute deterministic hashes over the material presented for review instead of trusting a filename, database row or export label as identity.
Detached signatures
Verify Ed25519 signatures with public-key material. Verification uses public material while the private signing key and originating runtime remain outside the reviewer boundary.
Release universe
Reconcile the release against its explicitly declared payload universe and reject duplicate, unsafe, undeclared or unexpectedly injected ZIP entries.
Embedded receipt state
Verify embedded signed or unsigned V2 receipt snapshots as part of detached release review rather than treating the archive itself as sufficient evidence.
Failure as evidence
Return a failed verification when declared invariants do not hold. Failed invariants remain failed evidence; verification preserves the broken state for review.
PORTABILITY
Verification is designed to survive the handoff.
The useful test is not whether the originating system can explain its own output while it is still running. It is whether a later reviewer can receive the declared material, recompute its commitments and determine whether the released record still satisfies the verification contract.
Originating runtime
Creates or records the declared evidence state under the implemented receipt, signing and release rules. This is where execution happens, but it is not required to remain available forever for later verification.
Release package
Carries the declared payload universe and verification material needed for the release form being checked. Unexpected material is a verification concern, not harmless archive decoration.
Independent reviewer
Uses public verification material and the released record to evaluate the declared invariants. The reviewer operates from public verification material and the released record while private signing custody remains with the originating environment.
Later review
The same boundary supports after-the-fact inspection. A reviewer can see what was declared, what bytes were committed and what receipt state was included. They can also see what signature was checked and whether the verifier accepted or rejected that material.
SEPARATE TECHNICAL STATES
Cryptographic words are not interchangeable claims.
Blackbox deliberately separates states that are routinely blurred together. Each control retains its specific technical meaning and authority boundary.
Hashed
A digest commits to bytes under a declared algorithm. Approval identity and trusted time remain separate evidence states.
Signed
A signature can bind declared material to a key. It is not encryption, a timestamp, a certification or proof that the signed assertion is factually true.
Encrypted
Encryption protects confidentiality under its own key and protocol state. Receipt-chain and release verification remain separate controls.
Timestamped
A timestamp is a separate claim about time and authority. Hashing, signing and time authority remain separately inspectable controls.
Blockchain-anchored
Anchoring remains optional future proof augmentation. Sensitive evidence stays off-chain; bounded commitments may be anchored only as a separate downstream state.
IMPLEMENTATION BOUNDARY
Implementation, verification and deployment remain separate evidence states.
Detached release verification exists in the current product source, but default packet compilation activation is under operator control. The transactional signed journal is also implemented without being claimed as the default operational job ledger. Those integration boundaries matter because a control can be real in source without being active in every product path.
Implemented now
The current product body contains canonical V2 receipt-chain semantics, deterministic hashing, crash-safe serialized append, and detached Ed25519 signing with public-key verification. It also contains independent signed-chain verification, transactional signed journals, detached release verification and non-destructive legacy migration preparation.
Activation gates
Default packet/release integration, signed-journal operational activation, key-provider adapters and rotation/revocation/compromise runbooks, complete end-to-end release fixtures, enterprise pilot controls and optional anchoring remain separate hardening or activation work.
Legacy records
Migration preparation preserves exact legacy bytes and commits to both raw-byte and canonical-row digests. Raw legacy bytes, canonical-row digests, migration preparation and activation remain distinct recorded states.
HASH EMISSION
Every release emits both hashes.
Blackbox manifests commit with SHA-256 and SHA3-256 side by side so a reviewer holding either algorithm can recompute the commitment. The digests below cover the live briefing clip, hero film and map frame; recompute them against the served bytes with any tool on ordinary CPU.
Briefing audio (m4a, 10s)
sha256:8ce59e4673c31dcddfe014700f277f0941f70cb5e611f1b67c8e63fa1d8570c7
sha3-256:b130730746384653a3fc3a55a14977f71d38b610890639fd2ee4e393e857cb71
Briefing audio (ogg, 10s)
sha256:6c806dd26b1a8eee3b704f67b8e7f452a43aae4f4c0026f281555e788a1bcfea
sha3-256:f2bb24883f46fa7d134815f3425b62cb6a9bef1a82846c30aa754140c4d35210
Hero film (mp4, 45s)
sha256:68e417f3674d684b0917b4b4295c97d14edb84d85d50fbb51b52cb3fb4ce3a9a
sha3-256:d337db0cd84c67dbb7939b5ff19157a07f91843be76af887638a4778edacc75d
Hero map frame (webp)
sha256:2ae42a9214fe83af638affcd8f62c65d0e1a48fd42f066a88ef2e50a6df2740d
sha3-256:8cd02aadfe97dc12305ec19f4e9caa4a84e5a8abe1085c22e2a2dfbf2cd4ed98
VERIFICATION BOUNDARY
Technical acceptance has a deliberately narrow meaning.
A successful verifier result can establish that the presented material satisfies the implemented technical contract being checked. Factual truth, upstream completeness, legal admissibility, certification, customer acceptance, production deployment and proceeding-specific fitness remain governed by their own evidence and authority.
Blackbox records and verifies declared technical state. Professional judgment, legal sufficiency, factual conclusions and the authority of upstream acquisition or review remain outside that verifier result unless separate evidence establishes them.