User Journey

This dashboard is designed as a drill-down workflow for an operator who needs to understand the current crypto volatility environment, identify what is driving it, translate that into market-implied outcomes, sync Alpha trades into the dashboard, and interpret what those trades say about trading behavior.

Start here when you want to understand what the dashboard is telling you, not just whether the system is technically healthy.

Production entry point: Vol Dashboard frontend

The Core Question

The dashboard should help answer one operating question:

What is the market pricing, what is driving that pricing, and what do the synced Alpha trades tell us about how we traded the opportunity?

The answer develops in layers. Do not start with the most complex diagnostics page. Start with the model summary, then drill into market setup, signal confidence, probability outcomes, and measurement evidence.

The intended conversation arc is:

1. Model. Model Explorer answers, "What is the current thesis, can we trust it, and what outcomes does it imply?" It gives the cross-page read first, then expands into source layers, diagnostics, and probability context.
2. Market Setup. Overview, Flow, Futures & Carry, and Yield Screener answer, "What is priced, what is driving it, and does carry/leverage confirm it?"
3. Measurement. Performance and Trade Book answer, "Did Alpha trade consistently with that setup, and are the source rows loaded?"
4. Help. Reference answers, "Where are the methodology docs?"

So yes: the working model is that you use Model and Market Setup to understand when and why the opportunity might exist, then use Measurement to understand what Alpha actually did and what can be defensibly evaluated from those trades. It is not a deterministic trade-timing engine; it is an evidence stack for deciding when conditions are worth considering and a post-trade attribution stack for checking whether Alpha traded consistently with that evidence.

The important qualifier is that Performance is not yet a complete P&L report. Today it is strongest as an opportunity-alignment and data-readiness view. It already answers "did our trades look directionally consistent with the opportunity context?" It does not yet answer "did we execute well?" or "did the trades make money?" unless the required execution benchmarks, forward marks, or realized P&L sources are populated.

Regime-Aware Trade Copilot Direction

The next strategic extension is documented in Regime-Aware Trade Copilot Strategy. That direction keeps the current dashboard journey intact, then adds a decision-support layer for questions like:

Does this proposed trade or restructuring action fit the current regime,
surface, conditional distribution, liquidity, and portfolio exposure?

The first product value is accident avoidance, not automatic trade selection. If the model detects that spot up / vol up behavior is live in a specific tenor, delta bucket, or smile segment, and the conditional-vs-vanilla distribution says upside options are underpriced, the system should warn before the trader adds short vol in that band. Those warnings must remain gated by stationarity, source quality, proxy mapping, and mixed-thesis confidence.

Operator-Overview Entry Point

Use Model Explorer before walking the full path when you need a fast cross-page read. It is organized as an expandable decision tree rather than a flat wall of cards:

1. Decision Summary shows the headline thesis, agreement, confidence, and source date.
2. Market Setup groups vol premium, surface shape, flow, dealer gamma, leverage, basis, liquidations, and carry-screen evidence.
3. Model Trust groups stationarity, live GEX freshness, and alert diagnostics.
4. Probability Outcomes groups the vanilla density anchor, conditional density, touch probability, and candidate screen.
5. Alpha Measurement groups Alpha opportunity-alignment evidence.

Each tree group can be expanded into the underlying signal nodes, data inputs, calculations, diagnostics, and source links. Help icons carry the core methodology text so the view remains compact without losing explanation.

Model Explorer is an agreement view, not a composite score or a trade signal: unavailable layers stay unavailable, partial layers stay partial, and stationarity controls how much weight to place on conditional probability outputs.

Recommended Path

How To Read The Custom Algorithms

This section explains the dashboard-specific algorithms at operator level. It is meant to answer, "What should I do with this output?" rather than repeat every formula. For formulas, units, and boundaries, use the Calculation Reference.

Gamma Analytics

Gamma analytics describe how dealer positioning can affect the next price move. The dashboard uses several related reads:

The best gamma read combines level and regime:

