Requirements Document

Introduction

The Market Maker Dashboard provides real-time and historical visualization of market maker performance, regime analysis, and trading recommendations. The dashboard is implemented as a static website that reads from historical metrics data stored in YAML files (collected by the Regime Management System per Requirement 15 in regime-management spec) and presents key information through interactive charts and status displays.

This spec focuses on the visualization and user interface aspects of the dashboard. The metrics collection functionality is defined in the regime-management spec (Requirement 15).

Glossary

  • Dashboard: The static web-based visualization interface for market maker metrics
  • Spot_Check_Dashboard: A standalone HTML file generated for each recommendation that visualizes all underlying analysis factors and decision data
  • Static_Site_Generator: A tool that generates static HTML/CSS/JavaScript files from templates and data
  • Metrics_Store: The file-based storage system containing historical YAML metric files (managed by Regime Management System)
  • Regime: The current market state classification (RANGE_OK, RANGE_WEAK, TRANSITION, TREND)
  • Grid_Analysis: Performance and operational status of trading grid levels
  • Time_Series_Chart: A chart displaying data points over time
  • Risk_Level: Classification of current risk (LOW, MEDIUM, HIGH, CRITICAL)
  • Market_Metrics_File: Individual YAML files containing minute-by-minute price data and regime analysis for a specific market and time period
  • Client_Side_Rendering: JavaScript code that runs in the browser to load and display data dynamically

Requirements

Requirement 1: Generate Static Dashboard Site

User Story: As a trader, I want a static website dashboard that can be viewed without a running web server, so that I can easily access my metrics from any browser.

Acceptance Criteria

  1. THE Dashboard SHALL generate static HTML, CSS, and JavaScript files
  2. THE Dashboard SHALL be viewable by opening the HTML file directly in a browser without requiring a web server
  3. WHEN the Dashboard is generated, THE System SHALL create all necessary assets (HTML, CSS, JavaScript, chart libraries) in a single output directory
  4. WHEN generating the Dashboard, THE System SHALL pre-process all YAML metric files and extract data needed for visualization into optimized JSON or JavaScript data structures
  5. WHEN pre-processing metrics, THE System SHALL include only the data required for each chart type to minimize file size
  6. THE Dashboard SHALL be regenerated automatically after each metrics collection cycle
  7. WHEN accessing the Dashboard, THE System SHALL serve files from the local filesystem or via a simple static file server

Requirement 2: Load Historical Metrics Data

User Story: As a trader, I want to view historical market maker metrics, so that I can analyze past performance and market conditions.

Acceptance Criteria

  1. WHEN generating the Dashboard, THE System SHALL scan the Metrics_Store directory structure for all available metric files
  2. WHEN metric files are found, THE System SHALL parse YAML files and extract pricing, regime, and grid data
  3. WHEN parsing fails for a file, THE System SHALL log the error and continue processing remaining files
  4. THE System SHALL support loading metrics from multiple dates and hours
  5. WHEN processing data, THE System SHALL preserve chronological ordering based on file timestamps
  6. WHEN the Dashboard loads in the browser, THE Client_Side_Rendering SHALL load pre-processed data files without needing to parse YAML

Requirement 3: Display Pricing Data

User Story: As a trader, I want to see price movements over time with minute-level granularity, so that I can understand market trends and volatility in detail.

Acceptance Criteria

  1. WHEN pricing data is loaded, THE Dashboard SHALL display a Time_Series_Chart showing price over time with minute-level granularity
  2. THE Dashboard SHALL plot opening, closing, high, and low prices for each hour
  3. WHEN grid configuration exists, THE Dashboard SHALL overlay grid bounds (upper and lower) on the price chart
  4. WHEN grid levels exist, THE Dashboard SHALL display individual grid level prices as horizontal lines
  5. WHEN displaying market metrics, THE Dashboard SHALL overlay regime classification data on price charts to show regime changes relative to price movements
  6. THE Dashboard SHALL support zooming and panning on the time axis
  7. WHEN hovering over a data point, THE Dashboard SHALL display detailed price information in a tooltip

Requirement 4: Visualize Regime Analysis

User Story: As a trader, I want to see regime classifications over time, so that I can understand market state transitions and confidence levels.

