Blog · Spec release

AdCOM 1.0-202607: new enums, five redefined playback methods, and two releases carrying the wrong field names

July 30, 2026 · RTBlint

AdCOM is where OpenRTB 2.6 keeps its enumerated lists. When a bid request sends video.plcmt or video.pos or video.playbackmethod, the integers mean whatever the current AdCOM document says they mean, and OpenRTB itself only holds a link. AdCOM 1.0-202607 was tagged on July 16, 2026. It adds the enumerations behind the CTV Ad Portfolio formats, it rewords five playback methods that already existed, and it carries a Content object with seven field names that are not AdCOM's. The names were corrected on the main branch six days later. The tag was not re-cut, and neither was the one before it.

What the release adds

The substantive change came in through a single commit from June 25 titled "Ad Format Signaling Enumeration Updates," and it extends four lists. These are the machine-readable half of the CTV Ad Portfolio work whose signaling guidance was finalized on July 22.

List: Creative Attributes
  19  Contains advertiser QR Code
  20  Support alpha channel transparency
  21  Static Visual
  22  Limited Motion (Cinemagraph)
  23  Full-Motion Video

List: Plcmt Subtypes - Video
  5  Pause      6  Screensaver   7  Overlay
  8  Squeezeback            9  In-scene

List: Placement Positions   (was 0 through 7)
  8  Partial Screen         9  Top Left        10  Top Right
 11  Frame the content     12  Double box      13  Double box with background
 14  Bottom Left           15  Bottom Right    16  L shape
 17  Reversed L shape

List: Playback Methods      (was 1 through 7)
  8  Initiated by user pausing content, Sound on
  9  Initiated by user pausing content, Sound off
 10  Initiated by idling (e.g. screensaver), Sound on
 11  Initiated by idling (e.g. screensaver), Sound off

Nothing controversial there. A pause ad needs a way to say it is a pause ad, a squeezeback needs a way to describe an L shape, and a cinemagraph is genuinely neither a still nor a video. The creative-side view of these formats is covered in vastlint's piece on the VAST 4.4 draft schema.

Five playback methods changed meaning without changing number

The additions are the easy part. In the same diff, five values that have been in use for years were reworded.

1  was: Initiates on Page Load with Sound On
   now: Initiates without any specific user interaction with Sound On

2  was: Initiates on Page Load with Sound Off by Default
   now: Initiates without any specific user interaction Sound Off by Default

4  was: Initiates on Mouse-Over with Sound On
   now: Initiates on Mouse-Over or cursor over with Sound On

5  was: Initiates on Entering Viewport with Sound On
   now: Initiates on Entering Viewport or scrolling into view with Sound On

6  was: Initiates on Entering Viewport with Sound Off by Default
   now: Initiates on Entering Viewport or scrolling into view with Sound Off by Default

The direction is deliberate and reasonable. "Page load" is browser vocabulary that never described a television, so values 1 and 2 were generalized to cover any initiation without user interaction, and 4, 5 and 6 picked up the cursor and scroll phrasing that CTV remotes and feed surfaces actually need. Nobody was going to spend a new integer on that.

It still means a seller who implemented playbackmethod: 1 against the old text and a seller who implemented it against the new text are making different claims with the same byte, and a buyer cannot tell which. This is the same shape as the content.livestream redefinition in OpenRTB 2.6-202606 and the same shape as the plcmt migration: a good correction landing on an enforcement layer that has no way to reject a stale interpretation.

The timing is worth noting. The Redefining Media Types standard is in public comment until August 8, and its sound-state attribute maps onto exactly these five values. The definitions underneath that mapping moved on July 16, in a different repository, three weeks into a thirty-day comment window.

The Content object in both current releases has the wrong field names

AdCOM has always used short field names on its own objects. OpenRTB 2.x uses longer ones for the same concepts. Content.rating in AdCOM is Content.contentrating in OpenRTB, live is livestream, lang is language, and so on. Two documents, two naming conventions, deliberately.

On March 20, 2026, a commit titled "Live Attributes to Object: Content" added the new live signals to AdCOM's Content object. It also converted that object's table from HTML to markdown, and in the rewrite seven existing field names were replaced with their OpenRTB spellings.

AdCOM name    became        reverted on main 2026-07-22
------------------------------------------------------
rating        contentrating         rating
urating       userrating            urating
mrating       qagmediarating        mrating
live          livestream            live
srcrel        sourcerelationship    srcrel
lang          language              lang
embed         embeddable            embed