• A nearby magnet matters more when gamma is positive and concentrated.
• A nearby repeller matters more when the broader regime is short gamma.
• Percentile extremes matter more when flow, VRP, and smile shape agree with the same story.
• Transition stats are historical context; stationarity still controls how much confidence to place in them.

Regime Stationarity

Regime stationarity is the main confidence-control algorithm for the conditional probability views. It asks whether historical forward returns in each gamma regime still look like recent forward returns.

The dashboard groups observations by gamma regime:

For each regime, the stationarity panel compares an older baseline window with a recent window:

How to use it:

• If all relevant relationships are stable, the conditional density is more useful as a regime-adjusted read.
• If one or more relationships are unstable, treat conditional density, touch probabilities, and candidate-screen suggestions as lower-confidence overlays.
• If relationships are insufficient, avoid concluding that the regime is safe. The correct read is "not enough evidence", not "no risk".
• If the stationarity panel says Model adjustment required, use the vanilla risk-neutral density as the anchor and treat the conditional shift as a weaker signal.

Probability Stack

The Probability screen has a hierarchy. Read it in this order:

1. Risk-neutral density: the vanilla market-implied distribution extracted from one timestamped IV surface. The x-axis is implied terminal price and the y-axis is density per dollar, so area integrates to one.
2. Current regime: the gamma percentile and regime context used for conditioning.
3. Conditional density: the vanilla distribution tilted by historical returns observed in similar gamma states.
4. Stationarity and blend weight: the confidence control that decides whether the conditional tilt should be trusted.
5. Touch probabilities: path-risk approximations derived from the distribution.
6. Candidate screen output: ranked contracts that depend on the conditional distribution and live option filters.

The key comparison is not "conditional is right and vanilla is wrong." The useful read is:

What does the options market imply first, and how much does the current regime justify shifting that implication?

If stationarity is unstable, the answer should be conservative: the conditional model is informative, but it should not override the vanilla market-implied distribution.

Model Lab

Use Model Lab when you need to test probability assumptions without changing production defaults. It runs a scenario request with explicit parameters, then shows production baseline and tuned outputs side by side.

V1 boundaries:

• Scenario runs are export-only; durable preset saves are not included.
• Production defaults remain unchanged.
• Alternative density methods, KDE/bootstrap likelihood, as-of replay, and full barrier touch models are disabled until implemented.
• Candidate-screen settings are included as provenance, while tuned optimizer integration is labelled as not included in V1.

Read Model Lab as a sensitivity and review surface. A tuned result can explain which assumptions matter, but it should not be treated as a promoted production model unless a later workflow explicitly promotes it.

Flow And Dealer Positioning

The Flow page combines actual trading activity with dealer-positioning analytics.

The strongest flow read is when several signals agree. For example, short-dated put demand, negative GEX, elevated VRP, and downside-skewed smile all point to a coherent protection-demand story. A single large trade without surface confirmation is weaker.

Smile And Spot-Vol Reads

Smile tracking and spot-vol correlation are shape and relationship checks:

• Smile tracking compares each DTE/delta IV point with its trailing baseline and labels it rich, cheap, or fair.
• A rich wing means that part of the surface is elevated versus its own recent history.
• A cheap wing means that part of the surface is depressed versus its own recent history.
• Vol heatmap buckets spot and time, then shows average IV in each bucket.
• A high-IV heatmap band around lower spot buckets supports a downside-stress interpretation.
• A high-IV heatmap band across many spot buckets points more to broad vol regime change than spot-level sensitivity.
• Spot-vol correlation compares spot returns with IV changes over a rolling window.
• The spot-vol card separates Live spot from Correlation as-of. Live spot is current market context. Correlation as-of and Historical spot in calc are the latest overlapping spot/IV observation used for the rolling calculation, so they can lag live spot when IV surface snapshots are delayed.
• negative spot-vol is the classic risk-off pattern where spot down often coincides with vol up.
• positive spot-vol means spot and IV are rising or falling together.
• decorrelated means the usual relationship is weak, so be careful applying standard spot-vol intuition.

These reads are best used as explanations for surface shape. They are not execution recommendations by themselves.

Alert Signals

Alert signals are rule-based monitoring outputs. The current alert engine watches:

