VAST-4.4-adcom-extension-type-mismatch
<Extension> type attribute and AdCOM payload element name disagree
Short answer
The type attribute names the signal and the child element carries its value. Consumers key off type to decide what to read, so <Extension type="pos"> wrapping a <plcmt> payload will have the wrong value read for the wrong field, or be dropped entirely.
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="pos" ext="adcom">
<plcmt>5</plcmt>
</Extension>Valid
<Extension type="plcmt" ext="adcom">
<plcmt>5</plcmt>
</Extension>VAST-4.4-adcom-extension-type-mismatch and other issues instantly.Open the VAST tag validator →