Upload docs/source_one_dome.md with huggingface_hub

docs/source_one_dome.md

@@ -0,0 +1,81 @@
+# Source One: DOME Baseline Data
+
+Prepared: 2026-07-02 UTC
+
+## Purpose
+
+DOME is the existing local market-data corpus and remains the audit/baseline source for the strategy stack. It is not being replaced. It gives us continuity with the already-built reconstructed windows, Binance and Chainlink joins, labels, and older research artifacts.
+
+Canonical local root:
+
+```text
+/home/Binance_Chainlink_Data/isolated_balanced_pm2s
+```
+
+## Local Layers Observed
+
+The current DOME corpus has three relevant layers:
+
+- `reconstructed/{ASSET}/date=YYYY-MM-DD/window_*.jsonl.gz`
+- `raw/orderbooks/{ASSET}/date=YYYY-MM-DD/window_*_{yes,no}.json.gz`
+- `raw/trades/{ASSET}/date=YYYY-MM-DD/window_*_{yes,no}.json.gz`
+
+Observed inventory from the local filesystem:
+
+| Layer | Assets | Date coverage | Shape |
+|---|---|---|---|
+| `reconstructed` | BTC, ETH, SOL, XRP | BTC starts `2026-02-13`; ETH/SOL/XRP start `2026-02-19`; all extend to `2026-05-31` locally | 1 Hz window files, usually up to 288 five-minute windows per day |
+| `raw/orderbooks` | BTC, ETH, SOL, XRP | `2026-03-16` through `2026-05-31` locally | YES and NO raw orderbook files per market window |
+| `raw/trades` | BTC, ETH, SOL, XRP | `2026-03-16` through `2026-05-31` locally | YES and NO raw trade files per market window |
+
+Exact generated counts are maintained in:
+
+```text
+/home/Data_Collection_v2/catalog/dome_inventory.csv
+/home/Data_Collection_v2/catalog/market_data_catalog.json
+```
+
+## Strengths
+
+DOME is strong for baseline research and cross-checks:
+
+- It already matches the existing strategy research code and reconstructed-frame loaders.
+- It covers multiple assets: BTC, ETH, SOL, XRP.
+- It includes reconstructed 1 Hz five-minute windows for large historical ranges.
+- It includes raw YES and NO books for many March-May windows, which is important for validating two-leg YES/NO parity.
+- It is integrated with the older Binance/Chainlink feature and resolution workflows.
+- It is useful as a fallback when another source has missing archives or questionable transforms.
+
+## What DOME Is Good For
+
+Use DOME for:
+
+- Baseline backtests where the old 1 Hz frame interface is expected.
+- Validating PMData-derived YES/NO ladders against real DOME YES/NO books.
+- Checking top-of-book agreement across sources.
+- Comparing reconstructed 1 Hz behavior with sub-second PMData behavior.
+- Maintaining compatibility with older Binance/Chainlink and resolution labels.
+- Fallback or patching for isolated PMData archive gaps.
+
+## Limitations
+
+DOME is weaker than PMData for execution-grade maker/taker fill simulation:
+
+- Reconstructed windows are 1 Hz, while the strategy plan needs sub-second book and trade-event replay.
+- The reconstructed NO side can be synthetic in some corpus products; two-leg math must validate against raw real NO books.
+- Raw trade quality and temporal density vary by date; some periods are tape-dense and some are patchy.
+- Queue position cannot be known exactly from DOME alone.
+- It is not as cleanly packaged for date-range archival and re-download as the PMData daily ZIP structure.
+
+## Strategy Role
+
+DOME should remain the audit and baseline source.
+
+Recommended uses in the V3 plan:
+
+- `data/twosided.py`: compatibility layer for 1 Hz frames.
+- Source validation: compare PMData top-of-book and derived YES/NO ladders against DOME raw books.
+- Acceptance testing: confirm PMData adapter output agrees with DOME on overlapping windows.
+- Fallback: use DOME only where PMData is missing and the fallback is explicitly marked.
+
+Do not use DOME alone as the final execution-quality source for maker queue-fill simulation unless the test is explicitly a baseline or compatibility run.