[Kishore-2572]

Draft. Do not merge until the working group confirms the disposition of #27.

What this changes

A line item can now point at the agreement and the exact terms it is executed under, without the specification modelling contracts. terms_ref (§ 5.8, { url, sha256, version }) names the legal terms or IO template the buyer accepts at assent; it is REQUIRED when terms_acceptance_required is true, and hash-pinned and frozen at agreed. agreement_ref (§ 5.10) is an informative pointer to the master or annual agreement a line item is priced under. external_references[] documents two role values, io and agreement. § 5.10 states that IO generation is a connector concern, and § 7 adds a non-normative note: relationships are issued proposals plus the buyer agent's business rules.

Related issue

Refs #27. Related: #26 (draft PR #74), where buyer-specific terms live on issued proposals.

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
• Appendix A (field index) matches the body — two rows; scripts/check_appendix.py passes
• Appendix B (fields by marker, and the counts) matches the body — seller-set 29 → 31; 71 → 73 fields
• Any affected example in examples/ is updated and still parses — terms_acceptance_required and terms_ref in line-item-display.yaml
• RFC 2119 keywords used deliberately — MUST / SHOULD / MAY are not synonyms
• The no-inheritance rule (§ 2) still holds — both fields sit on the line item
• Anything selectable declares available[] and included[]; anything settable declares bounds (§ 3.1, § 3.2) — no new selectable or settable fields
• No confidential or commercially sensitive content

Knock-on effects

• Breaking: a line item with terms_acceptance_required: true and no terms_ref no longer conforms.
• Change against the filed text: [Change] § 5.8, § 5.10 — Relationship and contract references (agreement_ref, terms_ref) #27 gave agreement_ref two markers ("seller-set (buyer MAY also supply)"), but § 3 gives every field exactly one and scripts/check_appendix.py reads one. It is seller-set here; a buyer-held agreement id travels as an external_references[] entry with role: agreement.
• Change against the filed text: [Change] § 5.8, § 5.10 — Relationship and contract references (agreement_ref, terms_ref) #27 named the parties [seller_id, buyer_id], but the specification defines no buyer_id. parties[] names the seller by its seller_id and the buyer by the id it holds in eligible_bidders[] (§ 5.8). A defined buyer identifier is for the working group; [Change] § 4.1 — Identify the seller by seller_domain; make seller_id OPTIONAL #61 proposes seller_domain for the seller side.
• For the working group:
  • [Change] § 4.1 — Define record_digest and assent[]; defer signer identity to the AAMP profile #63, [Change] § 4.1 — Freeze a version's offered terms; changes create version n+1 and a revised entry #64 and [Comment] § 1.1, § 4.1, § 5.1 — Lifecycle ends at agreed: say so, name the baseline #68 treat external_references[] as outside the offered terms. Whether terms_ref and agreement_ref belong inside the binding record is for adjudication.
  • Assent (§ 4.1) binding to an exact document needs the assent record to carry the sha256 of the accepted terms. [Change] § 4.1 — Define record_digest and assent[]; defer signer identity to the AAMP profile #63 proposes a digest-based assent[].
  • agreement_ref uses valid_from / valid_until, the same names as the proposal's offer window. effective_from / effective_until would avoid confusion.
• Related: [Comment] § 4.1: a seller revision can change a billable term with no history entry, and assent does not say what it commits to #45 (what assent commits to), [Comment] §§ 4.1, 5.6.1, 5.8 — Authorization evidence should travel with the transaction #57 (authorisation evidence on the transaction), [Comment] § 2 — The draft does not say what a parser does with a key it does not define #33 (the new role values on external_references[]).
• § 7 overlap: § 4.1, § 7 — Proposal templates and issued proposals (#26) #74 ([Change] § 4.1 — Proposal templates and issued proposals (proposal_template_id) #26) adds its "Templates and issued proposals" note at the same place in § 7, so the two PRs conflict there; whichever merges later rebases and keeps both notes.
• Appendix B: other open change requests also change these counts; whichever merges later recounts.

---

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

[KonstantinMirin]

Postindustria (IAB Tech Lab member). @Kishore-2572, our PRs carry #75 and change terms_ref and agreement_ref as follows:

• Name the field digest. A field name never names the algorithm, so the value carries it: sha256: + lowercase hex, the form record_digest (#63) already uses. Our shared types PR defines it once, as Digest in § 2.2. For a document, the input is the exact bytes served at url, with no content coding.
• Use one type, DocumentRef. It requires only url and digest, and stays open, so its publisher can add a version or a date. Every pinned document uses it, including a block list on #71 in place of list_ref.
• Make it an array. In our PR on what is signed, terms_refs[] lets a seller send a main agreement and its addenda. Every entry applies, with no AND or OR.
• Keep the documents. The seller keeps every published version retrievable. The buyer stores a copy and compares it with its digest before it commits.
• Acceptance. The buyer's commitment entry in assent[] carries record_digest, which covers each terms_refs[] digest. That entry accepts every listed document at those exact bytes. With no terms_refs[], it accepts none.
• Drop terms_acceptance_required. A non-empty terms_refs[] already says it.
• Rename agreement_ref to agreement. The suffix _ref is kept for DocumentRef and EntryRef. agreement stays an informative pointer. A term, an Interval, replaces valid_from and valid_until. type becomes agreement_type, an open vocabulary. parties[] holds Party objects, as in our parties PR. An optional document pins the agreement as a DocumentRef.
• Binding record. terms_refs[] and agreement are seller-set, so record_digest covers both. external_references[] are not terms, so an order or line id can arrive after agreed. In our post-agreement PR, role becomes reference_type, and io becomes order or line.

Revised 2026-11-03: Rewritten to match our PRs. We withdraw the point that § 3 makes "frozen at agreed" redundant.

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

[KonstantinMirin]

Postindustria (IAB Tech Lab member). @Kishore-2572, our parties PR carries this PR at its head. Its last commit renames agreement_ref to agreement, with a key table, and parties[] holds Party objects.

Our PR on what is signed turns terms_ref into terms_refs[] of DocumentRef and drops terms_acceptance_required. Our post-agreement PR renames role to reference_type.

Our revised comment above has the detail. Could you review them there?

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