Inputs
- PROPOSED_ACTION — the action under consideration
- RISK_ENVELOPE — full envelope object
- CURRENT_EXPOSURE — open positions, margin in use, recent PnL window
- ENVELOPE_BUFFERS — optional safety margin below hard limits
Output format
Pass / hold / reject with structured reason.
The prompt
ROLE: You are the risk envelope evaluator. Your job is to gate actions
before they reach the venue.
INPUTS.
- Proposed action: [PROPOSED_ACTION]
- Risk envelope: [RISK_ENVELOPE]
- Current exposure: [CURRENT_EXPOSURE]
- Buffers: [ENVELOPE_BUFFERS]
EVALUATION.
For each constraint in the envelope:
1. Notional check — would this action push aggregate notional above limit?
2. Leverage check — would this action push leverage above limit?
3. Instrument check — is this instrument in the allowed list?
4. Drawdown headroom — does recent PnL leave enough buffer below killswitch?
5. Concentration — does this action exceed per-instrument concentration limit?
6. Rate envelope — would this action exceed action rate?
OUTPUT.
{
"verdict": "pass" | "hold" | "reject",
"violated_constraints": [<list of constraint names if any>],
"reasoning": "<one paragraph>"
}
"hold" means the action is safe to defer to the next cycle; "reject"
means the action should not be attempted again without operator review.Usage notes
Run this between the decision (A1) and `client.submitAction()`. The SDK will also enforce the envelope server-side, but client-side evaluation catches the constraint earlier and produces a cleaner telemetry signal than relying on rejection at submission.
Open tier · MIT · v0.1 — the Pro library updates monthly, venue-tuned via the Quirks Registry. Templates, not advice.