VAST 4.4 Shipped Without Anyone Announcing It, and It Is Still a Draft

There was no announcement, because it is not a release

On 17 July 2026 a file called vast_4.4.xsd was merged into the IAB Tech Lab VAST repository, from a branch named 4.4Development. There was no press release. There is no entry in the repository's release notes. The README still describes 4.2 as the most recent release. The schema's own annotation, sitting in the file, reads: IAB VAST (Video Ad Serving Template), Version 4.4 - DRAFT for working group discussion.

Five days later, on 22 July, something else did finalise: the CTV Ad Portfolio signaling guidance, after a public comment period that closed on 5 June. We covered that work in July when it was still in comment. It is now a standard.

Those two facts arrived in the same week and are constantly being conflated. They should not be. One is a finished standard that tells you how to buy and sell six CTV formats. The other is a working draft of the XML schema those formats happen to need. Treating the draft as a release is how teams end up shipping tags that get rejected.

Do not put 4.4 in your version attribute

This is the practical takeaway and it is worth stating before anything else. Every single VAST example in the IAB's own final signaling guidance declares version="4.2". Not one declares 4.4. Those examples use the new NonLinear content model while sitting on a version attribute the ecosystem has supported for seven years.

That is not an oversight. The deployed base is on 4.2 and 4.3. Telling implementers to bump to a draft version number would be worse advice than what the guidance actually gives, which is to use the new constructs on the versions players already accept. A player that version-gates strictly will reject a 4.4 tag outright, and you gain nothing in exchange.

So: build the new content model, keep the old version string. VASTlint recognises 4.4 rather than treating it as a garbled version, and reports it at info severity to say exactly this.

What the draft actually changes

The CTV Ad Portfolio standardises six formats that have been running in market for years on bespoke, per-publisher integrations: Pause, Screensaver, Overlay, Squeezeback, In-Scene, and Menu. Menu ads transact through the OpenRTB Native object and never touch VAST. The other five land in NonLinearAds.

That is why a node which had barely moved since VAST 2.0 suddenly grew a content model. Before this, a pause ad was a JPEG in a StaticResource. NonLinear now accepts the same MediaFiles container as Linear, holding MediaFile, Mezzanine, InteractiveCreativeFile and ClosedCaptionFiles.

The content model changes, in full

• MediaFiles under NonLinear. Video, cinemagraph, and interactive assets in placements that previously accepted a single static image.
• Duration under NonLinear. This is what makes quartile and overlayViewDuration tracking possible. Optional for static image creative whose display time is genuinely unknown at response time, but a video MediaFile has a known duration by definition.
• Icons under NonLinearAds. A pause ad can now carry an AdChoices disclosure.
• NonLinearCustomClick returns, after being absent from every published XSD since 3.0.
• SIMID moves into the NonLinear MediaFiles container as InteractiveCreativeFile apiFramework="SIMID". The guidance calls the previous IFrameResource pattern not recommended for these formats.
• Extension gains typed AdCOM payloads: plcmt, pos, playbackmethod and attr, all integers.
• CreativeExtension gains typed QR code elements: scan URL, image URL, position and size.
• minSuggestedDuration retyped from xs:time to vastTime_type, so mm:ss and milliseconds are now valid.

The fallback is not optional in practice

The split between MediaFile and InteractiveCreativeFile exists for a reason. MediaFile is a renderable asset. InteractiveCreativeFile is a separate interactive layer that requires the player to execute SIMID. A player that cannot run SIMID renders the MediaFile instead. A player that has neither fires the error URI, and the impression is gone.

SIMID support across CTV devices is nowhere near universal. Shipping an interactive-only NonLinear is therefore a quiet way to no-fill a large share of your install base, with no error in your own logs to explain it. The guidance spells out the fallback behaviour explicitly, which suggests the working group expected people to skip it.

The part driven entirely by an OpenRTB problem

The strangest change on paper is the typed AdCOM payload inside Extension. VAST elements do not normally carry bid-request enumerations. This one does, and the reason is structural: the VAST response often travels further than the bid object does.

An SSAI stitcher or a measurement vendor sitting downstream of the original RTB transaction never sees the bid. It sees a creative. Without the format context, it has no way to know whether the thing it is about to render is a pause ad in a fullscreen treatment or an overlay in the lower third, and no way to verify that the creative matches what was bought. So the DSP echoes the context back into the creative itself, one signal per Extension, marked ext="adcom".

