UC Index

Note on UC_4.3 relationship

UC_4.3 ("12 Performance Metrics", Ref: UC_4.3) documents 5 dedicated Performance-screen widgets (Sharpe Ratio, Sortino Ratio, Avg. Win vs. Loss, Holding Time Analysis, Trade Efficiency Matrix). The Pulse (BR_4.2.2.1), Equity Curve (BR_4.2.3.x), Profit factor (BR_4.2.4.1), and Win Rate (UC_4.2.5 §7 Screen Description row 3) each carry their own formula inline in this UC — there is no cross-UC canonical-formula dependency between this UC and UC_4.3.

Overview — Performance Widgets

UC_4.2.1 — Position Monitor Table

1. Overview

Dashboard.png Overview screen — Position Monitor Table (top-right panel), populated state. Dashboard - Day 0.png Overview screen — Position Monitor Table, empty state (no open positions).

Motion reference: UC_4.2.1 motion clips

2. Trigger

The Overview screen (Ref: UC_4.1.1) has rendered.

3. Pre-conditions

• User is on the Overview screen (Ref: UC_4.1.1 §1 Overview).

4. Post-conditions

• The table displays the trader's current open positions and updates live as fills, partial fills, or closes occur.

5. Basic Flow

1. On Overview screen load — including a page reload/F5 — frontend subscribes to the POSITION_METRICS WebSocket event, and the table renders immediately from the Backend's latest held snapshot of the user's open positions rather than appearing empty while waiting for the next event (Ref: BR_4.2.1.3).
2. As fills, partial fills, or closes occur, Backend sends updated data for only the affected position(s), keyed by position_id (the position identifier), throttled to 1 evaluation/second (Source: RFQ_ Stack Trading Prop Tech V7.pdf §3.2 for the payload fields; Ref: BR_4.2.1.3 for the snapshot/delta mechanism and position_id keying, which supersedes a full-array re-send on every event).
3. Frontend uses position_id to identify the corresponding row and maps/updates only the changed data into that row; each row updates independently — the table does NOT wait for a synchronized batch update across all positions (Ref: BR_4.2.1.1).
4. If a position closes entirely, Backend flags the closure on that position's update and Frontend removes the row from the table (Ref: BR_4.2.1.3).
5. If the user has no open positions, the table shows the empty state instead of rows (Ref: BR_4.2.1.2).

6. Exceptional Flow

• WebSocket connection drops, market is closed, or page reload (F5): the table continues displaying the latest successfully captured snapshot rather than becoming empty — it does not reset to empty or zero simply because no new real-time events are arriving. This snapshot/reconnection resiliency behavior is shared across all real-time Dashboard widgets fed by WebSocket events (Ref: CR-14).

7. Business Rules

BR_4.2.1.1: Est. Swap — Forex-Only Visibility Window, Asynchronous Streaming

The Est. Swap column is visible only for Forex positions — it is hidden entirely (not shown as $0, the column itself does not render) for Futures positions. For Forex positions, the column follows this visibility window:

• Animates into view exactly 60 minutes before the Forex daily rollover.
• Disappears 1 minute after the rollover completes.
• If the column is visible but the backend has not yet pushed a swap estimate for a given position, the cell shows a neutral placeholder ($0) until the first est_swap value arrives.
• Whenever the backend receives an updated swap estimate from the execution gateway, it pushes the new est_swap value via the standard POSITION_METRICS WebSocket channel (subject to the same 1 evaluation/second throttle) — the frontend table updates each row independently as data arrives, it does NOT wait for a synchronized batch calculation across all active positions.

Rollover time — DST-aware (America/New_York timezone), not a fixed UTC offset: the Forex daily rollover is always 5:00 PM Eastern Time, which is a wall-clock anchor, not a fixed UTC time. Because the US observes Daylight Saving Time, the equivalent UTC time shifts twice a year:

• EDT (roughly mid-March → early November): 5:00 PM ET = 21:00 UTC.
• EST (roughly early November → mid-March): 5:00 PM ET = 22:00 UTC.

