A vendor changes a price field from dollars to cents without telling you and every downstream number rises by a factor of 100. Give the contract clause and the automated check that would have caught it at the ingestion boundary rather than in a PnL report.

A vendor changes a price field from dollars to cents without telling you and every downstream number rises by a factor of 100. Give the contract clause and the automated check that would have caught it at the ingestion boundary rather than in a PnL report.

Approach: Write down what the producer promises beyond the field's type, then define a check on the data itself that fails when that promise is broken.

The data contract must carry a unit and scale declaration for the field, and the boundary check is a distribution check comparing today's median price per symbol against a trailing median, failing the load when the ratio leaves a stated band. A type of decimal(18,6) catches nothing here, because cents are a valid decimal. The clause has to state the semantic: price is quoted in USD per share at scale 4, and any change of unit requires a new contract version. The check that catches it in a single load is a ratio test, the median price today over the median price across the trailing 20 days per symbol, failing outside 0.5 to 2.0 across a broad universe, since no genuine market move multiplies the median of a thousand symbols by 100. Add a cheap absolute range assertion per instrument class as well, because a ratio test is blind on a symbol's first day. On failure the load is held under quarantine rather than published, so the file lands in a staging table, no consumer sees it, and the alert names the field and the observed ratio. Publishing first and correcting later is what turns a vendor mistake into a wrong PnL report somebody has to explain.

Follow-up: What check would catch the same class of error when a vendor swaps close for previous close?

Key concepts: data contract, unit and scale declaration, distribution check, quarantine on failure.