Reading generated fixtures critically

The setup

API examples come from one of two places: captured real traffic, or schema-driven generation. This collection's examples are generated — and knowing how to detect that saves you from building logic on top of fixture noise.

The tells (all machine-verified, see methodology)

1. Constraint violations between fields. capacityRangeLow: 8967, capacityRangeHigh: 219. A generator that picks each field independently can't respect cross-field invariants. 16 of the 28 examples' range pairs are inverted.
2. Domain-impossible values. "age": 4012. Type-valid (it's an int), world-invalid.
3. Cross-record incoherence. totalRows: 6141, validRows: 7799 — the subset exceeds the whole.
4. Structured noise in strings. Emails like COB@VlNWEiwDoHYOF.sgb — RFC-shaped, obviously random.

What generated data is still good for

Everything structural: field names, nesting, types, which endpoints return which shapes, status codes, error envelopes. That's why this site's reference pages are built from these examples verbatim — labelled Tier A.

What it's not good for — and what leaks through anyway

Never for semantics: ranges, magnitudes, realistic relationships. Where this site needs a meaningful walkthrough (the lifecycle simulator), it uses clearly-labelled Tier B — authored illustration values instead, and those carry no source citation because they have no source.

But here's the subtle part: even random generation leaks real constraints. Every score field across all 28 examples lands in 0–4 — random values don't do that unless the schema itself is bounded. That's audit check INF1, and it's the single inference this site permits itself, labelled as such.

The transferable habit

When you meet a new API's examples, run the four tells above before trusting any value. Structure: trust. Meaning: verify.