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, binds it to self-hashed payload and detached release manifests, can verify a detached Ed25519 signature, and can 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: what was declared, what bytes were committed, what receipt state was included, 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 it is not yet the default output of packet compilation. 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
Canonical V2 receipt-chain semantics, deterministic hashing, crash-safe serialized append, detached Ed25519 signing and public-key verification, independent signed-chain verification, transactional signed journals, detached release verification and non-destructive legacy migration preparation are present in the current product body.
Still bounded
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.
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.