User strategies & collective validation

BLEEEP is a collective validation engine. Users can build their own strategies, while BLEEEP applies the same validation standard to each one: GO, NO_GO, or INSUFFICIENT. As those verdicts accumulate, the record of what passed and what was rejected becomes shared, verifiable knowledge: a collective intelligence no single desk could build alone.

BLEEEP does not run house strategies. The engine acts as a neutral validation layer, not a competitor. It does not trade against the users it evaluates. Its role is to judge every submitted strategy by the same standard and separate real skill from statistical luck.

User strategies: the user controls everything

A user builds a strategy in plain language through the BLEEEPY chat, which compiles it into a BleeepSpec, the frozen definition the engine evaluates. The spec can also be edited directly. Either way, the user sets the entry and exit conditions, the parameters, the risk limits, the position sizing, and the markets it trades. The logic belongs to the user.

The user then runs it through the validation gate and gets back a GO, NO_GO, or INSUFFICIENT verdict with the metrics behind it. Passing strategies move to paper forward-testing on real prices, then to live capital behind the Safety Vault once the user promotes them. Results seal and anchor on-chain, so a user can prove their own track record to anyone, without handing over the recipe.

One thing users cannot control by design is the passing bar. The standard is fixed, applied equally to every strategy, and cannot be adjusted by individual users. This is covered in the validation standard.

Collective intelligence: the GO/NO-GO record

Each validated strategy adds to a shared, public record. Every GO is a strategy that cleared an identical bar; every NO_GO is a strategy that was tested and turned down, with the reason sealed on-chain.

The rejected side is what most platforms hide. BLEEEP keeps the NO-GO archive: a verifiable record of what failed, what was skipped, and what never made it to trade. Across many users it becomes a body of knowledge no one owns alone: which ideas survive out-of-sample, which regimes break them, which “edges” vanish once costs are applied. The more strategies the community submits, the richer and more valuable that record gets: a network effect a single proprietary desk can never reproduce. Once a strategy’s forward record holds, its creator can list it for others to subscribe to; see the strategy marketplace.

Collective learning: what the shared AI may read

The accumulating record is also what the assistant learns from. By default it trains on the public side of the system: the NO-GO archive (a rejected strategy exposes no live edge), the gate-and-regime statistics of failures (which test broke a strategy, and in which regime), reduced-granularity public result curves, and any spec a creator opts to share. A creator can opt out of contributing even that. One line is absolute and holds regardless of the opt-out: the sealed BleeepSpec (a strategy’s private logic) is never trained on by anyone. The recommender reads over this opt-in corpus rather than baking it into fixed weights, so opting out genuinely removes a contribution instead of leaving it fossilized in the model.

What the assistant does with that is bounded too. It is a translator and a stress-tester, not a tout: it helps a user turn an idea into a BleeepSpec and points out where a strategy is fragile (“this fails walk-forward, widen the window”) but it never tells anyone which strategy to buy, and any comparison it draws routes through the deterministic engine and shows gate results rather than a bare confidence number. The AI proposes; the engine judges.

How logic stays private while results stay verifiable

A user can keep a strategy’s logic entirely private (that is their edge) and still prove its results to anyone. Commit–reveal is what lets both be true.

When a strategy makes a decision, a hash of the decision record is sealed before the outcome is known:

commit_i = keccak256( serialize(record_i) ‖ salt_i )

Only the hash is published at commit time. The record and the salt stay hidden, so the seal proves that something was decided at that timestamp without revealing what the strategy is. After the outcome settles, the record and salt are disclosed and anyone can recompute the hash, place it inside an anchored Merkle root, and confirm the seal predated the outcome.

Privacy of the logic and verifiability of the result are separate properties. Hiding the recipe does not make the outcome unverifiable because the proof is over the sealed record, not over the source code. This is exactly how a user proves a track record without publishing their own alpha to everyone else on the platform.

What is fixed, what the user controls

Everything about a strategy belongs to the user who built it. The one thing no one controls is the bar it must clear. That last row is the constitution, and it is the subject of the validation standard.

What “private” means, precisely

“Private” is a claim about a user’s own strategy logic, held back from other users. It is not a loophole in the proof.

• Private from others, never from the user. A user’s strategy logic is theirs; they can keep it hidden from everyone else while still proving results.
• Private logic, public results. What is kept back is the recipe. What is published is the sealed, anchored record of every decision, including the ones that lost and the strategies that were rejected.
• Private logic, public method. Strategies can be secret. The way they are judged is not: the validation methodology is published, versioned, and anchored, so “this was validated” is a falsifiable claim rather than a slogan.

Private does not mean unaccountable. It means an edge is protected while the record and the method stay open to inspection.

Next: see how the passing bar is set and continuously re-verified in the validation standard, how proven strategies get listed in the strategy marketplace, or what users do day to day in Using BLEEEP.