[aleksUIX]

A creative preview can send production notifications even though no live delivery occurred. This applies the proposal in #42 to section 5.4 and adds informative CTV example references.

Inspection must suppress every production notification, including notifications caused by executed creative code or landing-page redirects. Creative and media retrieval remain possible. A receiving service's documented test mode may exclude synthetic events from production measurement; an inspector's own flag is insufficient.

Failures use diagnostics, and skipped or unfinished checks cannot be reported as passed. No payload fields, inspection-result vocabulary or approval states are added. Those separate result semantics remain under discussion in #32.

The diff contains only the specification, changelog and CTV example. Supporting synthetic fixtures remain available at the original commit, as linked from #42. Their tooling and CI job are outside this spec diff.

Validation: the existing appendix check passes with 69 fields; all 11 example, issue-form, label and workflow YAML files parse. The fixture code is preserved as historical evidence; this revision does not claim new browser or runtime test results.

Member of the IAB Tech Lab Agentic Taskforce, commenting in a personal capacity.

[KonstantinMirin]

Postindustria (IAB Tech Lab member). @aleksUIX, the text matches #42.

• Scope. The MUST NOT lists six kinds, leaving mute, pause, skip and creativeView (VAST 4.3 tracking events, § 3.14.1) open. "MUST NOT send any production notification" covers all.
• Results. OpenProposal defines no "inspection result" or "required checks"; the rules hold without them. In your [Change] § 5.4 — Validate assets[].format_ref against the resolved formats selection at submission, not at creative review #32 terms: "MUST NOT report a check that was skipped or could not finish as passed." blocked is a proposed approval state on [Change] § 5.4 — Validate assets[].format_ref against the resolved formats selection at submission, not at creative review #32.
• § 6.3. Its MUSTs restate § 5.4 more narrowly, and the rule covers every line item. An informative note keeps one wording: "Inspecting this line item's VAST creative is subject to § 5.4."
• Tooling. The fixtures are strong evidence. Linked from [Change] § 5.4: Keep creative inspection and previews from sending production tracking #42 or in a separate PR, they let the working group adjudicate the wording alone (one logical change per PR), leaving the receipt's not_checked vocabulary to [Change] § 5.4 — Validate assets[].format_ref against the resolved formats selection at submission, not at creative review #32.

Open questions:

1. May inspection request a <ClickThrough> destination (VAST 4.3, § 3.10.1)? Sellers often check landing pages, but the URI is often a click redirect, and your inspector treats it as an event.

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

[aleksUIX]

Updated in response to your review. Section 5.4 now prohibits any production notification, and section 6.3 is an informative reference. Diagnostics do not introduce an inspection-result field, required-check set or approval state. A skipped or unfinished check cannot be reported as passed.

The fixture tooling and its CI job are removed from this PR's diff. The supporting evidence linked from #42 remains available at the original commit. Result semantics stay with #32.

On ClickThrough: VAST defines the destination separately from ClickTracking. Landing-page inspection remains possible when its requests and redirects do not send production notifications. A click redirect that records a live event needs a separate inspection URL or a receiving service's documented test mode. The fixture's conservative deny rule does not mean every ClickThrough is a tracker.

The remaining spec, changelog and example diff passes the appendix and YAML checks.

[KonstantinMirin]

Postindustria (IAB Tech Lab member). @aleksUIX, our shared types PR carries this PR at its head. Your "Creative inspection and previews" text is unchanged, except that its heading gains the number § 5.4.1. The § 6.3 note and the CTV example's comment point to § 5.4.1. The other edits in that example are our renames and the visibility key.

Could you check it there?

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

[aleksUIX]

Checked #137 at e47cbf5. The § 5.4.1 text matches this PR word for word apart from the heading number, and the § 6.3 note and the CTV comment point to § 5.4.1. The other CTV edits are #137's renames and visibility: public. The inspection text names no OpenProposal field, so the renames don't reach it. #146 carries the same text unchanged. On e47cbf5 the example, issue-form, appendix and check_examples.py checks pass locally.

One nit for #137: the CHANGELOG entry still points to section 5.4. Pointing it to § 5.4.1 would match the heading and the other entries.

I'll keep this PR as a draft until #137 lands and won't push to its branch, so the head you carried stays put.

[KonstantinMirin]

Thanks, @aleksUIX. #137's CHANGELOG entry points to § 5.4.1, in its own commit, and #146 carries the same line.

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