Decision records · What each rule accepts
D-034 What change does each mutability rule allow, between two versions and the party that made it, where the specification states the rule only in prose?
What the schemas do
Read each rule as narrowly as its words allow, and give it the vectors that reading decides: - A field's status is the status of the document that holds it. - A settable value is bounds the buyer narrows. - Seller assent is the seller's version. - A MAY grants only the change it names. - A derived field changes only with the fields it is computed from.
Options
Why
Type rules § 9 gives every rule a valid and an invalid vector, and a mutability rule's vector is a pair of versions plus the acting party, so leaving these rules without vectors fails the gate. The vectors read each rule as follows. immutable: the value never changes, and a version that first sets it after creation changes it. seller-set: only the seller changes the value, and only while the status of the document that holds the field, the line item or the proposal, is draft or published. selectable: the buyer changes included[] and leaves available[], pricing, and max_select, the seller-declared set, as they are. settable: in draft 1 a settable field holds only its bounds (D-018), so the buyer's value is bounds within the seller's: allowed[] a subset of the seller's. supplied: the buyer sets the value, and a seller's version that sets it pre-populates it. requestable: a buyer's version that changes the value is a request; the request takes effect only in a version the seller makes, so a buyer can't grant its own hold request (requested to held). derived: neither party changes the value on its own, so a version that changes it and nothing else sets it directly. A MAY grants only the change it names: a buyer may request a later materials_due, not an earlier one, and a committed_metrics[] value above the seller's ceiling, not below it. negotiation_history[] keeps every entry of the earlier version, unchanged and in order, and may add entries after them. The hold state moves only along none → requested → held → (expired | released | converted), whichever party acts, and expired, released, and converted are terminal. terms_ref is hash-pinned when it carries sha256, and frozen when no version whose status is agreed changes it.
What we ask the specification to state
State each mutability rule as a check on two versions and the acting party. Also say:
- whose status the
seller-setrule reads - where a settable field holds the buyer's value
- how a version shows seller assent to a request
- whether a buyer may ask for an earlier
materials_dueor a lower committed metric - which party may move the hold
state - whether
expiredandreleasedare terminal, asconvertedis
The specification lines it rests on
Each line is quoted as the record pins it. Expand an item to read the quote.
main
§ 3, the
immutablemarker row L121 at 44dfaafimmutable| Set once at creation. Neither party may change it.§ 3, the
seller-setmarker row L122 at 44dfaafseller-set| The seller sets it and MAY revise it while status isdraftorpublished. The buyer cannot change it directly.§ 3, the
selectablemarker row L123 at 44dfaafselectable| The buyer chooses from a seller-declared set. Each option MAY carry a price delta. Resolves without seller assent.§ 3, the
settablemarker row L124 at 44dfaafsettable| The buyer supplies a value within seller-declared bounds. Resolves without seller assent.§ 3, the
suppliedmarker row L125 at 44dfaafsupplied| The buyer provides data or an artifact. The seller does not pre-populate it.§ 3, the
requestablemarker row L126 at 44dfaafrequestable| The buyer MAY ask for a value outside the declared space. Requires explicit seller assent.§ 3, the
derivedmarker row L127 at 44dfaafderived| Computed from other fields. Neither party sets it directly.§ 5.6.2, paragraph 1: the value list L312 at 44dfaaf
expired|released|converted§ 5.6.2, a sentence L312 at 44dfaaf
Transitions:
none→requested→held→ (expired|released|converted).§ 5.6.2, a sentence L313 at 44dfaaf
convertedis terminal and occurs when the line item reachesagreed.§ 4.1, a requirement L192 at 44dfaaf
Entries MUST NOT be edited or removed
§ 5.4, a requirement L247 at 44dfaaf
A buyer MAY request a later date
§ 5.7, a requirement L320 at 44dfaaf
Seller declares a ceiling; a buyer MAY request above it
With the open PRs
§ 3, the
immutablemarker row L114 on main at 981a74eimmutable| Set once at creation. Neither party may change it.§ 3, the
seller-setmarker row L115 on main at 981a74eseller-set| The seller sets it and MAY revise it while status isdraftorpublished. The buyer cannot change it directly.§ 3, the
selectablemarker row L116 on main at 981a74eselectable| The buyer chooses from a seller-declared set. Each option MAY carry a price delta. Resolves without seller assent.§ 3, the
settablemarker row L117 on main at 981a74esettable| The buyer supplies a value within seller-declared bounds. Resolves without seller assent.§ 3, the
suppliedmarker row L118 on main at 981a74esupplied| The buyer provides data or an artifact. The seller does not pre-populate it.§ 3, the
requestablemarker row L119 on main at 981a74erequestable| The buyer MAY ask for a value outside the declared space. Requires explicit seller assent.§ 3, the
derivedmarker row L120 on main at 981a74ederived| Computed from other fields. Neither party sets it directly.§ 5.6.2, paragraph 1: the value list L305 on main at 981a74e
expired|released|converted§ 5.6.2, a sentence L305 on main at 981a74e
Transitions:
none→requested→held→ (expired|released|converted).§ 5.6.2, a sentence L306 on main at 981a74e
convertedis terminal and occurs when the line item reachesagreed.§ 4.1, a requirement L185 on main at 981a74e
Entries MUST NOT be edited or removed
§ 5.4, a requirement L240 on main at 981a74e
A buyer MAY request a later date
§ 5.7, a requirement L313 on main at 981a74e
Seller declares a ceiling; a buyer MAY request above it
§ 5.8, a requirement L335 in #75
terms_refMUST be hash-pinned and frozen atagreed.