Decision records · Where each statement is checked
D-029 How is each § 2 and § 3 statement checked, as a schema, a rule on payloads, or an obligation on a party's behavior?
What the schemas do
A statement about one payload, or about two versions and the acting party, is a rule. A statement about what a party does, which no payload shows, is an obligation. A statement the schema already says maps to the schema.
Options
Why
"Each line item MUST be fully self-contained" is what the line-item schema states: it is a document of its own and references no proposal. Replacing every catalog_ref at agreed is a rule on an agreed line item, which carries no catalog_ref. A seller's right to revise a seller-set field while the status is draft or published, and a buyer's right to ask for a value outside the declared space, compare two versions and the acting party, so they are rules of the Marker vocabulary. The rest are obligations, each on the party it names: a consumer doesn't inherit a value from the proposal; a buyer may commit a subset of the line items; and a seller keeps catalog entries immutable, resolves references during discovery, returns a summary and a full representation as § 2.1 says, gives in a summary the placement keys that the line item declares, which a summary alone doesn't show, publishes a current manifest with ETag and Last-Modified, declares everything a field needs to resolve, makes a field's default explicit, and recomputes addressable_scale and availability.
What we ask the specification to state
Mark the behavioral requirements of § 2 and § 3 as obligations on a named party. Keep them apart from what a schema or a rule can check.
The specification lines it rests on
Each line is quoted as the record pins it. Expand an item to read the quote.
main
§ 2, a requirement L62 at 44dfaaf
Each line item MUST be fully self-contained.
§ 2, a requirement L62 at 44dfaaf
A field on a line item MUST NOT inherit its value from the proposal or from a sibling line item.
§ 2.1, a requirement L76 at 44dfaaf
A catalog response MAY return it.
§ 2.1, a requirement L87 at 44dfaaf
catalog_refvalues MUST remain unresolved in a summary.§ 2.1, a requirement L90 at 44dfaaf
A full fetch MUST return it.
§ 2.2, a requirement L106 at 44dfaaf
A catalog entry MUST be immutable once referenced; a change creates a new version.
§ 2.2, a requirement L108 at 44dfaaf
References MUST resolve during discovery.
§ 2.2, a requirement L109 at 44dfaaf
When a proposal reaches status
agreed, everycatalog_refMUST be replaced by its resolved value in the stored record, so the committed artifact is self-contained and immutable.§ 3, a requirement L122 at 44dfaaf
The seller sets it and MAY revise it while status is
draftorpublished.§ 3, a requirement L126 at 44dfaaf
The buyer MAY ask for a value outside the declared space.
§ 3, a requirement L129 at 44dfaaf
selectable,settableandsuppliedfields MUST resolve without a round trip — everything needed to validate and price them is declared in the proposal.§ 3, a requirement L134 at 44dfaaf
An unset
selectableorsettablefield takes its declaredincluded[]or default, and that default MUST be explicit in the proposal.§ 2, a requirement L67 at 44dfaaf
A buyer MAY select and commit a subset of a proposal's line items, unless the proposal explicitly mandates linked execution through its binding terms.
§ 3.3, a requirement L166 at 44dfaaf
Because audiences, properties and formats are
selectable,addressable_scaleandavailabilityMUST be recomputed against the buyer's actual selection.
With the open PRs
§ 2, a requirement L55 on main at 981a74e
Each line item MUST be fully self-contained.
§ 2, a requirement L55 on main at 981a74e
A field on a line item MUST NOT inherit its value from the proposal or from a sibling line item.
§ 2, a requirement L60 on main at 981a74e
A buyer MAY select and commit a subset of a proposal's line items, unless the proposal sets
linked_executiontoall(§ 4.1).§ 2.1, a requirement L69 on main at 981a74e
A catalog response MAY return it.
§ 2.1, a requirement L80 on main at 981a74e
catalog_refvalues MUST remain unresolved in a summary.§ 2.1, a requirement L83 on main at 981a74e
A full fetch MUST return it.
§ 2.1, a requirement L89 in #120
A line item that carries
placement(§ 5.2) MUST also give, in its summary, whichever ofplacement.reward·placement.instl·placement.plcmt·placement.skipit declares.§ 2.2, a requirement L99 on main at 981a74e
A catalog entry MUST be immutable once referenced; a change creates a new version.
§ 2.2, a requirement L101 on main at 981a74e
References MUST resolve during discovery.
§ 2.2, a requirement L102 on main at 981a74e
When a proposal reaches status
agreed, everycatalog_refMUST be replaced by its resolved value in the stored record, so the committed artifact is self-contained and immutable.§ 2.3, a requirement L115 in #76
A seller MAY publish
https://<seller domain>/.well-known/openproposal.json.§ 2.3, a requirement L122 in #76
ETag/Last-Modifiedare REQUIRED, so buyers can poll cheaply.§ 2.3, a requirement L126 in #76
Manifest entries MUST match the current version of each proposal.
§ 3, a requirement L115 on main at 981a74e
The seller sets it and MAY revise it while status is
draftorpublished.§ 3, a requirement L119 on main at 981a74e
The buyer MAY ask for a value outside the declared space.
§ 3, a requirement L122 on main at 981a74e
selectable,settableandsuppliedfields MUST resolve without a round trip — everything needed to validate and price them is declared in the proposal.§ 3, a requirement L127 on main at 981a74e
An unset
selectableorsettablefield takes its declaredincluded[]or default, and that default MUST be explicit in the proposal.§ 3.3, a requirement L166 in #72
Because audiences, properties, formats and, where it is selectable,
geoareselectable, and buyerexclusions(§ 5.5) narrow delivery,addressable_scaleandavailabilityMUST be recomputed against the buyer's actual selection and exclusions.