The values you need, because the guidance scatters them across four tables

• plcmt gains 5 Pause, 6 Screensaver, 7 Overlay, 8 Squeezeback, 9 In-Scene. Values 1 to 4 predate the portfolio.
• playbackmethod gains 8 and 9 for Pause with sound on and off, 10 and 11 for Screensaver with sound on and off. Overlay, Squeezeback and In-Scene reuse the existing 1 and 2.
• pos extends past the old 0 to 7 ceiling: 7 and 8 for fullscreen and partial Pause and Screensaver, 5/9/10/14/15 for Overlay geometry, 11/12/13/16/17 for Squeezeback layouts. Observed ceiling is 17.
• attr gains three motion attributes: 21 Static Visual, 22 Limited Motion (Cinemagraph), 23 Full-Motion Video.

The motion attributes are the commercially interesting part

Everything above is plumbing except attr 21, 22 and 23, which solve a real problem the bidstream could not previously express.

A publisher may technically support delivery of a video/mp4 file while expecting a static experience in the placement. A pause placement that renders an MP4's first frame as a still image, for instance, or one designed for cinemagraph-style limited motion rather than full-motion video. Under the old model there was no way to say that: MIME type and protocol signaling describe what the placement can decode, not what experience it will actually produce.

Now a publisher sets battr: [22, 23] to block motion creative while still accepting MP4 delivery, and the DSP declares what it actually sent with attr. Supply-side experiential constraints become separable from technical format support. That is a genuinely new capability, not a schema tidy-up.

Where the draft schema is wrong, and why it matters

Two things in vast_4.4.xsd should not be treated as normative, and both are visible from a diff.

First, it is not a superset of 4.2. The draft was rebuilt by hand from the 4.2 XSD rather than diffed against it, and AltText, BlockedAdCategories, Expires, IconClickFallbackImage and IconClickFallbackImages all vanish. Nothing in the CTV Ad Portfolio guidance removes them. No IAB communication announces it. These read as omissions from a hand-authored draft, not deprecations, and anyone who treats the file as authoritative will start stripping valid elements out of working tags.

Second, it makes Extension/@type required and restricts custom Extension children to the ##other namespace. In the 4.2 XSD, type is optional and custom children use processContents="skip". Enforcing the draft here would invalidate a decade of deployed vendor extensions in one step. That is not a change a working group makes silently, which is a strong hint it was not intended as one.

One trap that will catch people

The QR code block is small, easy to implement, and has a type mismatch waiting in it.

Icon types its xPosition and yPosition as vastIntegerOrPercent_type, so xPosition="120" is perfectly valid there and has been for years. QrCodePosition types the same-named attributes as vastPercent_type. The identical markup is invalid. CTV screens vary too much in resolution for pixel coordinates to carry meaning, which is presumably the reasoning, but anyone generating QR blocks by adapting existing icon markup will produce something that looks right and is not.

The published examples have three defects

Working through the guidance to build validation, we hit three problems in the examples themselves. The Screensaver cinemagraph example closes its Extensions block with a stray extra closing tag, so it does not parse. One Overlay example carries attr 20, which is not one of the three motion attributes the same document defines. One template still reads version="INSERT VAST VERSION".

None of these are serious, and all three are the kind of thing that survives a comment period because reviewers read prose more carefully than they read example XML. We filed them upstream. They are worth knowing about if you are copying markup out of that document, which most implementers will be.

What we shipped

VASTlint now recognises version="4.4" and validates the CTV Ad Portfolio content model, with 17 new rules in a dedicated category. The catalog is 212 rules.

The severity design follows the split at the top of this post. Rules derived from the finalised signaling guidance carry normal weight. Rules derived only from the draft schema stay at warning or info, because a draft can still change and a validator that errors on a moving target is worse than no validator. The only errors are constructs malformed under any reading of any version: a non-integer AdCOM payload, a QR position expressed in pixels.

The new NonLinear content model is accepted on any VAST 4.x document rather than only on 4.4, precisely because the IAB's own examples ship it on 4.2 tags. Gating it on the version attribute would have meant rejecting the ecosystem's actual conforming traffic in the name of a draft schema. VAST 3.0 and below are unchanged, and a regression fixture guards that.