Acceptance Criteria

  1. WHEN regime data is loaded, THE Dashboard SHALL display regime verdict for each time period
  2. THE Dashboard SHALL use distinct colors for each regime type (RANGE_OK, RANGE_WEAK, TRANSITION, TREND)
  3. WHEN displaying regime data, THE Dashboard SHALL show confidence scores as a percentage
  4. THE Dashboard SHALL display regime strength (STRONG, MODERATE, WEAK) alongside the verdict
  5. WHEN regime changes occur, THE Dashboard SHALL visually highlight transition points
  6. THE Dashboard SHALL display range integrity, support strength, and resistance strength metrics
  7. THE Dashboard SHALL show competing verdicts with their weights when available

Requirement 5: Show Grid Performance Metrics

User Story: As a trader, I want to monitor grid trading performance and account balance, so that I can assess profitability and capital deployment.

Acceptance Criteria

  1. WHEN grid data is loaded, THE Dashboard SHALL display total profit and profit percentage
  2. THE Dashboard SHALL show the count of active trades and grid levels
  3. THE Dashboard SHALL display grid operational status (PRICE_ABOVE_RANGE, PRICE_BELOW_RANGE, PRICE_IN_RANGE)
  4. WHEN grid levels exist, THE Dashboard SHALL show how many buy levels are waiting and sell levels are active
  5. THE Dashboard SHALL display capital at risk and position health status
  6. WHEN displaying account metrics, THE Dashboard SHALL show time-series graphs of total balance, available balance, and deployed capital over time
  7. WHEN displaying grid metrics, THE Dashboard SHALL show charts of active grid count, total capital deployed, and profit/loss trends for each grid

Requirement 6: Display Risk Assessment and Recommendations

User Story: As a trader, I want to see current risk levels and recommendations, so that I can make informed trading decisions.

Acceptance Criteria

  1. WHEN risk data is loaded, THE Dashboard SHALL display the overall Risk_Level with appropriate color coding
  2. THE Dashboard SHALL list all identified risk factors for the current period
  3. THE Dashboard SHALL display actionable recommendations based on current market conditions
  4. WHEN Risk_Level is HIGH or CRITICAL, THE Dashboard SHALL prominently highlight the warning
  5. THE Dashboard SHALL show when the assessment was made and when the next review is recommended

Requirement 7: Support Time Range Selection

User Story: As a trader, I want to select different time ranges, so that I can focus on specific periods of interest.

Acceptance Criteria

  1. THE Dashboard SHALL provide controls to select start and end dates for data display
  2. WHEN a time range is selected, THE Dashboard SHALL filter all charts and displays to show only data within that range
  3. THE Dashboard SHALL support preset time ranges (Last 24 Hours, Last 7 Days, Last 30 Days, All Time)
  4. WHEN no data exists for a selected range, THE Dashboard SHALL display an informative message
  5. THE Dashboard SHALL update all visualizations simultaneously when the time range changes

Requirement 8: Provide Real-Time Data Updates

User Story: As a trader, I want the dashboard to automatically refresh with new data, so that I always see current information without manual intervention.

Acceptance Criteria

  1. THE Dashboard SHALL check for new metric files at regular intervals (configurable, default 60 seconds)
  2. WHEN new metric files are detected, THE Dashboard SHALL load and display the new data
  3. WHEN updating data, THE Dashboard SHALL preserve the user’s current view settings (zoom level, selected time range)
  4. THE Dashboard SHALL display the timestamp of the most recent data point
  5. THE Dashboard SHALL indicate when data is being refreshed with a visual indicator

Requirement 9: Support Multiple Markets

User Story: As a trader managing multiple trading pairs, I want to view metrics for different markets, so that I can monitor all my positions.

Acceptance Criteria

  1. THE Dashboard SHALL provide a market selector to switch between different trading pairs
  2. WHEN a market is selected, THE Dashboard SHALL load and display metrics specific to that market
  3. THE Dashboard SHALL support viewing multiple markets simultaneously in separate panels
  4. WHEN no data exists for a selected market, THE Dashboard SHALL display an informative message
  5. THE Dashboard SHALL display the list of available markets based on discovered metric files

