OpenByteInc/QuantDinger

Parent epic #254 Deliverable Write an architecture RFC for a durable multi-leg execution state machine and its recovery behavior. The RFC should define: Parent intent and child leg states, identifiers, and invariants. Sequential and parallel submission policies. Timeout, cancel, retry, compensation, and operator-intervention behavior. Partial-fill and unknown broker-state reconciliation. Restart and duplicate-delivery recovery. Broker capability boundaries, including venue-native combination orders. Acceptance criteria A state diagram and transition table are included. First-leg failure, later-leg failure, partial fill, timeout, crash, and duplicate delivery are covered. Unmatched exposure can never be silently discarded. Idempotency and observability requirements are explicit. Deterministic paper-adapter test scenarios are proposed. The RFC is submitted as a focused draft pull request. How to claim Comment with a short outline and any prior work you plan to reuse. A maintain

Parent epic #253 Deliverable Write an architecture RFC for first-class pair and spread identity across Strategy API V2, persistence, backtests, and live execution. The RFC should define: Pair and generalized spread identifiers. Leg identity, side, signed hedge ratio, and quantity semantics. Signal, intent, order, fill, position, and result relationships. Pair-level entry, exit, stop, and exposure semantics. Restart-safe serialization and compatibility with existing multi-instrument strategies. Reconciliation rules between pair-level and leg-level economics. Acceptance criteria The proposal includes concrete API and persisted-record examples. Asymmetric quantities and early closure of one leg are covered. Existing instrument-level records remain the source of execution truth. Migration and backwards-compatibility behavior is explicit. Open questions and implementation slices are listed. The RFC is submitted as a focused draft pull request. How to claim Comment with a short out

Parent epic #251 Deliverable Write an architecture RFC for the point-in-time universe rule contract and snapshot model shared by research, backtests, and live strategy runs. The RFC should define: The versioned rule schema and composable AND/OR filters. Observation time, availability time, and effective membership time. Daily, weekly, monthly, and explicit N-day refresh semantics. Snapshot identity, persistence, provenance, and replay behavior. Missing data, provider limits, and exclusion-reason behavior. Migration and compatibility expectations for saved universes. Acceptance criteria The proposal includes concrete request and persisted-record examples. Look-ahead protections are expressed as testable invariants. Research, backtest, and live consumers use one contract. Failure and stale-data behavior is explicit. Open questions and implementation slices are listed. The RFC is submitted as a focused draft pull request. How to claim Comment with a short outline and any prior w

NoteThe auditable AI entry decision filter has been delivered in #263. This issue now tracks the remaining point-in-time external signal ingestion and research/backtest/live contract. Problem Users want deterministic strategies to consult news, sentiment, or model output before opening a position without making exits dependent on an unavailable network service or introducing look-ahead bias. Desired outcome Create a point-in-time external signal contract that strategies can use as an optional, auditable entry gate. Initial scope Ingest timestamped external factors outside the strategy sandbox. Persist source, model/provider version, observation time, availability time, score, and explanation metadata. Expose deterministic point-in-time reads to research, backtest, paper, and live strategies. Let users choose fail-open or fail-closed behavior for new entries. Keep risk exits and explicit close signals independent by default. Acceptance criteria An RFC defines timing, provenance, re

Problem Users evaluating pairs and spread strategies need to see one logical position and its underlying trades. Instrument-only tables cannot explain spread exposure, leg imbalance, or pair-level performance. Desired outcome Provide a pair-level read model and UI while retaining drill-down access to every order and fill. Initial scope Pair position summary with both legs, quantities, hedge ratio, and imbalance. Pair-level realized and unrealized PnL reconciled to leg totals. Spread and z-score history with entry and exit markers. Execution status for pending, partially filled, compensated, and complete pairs. Backtest and live reports using the same metric definitions. Acceptance criteria Metric definitions and reconciliation rules are documented. API payloads preserve stable identifiers and timestamps. UI designs include loading, empty, partial-fill, failure, and closed states. Accessibility and light/dark themes are covered. Tests verify that pair totals equal the sum of und