Technical report
Detailed notes, interpretation, and operational boundaries
This section documents what the published evidence means, how it was produced, and where the interface deliberately avoids making a stronger claim than the data supports.
Validation boundary
Quality checks run before any row can influence a chart, aggregate, comparison, or forecast feature.
- 1,12,355 source variety rows were inspected in the current refresh; 1,12,316 passed validation and 39 were excluded.
- Non-positive prices, impossible minimum/representative/maximum ordering, exact duplicates, and values above the configured safety ceiling are rejected with explicit reason codes.
- Corrections and unresolved market references are recorded separately so a clean published count is never presented as proof that the source itself was error-free.
Aggregation and missingness
The public unit is a market, commodity, and report date; source varieties are retained as evidence but are not rendered as duplicate market rows.
- Representative price is arrival-weighted only when every retained variety reports arrivals; otherwise the median variety modal price is used.
- A missing report remains missing. The pipeline never converts an absent date or absent arrival quantity into a zero price or zero arrival.
- 6,376 published records carry a statistical anomaly flag; the flag is a review signal, not automatic proof of a bad source record.
Coverage and recency
Freshness and reporting consistency describe different risks and are shown separately throughout the product.
- 4 published series are stale and 36 contain a long reporting gap under the configured thresholds.
- Freshness counts calendar days from the dataset comparison date to a series' latest report; consistency measures how regularly the market reported during its active window.
- The prepared coverage currently spans 6 states, 75 districts, 112 markets, 14 commodities, and 89,665 prepared market-day records, covering 2024-08-16 through 2026-09-14.
Audit trail
Published counts, reason totals, manifests, and partition checksums make the transformation reviewable after each refresh.
- The data page exposes partition size, date range, and SHA-256 checksum so a downloaded file can be matched to this prepared release.
- Quality evidence is generated from the same artifacts the application reads; display totals are not maintained in a separate manual dashboard.
- A later source correction can change historical aggregates, so a snapshot date and generated timestamp accompany every release.