Research

The measurements behind the tools.

Two preprints ask questions the industry had asserted answers to but never measured: how much of the OpenRTB specification a validator can enforce even in principle, and whether structural validation is cheap enough to sit inside a live bid pipeline. Both publish their datasets and their code. Both are free to read here, with no account.

RTBlint·Preprint, ResearchGate·July 2026

How Machine-Checkable Is OpenRTB?

Classifying the Normative Content of the Protocol That Clears Real-Time Advertising

Aleksander Sekowski, Independent Researcher

OpenRTB is the wire protocol of open programmatic advertising, and it has no reference validator, no conformance test suite, and no formal normative language conventions. Neither OpenRTB 2.6 nor 3.0 references RFC 2119. This paper asks a question that had not been answered quantitatively: how much of the specification can any validator, of any design, actually enforce? It extracts every normative-keyword sentence from both specifications, screens them to genuine conformance statements, and hand-classifies each into four enforceability classes.

What it found

  • 417 normative sentences extracted from OpenRTB 2.6-202606 and 3.0, screened to 288 conformance statements and hand-coded into four enforceability classes
  • OpenRTB 2.6 is 53.5% statically checkable and 26% not machine-decidable at all; deduplicating repeated clauses shifts that to 45.7% and 31.8%
  • OpenRTB 3.0 inverts the profile: 50% of its conformance content is runtime behavior, only 27.3% is statically checkable
  • Across 16 releases from 2012 to 2026 the field surface grew from 167 to 417 while the required core grew from 16 to 22, leaving 94.7% of the protocol as optional surface settled bilaterally, off the wire
  • Two of the nine example payloads embedded in the 2.6 specification violate the document's own object tables, and have done so in every release since October 2022
  • A blind recoding of a 60-statement sample agrees with the author's labels at Cohen's kappa 0.77 to 0.79
VASTlint·Preprint, ResearchGate·April 2026

VAST XML Validation at Bid-Time Scale

Latency Analysis and Integration Patterns for Programmatic Video Pipelines

Aleksander Sekowski, Independent Researcher

Malformed VAST XML is a well-documented but structurally unaddressed source of impression loss in programmatic video. OpenRTB defines the protocol for real-time bidding but imposes no requirement on the structural validity of the VAST markup delivered in the bid response. This paper benchmarks whether structural validation can run inline inside a bid pipeline without material latency cost, compares the results against the IAB's own XSD schema validation, and analyses four integration points where it changes the economics.

What it found

  • A 17 KB CTV tag validates in 350 microseconds, 0.35% of a 100 ms bid window; a 44 KB tag in 2.1 ms, inside a typical creative-selection budget
  • 16,236 validations per second sustained on 10 cores, exceeding a mid-tier exchange's throughput on a single instance
  • XSD validation against the IAB's own VAST 4.2 schema is faster at 72 microseconds per tag, but its findings are entirely false positives: element ordering and VAST macro rejection that do not correspond to playback failures
  • Four integration patterns analysed: SSP bid response, DSP creative ingestion, SSAI stitch time, and an async observability sidecar
  • Concludes that inline structural validation is computationally feasible and its absence is a recoverable source of revenue loss

On the numbers in these papers. Each is a dated artifact and reports the tool as it stood at the time of writing. The April 2026 VAST paper describes a 108-rule catalog; the shipping catalog is larger now. That drift is expected and the papers are not retro-edited, because a benchmark that quietly changes after publication is not a benchmark. For what ships today, see the tool pages.