Slack dispatch is an operational notification path. The analytical read is the alert text and severity; a Slack send only proves the notification was delivered.

Alpha Trade Book Controls

The Trade Book page has a different purpose from the market setup, signal, and measurement pages. It is the Alpha sync and ingestion control surface. Its job is to load the selected Alpha trade scope into the dashboard and expose enough source-row economics for downstream analysis.

Use these controls as a data-readiness gate:

• Alpha sync state should show the expected configured scope, currently IMST, ICOI.
• Dry-run preview should show what would be fetched or updated before writing.
• source_total_quantity versus local_total_quantity is a sync-completeness check for the selected Alpha scope.
• source_total_premium_usd versus local_total_premium_usd is a sync-completeness check for the selected Alpha scope.
• unmatched_source_ids identifies Alpha rows not currently present in the dashboard cache for that scope.
• unmatched_local_ids identifies cached Alpha rows that are absent from the current selected source scope.
• Missing P&L, execution quality, or IV edge should stay blank when the dashboard lacks sourced marks, execution-time bid/ask quotes, traded-IV inputs, or authoritative realized-P&L data. Blank is safer than guessed economics.

When the sync-completeness checks are clean, the operator can treat the loaded Alpha rows as ready for the Performance page. The checks are not the point of the workflow; they are the guardrail that prevents interpreting stale or partially loaded trade data.

1. Start With Overview

Use Overview to build the first read.

The top cards answer:

Then read the major panels:

Operator output after this screen:

• A plain-language headline: for example, "BTC implied vol is above realized vol, skew is concentrated in short-dated puts, and activity is elevated."
• A decision on where to drill next: Flow if trading activity is the question, Futures if leverage/carry is the question, Model Diagnostics/Probability if model interpretation is the question.

2. Use Flow To Explain The Move

Use Flow after Overview.

This page answers whether the market signal is backed by actual option activity.

Operator output after this screen:

• A driver statement: for example, "Short-dated put demand and negative GEX are contributing to the elevated VRP."
• A confidence check: if flow is thin or fragmented, do not over-explain Overview moves from isolated trades.

3. Check Futures And Carry

Use Futures and Yields to test whether leverage or carry confirms the options signal.

Futures tells you:

Yields tells you:

Operator output after these screens:

• A shortlist, not an execution decision: for example, "BTC puts around this expiry show high annualized carry, but the yield is partly explained by short DTE and needs liquidity/risk review," or "Futures carry is mostly normal except one clipped outlier that should be investigated separately."

4. Check Model Confidence In Model Diagnostics

Use Model Diagnostics before leaning on conditional outputs.

Important reads:

Operator rule:

If stationarity is unstable or insufficient, treat conditional model outputs as lower confidence. The dashboard should make uncertainty explicit rather than hide it.

5. Translate Into Probabilities

Use Probability after you understand market state, flow, leverage, and model confidence.

This page translates option prices into implied outcomes. The current regime and conditional overlays use stored gex_hourly history, currently a 730-day lookback on the page. This is not the same object as the Model Diagnostics live magnet/repeller card, which uses the latest Amberdata strike-level GEX snapshot to show current strike concentrations.

Operator output after this screen:

• A probability statement: for example, "The vanilla market-implied distribution is centered near spot, but the conditional regime shifts downside touch probabilities higher."
• A confidence qualifier based on Model Diagnostics: for example, "Use with reduced weight because stationarity is unstable."

6. Confirm Trade Book Source Readiness

Use Trade Book when the question moves from market context to synced Alpha source rows.

The Trade Book screen is not the analytical destination. It is the control surface for bringing Alpha rows into the dashboard before the Performance page interprets them.

Recommended workflow:

1. Confirm Alpha sync state shows the expected portfolios, currently IMST, ICOI.
2. Keep Dry run enabled for previews.
3. Use incremental preview to check for new source trades.
4. Use the full-scope diagnostic dry run only as a sync-completeness check, for example after sync logic changes or when the loaded cache looks stale.
5. Check source/cache counts, quantity delta, premium delta, unmatched source IDs, and unmatched cached IDs as ingestion diagnostics.
6. Only disable Dry run when the preview is understood and intentional.
7. After real sync, confirm the synced trade economics: price per contract, multiplier, total premium USD, fees, source status, and source recon status.

