[Comment] § 1.1, § 4.1, § 5.1 — Lifecycle ends at agreed: say so, name the baseline #68

Which section?

Whole document / more than one section

Field(s) involved

status, assent[], cancellation_policy, shortfall_remedy, external_references[], correlation_id, and a new change_requests[]

Your comment

The spec doesn't cover a line item after agreed. We propose ending the lifecycle there, with the agreed line item as the baseline for every downstream change.

§ 1 ends the scope at "binding agreement", and § 4.1 gives agreed no next state. Yet cancellation_policy (§ 5.6) and shortfall_remedy (§ 5.7) act after agreed. Nothing says what a change is against or where it goes, and nothing reads correlation_id (§ 5.10).

Today (§ 1.1, § 4.1):

flowchart LR
    R["agreed line item"] -->|"lands in"| D["downstream standard"]
    C["change after agreed"] -.->|"new version? assent still names the old one"| R
    C -.->|"downstream only? the record never learns"| D

Proposed:

flowchart LR
    R["agreed line item, terminal"] -->|"external_references[]: order, line, deal"| D["downstream standard"]
    C["change request"] -->|"applied against the baseline VersionRef"| D
    C -->|"recorded outside record_digest"| H["change_requests[]"]

We propose:

• § 1.2, After agreed. The downstream standard executes the agreed line item, named by a VersionRef at its agreed version, and applies any later change on its side.
• § 4.1.2. agreed is terminal. The terms MUST stay as in the version assent[] names.
• § 4.4, change_requests[]. Each entry takes the OpenDirect 2.1 ChangeRequest fields except webhook, plus baseline, actor, at, and cancellation. It changes no term and sits outside record_digest.
• § 5.10. external_references[] replaces correlation_id and holds the downstream ids. Entries aren't terms, so the seller can add the deal ID after agreed.
• § 1.1, a change-path column, as @dineshbhat (Hypermindz) suggested. A direct_io line item or a programmatic_guaranteed reservation changes by ChangeRequest on the booked OpenDirect 2.1 Line. A deal changes by bilateral agreement, since the Deal Sync API 1.0 "does not support deal revisions".

Our post-agreement PR carries § 1.2, § 4.4, and § 5.10, and closes this issue. Our lifecycle PR carries § 4.1.2, and our handoff PR carries § 1.1.

Open questions

1. Answered by our post-agreement PR. Which OpenDirect 2.1 ChangeRequest field carries the baseline? None: the entry carries baseline itself, replacing the field in our earlier reply.
2. How does an entry state a change other than a cancellation? The OpenDirect 2.1 ChangeRequest has only free-text comments, and an entry doesn't carry ChangeRequestLine resources. Our post-agreement PR keeps this as a § 8 question.
3. Does an implementation need either rule in the rules issue: a deal change as a new deal on the same baseline, or the seller recording the order and line ids once booked?

Companions: our lifecycle change request (#65), the normative boundary (#59), and the binding record (#63).

Details: Agreed baseline: full rationale and examples

Concrete scenario

A buyer ends an agreed CTV deal early under its paid cancellation option. Today only the frozen record could take it. Proposed: the seller applies it to the deal, and a change_requests[] entry records the notice against the baseline.

You are commenting as

Other — IAB Tech Lab member (Postindustria).

Before you submit

• I have read CONTRIBUTING.md and agree my contribution may be published under this repository's licence.
• This comment contains no confidential or commercially sensitive information.

Revised 2026-11-03: Rewritten against our coming PRs; question 1 answered, 2 and 3 new.

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