Working with SJS
Keep main strategy logic in SJS and use L3 for explicit oversight and coordination.
SJS owns the main algorithm. L3 can add reusable oversight while SJS continues to calculate signals, inspect orders and positions, and call execution methods.
Establish a baseline first
Run SJS alone, save the result, then add one deterministic L3 check. Keep the input data and execution settings fixed so you can explain the changed request outcome.
Do not move working signal code into L3 merely to enable an intent check. The request guard demonstrates a separate advanced layer.
Use evidence from the actual request
Because the L3 frame hook precedes SJS, reading the SJS signal from L3's app can see an earlier frame's state. Check its timestamp instead of assuming it belongs to the current observation.
The intent hook runs during execution submission. The SJS crossover attaches its current signal in options metadata; L3 can read it at intent.options?.opt?.metadata?.signal. That metadata is supplied by the strategy, so validate it rather than treating it as independent market evidence.
Distinguish action ownership
A frame policy can propose and execute its own action, or L3 can only review SJS requests. Choose which behavior you want. If both layers may act, inspect ordering, pending orders, and skip behavior to avoid duplicate submissions.
Keep source labels accurate. An L3 action that bypasses the L3 intent hook still needs its own validation and remains subject to other execution controls.
Test complete close paths
The shared simulator's close method can invoke a close-kind check and then a placement check. Test exits as well as entries when introducing a new guard. Allowing the first check does not guarantee the delegated request will be accepted.
The existing SJS/L3 integration guide walks through this boundary. Continue with using policies to modularize multiple checks.