# Versioned LLM signals, separated trading authority

> A production reference architecture for turning an already-validated hybrid forecast into targets, independently risk-approved orders, venue events, and positions the firm can explain.

Published: 2026-08-30 · Lumisonde (https://lumisonde.com/reports/llm-signal-production-authority/)
Citations JSON (per-claim receipts): https://lumisonde.com/reports/llm-signal-production-authority/citations.json
Continues: https://lumisonde.com/reports/llm-quant-signal-fusion/

## The brief

**Question:** Once an LLM-derived semantic signal has proved incremental value, how should a hybrid quantitative system turn it into risk-approved orders and reconciled positions?

**Stake:** A semantic observation can influence capital only after several services interpret it, size it, authorize it, submit it, and reconcile what the venue actually did.

**Answer:** Treat the LLM output as immutable, versioned data and compile it through forecast, target, intent, independent risk authorization, child order, venue event, and reconciliation contracts. Keep one writer for each durable state; once an effect may have reached a broker, venue evidence determines whether the order existed or filled, and recovery moves forward from that truth. The design supports architecture endorsement and staged pilot evaluation, but it does not itself authorize live capital: rollout thresholds, cross-service authorization, and stale-writer fencing still require target-specific evidence and accountable approval. Released systems supply many component seams, yet the cited evidence does not demonstrate the complete independently enforced composition.

*The LLM Edge in Finance Is a Division of Labor* asked where an LLM-derived signal might add edge. *From Language to Incremental Edge: Engineering LLM Semantics into Quantitative Models* asked how to fuse that signal with conventional quantitative features. This report starts after both questions have been answered: the semantic feature has survived incremental-value tests, the hybrid model has been calibrated, and the remaining problem is to put the result in contact with capital without letting an uncertain observation become an unconstrained actuator.

The governing answer is simple. An LLM output should enter production as **versioned data**, not as a trader. The live system should compile that data through a sequence of progressively narrower contracts:

\[
\text{point-in-time features}
\rightarrow \text{forecast distribution}
\rightarrow \text{desired portfolio}
\rightarrow \text{trade intent}
\rightarrow \text{risk authorization}
\rightarrow \text{child orders}
\rightarrow \text{venue events}
\rightarrow \text{reconciled positions}.
\]

Each arrow changes the object's authority. The forecaster converts semantic observations into return distributions; the portfolio constructor converts forecasts into desired holdings; independent risk converts bounded intents into permission to trade. A submitted order is not a fill: venue evidence and reconciliation establish the resulting position. The architecture works when each component owns exactly one of those transformations, when capital-changing decisions are replayable from pinned inputs, and when the system stops trying to recompute truth once an effect may have reached a broker or exchange.

Authority separation is therefore an architectural invariant, but it is not the article's sole thesis. The point is to build an operating system in which forecasts, portfolio construction, risk, execution, and accounting can each change independently without changing what the neighboring stages are allowed to mean.

## Begin with a deployable signal contract

A successful experiment reaches production through an immutable `SignalBundle`: a versioned unit that contains or identifies the semantic extractor, conventional and semantic feature definitions, forecast model, calibration transform, training snapshot, output units and horizon, schema versions, compatible portfolio-policy API, and evaluated fallback behavior.

The bundle should answer practical questions before a live run begins:

- Which instruments and universes may use it?
- Which event-time and availability-time rules define an admissible input?
- How old may a semantic feature become before it expires?
- What does a missing feature produce: a conventional-only forecast, or no forecast at all?
- Which forecast and allocator schemas are compatible?
- Which artifact, code, dependency image, and evaluation report produced this candidate?

The fallback is part of the promoted strategy. `BASELINE_ONLY` is valid only if the conventional-only sibling was separately evaluated and calibrated. Carrying the last semantic value beyond its time-to-live silently creates a different, unevaluated strategy.

An alias such as `production-candidate` may be convenient for promotion, but a decision run resolves it once. The run then pins the resulting immutable artifact IDs. Current registry tooling exposes lifecycle seams for artifacts, lineage, evaluation, monitoring, access, and deployment; portfolio, risk, OMS, venue, and fill authority remain downstream.[2]

The production boundary can be represented as a small manifest:

```text
SignalBundle {
  bundle_id: ContentHash
  feature_schema: SemVer
  forecast_schema: SemVer
  semantic_extractor_id: ArtifactId
  forecast_model_id: ArtifactId
  calibration_id: ArtifactId
  training_snapshot_id: SnapshotId
  horizon: Duration
  return_unit: LOG_EXCESS_RETURN_BPS
  allowed_universes: [UniverseId]
  semantic_ttl: Duration
  null_policy: BASELINE_ONLY | NO_FORECAST
  compatible_allocator_api: VersionRange
}
```

This is the one place where training and semantic-feature construction matter to the present design: their artifacts, schemas, clocks, and tested outage behavior must cross into production intact. How they were learned remains upstream.

## Follow one DecisionRun through the three planes

With the bundle pinned, the next question is how one live decision moves through the system.

The end-to-end design separates observation, decision, and execution, while an append-only event and decision log connects them:

```mermaid
flowchart LR
  subgraph observation["Observation plane"]
    A["Market, reference and document adapters"] --> B["Immutable raw/event store"]
    B --> C["Semantic and numeric feature services"]
    C --> D["Validation and point-in-time snapshot"]
  end
  subgraph decision["Decision plane"]
    D --> E["Forecast service"]
    E --> F["Portfolio constructor"]
    F --> G["Trade planner"]
    G --> H["Independent pre-trade risk"]
  end
  subgraph execution["Execution plane"]
    H --> I["OMS and execution engine"]
    I --> J["Credentialed venue adapter"]
    J <--> K["Broker or exchange"]
    J --> L["Order and position reconciler"]
    L --> I
    L --> F
    L --> H
  end
  M["Append-only lineage and event log"] --- D
  M --- E
  M --- F
  M --- H
  M --- I
  M --- L
  N["Registry, limits, rollout and kill-state control plane"] -.-> C
  N -.-> E
  N -.-> F
  N -.-> H
  N -.-> I
```

Call the worked rebalance below `DecisionRun R`. At its trigger, `R` resolves the promoted alias once, pins one `SignalBundle`, and never substitutes a mutable artifact afterward. The same `decision_run_id` then follows one admitted snapshot through forecast, target, intent, risk, order, and reconciliation. It is the concrete path through the diagram:

```text
TRIGGERED
 -> SNAPSHOT_PINNED
 -> FORECASTED
 -> TARGETED
 -> INTENTS_PLANNED
 -> RISK_DECIDED
 -> RELEASED
 -> EXECUTING
 -> RECONCILING
 -> RECONCILED
 -> CLOSED
```

For `R`, the snapshot contains one eligible instrument, `Instrument A`, whose admitted semantic feature has not expired. The forecast service emits a distribution rather than a direction to trade. The portfolio constructor compares that forecast with the reconciled portfolio and emits a higher target for `Instrument A`. The planner turns the positive target delta into a parent `BUY` intent. The risk service returns `APPROVE` for an exact bounded envelope; the OMS reserves capacity before creating a child; and the credentialed adapter attempts submission. The worked branch then becomes difficult on purpose: the submit outcome is initially `UNKNOWN`, venue evidence later shows a partial fill, a monitor triggers a halt, and recovery proceeds from the reconciled fill rather than from the pre-submit assumption. Every later section advances or tests this same run.

An event bus carries facts and commands. The append-only log preserves the durable audit and replay history. Materialized stores serve current projections from that history. Each responsibility therefore has a distinct owner and recovery source.

Every cross-service message should share an envelope with a `decision_run_id`, causation and correlation IDs, producer identity, schema version, payload hash, and three clocks:

```text
Envelope<T> {
  event_id: UUID
  event_type: QualifiedName
  schema_version: SemVer
  decision_run_id: UUID
  causation_id: UUID?
  correlation_id: UUID
  producer: ServiceIdentity
  effective_at: Instant   // time in the modeled world
  observed_at: Instant    // first time the source was available
  produced_at: Instant
  owner_sequence: UInt64?
  payload_hash: ContentHash
  payload: T
}
```

The clocks prevent a corrected document, restated reference field, or late market print from masquerading as information that was available earlier. The `observed_at` boundary is especially important for semantic sources: the publication time printed on a document is not necessarily the time the production system could first retrieve and parse it. Current feature-store tooling provides offline and online storage, point-in-time historical retrieval, serving, registry interfaces, and monitoring; finance-specific symbology, corporate actions, calendars, and source-availability logic still have to surround it.[1]

### Run R pins an observation and produces a forecast

For `R`, the semantic service reads versioned source objects and emits structured, bounded feature values. It may decide how text maps to the promoted ontology. It may not decide expected returns, target weights, quantities, venues, or order types.

```text
SemanticFeature {
  entity: InstrumentId | IssuerId | MacroSeriesId
  feature_set_id: ArtifactId
  values: Map<FeatureName, Decimal | Int | Enum | Bool>
  source_object_ids: [ContentHash]
  source_available_at: Instant
  valid_from: Instant
  expires_at: Instant
  extractor_id: ArtifactId
  prompt_hash: ContentHash
  quality: {
    schema_valid: Bool
    evidence_coverage: Decimal
    truncation: Bool
    disagreement: Decimal?
  }
}
```

Admission is deterministic: schema and enum checks, numeric bounds, source allowlists, timestamp monotonicity, duplicate suppression, entity mapping, and expiry. Free text may be retained in a restricted audit store, but it is not parsed by a later trading service. A malformed or late observation becomes `FeatureUnavailable`; it is not repaired ad hoc downstream.

At a rebalance trigger, the snapshot service waits for a declared readiness barrier or reaches its deadline. It atomically binds the eligible universe, numeric features, admitted semantic features, prices, corporate actions, and availability timestamps into a content-addressed `FeatureSnapshotRef`. Late arrivals belong to a later decision run.

The forecast service maps that snapshot to a horizon-matched return distribution:

```text
Forecast {
  instrument: InstrumentId
  as_of: Instant
  horizon: Duration
  expected_excess_return_bps: Decimal
  stddev_bps: Decimal
  quantiles_bps: Map<Probability, Decimal>
  tradability: ELIGIBLE | OBSERVE_ONLY | INELIGIBLE
  feature_snapshot_id: ContentHash
  signal_bundle_id: ContentHash
  inference_hash: ContentHash
}
```

The service owns forecast artifacts and calibration state. It does not read order types or broker state. It publishes uncertainty and eligibility because a portfolio constructor needs more than a rank score, and it writes its full input/output lineage before emitting `ForecastReady`.

### Run R turns the forecast into desired holdings

With `R` now `FORECASTED`, the portfolio constructor combines the forecast batch with the current **reconciled** portfolio, risk-model snapshot, mandates, borrow or locate state, liquidity estimates, and transaction-cost model. Its output is a desired portfolio, not an order list.

A typical implementation solves a constrained problem of the form

\[
\begin{aligned}
w_t^* = \arg\max_w\quad & \mu_t^\top w
- \frac{\lambda}{2}w^\top\Sigma_t w
- C(w-w_{t^-})\\
\text{s.t.}\quad
& Aw\le b,\\
& \ell_i\le w_i\le u_i,\\
& \|w\|_1\le L,\quad
\operatorname{turnover}(w,w_{t^-})\le T.
\end{aligned}
\]

The hard constraints cover cash, mandate, gross and net exposure, concentration, factors, sectors, currencies, liquidity, and borrow as applicable. The cost term carries spread, fees, impact, and borrow rather than asking forecast calibration to absorb execution economics. Solver version, tolerances, tie-breaking rule, input hashes, and result are recorded. If the problem is infeasible, the constructor returns a typed failure; it does not relax a mandate or reuse an expired target.

`PortfolioTargetSet` binds each target to the forecast batch, risk snapshot, allocator version, decision run, and portfolio sequence it observed. Cvxportfolio 1.5.0 is a concrete open-source optimization seam: it exposes policies, costs, constraints, risk models, and a market simulator for portfolio optimization and backtesting, while live OMS and venue-state authority remain separate.[4] Related research tooling similarly offers loosely coupled signal, record, and portfolio-analysis modules.[23] Those libraries are useful precisely because desired holdings can be kept separate from order authority.

### Run R turns desired holdings into bounded intent

When `R` reaches `TARGETED`, the trade planner compares the target set with reconciled positions and working orders, nets demands according to an explicit cross-strategy policy, applies lot and currency rules, checks restricted and borrow state, and creates parent intents:

```text
OrderIntent {
  intent_id: ContentHash
  target_set_id: ContentHash
  based_on_portfolio_seq: UInt64
  instrument: InstrumentId
  side: BUY | SELL
  total_quantity: Decimal
  urgency: PASSIVE | NORMAL | URGENT | RISK_REDUCTION
  start_at: Instant
  complete_by: Instant
  max_participation: Decimal
  limit_guard_bps: Decimal?
  strategy_allocation: Map<StrategyId, Decimal>
}
```

The planner may express urgency, a completion window, participation, and price protection permitted by the portfolio policy. It cannot authorize the exposure it requests.

Before any submission, an independently controlled pre-trade risk service reloads authoritative account, position, working-order, price, instrument, limit, restricted-list, locate, venue, and global trading-state snapshots. It does not trust P&L, prices, or quantities computed by the allocator. Checks use fixed-point arithmetic and deterministic rounding.

This independence has a concrete regulatory analogue. In its scope, Rule 15c3-5 requires market-access controls to remain under the broker-dealer's direct and exclusive control and to reject orders that breach aggregate credit or capital thresholds, price or size parameters, or duplicate-order checks.[5] Official SEC guidance further says automated pre-trade controls are required when an electronic system participates in execution.[6] Those rules do not prescribe the upstream forecast architecture, but they make clear why a typed `OrderIntent` cannot double as risk approval.

The risk result should authorize exact fields or a narrow parent envelope:

```text
RiskDecision {
  risk_decision_id: ContentHash
  intent_id: ContentHash
  authorization_seq: UInt64
  decision: APPROVE | CLIP | REJECT
  authorized: {
    instrument: InstrumentId
    side: BUY | SELL
    max_cumulative_quantity: Decimal
    max_child_quantity: Decimal
    allowed_order_types: [Enum]
    allowed_venues: [VenueId]
    worst_price: Decimal?
    max_participation: Decimal
    not_before: Instant
    expires_at: Instant
  }?
  evaluated_portfolio_seq: UInt64
  market_snapshot_id: ContentHash
  limit_set_id: ContentHash
  check_results: [RuleResult]
}
```

An approval becomes invalid for a new reservation when its position sequence, limit version, side, price bound, expiry, or cumulative authorized quantity changes. `CLIP` is permitted only where policy can prove from authoritative current state that the reduction is monotone in the relevant exposure. Otherwise the safe result is `REJECT`. The signed and consumable envelope is a reference-design extension, not a feature demonstrated by the open-source systems cited here.

For this reference architecture, the authorization journal and the OMS order journal meet through an explicit reserve, commit, retain, and release protocol. This protocol is an engineered way to enforce the bounded envelope; it should not be attributed to the released engines or venue protocols cited in this article.

The risk service is the sole writer of authorization availability and consumption; the OMS is the sole writer of child-order lifecycle. Each `RiskDecision` therefore carries an `authorization_seq` in addition to the portfolio sequence it evaluated. Each child uses one stable `child_order_id`, and every risk mutation supplies the expected authorization sequence so that a duplicate command returns the prior result while a stale command fails closed.

The risk journal keeps the parent authorization in `OPEN`, `STALE`, `EXHAUSTED`, `REVOKED`, or `EXPIRED`; each child reservation moves through `RESERVED`, `COMMITTED`, `RETAINED`, and finally `SETTLED` or `RELEASED`. The OMS keeps the separate venue-facing lifecycle shown in the next section. Those two state machines meet only through sequenced receipts and events, so neither service writes the other's state.

The boundary runs as follows:

1. **Reserve.** Before the OMS can construct a sendable child, it asks the risk service to reserve an exact quantity against the authorization, naming the child, the observed `authorization_seq`, and the authorization expiry. The risk service checks that the authorization is open, unexpired, based on the required portfolio and limit versions, and has enough unreserved capacity. A successful compare-and-swap emits `AuthorizationReserved` with a new sequence. A refused or timed-out reservation produces no sendable order.
2. **Commit.** The OMS durably records the child as `SUBMITTING`, with a stable attempt ID, payload hash, and `NOT_SENT` transmission state, then asks the risk service to commit that reservation to the same attempt. The risk service emits `AuthorizationCommitted`; only a child carrying that sequenced commit receipt may reach the credentialed adapter. This handshake is deliberately fail-closed: the two services do not pretend to share an atomic transaction with the venue.
3. **Retain.** Before the first send, risk moves committed quantity to `RETAINED` and the adapter durably advances the attempt from `NOT_SENT` to `MAY_HAVE_LEFT`. A local timeout, process restart, or expired parent authorization cannot release that capacity by inference. Whenever a definitive response is lost after that boundary, the OMS records the child as `UNKNOWN`; the later venue section applies this rule to `R`.
4. **Settle or release.** A venue fill produces `AuthorizationSettled` for the filled quantity. Working leaves remain retained. A definitive local pre-send failure, venue rejection, expiry before commit, or acknowledged cancellation produces `AuthorizationReleased` only for quantity that venue evidence shows can no longer fill. A cancel request by itself releases nothing because fills may race with it.[10, 11]
5. **Reauthorize after state advances.** When a partial fill is booked, the reconciler advances the canonical portfolio sequence. The old authorization can still account for the already committed working child, but its unreserved headroom becomes stale: the OMS cannot create another child from it. To continue, it presents the same intent plus filled, working, canceled, and released quantities to risk. The risk service evaluates current positions, working orders, prices, limits, and trading state and either issues a successor authorization sequence for the remaining intent or rejects it. The successor never resets the parent's already filled or still-working quantity.

The cross-journal contract below makes the crash boundary executable. Every mutation supplies the expected owner sequence; duplicate calls with the same idempotency key return the first result, while a reused key with a different payload fails closed.

| Transition | Sole writer | Required prior state and sequence | Durable trigger and idempotency key | Authorization quantity effect | Allowed next command | Crash or restart behavior |
|---|---|---|---|---|---|---|
| reserve child | risk service | parent `OPEN`; current authorization and portfolio sequences; trading state permits the requested exposure | `ReserveRequested`; key = authorization plus `child_order_id` | available headroom becomes `RESERVED` | persist the OMS child | replay returns the same reservation; a stale sequence refuses |
| stage send attempt | OMS | matching `AuthorizationReserved`; child absent or identical | `ChildSendAttempt` with stable attempt ID, payload hash, and `NOT_SENT`; key = `child_order_id` | no change; quantity remains reserved | request commit | `NOT_SENT` proves the adapter has not crossed the send boundary |
| commit attempt | risk service | exact reservation and expected authorization sequence; attempt payload matches | `CommitRequested`; key = reservation plus attempt ID | `RESERVED` becomes `COMMITTED` | request retain-before-send | replay returns the same commit; expiry or a stale sequence refuses |
| retain before send | risk service | matching commit and expected authorization sequence; OMS `SUBMITTING`; global state still permits send | `RetainBeforeSend`; key = commit plus attempt ID | `COMMITTED` becomes `RETAINED` | give the retained receipt to the adapter | replay returns the same retained state; stale trading or authorization state refuses |
| cross the send boundary | credentialed adapter | matching retained receipt and OMS attempt in `NOT_SENT` with the same payload hash | `AttemptMayHaveLeft` is durable before the first socket write; key = attempt ID | no change; quantity remains retained | send the identical payload once | crash at `NOT_SENT` may resume the same attempt; crash at `MAY_HAVE_LEFT` must enter `UNKNOWN` |
| record send outcome | OMS | `SUBMITTING` plus the same retained attempt | adapter `Sent` receipt moves the child to `SUBMITTED`; missing definitive receipt after `MAY_HAVE_LEFT` moves it to `UNKNOWN`; key = attempt ID | retained quantity is unchanged | await venue evidence; for `UNKNOWN`, query or cancel by original identity | never mint a new identity or resubmit an uncertain attempt |
| record venue partial fill | credentialed adapter | original child identity correlates; venue execution identity unseen | raw venue event plus sequence and message hash; key = venue execution identity | no risk-journal change | publish the recorded venue fact | replay returns the same event and cannot invent leaves absent from the venue message |
| book the partial fill | position ledger/reconciler | recorded fill unseen in the canonical ledger; expected portfolio sequence | `FillBooked`; key = venue execution identity | cash and position change; portfolio sequence advances | publish the new canonical projection | replay books the fill once; unknown leaves remain explicitly unresolved |
| settle fill and retain unknown leaves | risk service | `FillBooked`; matching old authorization sequence and child | `SettleFill`; key = authorization plus venue execution identity | filled quantity becomes `SETTLED`; the entire unresolved remainder stays `RETAINED`; old headroom becomes stale | query, retransmit request, or cancel; no related increase | replay returns the same settlement and preserves retained leaves until venue evidence resolves them |
| release a resolved remainder | risk service | venue rejection, venue expiry, definitive pre-send failure, or acknowledged cancellation at the expected authorization sequence | venue event identity or local no-send attempt ID | only the proven non-fillable remainder becomes available headroom | close the child or evaluate a fresh successor | a cancel request without acknowledgement leaves quantity retained |
| halt directly | risk control plane | `ACTIVE` or `REDUCING`; current trading-state sequence | hard monitor predicate or authorized operator kill; key = halt incident ID | uncommitted capacity is revoked; committed and retained capacity stays accounted | query, reconcile, or cancel; submit and modify are blocked | restart loads `HALTED` before enabling any command path |
| evaluate successor | risk service | reconciled fill and leaves; current portfolio, limits, and trading-state sequences | successor request keyed by intent plus new portfolio sequence | old settled and retained quantities remain attached to the old authorization | while `HALTED`, refuse a sendable successor; after approved re-entry, issue or refuse a fresh sequence | replay cannot reopen the old sequence or reset prior fills |
| resume `ACTIVE` | risk control plane | one fenced writer, reconciled venue and internal state, no unexplained unknowns, current limits, and completed dry-run risk check | approved resume record; key = incident ID plus reconciled portfolio sequence | only a fresh current authorization exposes sendable headroom | start a new child from the current sequence | restart remains halted unless the approved resume record is durable |

Quantity conservation is checked per authorization sequence. Let `Q` be authorized cumulative quantity, `S` settled fills, `R_t` reserved, committed, or retained quantity, and `H` unused headroom: `Q = S + R_t + H`. Release moves quantity from `R_t` back to `H`; it never subtracts a fill. For `R`, let the child quantity be `q` and the observed partial fill be `f`. While leaves are unknown, `S = f`, `R_t = q - f`, and the old headroom `H = Q - q` is accounted for but not sendable because the portfolio sequence is stale. If reconciliation later establishes working leaves `l`, risk retains `l` and releases `q - f - l`; `HALTED` still exposes no sendable capacity, and any successor begins from the reconciled portfolio sequence.

Expiry is therefore a boundary on new reservation and commit, not a claim that an order already accepted by a venue disappears. An uncommitted reservation that reaches its deadline can be released locally. A committed `UNKNOWN`, acknowledged, or partially filled child stays retained until rejection, fill, expiry reported by the venue, or acknowledged cancellation establishes its remaining effect. Cancel commands remain available even when no new exposure may be authorized.

## Run R reaches capital only after each stage tests a different claim

`R` can be allowed to reach the live external-effect branch only after its pinned bundle, schemas, state machines, and strategy logic pass the staged gates below, with environments changing adapters, permissions, and risk budgets. The following ladder is a reference operating design, not a universally validated sequence with universal thresholds:

1. **Historical replay.** Run point-in-time inputs through the production feature, forecast, allocator, and risk code. Include revised documents, corporate actions, realistic calendars and costs, borrow, liquidity, rejects, partial fills, and injected outages. Require stable hashes for every post-semantic internal transition.
2. **Live shadow.** Consume live data and produce snapshots, forecasts, targets, intents, and risk decisions, but give the OMS no trading credentials. Measure readiness, latency, feature coverage, forecast maturity, counterfactual positions, and expected costs.
3. **Paper or exchange sandbox.** Exercise the real OMS, adapter, client identities, retries, reconnects, cancels, and reconciliation against a simulator or test venue. This stage tests lifecycle mechanics, not live queue position, impact, or economic edge. Interactive Brokers states that paper fills are simulated from top-of-book data, do not execute on an exchange or settle at a clearing house, and can handle partial market orders differently from live venues.[17]
4. **Capital-capped canary.** Enable a disjoint account, instrument subset, venue subset, or small risk budget. Partitioning is preferable to sampling random individual orders because the latter can distort portfolio constraints. Enforce notional, gross, participation, loss, instrument, and message-rate limits outside the strategy.
5. **Graduated production.** Increase risk budget only after predeclared system, execution, risk, reconciliation, and economic gates pass over minimum time and sample windows. Continue dual inference of the incumbent and candidate so proposed forecasts and targets remain comparable.

Promotion and re-entry need named accountable functions, not just passing dashboards. The thresholds and minimum windows below are predeclared from target-system distributions and recorded in the evidence packet; none is a universal constant.

| Decision | Accountable function | Metric and local calibration method | Minimum sample or window | Required evidence | Approver, exception rule, and rollback trigger |
|---|---|---|---|---|---|
| historical replay to live shadow | signal owner | deterministic transition hashes, point-in-time integrity, forecast calibration, and risk-rule coverage; bounds come from held-out replay plus injected failures | enough independent market regimes and failure cases to exercise every hard transition | pinned bundle, replay manifest, invariant results, failure-injection log, and unresolved-risk register | model governance and trading engineering approve; hard lineage or risk failures cannot be waived; mismatch reverts the candidate bundle |
| live shadow to paper or sandbox | production engineering | readiness, feature coverage, latency, forecast maturity, and counterfactual target stability; limits derive from observed live distributions | a predeclared live window spanning normal and stressed operating periods | shadow comparison, outage results, credential-isolation proof, and operator runbook | platform owner and independent risk approve; no exception for trading credentials in shadow; stale or incomplete inputs return to replay or shadow |
| paper or sandbox to capital-capped canary | execution operations | lifecycle completion, unknown-order age, reconnect recovery, cancel races, duplicate suppression, and reconciliation; bounds come from venue-specific drills | enough orders and injected session failures to exercise every legal order transition | OMS and risk journals, reconciliation drill, kill test, venue-simulation caveats, and residual-risk sign-off | market-access risk and compliance approve; no waiver for unresolved orders or failed kill paths; any journal or venue mismatch blocks live release |
| canary to graduated production | portfolio owner | hard-limit headroom, execution quality, reconciliation, realized-versus-modeled costs, and matured economics; gates come from the strategy's own liquidity, latency, loss, and horizon distributions | predeclared time and matured-decision windows for the canary scope | canary attribution, incident log, limit review, reconciliation record, and capacity analysis | senior independent risk accepts residual risk; soft-gate exceptions need an owner, expiry, and compensating control; hard breach, unexplained unknown, or cost deterioration rolls back the relevant component |
| `HALTED` to `ACTIVE` | incident commander | venue/internal agreement, unknown-order clearance, writer fencing, current limits, and dry-run authorization against the reconciled portfolio | stable reconciliation and service-health window declared in the incident plan | incident timeline, venue evidence, rebuilt projection, fencing proof, dry-run risk result, and open-risk register | risk-control owner approves with execution operations; no exception for unexplained external effects or split brain; recurrence returns directly to `HALTED` |

The same packet makes residual integration risk explicit:

| Residual integration risk | Mitigation owner | Canary-versus-scale status | Acceptance authority |
|---|---|---|---|
| cross-service authorization and OMS journals diverge | risk-platform owner implements sequenced reserve, commit, retain, settle, and release checks plus reconciliation alarms | canary blocker until quantity conservation and crash recovery pass; scale blocker on any recurring divergence | market-access risk |
| a stale execution writer survives failover | execution-platform owner implements fencing and startup reconciliation | canary blocker | risk-control owner and execution operations |
| rollout or monitor bounds lack target-system calibration | signal owner and site-reliability owner predeclare methods, windows, and action mapping | canary blocker for safety bounds; scale blocker for economic and capacity bounds | model governance for model gates; independent risk for capital gates |
| venue-specific recovery leaves an external effect unexplained | execution operations preserves original identities and reconciles open orders, fills, cash, and positions | canary and scale blocker while unresolved | incident commander with risk-control approval |

Regulatory guidance directly supports separated pre-production environments, authorized deployment, predefined instrument, price, value, volume and message limits, real-time monitoring, pre-trade controls, and kill functionality for unexecuted orders.[15] FINRA likewise organizes effective supervision around risk assessment, code development, testing, trading systems, and compliance while warning that reasonable controls cannot foresee every failure.[16] Those sources support the classes of control. They do not provide a valid canary percentage or alert threshold for this hybrid strategy; those values must be calibrated from its own latency, liquidity, execution, and loss distributions.

Changes should also be isolated by component. A candidate forecast model can shadow behind the incumbent allocator. A new execution algorithm can receive identical approved parent intents. A limit change can replay the recent intent journal. Changing extractor, forecaster, allocator, risk rules, and execution code together destroys causal diagnosis even when the bundle can technically be rolled back.

## Run R crosses into venue effects

With `R` risk-decided and those staged gates passed, the OMS owns client-order identity and the local order state machine. The execution engine may choose child timing, order type, limit price, and venue only inside an unexpired authorization. Each child follows the reservation protocol above; the adapter may translate canonical fields into a venue protocol but may not enlarge them. Only the adapter holds broker credentials.

A deterministic client order key can combine the account, risk decision, child index, and replacement generation, while the durable ledger supplies uniqueness across the full history. CME documents a venue `OrderID` that remains constant through an order's life while client-ID uniqueness is scoped to working orders within a sender and market segment; Binance permits a client ID to be reused after the previous order is filled.[8, 9] The ledger therefore retains the client key, venue order key, venue execution or trade key, session context, and replacement chain.

The local lifecycle needs pending and unknown states:

```text
CREATED -> RISK_AUTHORIZED -> SUBMITTING -> SUBMITTED -> ACKNOWLEDGED
                                      \-> UNKNOWN
ACKNOWLEDGED -> PARTIALLY_FILLED -> FILLED
ACKNOWLEDGED -> CANCEL_PENDING -> CANCELED
ACKNOWLEDGED -> REPLACE_PENDING -> REPLACED
SUBMITTED/ACKNOWLEDGED -> REJECTED | EXPIRED
```

The first child in `R` reaches `SUBMITTING` with committed authorization, but the adapter loses a definitive response after the command may have reached the venue. The OMS advances it to `UNKNOWN`, not `REJECTED`, and the reservation remains retained. A later venue report correlates the original client identity to an acknowledged order and reports a partial fill, but a subsequent sequence gap prevents the reconciler from proving the current leaves. It books the observed fill once, advances the portfolio sequence, and publishes the new cash, position, and strategy-allocation projection while keeping the unresolved remainder `UNKNOWN`. Risk marks the old authorization's unused headroom stale and retains the committed remainder. No second child can be created until full reconciliation establishes the working quantity and risk either issues a successor authorization or refuses the remainder.

A cancel request is not a cancellation fact. FIX order-state semantics keep a replacement pending until an execution report confirms it and allow fills while cancel or replace is pending; Cboe's venue specification rejects overlapping replace requests and applies quantity changes against current leaves.[10, 11] The OMS must retain the last accepted parameter chain and apply intervening fills to it.

The most important branch is `UNKNOWN`. If a network timeout occurs after bytes may have left the process, a local exception proves neither acceptance nor rejection. Do not create a fresh ID and resubmit. Query status using the original identities, consume private-stream or drop-copy events, request retransmission where the protocol permits, and reconcile open orders, fills, cash, and positions. NautilusTrader's current execution documentation makes this distinction directly: definitive local failure can deny a command, while a possibly sent command remains in flight rather than becoming an invented rejection. Its live node also reconciles cached order and position state with venue reports before trading components start.[7]

Venue acknowledgements, rejections, cancellations, expiries, and fills are external facts. The adapter records them with venue sequence numbers and raw-message hashes. The OMS applies only legal transitions. The position ledger books each fill once using the venue's execution or trade identity, qualified by the protocol's actual uniqueness scope. Partial fills immediately update cash, positions, remaining authorization, and strategy allocation. The next allocation run starts from that reconciled state—not from the desired target and not from an assumption that a submitted order filled.

### State ownership keeps R from forking into competing truths

Typed interfaces clarify responsibility, but they do not enforce it. LEAN demonstrates a useful `Insight` → `PortfolioTarget` → risk-adjusted target → execution flow, yet all modules live inside `QCAlgorithm`, and its supported hybrid mode can omit stages or place orders from insight events.[3] Types are therefore necessary documentation and validation boundaries; process identities, network policies, database permissions, and credential placement are what turn them into authority boundaries.

Each durable state needs one logical writer:

| Durable state | Sole logical writer | Recovery source |
|---|---|---|
| Raw market, reference, and document objects | ingestion/archive service | immutable objects plus source offsets |
| Admitted semantic features | semantic feature service | raw objects plus pinned extractor, or persisted feature events |
| Feature snapshots | snapshot service | versioned feature tables and manifests |
| Forecast batches | forecast service | pinned snapshot plus pinned bundle |
| Desired targets | portfolio constructor | forecast, risk-model, and portfolio snapshots |
| Limits and global trading state | risk control plane | versioned configuration history |
| Risk decisions and authorization consumption | risk service | decision log and consumption journal |
| Client-order state | OMS | order event log, then venue reconciliation |
| Venue order and fill evidence | broker adapter as recorder | venue queries, reports, and private streams |
| Cash, positions, and realized P&L | position ledger/reconciler | booked fills plus account snapshots |
| Deployment state | rollout controller | declarative state and rollout history |

The venue is authoritative about whether an external order existed or filled. The reconciler is authoritative about the firm's canonical internal projection of that evidence. Other services may cache projections, but every cached value carries its owner sequence. A stale sequence forces retry or fail-closed behavior; it never wins through last-write-wins merging.

Service identities should make prohibited paths impossible: the forecaster cannot publish targets, the planner cannot reach a broker network, the execution service cannot write limits, and the semantic service cannot mint risk approval. Replica failover also needs writer fencing so a partitioned former leader cannot continue to submit. Current engine and venue sources demonstrate local deterministic ordering, persistence, reconciliation, and session failover mechanics; they do not establish atomic fencing across separately deployed replicas. Fencing is an integration requirement, not a capability to attribute to those projects.

### Replay reproduces R only until the external effect

Once state ownership prevents competing writers, `R` is replayable through its recorded internal path, while its venue branch is reconstructed from venue evidence. Internal transitions compare-and-swap against the preceding artifact hash. Duplicate delivery of `ForecastReady` returns the existing target when the input, code, and configuration hashes match. A different hash starts a new run. Randomness required by an execution or allocation algorithm is recorded as an input: seed, sampled result, and implementation version.

For local durable effects, transactional outbox/inbox records are a reasonable integration pattern: commit state and the event to be published together, then make consumers idempotent. Transactional exactly-once processing reaches effects inside its own boundary and excludes arbitrary external RPC side effects.[12] Across a broker boundary, the practical contract is at-least-once messaging, scope-aware stable identity, explicit pending states, deduplication, and reconciliation.

General agent runtimes reach the same boundary: checkpointed work can resume by executing pre-interrupt side effects again, so those effects must be idempotent.[18] Released agent tooling can help draft a candidate manifest, investigate an incident, or orchestrate research; uncertain broker calls still require stable identity and reconciliation.

For `R`, that replay boundary leaves the child unresolved and hands the next stage retained authorization plus an external fact the internal log cannot settle.

## Run R stops at the narrowest boundary that still preserves truth

`R` now has an `UNKNOWN` child, retained authorization, and incomplete venue truth. It cannot advance by retrying or by assuming the target remains safe. Not every failure warrants a global halt; the response depends on two questions: is external truth known, and can the next action increase exposure?

| Failure | Immediate behavior | Recovery condition |
|---|---|---|
| Document feed or semantic extractor unavailable | emit `FeatureUnavailable`; use only the bundle's tested null policy | fresh feature or evaluated baseline-only path |
| Invalid feature, bad entity mapping, or expiry | quarantine the observation | corrected source mapping or later run |
| Stale market/reference data or clock skew | fail the affected snapshot barrier | point-in-time inputs become current and consistent |
| Forecast model load or inference failure | publish no forecast batch | pinned artifact loads and deterministic health check passes |
| Optimizer infeasible or non-convergent | publish no target set | explicit constraint or input correction; never auto-relax hard limits |
| Risk unavailable or its snapshots stale | reject new or increasing exposure | authoritative position, price, limits, and service health restored |
| Authorization expires in a queue | refuse release | fresh risk decision against current state |
| Broker submission has ambiguous outcome | mark `UNKNOWN`; block unsafe related increases | original identity resolved and reconciled |
| Private stream gap or disconnect | stop assuming order freshness | sequence recovery or venue query reconciles state |
| Partial-fill/cancel race | apply venue events to the accepted order chain | remaining quantity and authorization recomputed |
| Ledger/venue mismatch | preserve evidence; move to `REDUCING` or `HALTED` | discrepancy explained and canonical projection rebuilt |
| Execution split brain | fence the stale writer | one writer restores OMS state and reconciles before release |

The global control state should be deterministic. `ACTIVE -> REDUCING`, `ACTIVE -> HALTED`, and `REDUCING -> HALTED` are legal; returning to `ACTIVE` requires the durable resume predicate in the transition contract. `HALTED` blocks submit and modify, not cancellation. `REDUCING` accepts only orders whose independent risk calculation proves they cannot increase the controlled exposure. A panic flatten is still an execution program; it needs current positions, liquidity, price protection, venue state, and fresh reduce-only authorization.

The risk gate must also be comprehensive, not merely present. The SEC's Knight Capital order records how a deployment inconsistency, missing duplicate-order and aggregate-capital controls, and inadequate review allowed the system to send more than four million orders and incur a loss exceeding $460 million.[13] Effective risk controls must assess component failures, provide safety nets, and be reviewed for effectiveness before malfunctioning systems can amplify erroneous orders.[14] These incidents are not evidence for one specific microservice design. They are evidence that limits need current aggregate state, calibrated thresholds, and coverage over every order path.

## Run R's boundary monitors decide when to halt

The failure policies become operational when monitors map each boundary predicate to an owner and a trading-state transition. Once `R` is live, its identifiers let surveillance distinguish a stale feature, a risk denial, an aged `UNKNOWN`, and a reconciliation mismatch instead of collapsing them into P&L. One P&L chart detects problems late and cannot identify where the chain broke. Monitoring should join technical and economic measurements using the same identifiers carried by production objects.

**Observation and snapshot health.** Track source lag, event-time versus observed-time delay, missing, duplicate and correction rates, parse failures, entity coverage, schema rejection, feature drift, null rate, expiry, extractor disagreement, and data-readiness deadline misses. Test a fixed golden-document set whenever the extractor changes. Keep sensitive source text out of broad application traces.

**Forecast health.** Track inference failures and latency, forecast coverage, cross-sectional distribution, uncertainty, exposure-weighted drift, and hybrid-versus-conventional deltas. Evaluate rank, calibration, residual, and hit-rate statistics only when the forecast horizon matures. A dual-run baseline asks whether the semantic path continues to add value without giving that counterfactual its own capital authority.

**Portfolio and risk health.** Track optimizer status and tolerances, predicted risk, factor and sector exposures, gross and net, concentration, turnover, liquidity, borrow, target churn, and cost-adjusted expected edge. Count rejects and clips by rule, stale-snapshot denials, limit headroom, authorization expiry, and trading-state transitions. Independently recompute hard limits from reconciled positions so an inline-gate defect is not invisible to itself.

**Execution and reconciliation health.** Separate decision-to-intent, risk, wire, acknowledgement, and fill latency. Track working and unknown-order age, rejections, cancel rejects, fills, participation, spread capture, implementation shortfall, modeled versus realized impact, reconnects, sequence gaps, duplicate suppression, and reconciliation discrepancies.

**End-to-end economics.** Attribute realized return to selection, sizing, timing, fees, spread and impact, borrow, and residual. Carry `decision_run_id`, bundle, feature snapshot, forecast batch, target set, intent, risk decision, client order, venue order, and execution IDs into every metric. That join makes “why did we own this position?” answerable from structured lineage rather than a search across log text.

Every important signal needs an action owner. A freshness breach blocks affected forecasts; a reconciliation mismatch blocks increases; a hard risk breach moves the system to `REDUCING`; an aged unknown order pages execution operations; sustained calibration or cost deterioration after its minimum sample reverts the relevant component. Exact thresholds are strategy- and venue-specific operating parameters, not constants supplied by the cited literature or repositories.

For the worked branch, suppose the `UNKNOWN` age and a private-stream sequence gap cross their predeclared hard operating bounds before reconciliation completes. The execution monitor owns detection, not trading authority: it emits a halt request carrying `decision_run_id`, client identity, last trusted venue sequence, and authorization sequence. The risk control plane owns the trading-state change and moves the system to `HALTED`; the OMS blocks submit and modify, keeps cancellation available, and the risk service revokes only uncommitted authorization. Committed capacity for the unresolved child remains retained. The particular bounds are local operating parameters that require target-system calibration, not universal constants supplied by these sources.

## A halted Run R moves forward from venue truth

With `R` now `HALTED` and the venue sequence incomplete, recovery has to distinguish three operations commonly called rollback.

**Decision rollback** stops new runs, moves an alias to a previously approved immutable bundle, and begins new runs with that version. It does not rewrite forecasts, targets, or authorizations already emitted.

**Execution rollback** fences the old writer, leaves the OMS and reconciler running, and inventories orders in `SUBMITTING`, `UNKNOWN`, working, partially filled, and cancel-pending states. A deterministic policy decides whether each parent should remain, cancel, or complete under its original authorization and the current trading state. Only after venue reconciliation can another execution build acquire writer authority.

**Risk incident response** moves the global state to `REDUCING` or `HALTED`, revokes unconsumed authorizations, and blocks new exposure. Already executed fills remain facts. If a previous model now desires different holdings, the transition happens through new reduce-only or ordinary intents, current costs and liquidity, fresh risk approval, and new venue events.

For `R`, recovery leaves the bundle, forecast, and pre-submit target untouched as historical artifacts. The reconciler preserves the already booked partial fill, queries the original identity, retrieves the missing venue evidence, and establishes the current working leaves. Those leaves remain a possible effect until an acknowledged cancel, fill, rejection, or venue expiry resolves them. If the OMS sends a cancel during `HALTED`, the risk service retains the committed quantity until that acknowledgement; only then does it release the unfilled remainder and close the old authorization sequence.

At that point there are two forward paths. If the original target is still within its validity window and the bundle has not been revoked, the OMS presents the reconciled fill, resolved working quantity, and remaining intent to the risk service. Risk evaluates the new portfolio sequence and either mints a successor authorization for the remainder or refuses it. If the target has expired or the decision artifact was rolled back, `R` closes after reconciliation and a new run starts from the new position. Neither path reopens the original authorization or erases the fill.

This is why software rollback cannot move market state backward. Paper accounts create no exchange or clearing effect, while the Knight incident left real long and short positions after erroneous order flow was stopped.[13, 17] A kill function cancels unexecuted orders; it does not erase fills.[15] Recovery therefore moves forward from current venue truth through reconciliation and, when needed, compensating orders.

Restoring an old container is not the completion criterion. Recovery is complete when there is one fenced order writer, pinned approved artifacts, no unexplained unknown orders, venue and internal state agree, current limits hold, and a dry-run risk check passes before returning to `ACTIVE`.

## The completed run shows where released systems stop

This implementation inventory is subordinate to `R`: it asks which documented seams can supply a stage of the run without inheriting authority over the next stage. The cited released systems supply components rather than the entire independently enforced composition. The practical path is to reuse component seams without importing authority assumptions they do not provide.

| Stage of `R` | Released system | Reusable seam | Boundary to preserve |
|---|---|---|---|
| Snapshot | Feast | point-in-time feature retrieval, offline/online stores, serving, registry, monitoring | no portfolio, risk, OMS, or venue authority |
| Bundle and lineage | MLflow | artifact tracking, evaluation, registry, lineage, access, deployment | no trading-state or fill truth |
| Forecast and target research | Qlib | quantitative research, modeling, signals, experiment records, portfolio analysis | research and analysis rather than broker-safe OMS control |
| Portfolio target | cvxportfolio 1.5.0 [4] | portfolio policies, costs, constraints, risk models, market simulation | optimization and backtesting, not live order authority |
| Target through execution | LEAN | typed alpha, target, risk-adjustment, execution flow and broker plugins | shared `QCAlgorithm` runtime permits hybrid bypasses |
| Order lifecycle and reconciliation | NautilusTrader | documented live execution, order-state, portfolio/accounting, data, adapter, and reconciliation seams | project-level workflow summary; the 2.0.0rc3 release is established separately, while credentials, firm limits, cross-service authorization, and fencing remain integration work |
| Risk analytics input | ORE 16 [24] | pricing, market-risk, and XVA analytics | analytics is not pre-trade authorization |

The cited interfaces and selected versions establish shipped mechanics, while production assurance requires independent evidence of safety, control effectiveness, execution quality, profitability, and capacity. The table summarizes project-level workflow seams. Separately, NautilusTrader's August 2026 release page identifies 2.0.0rc3; its release-candidate label carries no production assurance.[19]

The same discipline applies to financial agents. Released systems support automating factor and model research with historical evaluation while leaving live order authority elsewhere.[20] A broker-integrated financial agent is an important counterexample to the claim that released systems stop before brokers: it translates target weights through execution and describes monitoring, persistence, and reconciliation-oriented safeguards. Its disclosed deployment evaluation is Alpaca paper trading, where transactions use virtual money rather than real securities.[21, 22]

Agents can productively sit above or beside the capital-changing state machine: proposing candidate bundles, running research experiments, drafting deployment manifests, summarizing incidents, or suggesting operator actions that require approval. The released evidence does not establish them as the independently enforced owner of live pre-trade risk, canonical OMS state, broker credentials, reconciliation, and recovery. That is a bounded statement about current demonstrated controls, not a claim that no future agent system can implement them.

## Limitations

This is a composite reference architecture, not a description of one turnkey open-source stack. Typed stages, point-in-time features, portfolio optimization, pre-trade controls, order-state protocols, live engines, and reconciliation are individually visible in current systems. Separately credentialed services, a consumable cross-service authorization envelope, a shared lineage schema, dual live counterfactuals, and atomic stale-writer fencing remain engineered integration in the cited evidence.

The operational ladder is likewise a prescriptive decomposition of claims, not a measured universal law. Regulation, broker documentation, and incidents support separated testing, simulation limits, live blast-radius controls, monitor-to-action coupling, and forward recovery from executed effects. They do not validate the exact stage order, numerical canary allocation, promotion thresholds, or submit-reopening rule for this hybrid signal. Those require target-specific failure injection, paper and canary observations, and predeclared acceptance criteria.

Finally, repository activity and documentation demonstrate shipped mechanics, not trading edge or production safety. The article assumes incremental semantic edge and a validated fusion method; it does not re-establish either. The cited systems also leave stronger integrated implementations possible. The open question is whether, and under what tested conditions, a released integrated system can enforce the complete authority-separated chain.

## References

[1] Feast official repository — https://github.com/feast-dev/feast
[2] MLflow official repository — https://github.com/mlflow/mlflow
[3] QuantConnect Algorithm Framework overview and Hybrid Algorithms — https://www.quantconnect.com/docs/v2/writing-algorithms/algorithm-framework/overview
[4] cvxportfolio version 1.5.0 documentation — https://www.cvxportfolio.com
[5] Electronic Code of Federal Regulations, 17 CFR § 240.15c3-5 — https://www.law.cornell.edu/cfr/text/17/240.15c3-5
[6] U.S. Securities and Exchange Commission, Trading and Markets Frequently Asked Questions on Rule 15c3-5 — https://www.sec.gov/rules-regulations/staff-guidance/trading-markets-frequently-asked-questions/divisionsmarketregfaq-0
[7] NautilusTrader Execution and Live Trading documentation — https://nautilustrader.io/docs/latest/concepts/execution
[8] CME Group, iLink CME Globex Identifiers — https://cmegroupclientsite.atlassian.net/wiki/spaces/EPICSANDBOX/pages/457096319/iLink+-+CME+Globex+Identifiers
[9] Binance Spot REST Trade API — https://developers.binance.com/en/docs/catalog/core-trading-spot-trading/api/rest-api/trade
[10] FIX 4.2 Dictionary, Execution Report — https://www.b2bits.com/fixopaedia/fixdic42/message_Execution_Report_8.html
[11] Cboe Titanium U.S. Equities FIX cancel/replace specification — https://www.cboe.com/document/tech-spec/content/technical-specifications/cboe-titanium-u.s.-equities-fix-specification/fix-messages/order-protocol---member-to-cboe/order-cancelreplace-request-message-fields
[12] Confluent, Exactly-once semantics in Apache Kafka — https://www.confluent.io/blog/exactly-once-semantics-are-possible-heres-how-apache-kafka-does-it
[13] U.S. Securities and Exchange Commission, SEC Charges Knight Capital With Violations of Market Access Rule — https://www.sec.gov/newsroom/press-releases/2013-222
[14] U.S. Securities and Exchange Commission, SEC News Digest, October 16, 2013 — https://www.sec.gov/news/digest/2013/dig101613.htm
[15] Financial Conduct Authority, Resilience of trading systems — https://handbook.fca.org.uk/technical-standards/s119c1039
[16] FINRA Regulatory Notice 15-09 — https://www.finra.org/rules-guidance/notices/15-09
[17] Interactive Brokers, About Paper Trading Accounts — https://www.ibkrguides.com/clientportal/aboutpapertradingaccounts.htm
[18] LangChain, LangGraph Interrupts documentation — https://docs.langchain.com/oss/python/langgraph/interrupts
[19] NautilusTrader official releases — https://github.com/nautechsystems/nautilus_trader/releases
[20] Microsoft Research, R&D-Agent-Quant — https://www.microsoft.com/en-us/research/publication/rd-agent-quant-a-multi-agent-framework-for-data-centric-factors-and-model-joint-optimization
[21] FinRL-X paper and official repository — https://arxiv.org/html/2603.21330v1
[22] Alpaca paper-trading API description — https://alpaca.markets/learn/data-scientists-approach-algorithmic-trading-using-deep-reinforcement-learning
[23] Microsoft Qlib official repository — https://github.com/microsoft/qlib
[24] Open Source Risk official project site — https://opensourcerisk.org

---
Every [N] marker above is verifiable: fetch the citations JSON, match the marker id, and check the extraction (summary and key facts) plus placements against the source URL. Verification guide: https://lumisonde.com/for-agents/