Separating trading decisions from authority to execute them.

THE WORK

The project.

trades makes a strategy's proposed action available for inspection before execution. The decision service evaluates the market snapshot, applies risk rules and records explicit order intents. Paper, shadow and live runtimes can then handle execution separately, while the saved cycle preserves what the strategy and risk layer decided.

Live activation has its own authorization path. Administrative access, approval, readiness and control state are checked before a session can start. Execution records also feed back into later planning: recent rejection clusters and longer latency and slippage history determine a saved degradation mode, which can limit new order intents until the checks recover.

IMPLEMENTATION

Design choices.

1. Order intents are data before they become execution work. Logging the complete decision cycle preserves the strategy and risk result even if execution later fails or produces a different outcome. A recorded intent is still not proof of an executed order.
2. Live arming sits outside strategy evaluation. The API and control service check authority and operational readiness, keeping a valid trading proposal separate from permission to act on it.
3. Recent rejection and cancellation clusters use a shorter lookback than latency and slippage. The recorded correction lets an old failure burst age out while retaining the wider quality history. When the checks pass, the evaluator clears the active degradation state that later planning reads.
4. apply_actions=false disables operational actions, not persistence. Evaluation still saves policy state and incident history, making its result available to later plans. An action-disabled call therefore remains a write and must not be used as a read-only diagnostic.

HOW IT FITS TOGETHER

Architecture.

• DecisionService passes the strategy result through risk_engine.apply and execution_planner.build, then appends a DecisionCycleResult containing the order intents. The recorded plan remains distinct from the exchange or runtime result, so later inspection can compare the proposal with what happened during execution.
• Paper, shadow and live runtimes consume those intents through separate execution modes. The strategy can propose a trade without owning the permission to start a live session; activation comes through the control path.
• The FastAPI live-arm route resolves authentication and role, checks promotion readiness and approval, then calls the control service. Stop, maintenance and readiness conditions can refuse activation before session creation. These checks govern the inspected arming path, not every possible application route.
• Execution events feed a longer quality summary for latency and slippage and a shorter summary for rejection or cancellation clusters. The evaluator combines those checks, saves the current degradation mode and updates incident history. Later order adaptation reads that saved mode when adjusting new intents.
• SQLAlchemy repositories persist records in PostgreSQL, with Alembic managing schema changes. Policy state, incidents and optional operational actions are updated through separate calls, so testing recovery has to follow all of them rather than only the evaluator's return value.

ACCESS & INPUT

Security controls.

• The inspected live-arm route checks configured authentication and administrative authority, followed by approval, readiness and control state. A strategy result that passes risk checks does not by itself authorize live activation.
• This account covers the reviewed route-to-service path. It does not establish a full API security audit, the state of a current deployment or the safety of live trading.

CHECKS & RESULTS

What was checked.

A source review shows what the code does. It is not a fresh test of the running app.

1. Code and development records reviewedReviewed11 September 2026

   The code, tests and available development records were checked. Reported test results keep their original scope. No fresh app or live deployment check was run for this write-up.

   Scope of this check

   Code review, not a fresh run of the app