The NO-GO Archive

Performance reporting often omits decisions not to trade. BLEEEP treats those Trade Abstentions as first-class evidence. The public NO-GO Archive therefore contains two explicitly labeled record types: a Validation NO-GO, which is a computation-provenance verdict, and a Trade Abstention, which uses the pre-outcome decision proof class.

Any resulting paper or live execution is represented by a separate event-evidence record with its evidence-source label. These records may enter the same ordered batch, but their evidence and timing claims remain different.

A registered TRADE_ABSTENTION and a resulting execution event from another decision may share the same finalized batch root. The shared root proves inclusion; it does not make the execution event a pre-outcome commitment or remove the need for authoritative event evidence.

Why non-actions require proof

A fill may leave a finalized onchain transaction record or an authenticated broker record, while an abstention has no natural execution artifact. Without a timely cryptographic commitment, anyone could claim afterward that they would have skipped an unfavorable trade. A registered Trade Abstention in the NO-GO Archive addresses that asymmetry within the formally registered stream.

BLEEEP’s Validation Engine can reject a strategy version before any BLEEEP-enabled live deployment. Recording only survivors would misrepresent the tested population. Every admitted evaluation retains the required Index state described under the registered denominator. The NO-GO Archive is the Index’s filtered rejection-and-abstention view, not a claim about private experiments outside BLEEEP’s admission process.

How a Trade Abstention is sealed

A Trade Abstention uses the same conceptual decision-record envelope as other eligible pre-outcome decisions, with direction set to NONE. Its accepted anchor must reach the required finality before the predefined outcome deadline, so a later commitment cannot be presented as timely. The following is illustrative, not the final canonical schema:

{
  "kind": "TRADE_ABSTENTION",
  "strategy_id": "…",
  "market": "BTC-USDT-PERP",
  "direction": "NONE",
  "rationale_hash": "0x…"    // digest of reasoning; plaintext not exposed
}

The secret salt is kept outside the serialized record until reveal. The record’s rationale_hash binds a later-disclosed rationale to the commitment without revealing the private engine logic at commit time. The record then follows the pre-outcome commit, anchor, reveal, and verification path defined in Proof of Provenance.

After the batch root and manifest commitment are finalized, alteration of included records breaks the commitment or inclusion check. Detection of omitted, inserted, or reordered records additionally depends on the registered-stream completeness controls. See Merkle anchoring for the mechanics.

What “verified” means, and does not mean

Verification has defined limits.

What a valid Trade Abstention proof establishes:

A commitment to the record existed by the anchor time.
Its accepted anchor reached the required finality before the predefined outcome deadline.
The disclosed record has not been altered since the commitment.

A Validation NO_GO establishes a different claim: the disclosed validation report and verdict match the committed computation-provenance artifact. It does not establish that the verdict was registered before a later market outcome unless a separate pre-outcome record and deadline support that claim.

What it does not establish:

That the decision was correct, or that skipping was the profitable choice.
That any strategy is or will be suitable for a user’s goals.
Anything about future returns: a proof describes the past only.

There is also a venue distinction. An onchain transaction can carry ON_CHAIN_TRANSACTION_RECORDS only within the registered account, network, contract, decoding, and finality scope. For a centralized exchange, commit–reveal can show that the disclosed decision record matches a commitment whose accepted anchor reached the required finality before the registered deadline, but the fill retains its actual lower-assurance evidence-source label unless supported by a venue- or broker-authenticated receipt or authenticated account-history record. The proposed second-chain resilience anchor is covered in dual-chain anchoring.

A registered Trade Abstention can carry the same class of pre-outcome commitment evidence as a registered entry decision. Any resulting order or fill still requires separate source-labeled event evidence. This makes restraint independently checkable within the registered scope.

Next: Independent Verification walks through the checks a reader can run.

Merkle anchoring System layers