Interpretation:

• Clean sync-completeness checks mean the selected Alpha rows are loaded into the dashboard cache for analysis.
• Quantity or premium deltas mean the Performance page may be reading a stale or incomplete trade cache until the difference is explained.
• P&L and IV-edge analytics are not part of the active Trade Book sync check. Forward marks and execution benchmarks belong on Performance after their source-quality checks pass; authoritative realized P&L still requires accounting or validated lifecycle data.
• The active trade-performance workflow is defined in Trade Performance Analytics. It separates opportunity alignment, execution quality, outcome attribution, and realized P&L source status so users can see which questions are answerable now and which are explicitly waiting on source data.

7. Review Trade Performance

Use Performance after the Alpha feed has synced cleanly.

What This Page Is For

Performance is the bridge between the market analytics stack and actual Alpha trading behavior.

The pages before Performance help build the trade thesis:

• Overview asks what the volatility market is pricing now.
• Flow asks what trading activity and dealer positioning are driving that pricing.
• Futures and Yields ask whether leverage, basis, funding, and carry support or contradict the options signal.
• Model Diagnostics asks whether the custom regime relationships are fresh and stable enough to trust.
• Probability asks what the options surface implies about future outcomes, and how regime context shifts that view.
• Trade Book confirms that Alpha executions have been synced into the dashboard cache.

Performance then asks:

Given the opportunity context the dashboard could observe at execution time, did Alpha trade in the direction the dashboard would have expected, and do we have enough sourced data to evaluate execution and outcome quality?

That is deliberately narrower than "did the portfolio make money?" The screen separates three different questions that are often incorrectly blended:

Current Default Read

At the time of writing, the default view is All portfolios, 365d, All underlyings, All regimes, All signals.

The headline state is:

The different denominators are intentional:

• 751 is the current full synced Alpha execution set and default Performance analysis population.
• 524 is the decisive denominator for the headline opportunity percentage: supportive plus opposing rows, excluding mixed/no-edge and insufficient rows.
• If a future view shows fewer analyzed rows than imported rows, that reflects the selected lookback, portfolio filter, or analysis limit rather than a failed Alpha import.
• 284 is the derived option-position count after grouping executions into lifecycle positions.

Meeting line:

The Performance screen is currently strongest as an opportunity-alignment and data-readiness dashboard. It tells us whether Alpha traded in a direction consistent with dashboard signals at the time. Execution quality and economic outcome are readable only for rows with sourced quotes or marks.

How Opportunity Scoring Works

Each trade is scored as a signal-consistency question at execution time.

The current implementation has no explicit strategy-intent field from Alpha, so it applies a simple assumption:

Every score starts at 50 when at least one usable signal exists. The score is then adjusted by available market context.

The label buckets are:

The score is not:

• P&L.
• Execution quality.
• A recommendation engine.
• A statement that a trade should or should not have happened.
• Size-weighted by premium or risk.

It is:

• A direction-versus-context score.
• A way to see whether trading behavior clustered around signals the dashboard considered supportive.
• A diagnostic for whether the process was trading with or against the observable volatility backdrop.

Why The Current Read Is Mixed

The default read still needs segmentation because the current trade set has offsetting drivers and detractors, and because 225 rows sit in the mixed/no-edge bucket.

Current label distribution:

Current major drivers include:

• low_vrp: implied vol looked cheap enough to support long-vol entries for some trades.
• front_term_risk: near-term term structure supported long-vol risk in some cases.
• long_gamma: supported short-vol assumptions in some cases.
• rich_dvol: supported short-vol assumptions in some cases.
• stable_stationarity: supported model reliability for a subset.

Current major detractors include:

• unstable_stationarity: many trades occurred when the regime-return relationship was not stable.
• low_vrp: detracts from short-vol trades because cheap implied vol is not a good setup for selling vol.
• long_gamma: detracts from long-vol trades because long gamma can dampen moves.
• rich_dvol: detracts from long-vol trades because implied vol already looked rich.

