Schema version
also known as: schemaVersion · contract versioning
A stamp on every capture recording exactly which version of the Envelope contract, capture driver, answer normalizer and provenance layer produced it, so a stored Envelope from six months ago can be understood correctly even after the contract itself has evolved. Without it, a schema change silently reinterprets old data instead of leaving it honestly attributable to the version that wrote it.
In AI Search API
provenance carries schemaVersion, driverVersion, normalizerVersion and provenanceVersion on every capture, four independent stamps, because the Envelope shape, the acquisition logic, the answer parser and the provenance model can each change on their own schedule. A stored capture stays reproducible years later precisely because it names the exact software that produced it, not just the date. Diffing captures across a schema bump is then a deliberate migration decision on your side, never an invisible reinterpretation. A dashboard built on stored Envelopes can branch on these fields to know when older records need a compatibility path rather than assuming every stored capture parses identically.
"provenance": {
"schemaVersion": "…", "driverVersion": "…",
"normalizerVersion": "…", "provenanceVersion": "…"
}Related terms
See it in the product
Every definition here is enforced in the Envelope contract. Run a capture and read the fields yourself.