The timekeeper must resolve the rollover trigger (and therefore the column's 60-minutes-before / 1-minute-after visibility window) from the US Eastern Time DST calendar, not from a hardcoded UTC offset — otherwise the 60-minute pre-rollover animation and the column's disappearance would fire at the wrong wall-clock time on the two DST transition days each year, breaking the UI timer.

BR_4.2.1.2: Empty State

When the trader has no open positions, the table displays a centered empty-state indicator (icon + text) reading "No open positions" instead of any rows. (Source: BA confirmation, 2026-08-08, QnA_init_docs.md A-04; visual per wireframe Dashboard - Day 0.png.)

BR_4.2.1.3: Snapshot Persistence, Delta Update by Position Identifier, and Row Removal on Close

Backend snapshot persistence (reload/F5): Backend maintains and holds the latest POSITION_METRICS snapshot (the current set of open positions and their latest field values) for the user, independent of any single WebSocket connection. On Overview screen load — including a page reload/F5 — the table is restored from this held snapshot immediately, so it does not appear empty while waiting for the next WebSocket event. This is the Position-Monitor-specific application of the shared snapshot rule (Ref: CR-14).

Delta update by position identifier (position_id): after the initial snapshot render, each subsequent POSITION_METRICS WebSocket event carries only the updated data for the position(s) affected by that fill/partial-fill/close — not a full re-send of every open position. position_id is the position identifier: Frontend uses it to find the matching row already on screen and maps/updates only the changed fields (net_pos, unrealized_pnl, realized_pnl, total_pnl, est_swap) into that row, leaving every other row untouched. symbol remains a display-only field on the row (the traded instrument) and is not used to key the update, since a trader can hold more than one open position on the same symbol (e.g. positions opened at different times or on different strategies) — position_id is what disambiguates them. This confirms and supersedes any full-array-per-event or symbol-keyed reading of §3.2 — the existing snapshot render plus this row-level delta, keyed by position_id, is the update mechanism (Source: User instruction (BA session), 2026-08-31).

Row removal on full close: when a position closes out entirely (net_pos reaches 0 for that position_id), the affected-position update carries a closed flag for that position_id. Frontend removes the corresponding row from the table on that event, rather than leaving a stale zero-quantity row on screen. If this was the trader's last open position, the table then shows the empty state (Ref: BR_4.2.1.2).

Market closed / connection drop: while the market is closed or the WebSocket connection is temporarily unavailable, the table continues showing the latest snapshot/delta-updated state rather than resetting to empty (Ref: CR-14).

8. Screen Description

UC_4.2.2 — The Pulse

1. Overview

Dashboard.png Overview screen — "The Pulse" panel, populated state (score + trend chart). Dashboard - Day 0.png Overview screen — "The Pulse" panel, session-start state (score = 100, empty chart).

Motion reference: UC_4.2.2 motion clips

2. Trigger

The Overview screen (Ref: UC_4.1.1) has rendered.

3. Pre-conditions

• User is on the Overview screen (Ref: UC_4.1.1 §1 Overview).

4. Post-conditions

• The widget displays the current Pulse score for the active session, updating in real time as scoring events occur.

5. Basic Flow

1. At the start of every trading session (Exchange Reset: 18:00 EST for Futures, 17:00 EST for Forex), the Pulse score resets to 100 (Source: RFQ_ Stack Trading Prop Tech V7.pdf §Risk Metrics Logic Definitions "Pulse Score").
2. As the trader places/modifies orders during the session, the backend evaluates each action against the deduction/reward rules and recalculates current_pulse_score (Ref: BR_4.2.2.1).
3. The backend pushes the updated current_pulse_score in real time via WebSocket (Ref: BR_4.2.2.2).
4. The widget renders the current score, updating live as new values arrive.

6. Exceptional Flow

• WebSocket connection drops, market is closed, or page reload (F5): the widget continues displaying the latest successfully captured score/snapshot rather than becoming empty (Ref: CR-14).

7. Business Rules

BR_4.2.2.1: Pulse Score — Reset, Deductions, Rewards

The Pulse Score is an integer, 0–100, reset to 100 at the start of every trading session (Exchange Reset: 18:00 EST for Futures, 17:00 EST for Forex).

Deductions:

• −25 — Averaging Down: submitting an order in the same direction on the same symbol while the current Unrealized P&L on that symbol is negative.
• −20 — Increasing Risk: modifying an existing Hard Stop order to move the price further away from the current market price.
• −15 — Erratic Sizing: submitting an order where the quantity exceeds 2× the average quantity of the last 10 fully filled or closed orders (partial fills ignored).

Rewards:

• +5 — Pyramiding: adding to a winning position in the same direction on the same symbol, while Unrealized P&L on that symbol is positive.
• +10 — Reducing Risk: modifying a Hard Stop to move it closer to the current market price, or locking in profit.

The score is clamped to the 0–100 range — deductions cannot push it below 0, rewards cannot push it above 100. (Source: RFQ_ Stack Trading Prop Tech V7.pdf §Risk Metrics Logic Definitions "Pulse Score".)

BR_4.2.2.2: Real-Time Update via current_pulse_score

The Pulse widget updates in real time over WebSocket. The payload includes a current_pulse_score (integer) field (Source: BA confirmation, 2026-08-08, QnA_init_docs.md A-06 — supersedes the original architecture finding that no WebSocket event in the Customer supplies payload table carried a Pulse-related field).

BR_4.2.2.3: Widget Display — Score and Trend Chart

• The panel title shows the current score inline, e.g. "The Pulse (42)".
• Below the title, a trend-line/area chart plots the score's history within the session. At session start (no history yet) the chart area renders empty.
• Chart data source: Get Pulse History endpoint (GET, user_id + limit, returns Array[[timestamp_utc, integer_score]]) (Source: RFQ_ Stack Trading Prop Tech V7.pdf §Risk Metrics Endpoints), refreshed live as current_pulse_score updates arrive (Ref: BR_4.2.2.2).

8. Screen Description

UC_4.2.3 — Equity Curve

1. Overview

Dashboard.png Overview screen — "Equity Curve" panel, populated state. Dashboard - Day 0.png Overview screen — "Equity Curve" panel, empty state (mockup shows a flat line at $0; [CR] per CR-20260831-001 this is now a flat line at the account's Initial Starting Capital baseline, not $0 — Ref: BR_4.2.3.1).

Motion reference: UC_4.2.3 motion clips

2. Trigger

The Overview screen (Ref: UC_4.1.1) has rendered, or the user changes the 1D/1W/1M filter.

3. Pre-conditions

• User is on the Overview screen (Ref: UC_4.1.1 §1 Overview).

4. Post-conditions

• The chart displays the account balance time series for the selected timeframe.

5. Basic Flow

1. On Overview screen load, frontend calls GET /equity-curve?timeframe=1D (default filter).
2. [CR] Backend returns Array[[timestamp_utc, float_value]] where float_value is the absolute Net Equity notional value at that timestamp (e.g. 25500.00) — not a relative PnL delta (e.g. 500.00). Computed per the formula and baseline in BR_4.2.3.1 (Source: CR-20260831-001).
3. [CR] Frontend renders the time series as a chart, plotting the exact array of absolute values returned by the backend — no client-side math (no re-basing, no delta calculation, no re-scaling of the underlying values) is performed on the data before charting (Ref: BR_4.2.3.2; Source: CR-20260831-001).
4. User clicks the 1D/1W/1M filter → frontend re-calls GET /equity-curve?timeframe= with the new value (Ref: BR_4.2.3.1 for re-fetch behavior, BR_4.2.3.4 for the snapshot cadence/aggregation applied per timeframe).

6. Exceptional Flow

• No balance snapshot yet (new account, Day 0): chart displays a flat line at the baseline — the account's Initial Starting Capital (Ref: §8 Screen Description row 2, BR_4.2.3.1).
• WebSocket/API connection drops, market is closed, or page reload (F5): the chart continues displaying the latest successfully loaded series rather than becoming empty (Ref: CR-14).
• [CR] Page reload (F5) after a snapshot has been captured but not yet pushed over WebSocket: if the backend has already captured a new 30-minute intraday snapshot (BR_4.2.3.4) but the corresponding WebSocket push to the chart has not fired yet, and the user reloads the page in that window, the reload must render the latest already-captured snapshot immediately (the page-load GET /equity-curve call always reads the backend's current persisted state, so it is not blocked on the socket push) — the chart must never show the older, pre-snapshot data merely because the socket event hasn't arrived (Ref: BR_4.2.3.5; Source: CR-20260831-001).

7. Business Rules

BR_4.2.3.1: 1D/1W/1M Filter — Re-fetch on Change; Net Equity Formula & Baseline

[CR] The chart calls GET /equity-curve?timeframe= on page load and every time the user changes the 1D/1W/1M filter — it does not pre-fetch or cache all 3 timeframes at once (Source: BA confirmation, 2026-08-08, QnA_init_docs.md A-09; re-fetch trigger unchanged by CR-20260831-001).

Baseline data source (Table A/B lookup): the chart's Initial Starting Capital baseline is not stored per-account — it is looked up live from the Zapier configuration matrix each time it's needed: the backend takes the account's asset class (Forex vs Futures) and its current level, finds the matching row in Table A (Forex Matrix) or Table B (Futures Matrix), and reads that row's Max_Forex_Notional / Max_Futures_Notional field as the baseline value. This is the same lookup used to derive the formula's Initial Starting Capital term below (Source: CR-20260831-001; BA confirmation 2026-09-03).

Formula (Source: CR-20260831-001 — see References/CR/2026-08-31_equity-curve-net-equity-formula/CR_summary.md):

Net Equity = Initial Starting Capital + (Realized PnL + Unrealized PnL) = Account Balance + Unrealized PnL

Note: all terms on the right-hand side — Account Balance (which already embeds Initial Starting Capital + Realized PnL), and Unrealized PnL — are read from the trader's own trading account (the live account/position data feed), not from a separate ledger or estimate. Only the Initial Starting Capital baseline itself comes from the Table A/B lookup above; everything else is the account's actual current balance and open-position PnL (Source: BA confirmation, 2026-09-03).

• Initial Starting Capital (the baseline): looked up once per account from the Zapier configuration table matching the account's asset class:

  • Forex accounts: Max_Forex_Notional (Table A). This column is already documented (Source: Zapier Integration V7.pdf, Appendix A).
  • Futures accounts: Max_Futures_Notional (Table B). ✅ Confirmed by client, 2026-08-31 (CR-20260831-001): this is a new column, distinct from the existing Futures_Capital column — the two represent different things.

• Each [timestamp_utc, float_value] point in the returned array is one snapshot's Net Equity computed by this formula, at the cadence defined in BR_4.2.3.4. No additional transformation, smoothing, or interpolation is applied on top of this formula.

Previously (superseded by CR-20260831-001): the series was built directly from the account's Daily Balance snapshots only — float_value was the raw account balance, which excludes Unrealized PnL entirely. This under-represented a trader's true net worth while holding open positions. See Changelog.

BR_4.2.3.2: Frontend Renders Absolute Values As-Is — No Client-Side Math

[CR] The frontend plots the exact [timestamp_utc, float_value] array returned by GET /equity-curve with no local/client-side computation on the float_value series — no subtracting a baseline to derive a delta, no adding a locally-held Unrealized PnL figure, no re-scaling, no smoothing/interpolation. Every value already fully embeds the BR_4.2.3.1 formula on the backend, so the chart is a pure renderer of whatever the backend sends. This guarantees a single source of truth for the Net Equity calculation — if the formula ever changes, only the backend needs updating, not the frontend chart logic. (Source: CR-20260831-001.)

BR_4.2.3.3: Y-Axis Dynamic Scaling & Target/Stop Overlay

The Y-axis does not start at $0 and is not a fixed range — it auto-scales dynamically to the trader's actual data:

• Scale bounds: the Y-axis min/max are computed from the actual high and low Net Equity values (float_value) among the data points in the currently selected window, not from $0 and not from the baseline alone (a profitable trader's whole chart may sit well above $0; a drawdown trader's chart may sit below the baseline without ever approaching $0).
• Padding for Target/Stop visibility: the backend also fetches the trader's Profit_Target and Market_Loss_When_Stopped for their current level via GET /current-level-detail (Ref: UC_4.8.1 BR_4.8.1.2), and derives the two static overlay levels:
  • Target level = Initial Starting Capital + Profit_Target.
  • Stop level = Initial Starting Capital − Market_Loss_When_Stopped.
  • The Y-axis top/bottom bounds must extend far enough beyond the min/max Net Equity data points that both the Target level and the Stop level remain visible within the chart frame at all times — i.e. axis_max ≥ max(high Net Equity, Target level) plus a visual padding margin, and axis_min ≤ min(low Net Equity, Stop level) minus a visual padding margin. If the trader's actual Net Equity range already exceeds the Target/Stop levels, the axis still auto-scales to the data (the Target/Stop lines simply sit inside the frame rather than at its edges).
• Overlay rendering: Target and Stop are drawn as static horizontal reference lines across the chart (distinct styling from the Net Equity line itself), not as additional data points in the series.

Axis & color semantics:

(Y-axis scaling/Target-Stop overlay is display/rendering behavior, not the CR itself — see BR_4.2.3.1 for the CR-tagged formula change. Target/Stop field names — Source: RFQ_ Stack Trading Prop Tech V7.pdf, per UC_4.8.1 BR_4.8.1.2.)

BR_4.2.3.4: Snapshot Cadence & 1W/1M Aggregation

1D timeframe — 30-minute intraday snapshots: a background cron captures a Net Equity snapshot every 30 minutes throughout the trading session, populating the array that powers the 1D chart. A single daily balance snapshot cannot render a 1-day time-series chart, so intraday snapshotting at this cadence is the implied technical mechanism required to satisfy the V7 spec's mandate that GET /equity-curve support a 1D timeframe (Source: CR-20260831-001 — "capturing a snapshot every 30 minutes is the correct technical approach to power the 1D chart... intraday snapshotting is an implied technical necessity"; cross-ref: RFQ_ Stack Trading Prop Tech V7.pdf §Risk Metrics Endpoints, Get Equity Curve 1D timeframe support).

• 1W timeframe — aggregated by day: given the underlying data is stored at 30-minute granularity, GET /equity-curve?timeframe=1W does not return all ~48 points/day — it returns one aggregated point per calendar day within the 7-day window. The aggregated point's float_value is the last (most recent, i.e. end-of-day) snapshot's Net Equity for that day — consistent with the existing "daily ticks" display rule in §8 row 2.
• 1M timeframe — aggregated by week: analogously, GET /equity-curve?timeframe=1M returns one aggregated point per calendar week within the window, using the last snapshot of that week.
• Current (in-progress) day/week stays live: the aggregation above applies to closed days/weeks only. The data point representing the current, still-in-progress day (for 1W) or current, still-in-progress week (for 1M) continues to update in place with every new 30-minute snapshot — it is not frozen at the last aggregation boundary — so the chart accurately reflects "today" at all times, matching the existing real-time-update behavior already defined in §8 row 2.

(Source: CR-20260831-001.)

BR_4.2.3.5: F5/Reload Reflects the Latest Captured Snapshot Immediately

This rule is a chart-specific application of the shared CR-14 snapshot-persistence pattern, made explicit for the 30-minute snapshot cadence in BR_4.2.3.4: if a new 30-minute snapshot has already been captured and persisted on the backend, but the corresponding WebSocket push to update the live chart has not fired yet, and the user reloads the page (F5) during that window, the page-load GET /equity-curve call reads directly from the backend's already-persisted data — so the reloaded chart reflects the latest captured snapshot immediately, never the older pre-snapshot state. (Ref: §6 Exceptional Flow; Source: CR-20260831-001.)

8. Screen Description

UC_4.2.4 — Profit factor

1. Overview

Dashboard.png Overview screen — "Profit Factor" panel, populated state. Dashboard - Day 0.png Overview screen — "Profit Factor" panel, no-trades state (Profit Factor (0)).

Motion reference: UC_4.2.4 motion clips

2. Trigger

The Overview screen (Ref: UC_4.1.1) has rendered.

3. Pre-conditions

• User is on the Overview screen (Ref: UC_4.1.1 §1 Overview).

4. Post-conditions

• The widget displays the trader's current-level Profit Factor, Gross Profit, and Gross Loss.

5. Basic Flow

1. On Overview screen load, frontend calls GET /core-performance for the trader's current level (Source: RFQ_ Stack Trading Prop Tech V7.pdf §Risk Metrics Endpoints).
2. Backend returns profit_factor, alongside gross_profit/gross_loss inputs used to compute it (Ref: BR_4.2.4.1).
3. Frontend renders the score, the Gross Profit / Gross Loss values, and the proportional profit-vs-loss bar.
4. On trade close, the PERFORMANCE_UPDATE WebSocket event pushes an updated profit_factor, and the widget updates live.

6. Exceptional Flow

• WebSocket/API connection drops, market is closed, or page reload (F5): the widget continues displaying the latest successfully loaded values rather than becoming empty (Ref: CR-14).

7. Business Rules

BR_4.2.4.1: Profit Factor Formula, Scope, and Zero-Trade Clamp

Formula: Profit Factor = Gross Profit ÷ Gross Loss, where:

• Gross Profit = sum of the absolute PnL of all winning closed trades at the trader's current level.
• Gross Loss = sum of the absolute PnL of all losing closed trades at the trader's current level.
• If Gross Loss = 0 (no losing trades yet), the result is Gross Profit itself, to avoid a divide-by-zero error.

(Source: RFQ_ Stack Trading Prop Tech V7.pdf §Risk Metrics Logic Definitions "Profit Factor".)

Scope: the widget uses the current level scope (all closed trades since the trader reached their current level) via GET /core-performance / PERFORMANCE_UPDATE — there is no lookback-window selector on this widget (Source: BA confirmation, 2026-08-08, QnA_init_docs.md A-12). This differs from the period-scoped profit_factor shown inside the Win Rate widget's stats row (Ref: BR_4.2.5.1), which uses a selectable lookback window — the two are separate values by design, not duplicates.

Zero-trade clamp: when the trader has not closed any trade yet at their current level (Gross Profit = Gross Loss = 0), the widget displays 0 rather than — (Source: BA confirmation, 2026-08-08, QnA_init_docs.md A-13; confirmed visually by wireframe Dashboard - Day 0.png, which shows "Profit Factor (0)").

8. Screen Description

UC_4.2.5 — Win Rate

1. Overview

Dashboard.png Overview screen — "Win Rate" panel, populated state. Dashboard - Day 0.png Overview screen — "Win Rate" panel, no-trades state (empty dot grid).

Motion reference: UC_4.2.5 motion clips

2. Trigger

The Overview screen (Ref: UC_4.1.1) has rendered, or the user changes the lookback filter.

3. Pre-conditions

• User is on the Overview screen (Ref: UC_4.1.1 §1 Overview).

4. Post-conditions

• The widget displays win-rate statistics and the win/loss dot grid for the selected lookback window.

5. Basic Flow

1. On Overview screen load, frontend calls GET /win-rate-grid-data?lookback_count=100 (default 100, per wireframe default "Last 100 trades").
2. Backend returns {period_total_trades, period_win_rate, period_profit_factor, period_avg_win, period_avg_loss, trade_results: [{ticker, timestamp_utc, pnl, holding_time_seconds, is_winner}...]} — trade_results is an array of per-trade objects for the lookback window, not a flat array of booleans (Ref: BR_4.2.5.1).
3. Frontend renders the stats row (Total trades, Win rate, Profit factor, Avg win/loss) and the dot grid from trade_results (Ref: BR_4.2.5.1).
4. User changes the lookback dropdown (10/30/50/100) → frontend re-calls the endpoint with the new lookback_count.
5. User hovers a dot in the grid → frontend renders a tooltip built from that trade's object (Ref: BR_4.2.5.1).
6. On trade close, the PERFORMANCE_UPDATE WebSocket event pushes an updated win_rate_percent — alongside the other performance fields in that same event payload (profit_factor, avg_win, avg_loss, latest_trade, holding_time, etc.) — and the widget's Win rate stat updates live, without waiting for the next GET /win-rate-grid-data re-fetch (Source: RFQ_ Stack Trading Prop Tech V7.pdf §12 WebSocket Events, PERFORMANCE_UPDATE payload; Ref: BR_4.2.5.2).

6. Exceptional Flow

• No closed trades yet: stats show 0/empty values and the dot grid renders with no colored dots (Ref: wireframe Dashboard - Day 0.png).
• WebSocket/API connection drops, market is closed, or page reload (F5): the widget continues displaying the latest successfully loaded values rather than becoming empty (Ref: CR-14).

7. Business Rules

BR_4.2.5.1: Win/Loss Dot Grid — Per-Trade Data, Dot Coloring, and Hover Tooltip

Data source: trade_results in the Get Win Rate Grid Data response (GET /win-rate-grid-data?lookback_count=) is a chronologically ordered array of per-trade objects — one object per closed trade within the selected lookback window — not a flat array of booleans:

{
  "ticker": "ESZ5",
  "timestamp_utc": "2026-03-09 09:45 AM",
  "pnl": 450.00,
  "holding_time_seconds": 870,
  "is_winner": true
}

(Source: BA-supplied backend spec update, chat, 2026-08-10 — supersedes the earlier trade_results: [boolean...] shape; the backend now delivers individual trade metrics per dot instead of a flat win/loss flag.)

Dot coloring — one dot per trade in the grid, colored per trade object, checked in this order:

• Grey — pnl = 0 (breakeven trade, no gain or loss), regardless of is_winner.
• Green — is_winner = true (winning trade, pnl not 0).
• Red — is_winner = false (losing trade, pnl not 0).

Hover tooltip — hovering a dot renders a tooltip built directly from that trade's object, no separate lookup:

• Ticker: ticker.
• Trade time: timestamp_utc.
• PnL: pnl, monetary value display per CR-11.
• Holding time: frontend formats holding_time_seconds into a Xm Ys string (minutes = floor(seconds ÷ 60), remaining seconds = seconds mod 60) — e.g. 870 seconds displays as "14m 30s".
• Tooltip trigger/dismiss behavior follows CR-10 Tooltip Interaction.

Grid layout: [ASSUMPTION] rows/columns, reading order follow the wireframe's column-major fill pattern (not confirmed by a data field in the response).

BR_4.2.5.2: Win Rate — Live Update via PERFORMANCE_UPDATE WebSocket Event

Per the client-supplied WebSocket events specification (Source: RFQ_ Stack Trading Prop Tech V7.pdf §12 WebSocket Events), the PERFORMANCE_UPDATE event fires on the closure of a trade and carries a JSON payload that includes win_rate_percent (alongside sharpe_ratio, sortino_ratio, profit_factor, avg_win, avg_loss, latest_trade, holding_time, etc.).

• On receiving this event, the frontend updates the Win rate label (§8 row 3) in place, using the event's win_rate_percent value directly — no re-call of GET /win-rate-grid-data is needed for this field to update.
• Same event also drives the live update of BR_4.2.4.1's profit_factor and appends the latest_trade object as a new dot in the win/loss dot grid (Ref: BR_4.2.5.1) — win_rate_percent updates in the same push, keeping the stats row and the dot grid in sync on every trade close.
• This live-push update applies on top of the lookback-window fetch/re-fetch flow in §5 — it does not replace the GET /win-rate-grid-data?lookback_count= call on page load or filter change, since only the WebSocket event carries the incremental per-close update (Source: BA confirmation, 2026-09-03).

8. Screen Description

Changelog