Trade Performance Discussion Guide

This page is the business-user discussion guide for the Performance page. It separates what the dashboard can currently measure from the data gaps and assumptions that need business sign-off.

Use this page before reviewing Performance with stakeholders. It is intentionally written as a meeting guide rather than an engineering contract.

Executive Summary

The current Performance page is strongest at answering:

Did Alpha trades line up with the dashboard's available opportunity context at entry?

It is not yet a complete execution-quality, forward-outcome, or realized-P&L report.

The most important caveat is that BTC-linked market context can explain the crypto-volatility backdrop for MSTR/COIN Alpha trades, but it cannot prove that a specific MSTR/COIN option trade had good execution liquidity. Execution-quality liquidity needs traded-contract market data at Alpha execution time.

Regime-Aware Copilot Context

The sponsor-facing strategy for the next phase is captured in Regime-Aware Trade Copilot Strategy. It expands the Performance discussion from post-trade measurement toward pre-trade and restructuring support, while preserving the same data-quality boundaries.

The near-term copilot focus is accident avoidance. The system should help identify trades that may look reasonable under the old spot up / vol down regime but are dangerous if current BTC behavior has shifted toward local spot up / vol up, especially in front-month upside vol. Gordon's practical example was a May upside short-vol position where rolling into a larger higher-strike short call structure could add short vol exactly where the surface may be underpricing upside volatility.

This does not remove the business decisions below. It makes them more important: proxy identity, source authority, strategy intent, lookback windows, model confidence, and estimated-mark policy determine whether a warning or restructuring recommendation is decision-grade or only exploratory.

Use the Source Authority Register as the decision checklist for which execution marks, forward marks, terminal marks, realized P&L sources, model estimates, and proxy states can feed decision-grade outputs.

Use Derivative Identity And Proxy Mapping as the decision checklist for exact listed contracts, adjusted contracts, standard-root fallback, SMA/OTC derivative-equivalent mappings, unsupported contracts, and unmapped rows.

Current Production Read

As of the 2026-05-10 production API check, the current 365d Alpha sample shows:

ENG-5169 Reliable Ingestion Planning Inputs

This section captures the open questions needed before the reliable Amberdata ingestion build can be split into implementation tickets under ENG-5169.

Known planning decisions as of 2026-05-11:

Recommended child-ticket order:

1. Contract identity and adjusted-contract mapping.
2. Amberdata endpoint and empty-response validation.
3. Coverage probe with reason buckets.
4. Request planner for market-hours-aware quote windows and provider limits.
5. Durable job/checkpoint framework.
6. Execution quote store and benchmark ingestion.
7. Liquidity ingestion through dedicated volume/OI sources.
8. Forward and terminal mark ingestion.
9. Data Readiness diagnostics and operator reporting.

The first slice should be contract identity plus provider coverage probing because it reduces the largest uncertainty before storage, job, and UI work. It also gives the business an auditable gap report before we start filling tables with partial data.

Open Questions For Full Ingestion Plan

These questions should be answered or explicitly marked as engineering-owned before implementation tickets are created.

Business and source-system questions

Provider and engineering validation questions

Data Gaps To Discuss

1. Execution-time option quotes

Execution benchmarking is partial because the dashboard has sourced MSTR/COIN option bid/ask quotes for some Alpha execution rows, but not for the full trade population.

Required fields:

Current provider validation found fresh sampled MSTR/COIN contract quotes with bid, ask, mark, bid/ask size, and quote timestamps. The sampled Amberdata level-1 rows did not include 24h contract volume or open interest. The dashboard therefore treats sourced bid/ask liquidity as partial execution-liquidity evidence until volume/OI are returned by the provider or sourced elsewhere.

Business question:

What source should be authoritative for MSTR/COIN execution-time option quotes?

Possible sources include Alpha, broker/OMS, OPRA, OptionMetrics, Amberdata TradFi coverage if entitled, or another approved market-data source.

2. Forward marks and outcomes

Forward outcomes are partial because the dashboard has sourced option marks for some trades and horizons, but not for the full MSTR/COIN trade population.

Business question:

Which source should define post-trade marks and P&L horizons?

The answer matters because hit rate and average P&L should exclude unavailable marks rather than treating them as zero.

3. Realized P&L authority

The dashboard can derive position lifecycles from Alpha rows, but derived same-contract cashflow should not be presented as realized P&L until validated.

Business question:

What is the authoritative realized-P&L source?

Candidates include accounting, PMS, broker statements, Alpha output, or a validated lifecycle accounting process.

4. Strategy intent

The current opportunity model assumes:

buy = long volatility
sell = short volatility

That is a useful first pass, but it may be wrong for hedges, rolls, spreads, closing trades, directional overlays, and portfolio-level constructions.

Business question:

Can Alpha provide strategy intent, trade reason, opening/closing flag, or parent-order grouping?

Without strategy intent, the dashboard should keep saying that opportunity alignment is assumption-based.

5. BTC proxy context

MSTR and COIN Alpha trades currently map to BTC-linked market context. This is appropriate for crypto-volatility backdrop, but it is still a proxy.

Business questions:

Where is BTC proxy context acceptable?
Where is it not acceptable?
Should MSTR and COIN have separate equity-option context layers?

Current recommendation:

6. Context coverage and freshness

Current source-group coverage has narrowed for opportunity context, but the table still matters because it distinguishes market backdrop from execution-quality evidence:

Business question:

Should the next phase prioritize backfilling context coverage, sourcing execution/outcome data, or adding strategy intent?

Assumption Gaps To Sign Off

Recommended Business Conversation

1. Start with the Performance page Data Readiness section.
2. State that opportunity alignment is scored, but execution quality and outcomes are not yet sourced.
3. Explain the current 61.5% as a strategy-read percentage among decisive rows, not a grade.
4. Show the large mixed bucket and ask whether the business wants segmentation by portfolio, regime, underlying, or strategy intent.
5. Explain that BTC proxy liquidity is market backdrop only.
6. Ask which data source should be authoritative for execution-time MSTR/COIN option quotes.
7. Ask which data source should be authoritative for forward marks and realized P&L.
8. Ask how adjusted 2MSTR / 2COIN contracts should be mapped and where standard-root proxy fallback is acceptable.
9. Ask what sourced-coverage threshold is acceptable for release sign-off if provider coverage cannot reach 100%.
10. Review the opportunity signal point rules and decide whether thresholds should be accepted, adjusted, or made configurable.

Business Decisions Needed