[Kishore-2572]

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

What this changes

A proposal can now carry an optional, immutable proposal_template_id (§ 4.1) linking an issued proposal to the seller's template, so issued copies of one template can be told apart and traced back to it. Each issued proposal has its own status, version and negotiation_history[], and buyers never need the template id to transact. § 7 adds a non-normative note separating seller-side templates from the issued proposals buyers see and commit against.

Related issue

Refs #26. Related: #27 (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 — one row; scripts/check_appendix.py passes
• Appendix B (fields by marker, and the counts) matches the body — immutable 6 → 7; 71 → 72 fields
• Any affected example in examples/ is updated and still parses — proposal_template_id in proposal.yaml
• RFC 2119 keywords used deliberately — MUST / SHOULD / MAY are not synonyms
• The no-inheritance rule (§ 2) still holds — an issued proposal inherits nothing from its template; the id is a pointer only
• 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

• Wording against the filed text: the § 7 note places buyer-specific terms on the issued proposal's line items, since visibility, eligible_bidders[] and pricing[] are line-item fields (§ 5.6, § 5.8). "Proposal Store" is described as the seller's own systems, as the specification does not define it.
• Not included, for the working group (Postindustria on [Change] § 4.1 — Proposal templates and issued proposals (proposal_template_id) #26):
  • an immutable issued_from: { proposal_id, version } naming the shared proposal an issued proposal was created from. It points to a public proposal, where proposal_template_id points to a seller-internal template, so the two could coexist;
  • a creation rule: no ask, hold or commitment is evaluated against a shared proposal; the seller answers with a proposal issued to that buyer;
  • a definition of shared versus issued, and a rule that a revision does not open an issued proposal to another counterparty.
• Related: [Change] § 4.1 — Freeze a version's offered terms; changes create version n+1 and a revised entry #64 (version freezing), [Change] § 4, § 5.1 — Add § 4.3 Lifecycle: who moves each status #65 and [Change] § 5.6.2 — hold_status needs refused and re-entry to requested #66 (lifecycle and holds on issued proposals), [Change] § 5.6 — Give the buyer's counter a field (requested_rate), state how agreed_rate is derived, and say who can read floor and seller_rate #30 (counters on issued proposals) and [Comment] § 2 — The draft does not say what a parser does with a key it does not define #33 (handling of keys buyers do not resolve).
• Overlap: examples/proposal.yaml is also changed by § 2, § 4.1, § 5.6 — Line-item dependencies and bonus lines (#23) #70 (linked_execution: none); whichever merges later rebases.
• 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.