FST Safety: The Model Can Propose; Policy Decides What May Execute
FST places deterministic controls around probabilistic AI reasoning so an eloquent answer is never treated as authorization to risk capital.
Key Takeaways
- Only the exact selected account and its current certified capabilities determine whether AUTO execution is eligible.
- Risk limits, allowed instruments, exposure, environment, and approval settings are evaluated outside free-form model text.
- Every order is previewed before submission and carries an idempotency identity to prevent duplicate execution.
- Broker reconciliation, not the agent's expectation, determines the authoritative order and position state.
- Users retain visible pause, stop, approval, and parking controls; unsupported or ambiguous operations fail closed.
The FST Control Boundary
FST separates two jobs. The agent interprets research, explains a thesis, and proposes a bounded plan. Deterministic brokerage and policy services decide whether that plan is allowed for the exact user, provider, connection, account, environment, asset, operation, size, and validity window.
The capability progression is Connected, Portfolio verified, Stock trading verified, Options verified, and AUTO eligible. A provider name, logo, successful login, or readable portfolio does not imply live write capability. Only accounts that pass the required certification belong in the AUTO destination picker.
Preview, explicit approval policy, idempotency, upstream receipts, reconciliation, monitoring, and audit history protect the full lifecycle. If state is missing, stale, unsupported, degraded, or contradictory, the safe behavior is to reject or pause rather than guess.
How It Works
- Account eligibility — Bind the session to one user, provider, connection, account, environment, asset, and permitted operation.
- Risk verdict — Apply hard size, exposure, loss, instrument, and session constraints outside model-generated prose.
- Order preview — Show the exact proposed order and estimated effect before any write is attempted.
- Approval and idempotency — Follow the configured approval policy and attach a stable identity so retries cannot silently duplicate an order.
- Reconciliation — Treat provider receipts, orders, fills, and positions as authoritative and surface any mismatch.
- Continuous control — Maintain visible monitoring, safe defaults, pause, stop, and audited parking actions throughout the session.
Frequently Asked Questions
Can the language model override an FST risk limit?
No. Risk and capability checks are deterministic control-plane decisions, not suggestions embedded in model text.
What does AUTO eligible mean?
AUTO eligible means the exact account has passed the required connection, read, asset-specific write, reconciliation, and full-session checks for the intended environment and operation.
How does FST prevent duplicate orders?
Write operations use idempotency identities and reconcile provider responses so a retry cannot be treated as a new intent without detection.
What happens when account capability is uncertain?
FST fails closed: it blocks the operation or requires a safer route rather than inferring capability from the provider name.
Are live trades risk free because FST has guardrails?
No. Guardrails constrain process and exposure but cannot eliminate slippage, gaps, outages, model error, liquidity risk, or market loss.
Install FST 2.0 (desktop CLI & mobile app) · See QuantSignals V6