Independent Verification

Verification applies the class-specific timing and evidence rules defined under Proof of Provenance. A pre-outcome decision requires an accepted anchor that reaches the required finality before its outcome deadline, while event evidence requires the source identified by its evidence-source label and the later integrity anchor required by the registered rules.

What a proof contains

When BLEEEP reveals a decision, it discloses the original decision record, secret salt, batch manifest and ordering fields, and Merkle path linking the record to a finalized batch root on Robinhood Chain. Anyone can then derive the record commitment and ordered leaf, recompute the manifest commitment under the registered schema, use the supplied path to derive the candidate root, and compare the manifest commitment, root, and accepted anchor timing without trusting BLEEEP’s dashboard.

Verifier checklist

1. Recompute the commitment from the disclosed record and salt.
2. Recompute the batch-manifest commitment under the registered canonicalization and schema, compare it with the manifest_hash committed by the finalized anchor, and confirm that the manifest’s scope, ruleset, ordering fields, and record-count commitments cover the disclosed record.
3. Derive the ordered leaf and test the supplied Merkle path against the finalized anchor.
4. Apply the rule for the record’s proof class:
   • for a pre-outcome decision, confirm that the accepted anchor reached the required finality before the predefined outcome deadline; and
   • for an order, fill, or other event, check the evidence required by its evidence-source label and treat the later anchor only as making subsequent alteration detectable. For ON_CHAIN_TRANSACTION_RECORDS, confirm the transaction identifier, declared network, registered wallet or account and contract scope, receipt or execution status, applicable decoding, and required finality.
5. Confirm that the verification conclusion does not exceed the claim permitted by the proof class and evidence-source label.

When these checks hold, the verifier has evidence that the disclosed record matches its registered cryptographic commitment, belongs to the anchored batch, and satisfies the permitted claim. This does not prove the record’s factual truth, the correctness of undisclosed logic, the absence of unregistered activity, or that a paper fill occurred live.

Applying the checklist to NO-GO records

A Trade Abstention uses the pre-outcome decision class: a verifier can recompute the leaf, validate the Merkle path, and check that the anchor reached the required finality before the applicable outcome deadline. A rejected strategy carries a Validation NO_GO, which is a computation-provenance record. Its cryptographic commitment establishes which report and verdict were registered; independent reproduction still requires the necessary inputs and computation.

Programmatic verification

Independently inspectable verifier logic is the reference path. The programmatic verifier lets third parties and other agents check disclosed proofs without rebuilding the workflow. Its response returns the disclosed verdict or event status, methodology outputs where applicable, report reference, batch manifest, reveal-status evidence, proof material, proof class, evidence-source label where applicable, and actual anchor references.

Provenance status and reproduction availability are reported separately so a verified cryptographic commitment is not presented as independent reproduction of undisclosed computation. Public inspection of a disclosed proof remains free.

Next: Dual-chain anchoring describes the primary anchoring rail and the proposed resilience anchor.