The commits that fixed it are titled "revert inadvertent name changes" and "Revert Inadvertent Content Object Name Changes," so the working group is clear about what happened. A second commit the same day standardized the type column from int to integer, which is a smaller version of the same problem for anyone parsing that column.

Here is the part that matters. The rename shipped in AdCOM 1.0-202606, tagged June 11, and in AdCOM 1.0-202607, tagged July 16. The fix landed on main on July 22 and 23. Neither tag has been moved, so as of today both of the two most recent AdCOM releases describe a Content object with seven fields AdCOM does not have, and the corrected text exists only on an untagged branch.

If you generate anything from a tagged release, which is the normal and correct thing to do, you generated the wrong names. If you read the document in a browser this week, you read the right ones. Those two facts coexisting is the whole hazard.

Why a pipeline notices this and a reader does not

Seven renamed rows inside a two-hundred-row object, in a document nobody reads end to end, introduced as a side effect of a table format conversion, is close to invisible to review. It stayed in for four months and two releases.

It is not invisible to anything that parses the document into a catalog and diffs the catalogs release over release. That is what our AdCOM handling and the generated JSON Schemas exist to do. Table format conversions are a recurring source of this: an object rewritten from HTML into markdown can come out with an empty field list, which is loud and gets caught immediately, or with seven fields under different names, which is silent unless something is comparing the before and the after.

The general lesson for anyone maintaining bidder code against these documents: pin the release you generate from, diff every new release against the last one at the field level rather than reading the changelog, and treat a rename as a breaking change even when the changelog does not mention it. The changelog for 202607 does not mention this one, because nobody intended it.

What our own validator does with the new values today

Worth being straight about this, because it is the flip side of the same problem. Our AdCOM value sets predated 202607, so until we published this post a perfectly valid pause-ad bid request failed validation against the newest snapshot. Four errors, all of them ours:

openrtb.value.invalid  error  imp[0].video.plcmt
    has unsupported value 5. Allowed values from List: Plcmt Subtypes - Video
    are 1, 2, 3 or 4.
openrtb.value.invalid  error  imp[0].video.pos
    has unsupported value 14. Allowed values from List: Placement Positions
    are 0, 1, 2, 3, 4, 5, 6 or 7.
openrtb.value.invalid  error  imp[0].video.playbackmethod[0]
    has unsupported value 9. Allowed values from List: Playback Methods
    are 1, 2, 3, 4, 5, 6 or 7.
openrtb.value.invalid  error  imp[0].video.battr[0]
    has unsupported value 19. Allowed values from List: Creative Attributes
    are 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18 or >=500.

That is fixed as of today. The four value sets now carry the 202607 ranges, the tester and the MCP endpoint are running the rebuilt validator, and the enum reference lists the new values and flags the five reworded playback methods. Values outside the new ranges still fail, so plcmt: 10 and pos: 18 are still errors.

Saying so is cheaper than the alternative. A validator that is quietly out of date on an enum tells you your good traffic is broken, which is worse than telling you nothing. If you pin a version of the CLI or the library rather than using the hosted tools, check that you are on a build dated after this post.

What to do about it

Do not generate from AdCOM 1.0-202607 or 1.0-202606 without checking the Content object. Both tags carry the seven renamed fields. Compare against main, or against 1.0-202409, which has the correct names.
Accept the new enum values on the receive side now. A buyer rejecting plcmt 5 through 9 or pos 8 through 17 is rejecting the CTV formats sellers are actively trafficking, and the rejection looks like a no-bid rather than an error.
Re-read your playbackmethod mapping against the current text. If your documentation still says "initiates on page load," your implementation and the spec have diverged in wording even where they agree in intent.
Diff catalogs, not changelogs. The changes that hurt are the ones nobody wrote down, because nobody meant to make them.
Check a request against a pinned snapshot in the bid request tester, or gate it per the CI guide. Version pinning is the part of this that is entirely in your control.

Sources

AdCOM and OpenRTB are published by IAB Technology Laboratory under a Creative Commons Attribution 3.0 License. Field names, enumerated values and quoted definitions are drawn from those documents and from the public commit history of their repositories; the analysis is our own. Diagnostic output shown here was produced by RTBlint. RTBlint is independent and not affiliated with IAB or IAB Tech Lab.