Last Updated: 2026-05-03 Owner: Docs-Dev Summary: Prompt for designing the trade analytics, labeling, review, and recommendation layer for QuantMatrix.

QuantMatrix Trade Analytics Specification Prompt

You are a principal quantitative systems architect and senior data engineer.

I am building a production-grade automated momentum day trading platform called QuantMatrix.

I already have: - a system design document - an implementation specification

Your job now is to produce a dedicated Trade Analytics Specification that defines exactly how the platform should capture, store, analyze, explain, and learn from completed trades.

This document must help me answer questions like: - Why did a specific trade make money or lose money? - Which setups, strategies, symbols, times of day, and market regimes perform best or worst? - Which entry and exit conditions correlate with better outcomes? - What execution issues reduced profitability? - What specific changes should be recommended to improve future trades?

I do not want a vague analytics overview. I want an implementation-ready analytics specification that is explicit about schemas, features, storage, workflows, reproducibility, and recommendation logic.

Assume: - The system supports live trading, paper trading, and backtesting - Market data and execution brokers may be different - Redis may be used for live cache/state - PostgreSQL is available for durable storage - The system must be auditable - The analytics layer should support both rules-based recommendations and future ML-based analysis

Please produce the output in the exact structure below.

1. Analytics Scope and Goals
2. What this analytics specification covers
3. What business and trading questions it must answer
4. What it depends on from the design and implementation documents

5. What is intentionally out of scope for now

6. Trade Analytics Architecture Describe the full architecture for post-trade analytics.

Cover: - data producers - ingestion points - feature extraction layer - analytics storage - query and reporting layer - recommendation generation layer - UI/dashboard consumers - optional offline research workflows

Explain which parts are: - event-driven - synchronous - asynchronous - batch - streaming

1. Trade Lifecycle Capture Model Define the exact lifecycle data that must be recorded for every trade.

Include: - trade identifier - parent order and child execution links - strategy identifier and strategy version - symbol - side - quantity - timestamps for candidate, signal, order submit, fill, partial fill, exit, close - order type and broker route details - entry reason - exit reason - manual override indicators - risk rule interactions - mode: live, paper, backtest

Explain how to preserve the full chronology of a trade.

1. Feature Capture Specification Define the exact features that should be stored for every trade.

Split into sections: - market context features - entry features - exit features - execution quality features - position management features - outcome features - session and account context features

At minimum cover: - price at signal - price at entry - price at exit - daily percent gain - 1-minute and 5-minute momentum - volume and relative volume - float - spread - VWAP relationship - 9 EMA, 20 EMA, 200 EMA state - MACD state - high-of-day relationship - sector - time of day - opening range context - halt status if relevant - slippage - time in trade - MFE - MAE - realized P&L - unrealized excursion during trade - account equity at time of trade - concurrent open positions

For each feature define: - name - type - source - when it is captured - whether it is raw or derived - whether it is required or optional

1. Storage and Schema Design Define exact durable schemas for analytics storage.

Include recommended tables for: - trades - trade_events - trade_features - trade_outcomes - trade_explanations - recommendation_history - analytics_runs - strategy_versions

For each table define: - columns - types - primary key - foreign keys - indexes - partitioning or retention if needed - source of truth vs derived

Also define which analytics data, if any, should live temporarily in Redis and why.

1. Feature Extraction Workflow Describe exactly how and when features are generated.

Cover: - real-time capture at entry - updates during trade - capture at exit - finalization on trade close - backfill or replay behavior - recomputation when strategy logic changes

Explain how to handle: - missing market data - delayed fills - partial fills - broker corrections - manual edits or overrides

1. Outcome Labeling Specification Define how trades should be labeled for analysis.

Include labels such as: - winner / loser - hit target / stopped out / manual exit - strong setup / weak setup - clean execution / poor execution - momentum continuation / failed breakout / fade / reversal

For each label define: - logic - thresholds - source data required - whether manual review is allowed - whether it is deterministic or analyst-assigned

1. Explanation and Recommendation Engine Define how the system should explain outcomes and generate recommendations.

Split into: - deterministic rules-based explanations - aggregated pattern detection across historical trades - optional future ML-assisted recommendations

The spec must explain how to generate statements like: - “Trades entered below VWAP with falling volume underperformed.” - “Strategy A performs poorly after 10:30 AM on low-float names.” - “Average slippage is materially reducing profitability for market orders.” - “Winning trades tend to occur when 1-minute momentum and relative volume both exceed threshold X.”

For this section define: - input datasets - analysis windows - grouping dimensions - minimum sample size rules - confidence scoring - recommendation format - reproducibility and versioning rules

1. Query and Reporting Design Define the queries, APIs, and reporting outputs needed for trade review.

Include views for: - single trade deep-dive - daily review - strategy performance review - symbol performance review - time-of-day review - setup-pattern review - execution quality review - recommendation summary

For each view define: - purpose - key metrics - filters - group-bys - drill-down paths

1. Trade Review UI Requirements Define the UI modules required to consume this analytics system.

At minimum cover: - Trade Journal screen - Trade Detail screen - Strategy Analytics screen - Recommendation Insights screen

For each screen define: - widgets - tables - charts - filters - actions - required columns

1. Auditability and Reproducibility Define how analytics remain trustworthy over time.

Cover: - versioning of strategy logic - versioning of feature extraction logic - versioning of recommendation logic - immutable raw event history - recomputation rules - audit trails for manual annotations - differences between paper and live data quality

1. Testing and Validation Define how to test the analytics layer.

Include: - unit tests for feature extraction - integration tests for trade close pipelines - reconciliation tests against broker records - replay tests from historical events - recommendation consistency tests - dashboard query correctness tests - acceptance criteria for production readiness

1. Delivery Plan Break the analytics system into phases.

For each phase define: - scope - dependencies - schema work - pipeline work - UI/reporting work - validation requirements - what should be manual first vs automated later

1. Final Deliverables At the end provide:
2. analytics module map
3. schema summary
4. implementation order
5. MVP analytics slice
6. production-grade analytics slice
7. top hidden risks
8. recommended first analytics milestone

Important rules: - Be concrete, not conceptual - Prefer exact schemas and workflows - Optimize for deterministic and auditable behavior first - Keep the design compatible with future ML enhancements, but do not rely on ML for the initial version - Explicitly separate raw facts, derived features, labels, explanations, and recommendations - If a metric or recommendation could be misleading, call that out - Include tables where useful - Include Mermaid diagrams where useful

After producing the full Trade Analytics Specification, also provide: 1. A trade analytics dependency graph in Mermaid 2. A feature capture checklist 3. A “build this first” analytics starter plan for the first sprint