System layers

BLEEEP uses five functional layers. The separation keeps strategy logic, evaluation, execution authority, proof material, and public disclosure as distinct responsibilities.

The five layers

L0, Validation Engine. Evaluates a frozen user strategy under the controlling Validation Standard and produces GO, NO_GO, or INSUFFICIENT with supporting metrics. See the validation engine.

L1, Execution. Provides a common decision interface for paper execution and any separately released live-execution integration. Order routing requires the current effective authority defined under the Safety Vault.

L2, Proof of Provenance. Orders registered artifacts, creates cryptographic commitments and Merkle batches, manages reveal state, and publishes the applicable anchor and verifier material. See Proof of Provenance.

L3, BLEEEPY. Provides the conversational Agent interface. It helps translate an idea into an inspectable strategy specification, routes the specification through validation, presents the resulting evidence, and makes the applicable one-order or execution-mandate authorization controls available.

L4, Public surface and integrations. Exposes disclosure-controlled records, the NO-GO Archive, verification tools, permitted execution-mandate status and history, Marketplace entitlements, and approved external interfaces.

These layers describe the Agent decision path. BLEEEP Prop is a separate qualification domain that reuses shared data, paper-execution, proof, and public-surface capabilities; it is not an additional Agent layer.

How a registered signal moves

For an eligible strategy version, the forward process begins with stream activation. Routing remains separately authorized, either per order or through the execution mandate described in Step 0. Each decision recorded after activation follows evaluate → cryptographic commitment → timely anchor → route or remain unexecuted → capture event evidence → assess and verify. Decision generation and order-routing authority are separate.

0. Continuous promotion: activate the stream; authorize routing separately. After reviewing a historical GO and satisfying the applicable deployment gates, the user may activate a forward decision stream for that frozen strategy version. Stream activation and order-routing authority are separate, linked records. The account owner or another authorized principal may approve one order or create a revocable, time-bounded execution mandate identifying the strategy version, Validation Standard version, execution mode, account and venue scope, permitted markets, risk limits, expiry, and termination conditions. PaperExecutor is the default mode. LiveExecutor may be selected only after all applicable simulation, validation, eligibility, approval, venue, and risk gates are satisfied. A GO does not create an execution mandate. Human decision-making occurs when the user approves an order or grants the mandate, not when validation issues a verdict.

1. Evaluate. While the registered forward stream remains active, the frozen logic evaluates current inputs and produces an action signal, TRADE_ABSTENTION, or the predefined no-data or no-decision state. Evaluation may continue when no execution mandate is current. An action that is not routed remains an unexecuted registered decision; it is not relabeled as an abstention or fill.

2. Commit. L2 creates a cryptographic commitment for the eligible decision and places it in the ordered stream.

3. Anchor. The pre-outcome proof is valid only if the accepted anchor reaches the required finality before the registered deadline.

4. Route or block. At routing time, L1 applies the current effective authority defined under the Safety Vault. A permitted action is routed to the executor named by the mandate. An out-of-scope or blocked action produces no order and receives a separate source-labeled ROUTING_BLOCKED disposition. A TRADE_ABSTENTION also produces no order but remains a distinct decision record.

5. Capture event evidence. Each submitted instruction records the originating decision and the execution-mandate identifier and version that were current when it was routed. Orders, acknowledgments, cancellations, fills, fees, funding-rate payments, paper-simulation outputs, mandate lifecycle events, and routing blocks retain their actual evidence-source labels. A later fill traces through its originating order and is not retroactively invalidated solely because the mandate later expired or changed.

6. Assess and verify. Continuing evidence is assessed under the applicable continuing-eligibility and deployment rules without rewriting the historical GO. The disclosed record, manifest, and proof material enable the checks defined by the applicable proof class. The public surface can show the disclosure-controlled result and authorization trace without publishing private strategy logic or sensitive account controls. Provenance of the disclosed record and independent reproduction of undisclosed computation remain separate claims.

Forward-stream activation, pause, resumption, and termination are separate from execution-mandate lifecycle events and retain their actual event-evidence source labels. Pausing or terminating the stream stops new registered decisions; suspending, revoking, or allowing a mandate to expire stops routing but does not by itself stop the stream.

Next: The validation engine covers how a strategy version receives its verdict.