The validation engine (L0)
At the bottom of the BLEEEP stack sits L0, the validation engine. It is a neutral judge: users build strategies, and this one fixed, public engine evaluates each one against the same bar for everyone. Its thresholds and its method are fixed, versioned, and public, including BLEEEP’s, while each user’s strategy logic stays private to that user. What is published is not what the engine concludes about any given market, but how it reaches a verdict: the method by which it separates skill from luck before anything is allowed to trade. This page describes that method and the engine’s interface: what goes in, what comes out, and why every result is auditable.
The boundary: private logic, public method
The design principle is a clean separation between private alpha and public proof. A user’s strategy logic is not published upward; only verdicts, metrics, and proofs flow upward to the proof layer. That boundary is the whole point: it lets a user make a falsifiable claim (“this was validated, that was rejected”) without handing anyone the recipe. The engine is a neutral judge and never runs a book of its own against the users it validates. So the interface is intentionally narrow:
- Inputs: a
frozen_spec(a strategy definition whose parameters are locked before evaluation begins) plus recorded market data to replay it against. - Outputs: a
verdictofGO,NO_GO, orINSUFFICIENT, accompanied by the supporting metrics that produced it.
Every strategy is user-built. The spec belongs to the user who wrote it: that user sees every field, while to everyone else the logic behind a frozen_spec stays hidden. What is visible to others is the verdict, the metrics, and the fact that the evaluation happened at all. Commit-reveal lets a user keep their own logic private while proving their results. The passing bar itself is fixed, public, and identical for everyone. See User strategies.
Capture-first pipeline
The engine is structured to eliminate look-ahead bias and curve-fitting by construction rather than by discipline. It records real market data first, then tests against it.
[Collector] Ingest raw market data first, append-only (record)
└─ Snapshot time is fixed to a slug/era-invariant anchor → designed to prevent look-ahead bias on replay
[Evaluator] Replay a FROZEN spec against future data only
└─ Params locked before evaluation → no post-hoc tuningBecause data is captured first and the spec is frozen before the Evaluator runs, any variant can be replayed against the same recorded history without the test ever “seeing” the future. Parameters cannot be changed inside an evaluation after the outcome is known. If a user revises the strategy, BLEEEP treats it as a new spec version with a new validation record.
The validation gate: skill vs luck
A frozen_spec does not earn a GO by being profitable in one backtest. It must pass a battery of independent checks, each targeting a different way a result can be luck rather than skill. It has to clear all of them.
| Check | What it rules out |
|---|---|
| Deflated Sharpe Ratio | Apparent significance that is really an artifact of many trials |
| Walk-forward out-of-sample | Performance that does not persist beyond the fitting window |
| Multi-regime durability | Profit concentrated in a single market regime |
| Monte Carlo / permutation | Results attributable to chance |
| Adversarial refutation | Edges that break under active attempts to disprove them |
| Cost realism | ”Wins” that vanish once fees, slippage, and funding are applied |
Any single failure is enough for a NO_GO. In practice, most strategies fail here, and, unusually, that is treated as the product, not an embarrassment to hide.
Every evaluation is logged, including rejects
Each evaluation cycle writes its input, verdict, and reason to a full gate log. This log is the source that the proof layer above draws from, which means rejections are as auditable as approvals. A strategy that was tested and turned down leaves a permanent, sealable record of why it was turned down. In a market where dashboards only ever surface winners, an archive of proven rejects is the harder thing to fake, and the more credible one to publish.
Where this connects
- Validation architecture: how L0’s verdicts feed the rest of the stack.
- The NO-GO archive: the sealed record of what the engine deliberately did not trade.
- Proof of Provenance: how verdicts become tamper-evident, on-chain proofs.
- Merkle anchoring: how a batch of logged decisions becomes a single anchored root.
Next: see how sealed verdicts are turned into on-chain proofs in Proof of Provenance.