Versioned LLM signals, separated trading authority

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:

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:

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:

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:

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:

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.

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:

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

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:

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:

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.

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.

The same packet makes residual integration risk explicit:

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:

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:

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?

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.

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.