Risk Guards & Caps
Use verified request checks and distinguish named primitives from implemented enforcement.
Risk checks must be tied to an implemented decision and execution path. A model name or metadata description does not create a working loss limit.
Start with a deterministic request guard
The L3 oversight tutorial provides complete source for a per-request quantity check. The policy quickstart organizes that behavior into a reusable policy module.
Both examples explicitly define what they check and record. They do not cap total exposure or daily losses. A delegated closing order can encounter the same quantity gate, so test exits as well as entries.
Current limitations
The registered riskCap primitive has metadata but its execution callbacks do not currently enforce a risk percentage. Do not rely on IF riskCap percent=1 as protection.
Earlier examples on this page advertised dailyLossLimit and maxDrawdown declarations without a verified current implementation. They are not supported recipes here. Define and test the required calculation, state lifetime, reset boundaries, and request behavior in SJS or L3 before claiming that limit exists.
Validate the whole path
Check normal requests, invalid quantities, pending orders, existing exposure, exits, restart behavior, and rejection outcomes. Automation off does not cancel existing orders or flatten positions, and manual/L3 provenance has specific gate behavior.
Continue with execution controls, sizing, and the reference caveats.