[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.