Operator UX

0.A note to the team #

The current signal tab does the hardest part of this problem: it makes invisible bot behaviour visible. Plotting bot signals on the same canvas as price action is the right instinct. The strategy filtering, date filtering, and status workflow are also a strong base — the underlying data model is clearly there, which is the part that actually takes time.

What follows is not a redesign. It is a sketch of where the existing foundation should evolve next, with a single goal: move from viewer of bot signals to trading-ops console that supervises bots. Almost every suggestion below uses data we already have. The work is mostly assembly and UX, not new data infrastructure.

1.Why this model representation #

Six reasons the proposed layout matches what Polytraders actually does.

2.Jobs to be done #

Two columns. One is what the current screen optimises for. The other is what we need.

3.The proposed layout, annotated #

Six zones, in order of importance. Each one uses data we already have.

4.Nine changes, in order of impact #

In order. Earlier items unlock later ones.

5.How to build it #

Three phases. Almost everything reuses data we already have.

5.1 Phase 1 — Two weeks, zero new data #

5.2 Phase 2 — Three to four weeks, the differentiating features #

5.3 Phase 3 — Polish, the things that compound #

6.Data model additions #

Two new tables. The first is required for Phase 1's ribbon, the second is the unlock for Phase 2's decision drawer.

create table match_events (
  event_id      bigserial primary key,
  market_id     text not null,
  ts            timestamptz not null,
  event_type    text not null,   -- pistol_won, bomb_plant, timeout, mvp, goal, state_called ...
  label         text not null,   -- human label for the ribbon tooltip
  impact_side   text,            -- YES | NO | null
  raw           jsonb            -- full provider payload, kept for replay
);
create index on match_events (market_id, ts);

create table signal_decisions (
  signal_id            uuid primary key,
  strategy_id          text not null,
  market_id            text not null,
  fired_at             timestamptz not null,
  model_prob           numeric(6,4) not null,
  market_implied_prob  numeric(6,4) not null,
  edge_cents           numeric(6,2) not null,
  kelly_fraction       numeric(6,4),
  top_features         jsonb not null,    -- [{name, value, contribution}, ...]
  risk_checks          jsonb not null,    -- [{name, passed, threshold, actual}, ...]
  suggested_size       integer,
  actual_size          integer,
  counterfactual_pnl   numeric(12,4),     -- backfilled at resolution
  order_id             uuid references orders(order_id)
);
create index on signal_decisions (market_id, fired_at desc);
create index on signal_decisions (strategy_id, fired_at desc);

7.Engineering practicalities #

7.1 State management #

The dashboard trap is re-rendering the entire React tree on every tick. Use a fine-grained reactive store (Zustand, Valtio, or signals) keyed by market_id, so the header strip re-renders independently of the leaderboard, which re-renders independently of the chart.

7.2 The chart is not React #

Use a single <canvas> with imperative draws. React's reconciliation cost is too high for sub-second tick updates with hundreds of marks. The mockup deliberately uses canvas — keep that pattern.

7.3 Websocket discipline #

One socket per page, multiplexed by market_id and strategy_id on the server side, dispatched to subscribers on the client. Never one socket per widget.

7.4 Materialised views for leaderboard stats #

Do not compute Sharpe in the request path. Pre-aggregate every minute, refresh on demand if you want immediacy.

7.5 Honest readiness states #

The five-state taxonomy still applies: docs-complete → demo-wired → shadow-ready → runtime-live → production-live. A dashboard surface that displays decision counterfactuals is shadow-ready, not production-live, until backfill, replay, and the kill switch have all run hot for two weeks without a regression. See Start here.

8.If you only have one sprint #

Build the header strip + leaderboard + fill glyphs + kill switch — items 1–4 of Phase 1. That alone takes the screen from viewer to console and reuses 100% of the data we already have. Everything else is upside.