Define and validate the Versioned Dataset Contract

[sybapp]

Parent

• PRD: ES TradingView-to-Nautilus strategy evolution system #1

What to build

Define the first Versioned Dataset Contract for the Strategy Evolution system and prove it with fixtures and validation. This slice should establish the externally visible dataset shape shared by the TradingView Collector and Nautilus Evaluator: a dataset manifest, bars data, feature data, and validation behavior for ES RTH 5-minute research datasets.

The goal is not to collect live TradingView data or run Nautilus yet. The goal is to make the dataset contract concrete enough that later collector and evaluator work can proceed independently.

Acceptance criteria

• A dataset manifest schema captures symbol, session, interval, contract type, continuous futures metadata, roll policy metadata, indicator allowlist, collection time, and schema version.
• Bars data schema captures time-aligned OHLCV records for ES RTH 5-minute data.
• Feature data schema captures TradingView-derived plots and Structural Features with event time, availability time, feature type, value payload, and repainting-risk metadata.
• A tiny fixture dataset exists and exercises manifest, bars, confirmed features, and repainting-risk features.
• A validator rejects malformed datasets, missing required metadata, features without availability time, and invalid repainting-risk metadata.
• Tests cover the contract at the fixture/validator seam without depending on TradingView websocket internals or Nautilus internals.

Blocked by

None - can start immediately