A bid response can be valid JSON, satisfy every local field constraint, and still answer the wrong auction. Its id can belong to another request. Its impid can name an impression that was never offered. Its currency can sit outside the request's allowed set. None of that is visible in the response alone.
The same problem shows up one step earlier. OpenRTB integrations share field names without sharing one wire contract. The specification types many flags as integers. The IAB protobuf model types a set of those fields as booleans. Google's Authorized Buyers JSON adds its own serialization. Prebid Server's publisher-facing auction adds bidder selection and stored requests. A value that is acceptable at one boundary is a useful diagnostic at another.
That is why "is this OpenRTB valid?" is the wrong question until the check names four things: the specification snapshot, the wire encoding, the integration direction, and whether an originating request was supplied. The November 2026 preprint RTBLint: Executable, Versioned Contracts for OpenRTB Interoperability evaluates one frozen implementation of that idea, RTBLint 0.14.7. It is an author-review preprint. It has no archival DOI. The PDF is also on OpenAdTech, which is where the earlier OpenRTB measurement papers live: openadtech.org/papers/rtblint-executable-versioned-contracts-for-openrtb-interoperability-sekowski-2026.pdf.
What the contract actually selects
The checker keeps three inputs apart.
| Input | What it is | What a missing one means |
|---|---|---|
| Original bytes | The payload string, with its width and a SHA-256 | A rewritten body is a different message |
| Declared context | Snapshot, encoding, profile, direction, payload role | "OpenRTB 2.6" does not name which dated revision, or which boundary |
| Available evidence | Originating request, or another supplied local artifact | A response-only check cannot test impid membership or currency against a request it never saw |
Profiles are not a stricter schema stacked on the canonical one. A profile can add requirements and it can authorize a documented exception. The paper's witness is a Google fixed-price request: the canonical catalog rejects the auction type, and the Google profile authorizes it. The same profile can still reject a request that omits a documented integration field. Fewer findings are not automatically a better result.
The boolean valid is true only when the selected checks return no error-severity finding. Warnings can carry useful evidence without forcing rejection. A clean boolean also cannot, by itself, tell a fully applicable pass from a warning that the scope was unsupported. The context, the diagnostics, and the coverage boundary have to travel with the result. The tool that ships that behavior is RTBLint.
What 0.14.7 agrees with
The evaluation splits development evidence, author-derived protocol tests, and externally authored receiver fixtures. These directed cases do not estimate production accuracy.
| Comparison | What frozen 0.14.7 did |
|---|---|
| 77 original cases inside common scope | Agrees with 75 stated expectations. The two disagreements are malformed Native JSON reported as warnings. A separately implemented schema checker, given the same context, agrees with all 77. |
| 792-case seeded challenge | Eight further decisions trace to two omitted protobuf root flags. A two-field research patch repairs those failures. The patch is identified as a research candidate, not as the frozen release. |
| Candidate gate with an explicit Native-warning policy | Agrees with all 80 original binary labels and all 792 reviewed challenge labels, and marks five original scope controls indeterminate. |
| 140 Prebid Server fixtures, four predeclared suites | Accepts 27 of 34 expected acceptances and rejects 57 of 106 expected rejections. That is agreement with 84 of 140 maintainer-authored HTTP expectations. |
| Same 140 fixtures, production-handler replay | Matches all 140 HTTP expectations. |
| 34 accepted transactions, request side | Passage under the same Prebid contract rises from 27 before normalization to 32 afterward. |
The schema comparison is the mechanism result. Once a separate checker receives the same context, the advantage over a context-free schema is attributable to the supplied context and the implemented obligations.
The Prebid comparison is the practical limit. The 56 differing static decisions stay in the artifact. Six of the seven rejected positive fixtures produce relocated-field findings under the selected 2.6 contract: all-ext.json carries regs.ext.gdpr and user.ext.consent, and the checker points at regs.gdpr and user.consent. The suite includes explicit 2.5/2.6 conversion fixtures, so a normalized 2.6 contract at raw ingress is a different claim from the one the handler makes. The disagreements are normalization, configuration, and unimplemented receiver rules.
What the timing measurement is
Native and WASM agree on 3,846 byte-identical release cases. Eleven shuffled blocks on the same M4, in macOS and Linux environments, put one-request median block p95 at 2.13 microseconds and 1.92 microseconds. That figure is the cost of the frozen interfaces on that machine.
Where to read it
The preprint, the figure, and the frozen-release link are on the OpenAdTech research page. The same PDF is hosted there directly, so the citation opens without an account. The ResearchGate record is publication 417773206.
Two earlier preprints on that same page ask the questions this one cites them for. How Machine-Checkable Is OpenRTB? classifies how much of the specification any validator can enforce. Measuring OpenRTB Dialects in Client-Side Header Bidding measures one slice of live client-side traffic. This paper evaluates a frozen checker, and those two measure the document and one traffic sample.
The shipping tool is at rtblint.org. The paper studies commit 4defcb383729e20147a82ca5737974be03426192. Later releases are a different artifact.
