Tiers — the verifier's vocabulary

The thing you wrote is a well-formed query at all — parses, has a recognizable schema reference, and isn't structurally garbage.

No public-record incident anchored to this tier yet — see the lattice page for the verifier's mechanism on this class.

The columns you reference exist with the types you assume. No silent int↔string coercion; no column rename that drifted past you.

You won't materialize a null where downstream code assumes non-null. Renames don't leave dangling references that pass review.

Foreign keys point at real rows. Joins target columns that actually exist. Declared types match the warehouse — no phantom columns from a hallucinated schema.

Joins don't fan out unboundedly. Loops and recursion terminate. A boolean flag's meaning is consistent across every live consumer.

Two runs on the same data produce the same answer. No race condition, no ORDER BY drift, no batch-evaluation order changing eligibility downstream.

PII can't reach a public sink. Tainted data can't leak through a join, union, or aggregation. Sensitive labels propagate.

Numeric values stay inside their declared bounds. Phantom columns are refused. Timestamp joins handle DST and timezone discontinuities correctly.

PII tier survives every operator — no abstract over-approximation collapses to public when two sensitivity labels meet.

Two queries provably compute the same answer on every input. A refactor proven equivalent is a refactor that won't surprise you in production.