Trade Copilot Evaluation Specification

This document defines the preparatory contract for accident-avoidance warnings, trade-action taxonomy, restructuring comparison, and candidate-screen diagnostics. It covers ENG-5246, ENG-5247, ENG-5248, and ENG-5250.

It is not an implementation and it does not authorize live recommendations. It defines the product and data contract that should be reviewed before code changes.

Purpose

The first valuable copilot behavior is accident avoidance:

Do not let the trader add exposure in a part of the surface where the current
regime and conditional distribution say the trade is poorly compensated.

The later behavior is restructuring evaluation:

Given the current book and regime, compare credible alternatives such as
buying back May, selling July, using June, trading a vertical, selling a 1x2,
or doing nothing.

Ticket Coverage

Accident-Avoidance Warning Contract

Gordon's example:

• trader is short May upside calls
• spot rallies
• trader buys back one strike and sells more of a higher strike, such as a 1x2-style roll
• in a spot up / vol up regime, this can increase short vol in exactly the area where vol may reprice higher

The system should eventually detect this type of structure and explain the risk.

Minimum warning output:

accident_warning = {
  trade_or_scenario_id,
  warning_type,
  warning_severity,
  surface_region,
  exposure_change,
  regime_evidence,
  conditional_distribution_evidence,
  term_structure_evidence,
  liquidity_evidence,
  trust_state,
  source_quality,
  message,
  caveats
}

Warning types:

Severity:

Warning wording must be risk-control language, not formal trade advice.

Trade Intent And Action Taxonomy

The current shortcut that "buy means long vol" and "sell means short vol" is useful for a first pass but is not enough for a copilot. The system needs action and intent labels.

Action taxonomy:

Intent source:

Every score should report the intent source. If intent is only inferred or direction-based, confidence should be lower.

V1 Restructuring Evaluator

The first evaluator should be a bounded comparator, not a full optimizer. It should compare realistic actions Gordon mentioned:

• buy back May and do nothing else
• buy back May and sell June
• buy back May and sell July
• trade a vertical spread
• trade a calendar or diagonal
• sell a 1x2 or similar ratio structure
• do nothing

Scoring dimensions:

Minimum evaluator output:

restructuring_candidate = {
  scenario_id,
  action_type,
  legs,
  regime_fit_score,
  surface_edge_score,
  conditional_distribution_score,
  term_structure_score,
  liquidity_score,
  source_quality_score,
  portfolio_exposure_score,
  confidence,
  warning_flags,
  rank,
  explanation
}

The explanation should be direct. Example:

Selling more May upside improves premium but increases short exposure in a
front-month region where spot-vol sensitivity is positive and conditional
probability exceeds vanilla. Confidence is discounted because execution
liquidity is partial.

Candidate-Screen Diagnostics

The candidate screen ranks live option quotes against expected payoff under the conditional density and applies filters. Gordon and operators need to know why candidates appear or disappear.

Every candidate view should report:

• starting candidate count
• count removed by DTE filter
• count removed by open-interest filter
• count removed by premium filter
• count removed by liquidity/source-quality filter
• count removed by conditional-edge threshold
• final candidate count
• reason for empty results
• source timestamps and trust state

Filter provenance output:

candidate_filter_summary = {
  starting_count,
  after_dte_count,
  after_open_interest_count,
  after_premium_count,
  after_liquidity_count,
  after_conditional_edge_count,
  final_count,
  removed_counts_by_filter,
  empty_state_reason,
  filter_settings,
  source_quality
}

Candidate rows should be described as construction context, not recommendations, until the warning and recommendation policy is approved.

Decision Points

Preparatory Acceptance

This specification is complete when:

• accident warnings have named triggers and severity states
• trade actions and intent-source labels are defined
• restructuring comparison dimensions are explicit
• candidate filters have provenance requirements
• warning language is separated from formal recommendations
• low-confidence and blocked states remain first-class outcomes