Requirement 10: Export Data and Visualizations

User Story: As a trader, I want to export charts and data, so that I can share analysis with others or keep records.

Acceptance Criteria

  1. THE Dashboard SHALL provide an export button for each chart
  2. WHEN exporting a chart, THE Dashboard SHALL support PNG and SVG image formats
  3. THE Dashboard SHALL provide an option to export raw data as CSV or JSON
  4. WHEN exporting data, THE Dashboard SHALL include all visible data points in the current time range
  5. THE Dashboard SHALL include metadata (export timestamp, time range, symbol) in exported files

Requirement 11: Responsive Design

User Story: As a trader using multiple devices, I want the dashboard to work well on both desktop and mobile, so that I can monitor my positions from anywhere.

Acceptance Criteria

  1. WHEN charts are displayed, THE Dashboard SHALL use responsive design that works on both desktop and mobile devices
  2. WHEN viewed on mobile devices, THE Dashboard SHALL adapt layout to fit smaller screens
  3. WHEN viewed on desktop, THE Dashboard SHALL utilize available screen space efficiently
  4. THE Dashboard SHALL maintain readability and usability across different screen sizes

Requirement 12: Spot Check Dashboard for Recommendation Support

User Story: As a grid trader evaluating a recommendation, I want a detailed “spot check” dashboard that visualizes all the underlying market data and analysis factors that led to the recommendation, so that I can validate the system’s reasoning and make informed decisions.

Acceptance Criteria

  1. WHEN a recommendation is generated, THE Dashboard SHALL create a spot check data snapshot containing raw exchange data, analysis results, and configuration state
  2. WHEN storing spot check snapshots, THE Dashboard SHALL save them as JSON files to a dedicated spotchecks directory in the market-maker-data repository
  3. WHEN storing raw exchange data in snapshots, THE Dashboard SHALL preserve OHLCV candlestick data from KuCoin in its original form for all timeframes used in regime analysis (1m, 15m, 1h, 4h)
  4. WHEN storing 1-minute OHLCV data in snapshots, THE Dashboard SHALL include high and low values (not just close) to enable accurate grid level crossing detection and boundary violation analysis
  5. WHEN storing multi-timeframe candlestick data in snapshots, THE Dashboard SHALL preserve the complete OHLCV data (open, high, low, close, volume) for each timeframe to enable recalculation of TrendScore, MeanRevScore, VolScore, and gate evaluations
  6. WHEN storing analysis results in snapshots, THE Dashboard SHALL include all calculated regime scores, gate evaluations, discovered ranges, and competing verdicts as they were computed at recommendation time
  7. WHEN storing configuration in snapshots, THE Dashboard SHALL capture grid configuration parameters, thresholds, and system settings that were active at recommendation time
  8. WHEN naming spot check snapshot files, THE Dashboard SHALL use the format “spotcheck_{timestamp}{symbol}{recommendation_id}.json” to ensure uniqueness and traceability
  9. WHEN the static site is generated, THE Dashboard SHALL scan the spotchecks directory and generate an HTML page for each snapshot file
  10. WHEN generating spot check HTML pages, THE Dashboard SHALL use the same shared JavaScript libraries and CSS as the main dashboard to avoid versioning complexity
  11. WHEN a spot check snapshot includes a recommendation ID, THE Dashboard SHALL include a link to the corresponding decision record file in the market-maker-data repository
  12. WHEN displaying spot check data, THE Dashboard SHALL show comprehensive market analysis data for the analyzed time period
  13. WHEN displaying regime classification factors, THE Dashboard SHALL show time-series charts for mean reversion indicators including lag-1 autocorrelation, OU half-life, and z-score reversion rate
  14. WHEN displaying regime classification factors, THE Dashboard SHALL show time-series charts for directional persistence indicators including ADX, normalized slope, and trend strength
  15. WHEN displaying regime classification factors, THE Dashboard SHALL show time-series charts for range quality metrics including discovered range bounds, range ratio (amplitude/ATR), and efficiency ratio
  16. WHEN displaying regime classification factors, THE Dashboard SHALL show time-series charts for volatility state metrics including ATR percentage, volatility expansion/contraction, and Bollinger Band bandwidth
  17. WHEN displaying regime classification factors, THE Dashboard SHALL show time-series charts for volatility state metrics including ATR percentage, volatility expansion/contraction, and Bollinger Band bandwidth
  18. WHEN displaying discovered range analysis, THE Dashboard SHALL overlay discovered support/resistance levels on the price chart with visual indicators showing rejection frequency and range stability duration
  19. WHEN displaying grid comparison data, THE Dashboard SHALL show the relationship between discovered market range bounds and configured grid bounds (if a grid exists)
  20. WHEN a grid exists, THE Dashboard SHALL highlight price position relative to both discovered range and configured grid bounds
  21. WHEN grid restart gates are being evaluated, THE Dashboard SHALL display gate status for all three gates (Directional Energy Decay, Mean Reversion Return, Tradable Volatility) with pass/fail indicators
  22. WHEN displaying gate evaluation details, THE Dashboard SHALL show the specific metrics and thresholds for each gate component with visual indicators of whether each metric passes or fails
  23. WHEN displaying gate evaluation history, THE Dashboard SHALL show time-series data of gate status over the evaluation period to visualize gate stability
  24. WHEN displaying spot check data, THE Dashboard SHALL show minute-by-minute price data from the exchange for the analyzed period to provide granular price movement context
  25. WHEN displaying technical indicators, THE Dashboard SHALL overlay indicator values on price charts where appropriate (e.g., Bollinger Bands, moving averages, ATR bands)
  26. WHEN displaying regime verdict, THE Dashboard SHALL show the final classification (RANGE_OK, RANGE_WEAK, TRANSITION, TREND) with confidence score and supporting metrics
  27. WHEN displaying competing verdicts, THE Dashboard SHALL show alternative regime classifications with their weights and supporting data
  28. WHEN displaying spot check data, THE Dashboard SHALL provide export functionality for all charts and underlying data for external analysis
  29. WHEN a recommendation includes a proposed grid configuration, THE Dashboard SHALL visualize the proposed grid levels overlaid on the price chart with discovered range bounds
  30. WHEN displaying historical spot checks, THE Dashboard SHALL provide an index page listing all available spot check snapshots with links to their generated pages
  31. WHEN spot check data is incomplete or unavailable, THE Dashboard SHALL clearly indicate which metrics are missing and why
  32. WHEN displaying spot check visualizations, THE Dashboard SHALL use consistent color coding and visual language with the main dashboard for regime types and risk levels
  33. WHEN re-analyzing historical spot check data, THE Dashboard SHALL use the preserved raw exchange data from the snapshot to recalculate analysis with updated algorithms without requiring access to the exchange API