Meeting line:

The 61.5% is not telling us the trades made money. It is telling us that, when the dashboard context was decisive, more rows were supportive than opposing. The process still needs segmentation because 225 rows are mixed/no-edge, confidence is below 50%, and execution/outcome evidence is only partial.

Why There Are Many Partials

The source-group section is there to prevent false confidence.

Opportunity scoring uses several source groups. A group is available only when all required fields for that group are present. It is partial when at least one field exists but other fields are missing. It is unavailable when the group has no usable source for that trade. It is not_sourced when we intentionally do not compute that group for this Alpha trade scope.

Current source-group interpretation:

The key point: partials are not necessarily failures. They are visibility into data coverage.

Meeting line:

The partial source groups are a feature, not a bug. They tell us exactly where the dashboard had incomplete context at the time of scoring. That protects us from treating the 61.5% headline as more precise than it really is.

Why Execution Is Only Partially Benchmarked

Execution quality requires a sourced execution-time market benchmark for the actual option that Alpha traded.

The intended benchmark is:

To compute this, the dashboard needs:

• The actual traded option contract.
• The Alpha execution timestamp.
• A sourced bid/ask quote for the same MSTR/COIN option near that timestamp.
• A quality label showing whether the quote is fresh, stale, estimated, or unavailable.

Current state:

• quoted: 331
• estimated: 0
• stale: 0
• unavailable: 420

That means the execution-benchmark table has usable bid/ask quote marks for part of the Alpha population, but many rows remain unsourced.

Meeting line:

We can read execution quality only for the 331 quoted rows. The remaining rows are not good or bad executions; they are rows where we do not yet have reliable execution-time MSTR/COIN option quotes.

Why Forward Outcome Marks Are Partial

Forward outcome marks answer what happened after the trade at a selected horizon, such as 1d, 7d, or 30d.

For 7d outcomes, the dashboard needs:

• The original trade.
• The target timestamp: trade time + 7 days.
• A sourced option mark for the same contract near that target timestamp.
• Fees, if available.
• A quality state for the mark.

The intended P&L logic is:

Current 7d state:

• available: 177
• pending: 1
• unavailable: 573

Interpretation:

• pending means the 7d horizon has not matured yet.
• unavailable means the horizon has matured, but no sourced forward mark is available.
• Neither state should be interpreted as zero P&L.

Meeting line:

The regime and signal buckets are ready, but 7d P&L and hit rate should be read only for the 177 rows with sourced marks. The dashboard deliberately excludes unavailable rows instead of fabricating P&L or counting gaps as zero.

Why Realized P&L Is Withheld

The dashboard can derive lifecycle groupings from Alpha execution rows, which is why it can show open and closed derived option positions. That is not the same as authoritative realized P&L.

Current position read:

• 284 derived positions.
• 208 closed.
• 8 open long.
• 68 open short.

The dashboard intentionally does not show derived FIFO cashflow as realized P&L yet because that would require validation against:

• source accounting,
• portfolio accounting,
• settlement marks,
• explicit open/close/roll lifecycle intent,
• or another approved realized-P&L source.

Meeting line:

Position coverage tells us the dashboard can group executions into likely positions, but realized P&L remains not sourced. We are not using derived lifecycle cashflow as an official P&L number until it is validated.

How To Drive The Meeting Conversation

Use this sequence:

1. Start with the thesis: "The dashboard first builds a volatility opportunity view, then checks whether Alpha traded consistently with that view."

2. Explain what is working: "The Alpha feed is synced. The Performance screen has scored 749 of 751 rows for opportunity alignment. Today the headline read is 61.5% supportive among decisive rows, with a large mixed/no-edge bucket."

3. Explain what the score means: "This is a signal-consistency score, not a P&L score. It compares buy/sell direction against DVol, VRP, gamma regime, stationarity, and term-structure context at the trade time."

4. Explain why the score still needs segmentation: "Supportive rows outnumber opposing rows among decisive cases, but many trades still sit in mixed, partial, or weak-alignment buckets, and average confidence is below 50%."

