Inspiration
What it does
How we built it
Challenges we ran into
Accomplishments that we're proud of
What we learned
What's next for SHADOW C Operations Monitor
Inspiration
Stateful automation rarely fails as one clean error. A close may be confirmed while the next entry times out, or a restart may encounter evidence from work that already completed. In those cases, local intent can differ from confirmed external state. Operators need a way to see what was requested, what was confirmed, what remains unresolved, and which state is safe to adopt.
What it does
SHADOW C Operations Monitor is a read-only incident replay dashboard for three deterministic scenarios:
- Normal LONG to FLAT.
- Failed Reversal Contained.
- Restart and Safe Retry.
The monitor loads strict bundled JSON evidence, normalizes the event lifecycle, evaluates ten safety invariants on the server, and presents the result as an operator-friendly timeline. It distinguishes observed quote identity (MTX00) from the simulated order target (FITM), preserves completed eight-minute-bar evidence, and keeps TV_SIGNAL separate from F_FILTER evidence.
How we built it
The Build Week implementation is isolated in the operations_monitor package. It contains strict fixture validation, normalized evidence models, server-side invariant evaluation, a GET-only loopback server, a static dashboard, an isolated Windows launcher, three synthetic PAPER scenarios, and focused automated tests.
The monitor is deliberately independent of the existing trading runtime and proprietary broker DLL path. It requires no broker account, credentials, DLL, or external network connection and has no code path that can submit an order.
How Codex and GPT-5.6 were used
Codex with GPT-5.6 accelerated requirements decomposition, safety-boundary design, test-driven implementation, partial-failure modeling, UI iteration, code review, and verification. Key human-directed decisions included keeping the monitor read-only, separating Build Week code from the existing trading runtime, deriving unresolved work from the event lifecycle instead of a self-declared counter, and using anonymous deterministic PAPER evidence rather than private or live data.
Challenges we ran into
The hardest problem was representing partial success honestly. A reversal is not one atomic action: the close can succeed while the new entry fails. The monitor therefore preserves the confirmed close, leaves the failed entry uncommitted, restores the last confirmed checkpoint, and exposes the incident rather than hiding it behind a final position value.
Restart recovery introduced a second challenge. The replay must recognize completed work, block duplicates, and retry only the bounded unconfirmed action. This required explicit event lifecycles and invariants covering committed, staged, pending, duplicated, and unresolved actions.
Accomplishments that we're proud of
- Three deterministic incident scenarios.
- Ten server-computed safety invariants.
- Twenty-eight focused monitor tests.
- A complete read-only dashboard experience.
- No broker connection, order route, credentials, private account data, or live runtime dependency.
- A Windows launcher and broker-independent setup for judges.
What we learned
Operational trust comes from evidence and explicit state transitions, not from a green final counter. Modeling confirmation, failure, rollback, and restart as separate evidence makes subtle automation failures understandable and testable.
What's next
The next step is to generalize the evidence schema for other stateful automation systems and add exportable incident reports while preserving the same read-only boundary.
Built With
- openai
Log in or sign up for Devpost to join the conversation.