OQ-4 — The format registry has no entries for audio/*, ctv/* or dooh/*

Spec: § 5.4 · OpenProposal 3.0 draft 1 (§ 8, question 4)

specs delegates to a registry that cannot currently answer for half the
declared channels. Either the registry is extended before 3.0 ratifies, or the
spec has to say what an agent does when a format id has no registry entry.

What would settle it: a commitment and timeline on registry coverage, or a
proposed fallback behaviour.

This is the tracking issue for open question 4. Answer it here, in the comments. Evidence from implementation or real inventory carries the most weight (comment process).

Comment period: 2026-09-22 → 2026-10-22. This repository is public, so anonymise any examples.

Implementation feedback from an in-app supply-side exchange (mobile + CTV), running the seller side of AAMP and AdCP today.

The registry gap is wider than audio/*, ctv/* and dooh/*. The mobile in-app formats that carry most app revenue — rewarded video, interstitial (display and video), playable, MREC, app-open and native in-app — have no registry entries either. And channel has no value for "mobile app" distinct from display / video: a rewarded video is a video and a reward-gated placement type, and the placement type is what buyers price on (rewarded and interstitial of the same duration clear at very different rates).

Two ways to close it, either of which we would implement:

A placement_type field on the line item (banner · interstitial · rewarded · native · app_open · playable), orthogonal to channel, so a rewarded video is channel: video, placement_type: rewarded.
Registry ids namespaced by placement (app/rewarded-video-30s, app/interstitial-display) with the registry, not the object, carrying the shape — consistent with how §5.4 delegates specs today.

We can contribute the in-app format list and their specs from a live catalog as a starting set if the registry maintainers want one.

Adding the CTV in-stream side here, building on the in-app comment above and on #32.

Fallback. I agree with the rule in [Change] § 5.4 — Validate assets[].format_ref against the resolved formats selection at submission, not at creative review #32 that a format id resolves through either a registry entry or an inline specs entry keyed by that id, which lets 3.0 ship before registry coverage is complete. [Change] § 5.4 — Validate assets[].format_ref against the resolved formats selection at submission, not at creative review #32 applies the rule when an asset is submitted, and I think the same rule is needed earlier, at discovery and composition, before any asset exists:

When a selected format id resolves to neither a registry entry nor an inline specs entry, an agent MUST report it as unresolved, using the error shape proposed in [Change] § 5.4 — Validate assets[].format_ref against the resolved formats selection at submission, not at creative review #32 with a new reason value, format_unresolved. It MUST NOT derive specs from the id string (ctv/instream-15s gives a duration and nothing else), substitute a generic video format, or report creative compatibility as validated. Because specs cannot change after agreed (§ 3) and [Change] § 5.4 — Validate assets[].format_ref against the resolved formats selection at submission, not at creative review #32 rejects assets whose format_ref does not resolve, a line item MUST NOT reach agreed while a selected format id is unresolved. If a seller wants to reach agreed before a registry entry exists, it can declare the inline specs.
What a ctv/ in-stream entry needs to carry, whether it lives in the registry or inline. On SSAI lines (§ 6.3 is serving_mode: ssai, creative_delivery.protocol: vast_4_2) the stitcher transcodes the creative to match the content stream and caches the result. So most of what decides whether an ad actually airs comes down to the source file and the creative's identity, more than duration and dimensions. Suggested keys below; the values are only illustrative.

   specs:
     "ctv/instream-15s":
       duration: { nominal_s: 15, tolerance_ms: 500, over_tolerance: reject }   # reject | trim
       source: vast_mezzanine           # vast_mezzanine | vast_mediafile | file_upload
       mezzanine: { required_for: [ssai], min_resolution: "1280x720", codecs: [prores_422, h264] }
       frame_rates: [23.976, 25, 29.97] # progressive
       loudness: { standard: atsc_a85, target: -24, tolerance_db: 2, seller_normalizes: false }   # atsc_a85 | ebu_r128
       creative_id: { universal_ad_id: required }
       first_impression: pretranscode_required   # pretranscode_required | skip_until_transcoded
       pretranscode_lead_time: "PT24H"
       interactive: { vpaid: false, simid: player_dependent }
       verification: { ad_verifications: player_dependent }   # executes | not_executed | player_dependent

A few notes on why these keys:

source and mezzanine line up with the VAST 4.x <Mezzanine> file, which exists for server-side transcoding.
creative_id and first_impression matter because stitchers cache transcodes under a creative key (often <UniversalAdId>, sometimes the media file URL) and commonly skip an ad that has not been transcoded yet. A missing or unstable key ends up as unserved first impressions, which buyers usually notice as early under-delivery.
loudness names the standard because the US and EU targets differ (ATSC A/85 and EBU R128).
interactive is there because VPAID does not run in a stitched stream, and SIMID depends on the player.
verification is there because whether <AdVerifications> code runs at all on a stitched line limits which measurement_source options a seller can honestly offer, which ties this back to § 5.7.

The values themselves should come from IAB Tech Lab's Ad Format Guidelines for Digital Video and CTV rather than be redefined here, with the registry entry pointing to them.

On the either/or question above: CTV has the same split, between in-stream and the non-in-stream units in Tech Lab's CTV Ad Portfolio (pause, menu, overlay, squeezeback, in-scene, screensaver). My preference would be namespaced ids such as ctv/pause, since that keeps the shape in the registry the way § 5.4 already intends and avoids adding a second discriminator next to channel. Whichever way the group goes, it would help to settle it once for both the in-app and the CTV cases.

On coverage, could the working group name an owner and a target date for at least ctv/instream-15s and ctv/instream-30s, the two ids used in the § 6.3 example? If those will not be in the registry by ratification, the inline path in item 1 covers the gap in the meantime.

Commenting in a personal capacity. Product leader in CTV, identity and data; I have led teams that built DSP bidding, household identity graphs, and CTV ad insertion and monetization platforms. I maintain OpenCTV, an open-source, non-commercial project on CTV ad delivery diagnostics.

support the fallback in #32 and the discovery-time rule proposed above: a format id that resolves to neither a registry entry nor inline specs MUST be reported as unresolved, and the line item MUST NOT reach agreed while it stays unresolved. Without that, 3.0 cannot carry a CTV- and audio-heavy seller's line items at ratification.

On audio/*, the registry needs to separate two kinds of format, because they fail in different ways:

Produced spots (audio/produced-30s in § 6.4; buyer-supplied file): duration and tolerance, file and encoding requirements, loudness standard, any companion display unit, and insertion method for streams. These look like the CTV in-stream entries above, and that shape adapts directly.
Host-read, live-read and talent-voiced spots (audio/host-read-30s in § 5.4 and § 6.4): there is no buyer audio file. The buyer supplies a script or talking points; the seller declares read length or word count, language of the read, live vs. pre-recorded, script-approval rounds and lead time, and whether talent endorsement is allowed. Today most of that has no home except production and approval.

A host-read registry entry should therefore declare which kind of asset the buyer supplies (a script, not an audio file). Otherwise #32's submission-time validation would reject a valid script for not being an audio file.

Could the working group name an owner and target date for audio/produced-30s and audio/host-read-30s, the two ids used in the § 6.4 example, alongside the CTV ids requested above?

Commenting as: seller. OUTFRONT Media, US out-of-home media owner (roadside static and digital, transit). Cites v3.0-draft-1.

Support the fallback in #32 and the discovery-time rule above. Adding what dooh/* entries need, since that side hasn't been covered yet.

What a dooh/ entry needs to carry, in the registry or inline:

Resolution and orientation per screen type. These vary by network and often by venue within a network.
Media type: static image or video, and whether motion is allowed at all. Roadside digital billboards are commonly limited to static images.
Max duration, which has to fit the slot length ([Comment] § 5.2, § 5.6 — Support share-of-voice and digital screen loop constraints #79, [Change] § 5.2, § 5.5 — DOOH properties: venue type, screens, operating hours, and loop #96). A 15-second file can't run in a 10-second slot.
File type and max file size.
Audio allowed, which is usually no.
Approval lead time. DOOH copy goes through the media owner's review, and on transit inventory often the transit authority's as well.

Static OOH has the same problem bhillman raises for host-read audio: there is no digital file. The buyer supplies print-ready art, and the seller declares print size, material, bleed and the date materials have to arrive at the plant. If #49 adds ooh as a channel, its registry entries need to say the asset is printed material, or #32 will reject valid artwork.

For coverage, start from the existing OpenOOH creative format work rather than a new list. Could the working group name an owner for dooh/* alongside the CTV and audio ids requested above?

Commenting as: Adgentek — buyer (AdCP-native buy-side / ORCA) and seller (publisher ad server / CTV path). Cites v3.0-draft-1 § 5.4, § 5.5, and the § 6.3 CTV example (examples/line-item-ctv.yaml). Related: #99 (break/pod as priced options), #98 (exclusivity).

Support the #32 fallback and the discovery-time format_unresolved rule already argued on this thread.

Adding CTV merchandising that still needs a home for ctv/* (registry or inline), beyond the SSAI/mezzanine/loudness keys already sketched above:

Pods and break position. Buyers price first-in-pod, pre-/mid-/post-roll, max ads in pod, and pod duration as hard product attributes, not footnotes. [Change] § 5.2 — Sell break position and pod slot as priced options: pre-roll, mid-roll, first in pod #99 puts break_position / pod slot on § 5.2 as selectable priced options (AdCOM delay / podseq / slotinpod / maxseq / poddur). A ctv/* format entry should still declare which of those options are valid for that unit (e.g. mid-roll in-stream vs pause), so format selection and [Change] § 5.2 — Sell break position and pod slot as priced options: pre-roll, mid-roll, first in pod #99 options stay consistent.
Competitive separation inside the pod. Distinct from deal-level exclusivity in [Change] § 5.6 — Give cancellation_policy and exclusivity options a typed shape #98 / § 5.6. Sellers routinely enforce category or brand separation within a break (min ads or seconds between competitors, sometimes vs the content brand). Buying agents need that as a typed promise or selectable option, not free text. Without it, two “valid” CTV lines can collide in the same pod after agreed.
Deduplication. CTV clears on household more often than device (§ 6.3 example; § 5.5). Format or targeting terms should make explicit: (a) frequency basis (household vs device), (b) whether frequency/dedup spans properties or apps in the package, and (c) whether the SSAI path dedupes the same creative / advertiser within a session or pod. Missing (c) shows up as repeated creatives and early under-delivery that look like forecast error.
Do not collapse CTV into generic video/*. A 15s in-stream CTV unit and a 15s app interstitial clear differently, fail differently, and take different creative. Keep channel ctv and registry ids under ctv/ (aligned with namespacing non-in-stream units like ctv/pause as proposed above).

Agree that starter coverage of ctv/instream-15s and ctv/instream-30s (the § 6.3 ids), plus unresolved-must-not-agree, is enough for 3.0. If the working group picks someone to own the ctv/* registry entries, I’m happy to pressure-test a draft of ctv/instream-15s / ctv/instream-30s against real CTV packages we see in market.

@franks33

Thanks, @franks33. A small correction on point 2: our exclusivity change request (#98) already covers separation inside the pod. Its exclusivity term takes separation: pod, alongside page, stream, episode, and inventory, with categories and competitors[] naming who is kept out. It is a selectable, priced term on the line item (the term's keys).

Two parts of your point go beyond #98:

Minimum spacing, in ads or seconds, between competitors in the same break. [Change] § 5.6 — Give cancellation_policy and exclusivity options a typed shape #98's term keeps them out of the pod entirely.
Separation from the brand of the content itself.

Separation that a seller applies to buyers without a term stays with the ad server at serve time, as #98 says. Its open question 5 asks whether the buyer declares its advertiser domain and category for that.

Analyzed and generated with the help of Claude, fully reviewed by me.

Implementation evidence for the discovery-time rule above. In our tests on an unreleased seller-agent branch (IABTechLab/seller-agent, feat/openproposal-mapping at e77022e), the synthetic format id dooh/portrait-1080x1920-10s resolved to no registry entry and no inline specs. The branch's many-to-one builder carried it into supported_formats, and its line-item model accepted it, without reporting it as unresolved. That's the case the rule above, with #32's fallback, would catch. #134 has the details.

The list premesh gives above covers what a dooh/* entry should carry, including a maximum duration that fits the slot. Most of what defines a DOOH buy isn't a format property, though: venue type, screen location, loop length, share of voice and impressions per play. #96, #93 and #92 draft homes for those, so dooh/* entries only need to cover the creative side.

OQ-4 from the audio side: proposed audio/* registry entries, a host-read requirements object, asset provenance, and a fallback rule

I'm commenting as an individual. I've sold media for 16 years, including at Oracle Advertising, and this year I built an MVP that checks AI-generated audio ads against a brand's standards before they air.

The § 6.4 audio example lets a buyer agent select audio/host-read-30s at +$9.00 CPM, cap frequency per listener and commit $60,000 without a round trip. Nothing in that commitment describes the spot. With no audio/* registry entry, specs resolves to nothing, so the agent has bought a host read with no machine-readable way to state what the host must say or how the brand name is pronounced. In my MVP's test run, the defect with the most media spend behind it was a synthetic voice mispronouncing a founder's name in a script that was correct on paper, which script review can't catch.

I'd propose four changes.

Seed audio/* entries before 3.0 ratifies. At minimum audio/produced-15s, audio/produced-30s, audio/produced-60s, audio/host-read-30s and audio/host-read-60s. Each entry's specs should declare duration and tolerance, container and codec, sample rate, an integrated loudness target with a true-peak ceiling, any companion display unit, and delivery via VAST 4.1+ (adType="audio"), since VAST 4.1 absorbed DAAST.
Add a read_requirements object for host-read formats, marked supplied: { mandatory_copy[], prohibited_claims[], pronunciation_guide[], read_style: verbatim | talking_points, voice: human_only | synthetic_permitted }. In a host read the seller's talent produces the creative, so the buyer's requirements have to travel with the line item.
Add provenance to assets[]: { synthetic, generator, model_version, voice_consent_ref, disclosure_method, content_hash }. EU AI Act Art. 50 has applied since 2 August 2026: providers must mark synthetic audio in a machine-readable format, and deployers must disclose deepfake audio. An agent placing audio in the EU needs to know whether an asset is synthetic and how it's disclosed before it commits. The field is channel-agnostic, but audio is where synthetic voice is already in market.
Fallback for unregistered format ids. If formats.available[] contains an id with no registry entry, the line item MUST carry inline specs, and that option SHOULD be treated as requestable, so a buyer agent can't resolve it without seller assent. Today an unregistered format looks as settled to an agent as display/300x250.

CTV and DOOH need the same fallback rule. I'll leave their registry contents to people who sell those channels daily.

I'm filing within the extended comment period announced by IAB Tech Lab (closes 10 November 2026). The README and docs/comment-process.md still list 22 October, so please confirm this enters the formal record instead of being labelled post-comment.

@cdorsey88

@cdorsey88 +1 on the fallback rule for DOOH. Screen specs vary enough by venue and network (resolution, orientation, spot length, static vs motion, audio usually off) that some formats will always sit outside the registry, even with the dooh/* entries I proposed above. Inline specs plus requestable is the right default for those, so an agent can't treat an unregistered screen format as settled.

@cdorsey88

Postindustria (IAB Tech Lab member). @cdorsey88, @premesh: our formats PR covers the inline half of the fallback rule. Once a proposal leaves draft, every offered format has a format_specs entry that holds the whole spec, registered or not. It doesn't make those formats requestable, because the spec the seller states is already the term the buyer reads before committing. A spec can also state asset, what the buyer supplies, as an open vocabulary. A receiver that doesn't know a term treats that format as unavailable. read_requirements and provenance stay here on #5.

Format spec keys proposed on #5 collects this thread's proposals by kind of format, credited to @Sirajmx, @fgranata, @unreconciled, @bhillman-TelevisaUnivision, @premesh, @franks33, @jaanijuk, and @cdorsey88. It's a starting point for registry entries, not spec text.

Analyzed and generated with the help of Claude, fully reviewed by me.

@KonstantinMirin

@KonstantinMirin thanks, that covers the fallback. With format_specs holding the whole spec for every offered format, the buyer reads the seller's stated terms before committing, so I'm dropping the requestable ask. Treating an unknown asset term as unavailable is the right default for the unregistered case.

Two host-read items stay here, and the audio/host-read-30s example in #152 doesn't cover either:

Voice and pronunciation. Nothing says whether a synthetic voice is permitted or whether the seller accepts a pronunciation guide with the script. I'd add two seller-stated spec keys: voice: human_only | synthetic_permitted and pronunciation_guide: accepted | not_accepted. The guide, the mandatory copy and the prohibited claims would travel with the script asset the buyer submits. That replaces my earlier line-item-level read_requirements object.
Provenance on assets[]: synthetic, generator, model_version, voice_consent_ref, disclosure_method, content_hash. § 5.4 — Formats and assets: pinned specs, what the buyer supplies, and how an asset was made (#87) #152 doesn't touch assets[]. EU AI Act Art. 50 has applied since 2 August 2026.

Happy to turn both into spec text against #152 before 10 November if that helps.

Add asset provenance and the seller's voice keys

@cdorsey88

Thanks, @cdorsey88. We made both changes in #152, so you can review them there:

voice and pronunciation_guide: the audio/host-read-30s example states both, and the key list credits you. § 5.4 leaves spec open, so they aren't rules. The guide, mandatory copy, and prohibited claims travel with the script asset, as you propose.
provenance: an OPTIONAL Asset key in § 5.4, with your keys. content_hash is content_digest, using the § 2.2 Digest. disclosure_methods[] is a list, because machine-readable marking and audience disclosure are separate duties.
Seller-built reads: assets[] in § 5.4 — Formats and assets: pinned specs, what the buyer supplies, and how an asset was made (#87) #152 holds them through built_by, so their provenance has a home. Buyer approval stays with our #32 comment.

We also checked Art. 50. It has applied since 2 August 2026, but the Digital Omnibus gives providers of systems already on the market until 2 December 2026 for Art. 50(2) marking.

Revised 2026-11-04: assets[] holds seller-built reads in #152.

Analyzed and generated with the help of Claude, fully reviewed by me.

Let assets record the creative the seller builds

Navigation Menu

Repository navigation

OQ-4 — The format registry has no entries for `audio/`, `ctv/` or `dooh/*` #5

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

OQ-4 — The format registry has no entries for audio/*, ctv/* or dooh/* #5

Description

Activity

fgranata commented on Sep 28, 2026

unreconciled commented on Oct 13, 2026

bhillman-TelevisaUnivision commented on Oct 15, 2026

premesh commented on Oct 23, 2026

franks33 commented on Oct 26, 2026

KonstantinMirin commented on Oct 26, 2026

jaanijuk commented on Oct 28, 2026

cdorsey88 commented on Nov 4, 2026

premesh commented on Nov 4, 2026

KonstantinMirin commented on Nov 4, 2026

cdorsey88 commented on Nov 4, 2026

KonstantinMirin commented on Nov 4, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

OQ-4 — The format registry has no entries for `audio/`, `ctv/` or `dooh/*` #5