5. Explain the gaps without apologizing for them: "Execution and outcome metrics are partial because they require separate sourced quotes and marks. The dashboard is designed not to manufacture missing numbers."

6. State the next unlock: "The next stage is sourcing execution-time bid/ask benchmarks and post-trade forward marks for the traded MSTR/COIN options. That will let us answer whether we executed well and whether the trades worked economically."

7. Close with the operational value: "Even before P&L sourcing, the dashboard already gives us a process-quality read: were we trading in the direction of the volatility opportunity the system could observe?"

What You Can Safely Say Today

Use these statements:

• "Opportunity alignment is live and scored."
• "The default opportunity read is supportive among decisive rows but still needs segmentation."
• "The screen is source-quality-aware; missing data is shown explicitly."
• "Execution quality is readable only for rows with sourced execution-time MSTR/COIN quotes."
• "Forward P&L and hit rate are readable only for rows with sourced forward marks."
• "Realized P&L is intentionally withheld until validated against authoritative accounting or lifecycle rules."
• "The next phase is data sourcing, not formula invention."

Avoid these statements:

• "We executed well."
• "We executed poorly."
• "The trades made money."
• "The trades lost money."
• "Unavailable means zero."
• "The 61.5% is a return, P&L score, or execution grade."
• "BTC smile is being used as a precise proxy for MSTR/COIN option smile."

Recommended workflow:

1. Filter by portfolio first, usually IMST or ICOI.
2. Check whether alignment coverage is high enough to interpret the scores.
3. Read opportunity source groups before over-interpreting the score. A scored trade can still have partial source coverage.
4. Use the alignment distribution to see whether trades are mostly aligned, mixed, weakly aligned, or misaligned.
5. Use opportunity drivers and detractors to see which signals are influencing the score, such as low VRP, front-term risk, long gamma, or stationarity.
6. Check execution quality coverage before reading fill-vs-mid. Read only quoted rows; unavailable rows are unsourced benchmarks, not zero slippage.
7. Read 7d outcome availability before reading P&L. Pending rows are not mature yet; unavailable rows need sourced marks.
8. Use regime and signal attribution tables as outcome attribution only for sourced marks. If available outcomes are low, quote the sample size before interpreting average P&L or hit rate.
9. Drill into the trade table and source IDs when an aggregate looks surprising.
10. Use position coverage to understand open versus closed derived lifecycle state, not as authoritative realized P&L.

Operator rule:

Trade performance is only actionable when the Alpha feed has synced cleanly and quality states are acceptable. Treat pending, unavailable, stale, estimated, open, and ambiguous as workflow states to investigate, not as zeros or failures.

What Good Looks Like

A good operator read should sound like this:

BTC implied volatility is elevated versus realized volatility, VRP is positive, and the surface shows near-term skew. Options flow shows concentrated put demand and dealer gamma is in a regime that can amplify moves. Futures funding is not yet showing extreme crowding, so the options signal is stronger than the leverage signal. Probability views imply a wider downside distribution, but stationarity is unstable, so conditional outputs should be used with reduced confidence. The Alpha feed is synced for the selected scope. Performance shows that the synced trades are currently mixed against available opportunity context; execution and forward-outcome numbers are read only where sourced quotes or marks exist, and realized P&L remains correctly withheld until authoritative accounting or validated lifecycle data exists.

That is the intended journey: Model, Market Setup, then Measurement, with Reference available as compact help. Trade Book supports Performance with source rows and sync state, but Performance is where Alpha behavior is measured against the setup.

Related Docs

• UX Verification Plan for browser sign-off steps.
• System Overview for architecture and screen mapping.
• Calculation Reference for formulas, units, and assumptions.
• Trade Performance Analytics for the trade-performance metric contract and data-quality rules.
• Trade Performance Business Issues for business-facing data gaps, assumptions, and sign-off topics.
• Opportunity Alignment Rules for the current signal point rules and confidence penalties.
• Operator Runbook for production operations.
• Alpha Trade Sync for trade-feed sync controls and diagnostics.