Schema, provenance, and freshness

Call /v1/scry/schema before constructing SQL. It is the authority for enabled relations, their columns, and the current helper catalog.

Keep source-native IDs, timestamps, URIs, and provenance fields in result sets. Those fields make answers recoverable and auditable.

For freshness-sensitive work, check the relation metadata in /v1/scry/schema and source status in /v1/stats before treating missing rows as meaningful absence.

Each relation in /v1/scry/schema serves a computed extent: observed min and max event dates, observed gaps between loaded partitions, and known_holes declared with provenance. Read a surface's extent before time-series work — it is computed from loaded data, so it states exactly which intervals a query can see.

Where a source allocates sequential identifiers, completeness is measured, not estimated — held rows divided by identifiers the source ever allocated is exact per time window, and the result is published in that relation's coverage note. Reddit is the worked example: its post and comment ids are single global base36 counters, so Scry states per-era capture (for example ~99.6% of all comment ids from 2023-04 onward, with the weakest historical band identified by month). Knowing what a corpus does not hold is part of the answer: an empty result over a measured-complete window is evidence of absence; the same result inside a declared weak band means "not captured", and the schema tells you which case you are in.