[KonstantinMirin]

What this changes

Draft 1 doesn't say whether specs holds a format's spec or only points at a registry entry, and a format id carries no version. A registry edit could change what an agreed line item requires. Nor can a line item say what the buyer supplies, who built an asset, or how it was made. This PR pins each spec in the record to one version and adds those three.

• § 5.4: specs becomes format_specs, a map from FormatId to FormatSpec. A FormatSpec holds the whole spec, and a spec_ref when the spec comes from a registry.
• § 5.4: spec_ref is an EntryRef (§ 2.2), so it names one exact version. A pinned spec equals that version's content, and the format id SHOULD match its <collection>/<entry_id>.
• § 5.4: once the proposal leaves draft, every offered format has an entry.
• § 5.4: a FormatId starts with the line item's channel.
• § 5.4: a spec MAY state asset, what the buyer supplies, and voice. A synthetic asset doesn't conform to voice: human_only.
• § 5.4: an Asset MAY state provenance: how it was made and how it's marked or disclosed.
• § 5.4: assets[] also records seller-built creative, through built_by.
• § 5.4: a receiver that finds a seller-built asset synthetic under voice: human_only reports that mismatch, naming the asset_id, the Digest of the bytes it reviewed, the spec key it conflicts with, and what was observed. The report never changes provenance. This follows @cdorsey88's evidence from their checker.
• § 5.4: approval and creative_policy are prose. creative_policy moves here from § 5.6.
• § 4.2: specifications becomes media_kit_detail.
• § 2.5 and § 2.7 treat a spec as open text the counterparty wrote.
• § 8 question 4 and OQ-4 state the registry gap.

Related issue

Closes #87, a change request from Postindustria (IAB Tech Lab member).

Refs #5 and #32.

Builds on

This PR builds on our video and audio PR and our audience PR.