Requirement 13: Recent Recommendations List

User Story: As a grid trader, I want to see a list of recent recommendations on the main dashboard with links to their spot check pages, so that I can quickly access detailed analysis for any recommendation.

Acceptance Criteria

  1. WHEN the main dashboard is displayed, THE Dashboard SHALL show a “Recent Recommendations” section listing the most recent 20-30 recommendations
  2. WHEN displaying each recommendation in the list, THE Dashboard SHALL show timestamp, symbol, regime verdict, confidence score, action, and status
  3. WHEN a recommendation has a corresponding spot check snapshot, THE Dashboard SHALL provide a clickable link to the spot check dashboard page
  4. WHEN displaying recommendations, THE Dashboard SHALL use color coding consistent with regime types (RANGE_OK=green, RANGE_WEAK=yellow, TRANSITION=orange, TREND=red)
  5. WHEN the recommendations list is displayed, THE Dashboard SHALL support sorting by timestamp, symbol, verdict, or confidence
  6. WHEN the recommendations list is displayed, THE Dashboard SHALL support filtering by symbol, verdict type, or action type
  7. WHEN a user clicks on a recommendation row, THE Dashboard SHALL navigate to the corresponding spot check dashboard page
  8. WHEN hovering over a recommendation, THE Dashboard SHALL display a tooltip with quick preview of key metrics
  9. WHEN generating the recommendations list, THE Dashboard SHALL scan decision records and match them to spot check snapshots
  10. WHEN a decision record exists without a corresponding spot check snapshot, THE Dashboard SHALL still display the recommendation but indicate that detailed analysis is not available