VAST-4.4-adcom-pos-format-mismatch
AdCOM pos is not a position the declared plcmt format supports
Short answer
Each signal is inside its own enumeration and the set still contradicts itself. The guidance's Format-to-Signal Reference Table pairs each format with the positions it can occupy: Pause and Screensaver take 7 or 8, Overlay 5, 9, 10, 14 or 15, Squeezeback 11, 12, 13, 16 or 17. plcmt=5 with pos=12 says Pause and Squeezeback at once, and a publisher validating the delivered experience against its bid request sees a contradiction. In-Scene is exempt, its pos cell reads NA, and pos=0 means unknown and is accepted anywhere.
Why this matters in production
This rule is a strong risk signal. Tags with this issue often still parse, but they become brittle across SDKs, SSAI resolvers, and CTV environments. The CTV Ad Portfolio standardises Pause, Screensaver, Overlay, Squeezeback and In-Scene ads, which ran for years on bespoke per-publisher integrations. These rules cover the VAST side of that contract: the NonLinear MediaFiles delivery model, the AdCOM signals round-tripped into Extensions so stitchers can validate the experience without the bid object, and the QR code block. The signaling guidance is final; the VAST 4.4 schema that accompanies it is still a working-group draft, so anything sourced only from the schema is reported as a warning or a note. Affected scope: All VAST versions.
Invalid
<Extension type="plcmt" ext="adcom">
<plcmt>5</plcmt>
</Extension>
<Extension type="pos" ext="adcom">
<pos>12</pos>
</Extension>Valid
<Extension type="plcmt" ext="adcom">
<plcmt>5</plcmt>
</Extension>
<Extension type="pos" ext="adcom">
<pos>7</pos>
</Extension>VAST-4.4-adcom-pos-format-mismatch and other issues instantly.Open the VAST tag validator →