Through them it builds on our placement PR (#120) and these PRs of ours:

• Our property option PR
• Our DOOH PR
• Our settlement PR
• Our pricing PR
• Our handoff PR
• Our post-agreement PR
• Our holds PR
• Our signing PR
• Our buyer writes PR
• Our lifecycle PR
• Our parties PR
• Our errors and extensions PR
• Our shared types PR

Through our PRs it carries #17, #18, and #70 to #72 by @Sirajmx, #73 to #76 by @Kishore-2572, and #117 and #118 by @aleksUIX. Review the commits "Fix earlier text and widen the example checks", a fix that changes no rule, "Write the line items into proposal.yaml and check the extracts", and "Pin each format spec to one version and rename the format fields". Review the checker fixes "Let the example manifest omit an OPTIONAL key", "Check a term that refers to another field's list", "Don't read a linked core-term list as the backticked names", and "Call the checker's three-argument err in the pricing checks". Also review "Add asset provenance and the seller's voice keys", "Let assets record the creative the seller builds", and "Define the voice key and flag a synthetic asset under human_only", which add provenance, built_by, and voice, and which the task force can drop. "Let a receiver report a synthetic asset under human_only" builds on them and goes with them.

Type

• Editorial — no normative effect
• Normative — changes what the spec requires
• Breaking — would break an implementation already built to this draft
• Examples / schema / docs only

Checklist

• The body section is updated — § 2.5, § 2.7, § 4.1.1, § 4.2, § 5.4, § 5.6, § 6.3, § 7, and § 8 question 4, with OQ-4 in docs/open-questions.md. "Write the line items into proposal.yaml and check the extracts" updates § 6.1, and "Fix earlier text and widen the example checks" rewords § 2.6, § 5.8, § 6.6, § 8 question 3, and OQ-3
• Appendix A (field index) matches the body. The media_kit_detail, formats, format_specs, and approval rows take the new names and types. creative_policy moves to § 5.4. scripts/check_appendix.py passes: 97 field names, 99 rows
• Appendix B (fields by marker, and the counts) matches the body. The renamed fields keep seller-set, and no count changes: 6 requestable, 27 of 99 touched by the buyer
• Any affected example in examples/ is updated and still parses. Every offered format has a whole spec. The CTV example pins two formats and defines ctv/instream-6s itself, and seller-defined entries state asset. Both record_digest values are recomputed. scripts/check_examples.py checks each format id against its channel, an entry per offered format, one spec per spec_ref across examples, and the EntryRef form. In "Write the line items into proposal.yaml and check the extracts", proposal.yaml holds its line items, the checker compares the extracts with them, and manifest.json is regenerated. "Fix earlier text and widen the example checks" widens the checker. Each commit passes scripts/check_appendix.py, scripts/check_examples.py, and scripts/check_pricing_fixtures.py, 60 of 60
• RFC 2119 keywords used deliberately — MUST / SHOULD / MAY are not synonyms
• The no-inheritance rule (§ 2) still holds — format_specs, approval, and creative_policy sit on the line item; provenance on the asset
• Anything selectable declares available[] and included[]; anything settable declares bounds (§ 3.1, § 3.2) — formats declares both; no new selectable or settable fields
• No confidential or commercially sensitive content

Knock-on effects

• Breaking. A record with specs, specifications, an approval or creative_policy object, or a format id that doesn't start with its channel no longer conforms.
• Changes from the filed text. [Change] § 5.4 — Pin each format's spec to a version and keep it in the agreed record #87's registry_ref object becomes spec_ref, an EntryRef string with no digest (question 2). Question 3 stays open.
• Filings this answers.
  • A seller-defined entry is the inline specs path that @VJAlkimi's #32 proposes and @unreconciled supports on #5.
  • Until the registry covers them, the dooh/* entries @premesh proposes and the audio/* entries @cdorsey88 proposes can travel as seller-defined specs.
  • asset lets [Change] § 5.4 — Validate assets[].format_ref against the resolved formats selection at submission, not at creative review #32's check accept the valid script or artwork that @bhillman-TelevisaUnivision and @premesh warn it could reject.
  • provenance, voice, and the host-read example's pronunciation_guide come from @cdorsey88 on #5 and on this PR.
  • [Change] § 5.4 — Validate assets[].format_ref against the resolved formats selection at submission, not at creative review #32's submission check, and the format_unresolved report and agreed bar proposed on OQ-4 — The format registry has no entries for audio/*, ctv/* or dooh/* #5, stay on those issues.

Open questions

1. Which registry can a spec_ref name, and how does a reader fetch an entry? This is [Change] § 5.4 — Pin each format's spec to a version and keep it in the agreed record #87 question 3, tracked on OQ-4 — The format registry has no entries for audio/*, ctv/* or dooh/* #5.
2. A draft line item on a published proposal needs entries, because the condition reads the proposal's status (§ 4.3.3). Should it read the line item's status instead?
3. Nothing limits format_specs keys to formats.available[]. Should it?
4. Two sellers can give one seller-defined id different specs. Is the copy in format_specs enough, or does such an id need a namespace beyond its channel?
5. Answered in part by @cdorsey88: a receiver now reports a seller-built asset that's synthetic under voice: human_only, with the digest of the bytes it reviewed, but nothing carries the report yet, and @cdorsey88 would leave the buyer workflow to approvals[] in [Change] § 5.4 — Validate assets[].format_ref against the resolved formats selection at submission, not at creative review #32. Still open: a seller-built entry has no field for the buyer's approval, because approval_status is the seller's review. Our #32 comment proposes approvals[]. Should that land here or with [Change] § 5.4 — Validate assets[].format_ref against the resolved formats selection at submission, not at creative review #32?

---

By opening this pull request I agree my contribution may be published under this
repository's licence, as set out in CONTRIBUTING.md.

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

[cdorsey88]

@KonstantinMirin thanks, I read the seller-built entries in 5160e65. That settles where provenance lives for a recorded read.

One gap left: nothing says what a receiver does when a seller-built asset states synthetic: true under a spec that states voice: human_only. Those two statements contradict each other, and a receiver can catch it from the record alone. I'd add one sentence to § 5.4 saying the receiver reports that mismatch instead of treating the asset as conforming.

[KonstantinMirin]

Thanks, @cdorsey88. Agreed, and this PR adds it. § 5.4 defines voice next to asset: a spec MAY hold voice, an open vocabulary with the core terms human_only and synthetic_permitted. An asset whose provenance.synthetic is true doesn't conform to a spec whose voice is human_only, and the example checker flags that pair.

We stopped short of a duty to report the mismatch, because the draft gives the buyer no channel to report on a seller-built asset. That's the gap in question 5 of the PR description. The key list marks voice as defined.

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