Policy requirements
Prepare the source, market data, and algorithm instances that a policy actually consumes.
A policy definition does not install its dependencies. Before running it, identify the editor it belongs in, the data it reads, and any configured algorithms it expects.
Start with the smallest dependency set
The quantity guard needs an execution request and the shared L3 policy framework. It needs no session-regime model, external data service, or AI provider.
A policy that reads context.algos.find("sessionRegime", "fast") additionally needs a configured instance with that exact name and ID. A policy consuming historical windows needs the requested data to be available. A policy calling a model provider needs the runtime's supported provider configuration.
| Dependency | What to verify |
|---|---|
| L3 source | Named exports are saved and config.enabled is not false |
| Framework | args.modules.policies exists in the L3 scope |
| Algorithm | The configured name and instance ID match the lookup |
| Snapshot | It is present, ready, and sufficiently recent for your rule |
| Market data | Instrument, interval, dates, and timezone match the experiment |
| Provider or service | The execution environment supports and configures it |
Treat “missing” and “not ready” as explicit decision states. Choose whether each execution check should permit or reject a request while evidence is unavailable, and state that choice in its reason.
What policyRequirements means
Some native SJS examples use a separate developer runner with a policyRequirements declaration. That runner extracts a literal object from SJS source and turns it into an app configuration. It is not an L3 policy field and is not an automatic dependency installer for every editor or Agent Lab run.
The following is an SJS developer-runner declaration, not code to append to the L3 quickstart. Replace the example instrument and date range with data available to your runner.
const policyRequirements = {
algos: [
{
name: "sessionRegime",
params: { id: "fast", interval: 3000, intervalRes: 15000 },
},
],
md: {
instrument: {
contract: {
symbol: "AAPL",
secType: "STK",
exchange: "SMART",
currency: "USD",
},
},
start: "2026-06-01T13:30:00.000Z",
end: "2026-06-01T14:00:00.000Z",
interval: "1m",
timezone: "America/New_York",
useRdx: true,
},
};The current source extractor accepts declarations named policyRequirements or policyRequires, requires algos and md, and recognizes sessionRegime and sessionEpisode algorithm names. Its literal parser does not evaluate function calls, imported settings, object spreads, or references such as config.regimeId.
That restriction belongs to this extractor, not the full engine model registry. For normal app or Lab workflows, configure the required models and data through the supported app/experiment configuration instead of assuming this declaration will be applied.
Agent Lab considerations
AI-assisted authoring and in-strategy AI calls are separate capabilities. Agent Lab's authoring model can edit source and inspect historical results; that does not enable live provider calls inside an L3 backtest. The existing backtest provider policy blocks real in-strategy AI calls.
The Lab historical path is bar-based. Do not write a policy that requires a live order book and interpret absent book data as a neutral signal in a bar-only experiment.
Next, define a reusable module, or use Debugging to investigate missing inputs.