DDrawLedger

Methodology

Data pipeline

  1. Source CSV is read and validated — bad rows are rejected, never silently coerced.
  2. Numbers are sorted, types coerced, and dates normalized to ISO.
  3. Duplicates are detected on the natural key (lottery, draw date).
  4. Canonical draws are written to the draw store (file-backed for the MVP).
  5. Derived statistics are computed and integrity-checked.
  6. Compact JSON artifacts are emitted for pages and client tools.

Statistics computed

  • Frequency & gaps — appearances, percentage of draws, current gap, average/median/max gap, first/last seen.
  • Patterns — odd/even split, high/low split, consecutive runs, decades, sum, and spread distributions.
  • Yearly aggregates — draw count, average sum, and jackpot averages per year.

Integrity invariants

Every ingestion run fails hard if any invariant is violated:

  • Σ number frequency = draws × numbers-per-draw.
  • Σ pair frequency = draws × C(numbers-per-draw, 2).
  • Σ triple frequency = draws × C(numbers-per-draw, 3).
  • No duplicate (lottery, date) keys; every draw has the correct count and range.

Canonical store

The MVP stores canonical draws as a versioned JSON file (data/<lottery>/draws.json). The intended production store is PostgreSQL; the data-access layer is the swap point. Derived JSON is regenerated from the canonical store and is never hand-edited.