Skip to content

Last Updated: 2026-05-03 Owner: Docs-Dev Summary: Prompt for converting the architecture design into implementation-ready module definitions, schemas, and build details.

QuantMatrix Implementation Specification Prompt

You are a principal engineer writing an implementation specification for a production-grade automated momentum day trading platform called QuantMatrix.

I already have a system design document. Your job now is to transform that design into a build-ready implementation specification that engineers can execute module by module without ambiguity.

The output must be: - concrete - implementation-oriented - explicit about boundaries - explicit about files, modules, APIs, schemas, and configs - suitable for phased delivery by a small engineering team

Do not rewrite the design document at a high level. Convert it into an engineering execution specification.

Assume the system includes: - UI frontend - backend API - market data ingestion - momentum radar - opportunity scanner - active strategy watchlist - strategy allocator - entry strategies - exit strategies - order execution service - broker abstraction - account summary service - positions service - orders service - P&L service - trade journal and analytics - recommendation and insights engine - global risk manager - health monitoring - settings/configuration - historical data download - backtesting - Redis - PostgreSQL

Please produce the output in the exact structure below.

  1. Implementation Scope
  2. What this implementation spec covers
  3. What it assumes from the design doc

  4. What is intentionally deferred

  5. Target Repository Structure Provide a proposed repo layout down to major directories and important files.

For each directory/file explain: - purpose - ownership - dependency direction

Include at minimum: - frontend app structure - backend app structure - domain modules - broker adapters - data modules - risk modules - strategy modules - scheduler/jobs - tests - infra/config - migrations - docs

  1. Module-by-Module Build Specification For each module define:
  2. module name
  3. purpose
  4. exact responsibilities
  5. what it must not do
  6. inputs
  7. outputs
  8. internal models
  9. public interfaces
  10. external dependencies
  11. persistence needs
  12. error handling expectations

  13. observability requirements

  14. File-Level Responsibilities For each major module, specify:

  15. expected files/classes/functions
  16. what each file should contain
  17. what should be kept separate
  18. what should be mocked in early versions

Do this in a way that an engineer can create the files directly.

  1. API Specification Define all required APIs in implementation detail:
  2. endpoint path
  3. method
  4. purpose
  5. request schema
  6. response schema
  7. validation rules
  8. auth expectations
  9. failure responses

Cover: - dashboard/account summary - momentum radar - watchlist actions - positions - orders - trade analytics and recommendations - risk/health - settings - historical data download - backtesting - emergency controls

  1. Redis Specification Define:
  2. key naming conventions
  3. streams
  4. hashes
  5. sorted sets
  6. expiration policy
  7. ownership of keys
  8. read/write patterns

Include exact examples for: - market data cache - momentum radar minute snapshots - blocked symbols - watchlist state if cached - position cache if used - risk state - health state - idempotency keys

  1. PostgreSQL Specification Define:
  2. tables
  3. columns
  4. indexes
  5. constraints
  6. retention policy
  7. source-of-truth vs derived tables

Include exact tables for: - orders - executions - trades - trade_features - trade_outcomes - trade_notes_or_explanations - recommendation_history - pnl snapshots - active_watchlist if retained - audit logs - settings overrides if persisted - optional archival of radar snapshots if needed

  1. Event and Message Contracts Define exact payloads for:
  2. market tick
  3. top gainer scan result
  4. watchlist candidate
  5. strategy assignment
  6. buy signal
  7. sell signal
  8. order command
  9. order ack
  10. fill event
  11. risk violation
  12. emergency halt event
  13. health event

Use JSON examples.

Also define payloads for: - trade_closed - trade_analysis_requested - trade_analysis_completed - recommendation_generated

  1. Configuration Specification List every environment variable and runtime setting:
  2. name
  3. type
  4. default
  5. required or optional
  6. which module uses it
  7. safety notes

Separate: - local dev - paper trading - live trading - backtesting

Include configuration for: - analytics retention windows - feature extraction toggles - recommendation generation mode - explanation model or rules engine version if used

  1. Build Order Provide exact implementation order.

For each step include: - modules to create - dependencies - required mocks - acceptance criteria - tests required before moving on

  1. Testing Specification Define:
  2. unit test targets
  3. integration test targets
  4. fixture strategy
  5. broker mocking strategy
  6. Redis test strategy
  7. DB migration test strategy
  8. end-to-end workflow tests
  9. backtest correctness checks

  10. paper trading validation checklist

  11. Operational Specification Define:

  12. startup sequence
  13. shutdown sequence
  14. health checks
  15. alert conditions
  16. retry and backoff behavior
  17. emergency liquidation behavior
  18. reconciliation jobs
  19. stale strategy handling
  20. scanner timing behavior
  21. trade analytics batch or streaming workflow

  22. recommendation refresh cadence

  23. Engineering Checklist Provide a checklist for each module that answers:

  24. implemented
  25. tested
  26. observable
  27. failure-safe
  28. idempotent
  29. documented

  30. analytically useful for post-trade review

  31. Final Output At the end provide:

  32. MVP implementation set
  33. Phase 2 implementation set
  34. Production hardening set
  35. Top 10 hidden risks during implementation
  36. Recommended first coding milestone

The implementation spec must explicitly define how to capture, store, and analyze the full context of every trade so that we can answer: - Why was this trade entered? - Why was it exited? - Which conditions were present in winning vs losing trades? - Which strategies, symbols, times of day, and market conditions perform best or worst? - What concrete recommendations should be generated from historical trades to improve future performance?

For the trade analytics module, require: - exact schemas - feature extraction points - storage of indicator values at entry and exit - outcome labeling - query patterns for review dashboards - recommendation generation workflow - rules for auditability and reproducibility

Important rules: - Be specific, not high-level - Prefer explicit file/module boundaries - Avoid vague “service layer” language unless fully defined - If a module should not be built yet, say so clearly - If one module depends on another, state it directly - If an API or schema is uncertain, list assumptions and recommended defaults - Optimize for step-by-step execution with minimal rework

After producing the full implementation specification, also provide: 1. A dependency graph in Mermaid 2. A module delivery checklist 3. A “build this first” starter set for the first sprint