Execution flow

A frame is one invocation of strategy processing with a current market-data bar and session context. An execution intent is a request to perform an operation. Several paths can request execution during one frame, so a frame and an order are not interchangeable.

Shared frame order

The shared runner sets the current bar and reads positions before invoking these paths:

1. L3 frame hook: the enabled L3 app export can update state, run policies, and execute a selected policy action.
2. SJS: the configured SJS function receives the frame scope.
3. L2 and L1: the applicable position-analysis or flat/tick branch runs, with L2 before L1 and skip controls applied.
4. Native Pine: configured native Pine processing runs with the runner's skip/warmup signal.

This is the shared strategy runner's order, not a promise that every data producer updates at the same point. When consuming a model snapshot or Pine signal, check its timestamp and readiness. In particular, L3 runs before SJS in this runner, so L3 must not assume SJS has already produced evidence for the current frame.

Policy frame decisions

Inside L3, your script wires the framework explicitly:

runPolicyFrames
    ↓
resolveFrameActions
    ↓
executeResolvedAction (if an eligible action wins)

Policies run sequentially in array order. Resolution selects at most one eligible action from that batch. That does not impose a one-order-per-frame limit on other scripts or direct context calls.

Read Intents and resolution for ranking, eligibility, and required payloads.

Execution checks

The shared execution methods apply automation controls before the L3 execution gate. The source attached to a request affects the L3 behavior:

An absent or disabled L3 module permits requests at the L3 gate. An enabled module without an intent function also permits them. The hook rejects only an explicit false; return a Boolean deliberately.

An intent-hook exception blocks ordinary automated execution and records an L3 error in the normal runtime. Agent Lab propagates L3 failures as run failures; do not use throwing as a substitute for returning a policy decision.

What skip controls mean

The frame runner's skipall() sets flags for subsequent L1/L2 processing; session L2 algorithms have exemptions. It also contributes to the skip flag passed to native Pine. It does not prevent the SJS function from being invoked after L3.

The policy executor calls skipall() after an accepted place, modify, cancel, or close request. It treats results other than false, undefined, and null as accepted. A block policy action returns true without invoking skipall() or submitting an order.

To reject requests from another strategy path, implement an intent check. A frame status of blocked is descriptive and is not an execution gate by itself.

Follow the outcome

Inspect three separate facts: what the policy proposed, whether execution was accepted, and what the simulator or broker actually filled. Store decision summaries for the first two and inspect orders/trades for the third.

Continue with State and lifecycle and Debugging.