{"schema":"https://ver.cy/schemas/card/1.0.0","id":"vr.wm-eco-019","code":"wm-eco-019-purchase-order","url":"https://ver.cy/models/wm-eco-019-purchase-order/","name":"Purchase Order","alternateNames":[],"kind":"world-model","status":"published","version":"0.3.0-research.1","language":"en","classifiers":{"family":"World Models","category":"Society, people and institutions","entryKind":"aggregate","plane":"","domain":["SOC.ECO.ORD"],"industry":["Cross-industry"],"navPath":"NAV.SOC.ECO.ORD","tags":["purchase","order","soc.eco.ord"],"facets":{}},"whatItIs":"Covers the purchase order as an identifiable commercial instrument issued by a buyer to a seller: identity and revision, classification and purchasing pattern, parties and commitment authority, line-item and commercial terms content, delivery instruction, lifecycle from issue through response, amendment, cancellation and closure, and the governance layers (provenance, retention, access, interoperability) needed to operate it. It stops where a distinct instrument or sibling model takes over: the quotation that may precede it, the contract or framework agreement it draws on, the fulfilment obligations it creates, and the invoice and payment that settle it. Registry entry_kind 'standalone-mm' is expressed here as 'aggregate' because the order header is the aggregate root and order lines have no identity outside it.","purpose":"Give an agent the context needed to interpret, create, validate and operate a purchase order as a buyer-issued commitment instrument, and to track it through response, amendment, fulfilment linkage and closure, independently of storage format or interface.","scope":{"in":["Order header identity, document versioning and revision control","Order classification and purchasing pattern (standalone, call-off/release against a framework, change, consignment, drop-ship)","Buyer, seller and ancillary party roles and their identification schemes","Order line composition: item identification, ordered quantity, unit of measure, packaging","Price basis, allowances and charges, currency and anticipated monetary totals as stated on the order","Payment terms and means, and references to governing contract terms and clauses","Delivery destination, requested delivery schedule, delivery terms and risk-transfer point","Order lifecycle states, order response and acceptance semantics, amendment, cancellation and closure","Provenance, transmission evidence, time semantics, retention, access control and syntax interoperability"],"out":["Invoice content, tax determination and payment execution (settlement instruments reference the order but are modelled separately)","Quotation and RFQ content and seller price-offer logic (WM-ECO-021)","Product catalogue and item master data content beyond the identifiers cited on the order","Physical fulfilment execution, despatch, transport and receipt/inspection events (WM-ECO-024)","Contract clause corpus, framework agreement negotiation and master terms body (WM-ECO-006)","Supplier onboarding, qualification and party master data management","Requisition, budget encumbrance and internal spend approval policy beyond the authority actually asserted on the order"],"boundaries":[{"neighbor":"Quotation / RFQ (WM-ECO-021)","distinction":"A quotation is seller-originated and, under FAR 13, is not an offer that the buyer can accept to form a contract; the purchase order is the buyer-originated instrument. UBL keeps Quotation and Order as separate documents linked by QuotationDocumentReference, so quotation content stays in the sibling model and only the reference is held here."},{"neighbor":"Fulfilment obligation (WM-ECO-024)","distinction":"The order states requested delivery; the obligations it creates and the performance events that discharge them (despatch, receipt, acceptance of goods) belong to the contained model. UBL and Peppol model despatch advice and receipt as separate documents."},{"neighbor":"Contract / framework agreement (WM-ECO-006)","distinction":"The order references a contract rather than restating it; UBL Order carries a Contract reference, and FAR treats a blanket purchase agreement and the calls placed against it as different objects. Clause bodies and negotiated terms live in the parent model."},{"neighbor":"Invoice and settlement","distinction":"The invoice references the order (EN 16931 BT-13 purchase order reference, BT-14 sales order reference); invoice content, tax breakdown and payment status are not order content, and the order carries only anticipated, not settled, monetary totals."},{"neighbor":"Transport and delivery-terms rules","distinction":"Incoterms 2020 allocate delivery, cost and risk between seller and buyer but are a referenced trade-term code plus named place; the ICC rules themselves are external and are not restated in this model, and they do not determine price, title transfer or payment."},{"neighbor":"Order response document","distinction":"An order response is a distinct document with its own identity and its own customization identifier in Peppol; this model holds the resulting acceptance state and the response reference on the order, not the response document's internal model."},{"neighbor":"Party master data and identifier registries","distinction":"GS1 allocates and governs GLNs and ISO 6523 ICD schemes qualify party identifiers; the order cites identifiers under a declared scheme but does not own their allocation, reuse policy or registry lifecycle."}]},"distinguishingFeatures":["A buyer-issued commitment instrument that binds the seller only after acceptance.","Unlike a quotation, it comes from the buyer; unlike a sales order, it lives in the buyer's system.","Unlike an invoice, its totals are anticipated, not settled.","Unlike a framework contract, it is a specific order, possibly a call-off under one."],"structure":{"bundles":[{"id":"order-identity-and-classification","name":"Order identity and classification","description":"What this order is, how it is uniquely referenced, how its revisions are distinguished, and what kind of purchasing instrument it is.","layers":[{"id":"order-identity-and-versioning","name":"Order identity and versioning","description":"Identifiers that name the order and its successive revisions across buyer and seller systems.","findings":[{"id":"order-identifier-and-scheme","name":"Order identifier and issuing scheme","description":"The buyer-assigned order number is the operative identity; UBL additionally allows a UUID, and the seller may hold a separate sales order identifier that must be correlated back.","questions":[{"text":"Which system of record assigns the authoritative order number, and in what domain is that number unique?","id":"q-who-assigns-order-number","kind":"identity"},{"text":"Is a globally unique document identifier carried alongside the human-visible order number, and which governs when the two disagree?","id":"q-uuid-versus-order-number","kind":"identity"},{"text":"How is the seller's own sales order identifier captured and correlated to the buyer's order number?","id":"q-sales-order-correlation","kind":"relationship"},{"text":"In what exact form must a despatch advice or invoice quote this order so the reference resolves without ambiguity?","id":"q-reference-form-downstream","kind":"interoperability"}]},{"id":"order-revision-and-versioning","name":"Order revision and document versioning","description":"How successive states of the same order are distinguished, which revision is in force, and how superseded revisions remain retrievable as evidence.","questions":[{"text":"How is a revision of the order numbered, and is that number part of the order's identity or an attribute of it?","id":"q-revision-numbering","kind":"identity"},{"text":"Which single revision is currently in force at any given instant, and how is that determined?","id":"q-current-revision-determination","kind":"state"},{"text":"Are superseded revisions retained in full or reconstructed from a change log, and for how long?","id":"q-superseded-retrieval","kind":"retention"},{"text":"What evidence proves that a stored revision has not been altered since it was issued?","id":"q-revision-integrity","kind":"evidence"}]}]},{"id":"order-classification","name":"Order classification","description":"The kind of purchasing instrument the order is and the pattern of commitment it expresses.","findings":[{"id":"order-type-and-purchasing-pattern","name":"Order type and purchasing pattern","description":"UBL carries an OrderTypeCode; FAR distinguishes a purchase order from a blanket purchase agreement and the calls placed against it, so the model must record both the coded type and the commitment pattern it implies.","questions":[{"text":"Which controlled code expresses the order type, and from which code list is that value drawn?","id":"q-order-type-code","kind":"classification"},{"text":"Does this order create a firm quantity commitment, a ceiling under which releases are drawn, or a release against an existing ceiling?","id":"q-commitment-pattern","kind":"definition"},{"text":"If the order is a call-off or release, which framework instrument does it draw against and how is the drawdown recorded?","id":"q-callout-parent-link","kind":"composition"},{"text":"Does the order type change which lifecycle states, approvals or response rules apply?","id":"q-type-drives-lifecycle","kind":"decision"}]},{"id":"replenishment-and-call-off-patterns","name":"Blanket, call-off, consignment and VMI patterns","description":"Peppol documents blanket, call-off and consignment (type 227) orders, including vendor-managed inventory where withdrawal of stock auto-issues a consignment order. UBL describes VMI, cyclic replenishment and replenishment on customer demand as related processes that may use Order plus catalogue, despatch and inventory documents. These patterns are in the wide-union surface but are not default for every adoption.","questions":[{"text":"Is this a standalone order, a blanket, a call-off against a blanket or contract, a consignment or VMI withdrawal, or a rush or standing order?","id":"replenishment-and-call-off-patterns-q01","kind":"classification"},{"text":"If this is a call-off, which blanket quantities, dates and locations does it split, and what remaining blanket balance is left?","id":"replenishment-and-call-off-patterns-q02","kind":"process"},{"text":"If this is a VMI or consignment order, was it issued automatically on withdrawal, and does the seller still send an order response acknowledgement without treating it as a new offer negotiation?","id":"replenishment-and-call-off-patterns-q03","kind":"exception"}]}]}]},{"id":"parties-authority-and-legal-effect","name":"Parties, authority and legal effect","description":"Who the order binds, how those parties are identified, who inside the buyer had authority to commit, and what legal effect issuance and acceptance produce.","layers":[{"id":"party-roles-and-identification","name":"Party roles and identification","description":"The roles an order distinguishes and the schemes under which each participant is identified.","findings":[{"id":"party-roles-on-the-order","name":"Buyer, seller and ancillary party roles","description":"UBL distinguishes BuyerCustomerParty, SellerSupplierParty, OriginatorCustomerParty and FreightForwarderParty, and GS1 application identifiers separate ship-to, bill-to and purchased-from, so role must be modelled separately from party.","questions":[{"text":"Which party roles does this order distinguish, and which of them are mandatory for it to be actionable?","id":"q-role-set","kind":"composition"},{"text":"Can one legal entity occupy several roles on the same order, and how is that represented without collapsing the roles?","id":"q-role-party-separation","kind":"relationship"},{"text":"Where the ordering party differs from the originating requester, which party carries the payment and which carries the requirement?","id":"q-originator-versus-buyer","kind":"ownership"}]},{"id":"party-identifier-schemes","name":"Party identifier schemes and electronic address","description":"Party identifiers on an order are only resolvable when qualified by a scheme: GLN under ISO 6523 ICD 0088, other ICD-qualified registration identifiers, and Peppol electronic-address EAS codes for routing.","questions":[{"text":"Under which registered scheme is each party identifier issued, and is the scheme code carried with the value?","id":"q-party-scheme-qualifier","kind":"identity"},{"text":"Does the issuing registry permit reuse of a retired party identifier, and how does that affect historic orders?","id":"q-identifier-reuse-policy","kind":"constraint"},{"text":"Which electronic address routes the order to the seller, and is it distinct from the party's legal identifier?","id":"q-electronic-address-routing","kind":"interoperability"},{"text":"Which tax or legal registration identifiers must appear on the order for the transaction to be lawful in the applicable jurisdictions?","id":"q-tax-registration-on-order","kind":"requirement"}]}]},{"id":"commitment-authority-and-formation","name":"Commitment authority and contract formation","description":"Who was entitled to bind the buyer, and what legal state the order creates before and after acceptance.","findings":[{"id":"commitment-authority-and-approval","name":"Commitment authority and approval","description":"An order commits funds only if issued by someone holding the authority to commit; FAR vests this in the contracting officer, and commercial buyers use delegated approval thresholds.","questions":[{"text":"Which named role holds authority to commit the buyer for this order's value and category?","id":"q-who-may-commit","kind":"authority"},{"text":"What record proves the approval was granted before issuance rather than reconstructed afterwards?","id":"q-approval-evidence","kind":"evidence"},{"text":"What happens to an order issued without adequate authority, and can it be ratified?","id":"q-authority-breach-handling","kind":"exception"}]},{"id":"contract-formation-and-legal-effect","name":"Contract formation and legal effect","description":"The order is an offer until accepted; FAR permits acceptance by performance and allows withdrawal before acceptance, while CISG governs formation for cross-border sales of goods between contracting states.","questions":[{"text":"Does issuing this order constitute an offer, or an acceptance of a prior seller offer?","id":"q-offer-or-acceptance","kind":"definition"},{"text":"By which modes may the seller accept - express response, signature, or commencement of performance - and which mode was actually used?","id":"q-acceptance-mode","kind":"event"},{"text":"Until what moment may the buyer withdraw the order without liability, and how is withdrawal evidenced?","id":"q-withdrawal-before-acceptance","kind":"lifecycle"},{"text":"Which law governs the order, and how are conflicting buyer and seller standard terms resolved?","id":"q-governing-law-and-terms-conflict","kind":"constraint"}]}]}]},{"id":"order-content-and-commercial-terms","name":"Order content and commercial terms","description":"What is being ordered, in what quantity, at what price, and on what payment and contractual terms.","layers":[{"id":"line-item-structure","name":"Line item structure","description":"How the order decomposes into lines, and what each line identifies and quantifies.","findings":[{"id":"order-line-identity-and-quantity","name":"Order line identity, composition and ordered quantity","description":"Lines carry a line identifier that responses must match, plus ordered quantity and unit of measure; Peppol requires all lines to be returned when an order is accepted with amendments.","questions":[{"text":"Is the line identifier stable across revisions and responses, or reassigned when lines are added or removed?","id":"q-line-id-stability","kind":"identity"},{"text":"May a line carry sub-lines or component items, and does a sub-line inherit the parent's terms?","id":"q-line-decomposition","kind":"composition"},{"text":"In which unit of measure is the ordered quantity expressed, and from which code list is that unit drawn?","id":"q-quantity-and-uom","kind":"measurement"},{"text":"Is the quantity expressed in consumer units, trade units or packs, and how is the conversion recorded?","id":"q-packaging-basis","kind":"measurement"}]},{"id":"item-identification-and-classification","name":"Item identification and classification","description":"Peppol requires an item identifier and/or item name per line; identifiers may be seller-assigned, buyer-assigned or standard trade item numbers, with optional classification codes.","questions":[{"text":"Which item identifier governs when seller, buyer and standard trade item identifiers are all present and disagree?","id":"q-item-identifier-precedence","kind":"identity"},{"text":"When no coded item identifier exists, what description is sufficient for the line to be unambiguously fulfillable?","id":"q-item-name-sufficiency","kind":"requirement"},{"text":"Under which classification scheme and version is the item categorised for reporting or regulatory purposes?","id":"q-item-classification-scheme","kind":"classification"},{"text":"Where the item is bespoke, which specification document forms part of the order and how is its version pinned?","id":"q-item-spec-attachment","kind":"provenance"}]}]},{"id":"pricing-and-monetary-terms","name":"Pricing and monetary terms","description":"Price basis, adjustments, currency and the anticipated totals stated on the order.","findings":[{"id":"price-basis-amounts-and-totals","name":"Price basis, allowances, currency and anticipated totals","description":"UBL carries price with a base quantity, allowances and charges, tax totals and an AnticipatedMonetaryTotal; these are the buyer's expectation, not a settled amount, and CISG contemplates contracts where the price is not fixed at formation.","questions":[{"text":"Is the unit price stated against a base quantity other than one, and how is the line amount derived from it?","id":"q-price-base-quantity","kind":"measurement"},{"text":"Is the price firm, indicative, or to be determined at delivery, and what rule fixes it if not firm?","id":"q-price-firm-or-provisional","kind":"constraint"},{"text":"In which currency is the order denominated, and is a second currency or conversion rate recorded?","id":"q-currency-and-conversion","kind":"interoperability"},{"text":"Do the anticipated totals bind the seller, or is the line detail authoritative when totals and lines disagree?","id":"q-totals-authority","kind":"validation"}]}]},{"id":"payment-and-contractual-terms","name":"Payment and contractual terms","description":"Payment expectations stated on the order and the external terms the order incorporates.","findings":[{"id":"payment-terms-and-means","name":"Payment terms and payment means","description":"UBL carries PaymentTerms and PaymentMeans on the order, expressing the payment expectation set at commitment time rather than the payment itself.","questions":[{"text":"Which event starts the payment period - invoice date, delivery, or acceptance of goods?","id":"q-payment-trigger-event","kind":"temporal"},{"text":"Does the order constrain the payment means or instrument the seller may use to collect?","id":"q-payment-means-constraint","kind":"constraint"},{"text":"Are early-settlement discounts or late-payment penalties stated, and on what base are they computed?","id":"q-settlement-discount","kind":"requirement"}]},{"id":"framework-agreement-and-clause-references","name":"Framework agreement and clause references","description":"UBL Order carries a Contract reference, and FAR distinguishes a blanket purchase agreement from the calls placed against it; the order incorporates terms by reference rather than restating them.","questions":[{"text":"Which external terms documents are incorporated into this order, and at which version?","id":"q-incorporated-terms","kind":"provenance"},{"text":"What precedence applies between the order face, the incorporated terms and any framework agreement?","id":"q-terms-precedence-order","kind":"constraint"},{"text":"How much of the framework's ceiling does this order consume, and who maintains the running balance?","id":"q-framework-consumption","kind":"relationship"}]}]}]},{"id":"fulfilment-instruction-and-delivery","name":"Fulfilment instruction and delivery","description":"Where and when the buyer requires delivery, on what trade terms, and how the order links to the obligations it creates.","layers":[{"id":"delivery-instructions-and-terms","name":"Delivery instructions and terms","description":"Destination, requested timing and the trade terms that allocate cost and risk.","findings":[{"id":"delivery-destination-and-schedule","name":"Delivery destination and requested schedule","description":"The order states where delivery is required and when, at header or line level; GLN identifies ship-to locations and delivery windows are commonly expressed as periods rather than instants.","questions":[{"text":"How is each delivery destination identified, and does the identifier denote a legal entity, a function or a physical place?","id":"q-destination-identification","kind":"spatial"},{"text":"Is the requested delivery expressed as a single date, a window, or a schedule of dated instalments per line?","id":"q-schedule-granularity","kind":"temporal"},{"text":"When header and line delivery instructions differ, which one governs for that line?","id":"q-header-versus-line-delivery","kind":"constraint"},{"text":"Who may change a requested delivery date without a formal order amendment, and within what limits?","id":"q-schedule-change-authority","kind":"authority"}]},{"id":"delivery-terms-and-risk-transfer","name":"Delivery terms and risk transfer","description":"Incoterms 2020 supply eleven trade terms that allocate tasks, costs and risk between seller and buyer; a term is only meaningful with the named place and the rules edition.","questions":[{"text":"Which trade term applies, under which rules edition, and at exactly which named place?","id":"q-incoterm-and-named-place","kind":"classification"},{"text":"At what point does risk in the goods pass from seller to buyer under the stated term?","id":"q-risk-transfer-point","kind":"state"},{"text":"Which costs - carriage, insurance, export and import clearance, duties - fall to each party under the stated term?","id":"q-cost-allocation-split","kind":"requirement"},{"text":"Is transfer of title addressed anywhere on the order, given that the trade term does not determine it?","id":"q-title-versus-risk","kind":"ownership"}]}]},{"id":"fulfilment-linkage-and-tolerances","name":"Fulfilment linkage and tolerances","description":"How the order's obligations are discharged, what variance is tolerated, and how fulfilment events attach back to lines.","findings":[{"id":"tolerance-substitution-and-obligation-linkage","name":"Tolerance, substitution and fulfilment obligation linkage","description":"Peppol line response codes allow a line to be changed for quantity, delivery period, replacement item or price, or reported as already delivered, so the order must state permitted variance and carry links to the obligations and fulfilment events it generates.","questions":[{"text":"What over- or under-delivery tolerance is permitted per line before the delivery is non-conforming?","id":"q-quantity-tolerance","kind":"constraint"},{"text":"May the seller substitute an equivalent item, and who decides equivalence?","id":"q-substitution-permission","kind":"decision"},{"text":"Are partial deliveries permitted, and does a partial delivery close the line or leave a residual obligation?","id":"q-partial-fulfilment-rule","kind":"lifecycle"},{"text":"How does each fulfilment event attach back to the specific order line and schedule instalment it discharges?","id":"q-obligation-linkage","kind":"relationship"}]}]}]},{"id":"lifecycle-and-change-control","name":"Lifecycle and change control","description":"The states an order passes through, how a seller response moves it, and how it is amended, cancelled or closed.","layers":[{"id":"lifecycle-states-and-responses","name":"Lifecycle states and responses","description":"The order state model and the response semantics that drive transitions.","findings":[{"id":"order-state-model-and-transitions","name":"Order state model and transitions","description":"An order moves from drafted through approved, issued, acknowledged, accepted or rejected, in fulfilment, and closed or cancelled; FAR makes acceptance the transition that converts an offer into a binding contract.","questions":[{"text":"Which states does an order occupy, and which of them are terminal?","id":"q-state-set-and-terminality","kind":"state"},{"text":"Which event triggers each transition, and is the trigger internal to the buyer or an inbound seller message?","id":"q-transition-triggers","kind":"lifecycle"},{"text":"Is the order state stored explicitly or derived from the event history, and which is authoritative on conflict?","id":"q-state-derivation","kind":"process"},{"text":"What happens when no seller response arrives within the expected window?","id":"q-stalled-order-handling","kind":"exception"}]},{"id":"order-response-and-acceptance-semantics","name":"Order response and acceptance semantics","description":"Peppol defines header codes AB (received, not processed), RE (rejected), AP (accepted without change) and CA (accepted with line amendments, all lines required), and line codes 1 added, 3 changed, 5 accepted, 7 rejected, 42 already delivered; one response refers to exactly one order.","questions":[{"text":"Which response codes are recognised at header and line level, and how does each map to an internal order state?","id":"q-response-code-mapping","kind":"classification"},{"text":"When a response accepts with amendments, does the amended content become binding automatically or require buyer confirmation?","id":"q-conditional-acceptance-effect","kind":"decision"},{"text":"Can several responses relate to one order over time, and which one expresses the current position?","id":"q-multiple-responses","kind":"relationship"},{"text":"How is acceptance recognised when the seller simply performs instead of sending a response?","id":"q-acceptance-by-performance","kind":"event"}]},{"id":"issue-time-and-validity-window","name":"Issue time and validity window","description":"UBL requires IssueDate assigned by the sender and permits IssueTime and ValidityPeriod. Peppol requires IssueDate and permits IssueTime. These are event times of issuance, not identifiers.","questions":[{"text":"When did the buyer issue this order, as an event timestamp distinct from when a gateway or agent later observed or ingested it?","id":"issue-time-and-validity-window-q01","kind":"temporal"},{"text":"For what period is the order valid as an offer, and what happens if the seller responds after that window?","id":"issue-time-and-validity-window-q02","kind":"lifecycle"},{"text":"How is the Peppol date-without-timezone issue date combined with optional issue time into an RFC 3339 event time with seconds and explicit offset for this Dimension?","id":"issue-time-and-validity-window-q03","kind":"constraint"}]}]},{"id":"amendment-cancellation-and-closure","name":"Amendment, cancellation and closure","description":"Controlled change to an issued order and the routes by which it ends.","findings":[{"id":"amendment-and-change-control","name":"Amendment and change control","description":"UBL provides an OrderChange document and FAR requires each modification to identify the order being changed and to carry an appropriate modification number, with contractor acceptance required only in defined cases.","questions":[{"text":"Which fields may be amended after issuance, and which require a new order instead?","id":"q-amendable-fields","kind":"constraint"},{"text":"Does the amendment require the seller's written acceptance to take effect, or does it bind unilaterally?","id":"q-amendment-acceptance-needed","kind":"authority"},{"text":"How is each amendment numbered and linked to the order and revision it changes?","id":"q-amendment-numbering","kind":"identity"},{"text":"What happens to fulfilment already in progress or already delivered when an amendment takes effect?","id":"q-amendment-effect-on-fulfilment","kind":"process"}]},{"id":"cancellation-and-closure","name":"Cancellation, termination and closure","description":"FAR distinguishes cancelling an order the supplier has not accepted from terminating one already accepted, and UBL provides an OrderCancellation document; closure is a separate, non-adversarial end state.","questions":[{"text":"Has the seller accepted the order, and does that make this a cancellation of an unaccepted offer or a termination of a contract?","id":"q-cancel-versus-terminate","kind":"decision"},{"text":"Does the seller claim costs incurred before cancellation, and how is that claim recorded against the order?","id":"q-cancellation-cost-claim","kind":"exception"},{"text":"What conditions must all lines satisfy before the order may be closed as complete?","id":"q-closure-criteria","kind":"lifecycle"},{"text":"May a closed or cancelled order be reopened, and what evidence must the reopening record carry?","id":"q-reopening-a-closed-order","kind":"exception"}]}]}]},{"id":"governance-evidence-and-interoperability","name":"Governance, evidence and interoperability","description":"Provenance and time semantics, retention and access, and the syntax and validation rules that let the order cross system boundaries.","layers":[{"id":"provenance-and-audit-evidence","name":"Provenance and audit evidence","description":"Where the order's content came from, when things happened, and what proves it.","findings":[{"id":"provenance-transmission-and-time-semantics","name":"Provenance, transmission evidence and time semantics","description":"An order needs a recorded origin (requisition, quotation, catalogue), proof of transmission and receipt, and time values that separate when something happened from when it was observed; RFC 3339 requires an explicit offset and forbids unqualified local time.","questions":[{"text":"From which upstream record did each part of the order's content originate, and was any value manually overridden?","id":"q-content-origin","kind":"provenance"},{"text":"What evidence proves the order was transmitted to, and received by, the intended seller?","id":"q-transmission-evidence","kind":"evidence"},{"text":"Where an order event time and the time it was recorded differ, are both retained and which is used for deadline calculation?","id":"q-event-versus-ingestion-time","kind":"temporal"},{"text":"Which actor - human, service account or agent - performed each recorded action on the order?","id":"q-actor-attribution","kind":"security"}]},{"id":"signature-attachment-and-integrity-evidence","name":"Signatures, attachments and validation","description":"UBL supports enveloped XML digital signatures and XAdES. Peppol permits Base64 attachments or URI links and recommends embedded objects; attachments are additional information, not order copies. Peppol fatal rules require CustomizationID, ProfileID, ID, IssueDate, DocumentCurrencyCode, Buyer, Seller and OrderLine, and forbid extra elements and schemaLocation. UBL conformance is XSD plus additional document constraints; senders must manifest all calculated values.","questions":[{"text":"Is the order signed, with which signature profile, and what integrity hash binds the signature to the issued content?","id":"signature-attachment-and-integrity-evidence-q01","kind":"evidence"},{"text":"Which additional binary or URI attachments accompany the order, and are they supporting drawings rather than a second copy of the order?","id":"signature-attachment-and-integrity-evidence-q02","kind":"evidence"},{"text":"Which XSD, Schematron and profile business rules were applied, and did the instance pass the fatal Peppol and UBL constraints?","id":"signature-attachment-and-integrity-evidence-q03","kind":"validation"},{"text":"Are all fixed and calculated amounts manifested by the sender so the receiver is not required to recompute the calculation model?","id":"signature-attachment-and-integrity-evidence-q04","kind":"quality"}]}]},{"id":"retention-access-and-confidentiality","name":"Retention, access and confidentiality","description":"How long the order and its evidence are kept, and who may see or change them.","findings":[{"id":"retention-and-disposition","name":"Retention and disposition","description":"FAR 4.703 sets a baseline of three years after final payment, 4.705-1 requires four years for purchase orders in financial records and 4.705-3 four years for purchase order files, calculated from the end of the fiscal year in which the entry is made; intermingled categories take the longest applicable period.","questions":[{"text":"From which event does the retention clock start for this order, and does a fiscal-year rule apply?","id":"q-retention-clock-start","kind":"retention"},{"text":"When the order file mixes record categories with different periods, which period governs the whole file?","id":"q-longest-period-rule","kind":"constraint"},{"text":"What suspends disposition, and how is a hold recorded and released?","id":"q-litigation-hold","kind":"exception"},{"text":"What proves that an order and its attachments were actually disposed of at the end of retention?","id":"q-disposition-evidence","kind":"evidence"}]},{"id":"access-and-commercial-confidentiality","name":"Access control and commercial confidentiality","description":"Order content is commercially sensitive - negotiated prices, volumes and supplier terms - and access differs sharply between the buyer, the seller and third parties such as auditors or forwarders.","questions":[{"text":"Which fields is each counterparty entitled to see, and which are buyer-internal only?","id":"q-visibility-per-party","kind":"access"},{"text":"Under what authority may the order be disclosed to an auditor, forwarder or regulator, and is disclosure logged?","id":"q-third-party-disclosure","kind":"privacy"},{"text":"Which roles may change an issued order, and does the seller ever gain write rights over any part of it?","id":"q-mutation-rights","kind":"ownership"},{"text":"Does the order carry personal data such as named contacts or delivery recipients, and what minimisation applies?","id":"q-personal-data-on-order","kind":"privacy"}]}]},{"id":"interoperability-and-validation","name":"Interoperability and validation","description":"How the order is bound to an exchange syntax and profile, and how it is validated and matched.","findings":[{"id":"syntax-binding-profile-and-code-lists","name":"Syntax binding, profile declaration and code lists","description":"Peppol requires ProfileID and CustomizationID on both order and response and binds them to UBL 2.1; UBL 2.4 is a later document model, and UN/CEFACT Buy-Ship-Pay provides a syntax-neutral semantic anchor, so a projection must declare both its syntax and its profile.","questions":[{"text":"Which profile and customization identifiers does an exchanged projection of this order declare?","id":"q-profile-declaration","kind":"interoperability"},{"text":"Which code lists and versions do the coded fields draw on, and how are version changes handled?","id":"q-code-list-versioning","kind":"validation"},{"text":"To which syntax-neutral semantic model do the order's terms map, so that two syntaxes can be compared?","id":"q-semantic-anchor","kind":"interoperability"},{"text":"Which fields are lost or approximated when the order is projected into a narrower syntax, and is that loss recorded?","id":"q-lossy-projection","kind":"quality"}]},{"id":"validation-matching-and-reference-integrity","name":"Validation, matching and downstream reference integrity","description":"Beyond syntax validity, an order must satisfy business rules (each line carries an item identifier and/or name; a response refers to exactly one order) and must remain resolvable from downstream documents that quote it as BT-13 or BT-14.","questions":[{"text":"Which validation rules are fatal, which are warnings, and who may waive a warning?","id":"q-rule-severity","kind":"validation"},{"text":"On what criteria and within what tolerance is the order matched to receipt and invoice before payment is released?","id":"q-match-tolerance","kind":"measurement"},{"text":"What happens when a downstream document quotes an order reference that does not resolve, or resolves to a superseded revision?","id":"q-broken-reference","kind":"exception"},{"text":"How is it verified that an order re-imported from an exchanged projection is semantically identical to the source?","id":"q-round-trip-fidelity","kind":"quality"}]}]}]}]},"agentConduct":{"may":["Compose and validate an order against item, party and terms references.","Register order responses and acceptance by performance.","Amend an order through the recorded change process.","Release call-offs against a framework within its limits."],"mustNot":["Issue an order while an unwaived fatal validation failure stands.","Issue an order without verified commitment authority.","Treat order totals as settled amounts.","Share order content with unauthorised parties.","Treat an unanswered order as accepted unless the terms say so."],"requiresHuman":["Approving orders above delegated limits.","Cancelling an accepted order with cost consequences."]},"ethics":{"considerations":["Purchasing choices affect suppliers' livelihoods and supply chain labour conditions.","Fair and transparent ordering matters especially in public procurement."],"affectedParties":["Buyers and requisitioners","Suppliers","Public funders in public procurement"]},"owners":{"steward":"A single adopting Dimension must own the order identifier scheme and declare its uniqueness domain before any order is issued, so that every downstream reference resolves deterministically.","roles":[{"name":"Order owner (buyer-side requisitioner or category owner)","responsibilities":["Define the requirement, item identification and requested delivery on the draft order.","Confirm that the order draws on the correct framework agreement or quotation.","Decide on substitution and residual write-off within delegated limits."]},{"name":"Commitment authority (contracting officer or authorised approver)","responsibilities":["Verify authority and thresholds before issuance and record the approval with its instant.","Authorise amendments, cancellations and terminations and select the correct procedural route.","Waive non-fatal validation findings with a recorded reason."]},{"name":"Order operations steward","responsibilities":["Maintain the identifier scheme, revision series and line identifier stability rules.","Register order responses and fulfilment linkages and resolve match exceptions.","Close orders once closure criteria are met and start the retention clock."]},{"name":"Interoperability steward","responsibilities":["Own profile, customization and code list version bindings and the mappings to external alignment targets.","Review projections for information loss and maintain loss records.","Fail closed on unrecognised profile or code list versions rather than guessing."]},{"name":"Records and retention officer","responsibilities":["Assign the governing retention rule to each order file and compute disposition dates.","Place and release holds and evidence every disposition action.","Enforce the longest applicable period across intermingled record categories."]},{"name":"Access and confidentiality controller","responsibilities":["Maintain the role-to-field visibility matrix and the counterparty projection definitions.","Authorise and log third-party disclosures to auditors, forwarders and regulators.","Review personal data carried on orders against minimisation requirements."]}],"masterSystems":[]},"relations":[{"target":"WM-ECO-006","type":"child","note":"The purchase order is a specialised instrument under the parent commercial agreement model; the parent owns clause bodies, negotiated terms and agreement lifecycle, while this model owns the order instrument itself."},{"target":"WM-ECO-024","type":"composes","note":"Order lines and delivery instalments generate fulfilment obligations owned by the contained model; this model contributes the obligation-creating terms and the linking references, not the fulfilment events."},{"target":"WM-ECO-021","type":"references","note":"An order may originate from an accepted quotation; the quotation reference is retained here while quotation content and pricing logic stay in the sibling model."},{"target":"Invoice and settlement model (not yet registered in vr.wm-eco)","type":"references","note":"Invoices quote the order as EN 16931 BT-13 and may carry BT-14; the reference integrity rules live here but invoice content and tax determination do not. The target model identifier is a registry gap."},{"target":"OASIS Universal Business Language 2.4 Order document model","type":"aligned","note":"Alignment target for header business information entities, OrderLine/LineItem structure and the OrderResponse, OrderChange and OrderCancellation companions. Alignment only; no conformance claim is made."},{"target":"OpenPeppol BIS Ordering 3.3","type":"aligned","note":"Alignment target for order and order response exchange, header and line response codes, one-response-per-order rule, line identifier matching and profile/customization declaration."},{"target":"UN/CEFACT Buy-Ship-Pay Reference Data Model (vocabulary D23B)","type":"aligned","note":"Syntax-neutral semantic anchor for trade transaction, party, trade line item and delivery concepts, used to compare projections across syntaxes."},{"target":"GS1 identification keys (GLN and trade item keys)","type":"aligned","note":"Alignment target for scheme-qualified party, location and item identifiers, including ISO 6523 ICD 0088 compatibility and the GLN non-reuse policy."},{"target":"ICC Incoterms 2020 rules","type":"aligned","note":"Alignment target for the delivery term code, named place and rules edition that allocate task, cost and risk; the rules text itself remains external."},{"target":"United Nations Convention on Contracts for the International Sale of Goods","type":"aligned","note":"Alignment target for offer-and-acceptance formation semantics and buyer/seller obligations in cross-border sales, where the convention applies and has not been excluded."},{"target":"IETF RFC 3339 date-time profile","type":"aligned","note":"Alignment target for every timestamp on the order, requiring explicit seconds and an explicit offset or Z rather than unqualified local time."},{"target":"US Federal Acquisition Regulation Parts 4 and 13","type":"aligned","note":"Jurisdiction-specific alignment for offer/acceptance treatment, modification numbering, cancellation versus termination, and purchase order file retention periods. Applies to US federal acquisition only."},{"target":"Quotation / RFQ (WM-ECO-021)","type":"neighbor","note":"A quotation is seller-originated and, under FAR 13, is not an offer that the buyer can accept to form a contract; the purchase order is the buyer-originated instrument. UBL keeps Quotation and Order as separate documents linked by QuotationDocumentReference, so quotation content stays in the sibling model and only the reference is held here."},{"target":"Fulfilment obligation (WM-ECO-024)","type":"neighbor","note":"The order states requested delivery; the obligations it creates and the performance events that discharge them (despatch, receipt, acceptance of goods) belong to the contained model. UBL and Peppol model despatch advice and receipt as separate documents."},{"target":"Contract / framework agreement (WM-ECO-006)","type":"neighbor","note":"The order references a contract rather than restating it; UBL Order carries a Contract reference, and FAR treats a blanket purchase agreement and the calls placed against it as different objects. Clause bodies and negotiated terms live in the parent model."},{"target":"Invoice and settlement","type":"neighbor","note":"The invoice references the order (EN 16931 BT-13 purchase order reference, BT-14 sales order reference); invoice content, tax breakdown and payment status are not order content, and the order carries only anticipated, not settled, monetary totals."},{"target":"Transport and delivery-terms rules","type":"neighbor","note":"Incoterms 2020 allocate delivery, cost and risk between seller and buyer but are a referenced trade-term code plus named place; the ICC rules themselves are external and are not restated in this model, and they do not determine price, title transfer or payment."},{"target":"Order response document","type":"neighbor","note":"An order response is a distinct document with its own identity and its own customization identifier in Peppol; this model holds the resulting acceptance state and the response reference on the order, not the response document's internal model."},{"target":"Party master data and identifier registries","type":"neighbor","note":"GS1 allocates and governs GLNs and ISO 6523 ICD schemes qualify party identifiers; the order cites identifiers under a declared scheme but does not own their allocation, reuse policy or registry lifecycle."},{"target":"WM-ECO-006","type":"parent"},{"target":"WM-ECO-024","type":"contains"}],"interaction":{"identity":{"applicability":"required","items":["Authoritative master-system identifier: the purchase order number assigned by the buyer's system of record, qualified by its issuing scheme, which is the identifier both parties and all downstream documents cite.","Governed global identifier or IRI: a scheme-qualified identifier issued by an external authority (for example a GS1 GLN for a party or location under ISO 6523 ICD 0088, or a profile/customization IRI for a projection) where the object is governed outside the buyer.","UUID or ULID minted by the adopting Dimension, used only where neither a master-system identifier nor a governed global identifier exists; it is a handle, never a substitute for the order number in counterparty-facing references.","A date, an issue period, a fiscal year or any date-bearing string is never an identifier and must not be embedded in one; ordering and recency are expressed by explicit timestamps and revision sequence numbers."]},"properties":{"applicability":"not-applicable","items":[]},"recognition":{"applicability":"optional","items":["A purchase order has a buyer-assigned number, buyer and seller, lines with items, quantities, prices and delivery terms.","Often confused with a sales order, a quotation, an invoice and a framework agreement."]},"capabilities":{"applicability":"required","items":["Resolve order reference: Bind an inbound reference to exactly one order and, where required, one revision.","Compose purchase order: Assemble a draft order from upstream demand, catalogue and framework terms, recording field-level provenance.","Validate order: Apply syntax, profile and business rules to an order and classify each failure by severity.","Authorise and issue order: Record commitment approval and issue the order to the seller as an offer, capturing transmission evidence.","Register order response: Record a seller response against exactly one order and apply its header and line codes to order state.","Record acceptance by performance: Derive acceptance from the seller commencing performance where no express response was sent.","Amend order: Issue a numbered modification that identifies the order and revision it changes and determines whether seller acceptance is required.","Release call-off against framework: Draw a release order against a framework agreement's ceiling and update the residual balance.","Link fulfilment and match: Attach fulfilment events to lines and instalments, compute outstanding quantities, and match order to receipt and invoice within tolerance.","Cancel or terminate order: End an order by the route appropriate to its acceptance status and record any resulting cost claim.","Close order: Close an order once every line satisfies its closure criteria and no residual obligation remains.","Apply retention and disposition: Compute the disposition date from the governing retention rule, honour holds, and evidence eventual disposal.","Project order to syntax: Render the order into a target exchange syntax and profile, declaring the binding and recording any information loss.","Calculate anticipated totals: Sender computes and manifests line extension, header allowances and charges and anticipated payable amounts using the Peppol formulae, without requiring the receiver to recompute.","Conclude contract on acceptance: Record that an acceptance has become effective, distinguishing CISG reach-the-offeror timing from MLEC dispatch and receipt of the data message."]},"hazards":{"applicability":"required","items":["Unauthorised commitments.","Duplicate orders causing overpayment.","Disputes from unclear acceptance status."]},"interfaces":{"applicability":"required","items":["UBL 2 Order and OrderResponse.","UN/EDIFACT ORDERS.","Peppol BIS ordering.","GS1 GTIN and GLN.","Incoterms 2020."]},"context":{"applicability":"required","items":["FAR Parts 4 and 13 govern US federal acquisition only. Their treatment of purchase orders as unilateral offers, modification numbering, cancellation versus termination, and the 3- and 4-year retention periods should not be assumed to apply to commercial buyers or to other jurisdictions.","Peppol BIS Ordering and BIS Billing reflect European post-award practice and their profile identifiers, EAS electronic address codes and ICD party schemes are governed by OpenPeppol; they carry no authority outside that network.","CISG applies only between parties whose places of business are in different contracting states (or where private international law points to one), and parties may exclude it by agreement; a purchase order under a domestic contract is governed by domestic sale-of-goods law instead.","GLN allocation, prefix length and the non-reuse policy effective 1 July 2022 are administered by GS1 Member Organisations; details cited here come from GS1 Australia and may differ in presentation, though not in the underlying standard, elsewhere.","Retention periods for commercial (non-government) purchase orders are set by national commercial, tax and accounting law and are not covered by any source consulted here.","Incoterms 2020 is the current edition but earlier editions remain in lawful use where a contract names them, so the edition must always be recorded with the term.","Peppol BIS Ordering is written for EU and EEA public eProcurement and B2B/B2G; it is an alignment, not a global mandate.","CISG applies to international sales of goods between contracting states and not automatically to services-only orders or to states that reserved Part II.","VAT, GST and sales-tax treatment of estimated tax on orders is regime-specific.","UN/EDIFACT ORDERS remains widely used in global retail and manufacturing independently of Peppol.","Public-sector buyers may be subject to EU procurement directives when using this BIS, as Peppol itself warns."]}},"sources":[{"title":"Universal Business Language Version 2.4","url":"https://docs.oasis-open.org/ubl/os-UBL-2.4/UBL-2.4.html","note":"OASIS Open"},{"title":"Peppol BIS Ordering 3.3","url":"https://docs.peppol.eu/poacc/upgrade-3/profiles/28-ordering/","note":"OpenPeppol AISBL (Post-Award Community)"},{"title":"Federal Acquisition Regulation Part 13 - Simplified Acquisition Procedures","url":"https://www.acquisition.gov/far/part-13","note":"U.S. Federal Acquisition Regulatory Council (acquisition.gov)"},{"title":"Federal Acquisition Regulation Subpart 4.7 - Contractor Records Retention","url":"https://www.acquisition.gov/far/subpart-4.7","note":"U.S. Federal Acquisition Regulatory Council (acquisition.gov)"},{"title":"United Nations Convention on Contracts for the International Sale of Goods (CISG)","url":"https://uncitral.un.org/en/texts/salegoods/conventions/sale_of_goods/cisg","note":"United Nations Commission on International Trade Law (UNCITRAL)"},{"title":"RFC 3339 - Date and Time on the Internet: Timestamps","url":"https://www.rfc-editor.org/rfc/rfc3339","note":"Internet Engineering Task Force (IETF)"},{"title":"UN/CEFACT Web Vocabularies (Buy-Ship-Pay Reference Data Model)","url":"https://vocabulary.uncefact.org/","note":"UNECE / UN/CEFACT"},{"title":"Global Location Number (GLN)","url":"https://www.gs1au.org/what-we-do/standards/global-location-number-gln","note":"GS1 Australia (GS1 Member Organisation)"},{"title":"Incoterms rules","url":"https://iccwbo.org/business-solutions/incoterms-rules/","note":"International Chamber of Commerce (ICC)"},{"title":"Peppol BIS Billing 3.0 - cac:OrderReference","url":"https://docs.peppol.eu/poacc/billing/3.0/syntax/ubl-invoice/cac-OrderReference/","note":"OpenPeppol AISBL"},{"title":"Blanket order","url":"https://en.wikipedia.org/wiki/Blanket_order","note":"Wikimedia Foundation"},{"title":"UBL 2.4 os - UBL-Order-2.4 data model","url":"https://docs.oasis-open.org/ubl/os-UBL-2.4/mod/summary/reports/UBL-Order-2.4.html","note":"OASIS Open"},{"title":"Peppol Order transaction 3.7 (T01) syntax binding to UBL Order","url":"https://docs.peppol.eu/poacc/upgrade-3/syntax/Order/","note":"OpenPeppol AISBL Post-Award Community"},{"title":"UN/EDIFACT Message ORDERS — Purchase order message, Release 99B","url":"https://service.unece.org/trade/untdid/d99b/trmd/orders_c.htm","note":"United Nations Economic Commission for Europe (UN/CEFACT)"},{"title":"UNCITRAL Digest of Case Law on the United Nations Convention on Contracts for the International Sale of Goods","url":"https://uncitral.un.org/sites/uncitral.un.org/files/media-documents/uncitral/en/cisg_digest_2016.pdf","note":"United Nations Commission on International Trade Law"},{"title":"UNCITRAL Model Law on Electronic Commerce with Guide to Enactment 1996, with additional article 5 bis as adopted in 1998","url":"https://uncitral.un.org/sites/uncitral.un.org/files/media-documents/uncitral/en/19-04970_ebook.pdf","note":"United Nations Commission on International Trade Law"}],"openQuestions":["UN/EDIFACT ORDERS D.99B and ANSI ASC X12 850/855/860/865 mapping to the model's semantics. The base could not retrieve either (UNECE 403, x12.org did not expose the 850 transaction set) and X12 TR3 content is membership-gated, so classic EDI remains an alignment gap rather than a modelled node; this is the largest interoperability weakness in the merged model.","UNCITRAL Model Law on Electronic Commerce art. 10 as a jurisdiction-neutral retention basis requiring data messages to be retained in accessible, integrity-preserving form with origin, destination and dispatch and receipt times, together with at least one national commercial-books retention regime, to break the merged model's dependence on US federal retention periods.","Reconciliation of UBL full Order Response replace-entire-order-state semantics against Peppol partial acceptance and multiple responses per order, so both patterns are represented without collapsing either into the other.","Typed related-document references for Catalogue and Project on the order, plus UBL CopyIndicator original-versus-copy semantics, both present in the Grok pack but too narrow to admit as structure in this pass.","Tax determination on orders including VAT category codes, reverse charge and place-of-supply rules, for which neither provider verified any primary source.","Services procurement modelled distinctly from goods, covering statements of work, milestone-based acceptance and progress payments, which the base currently treats identically to goods at line level.","Public-sector order metadata including procurement procedure reference, CPV or UNSPSC classification obligations and contract award notice linkage, absent from both packs.","Electronic signature and sealing formats for orders and the legal weight of each beyond the UBL XAdES and Peppol non-mandate facts merged in this pass, including transport security, non-repudiation levels and key management for sealed revisions.","UN/EDIFACT ORDERS and ANSI ASC X12 850/855/860/865 are the two most widely deployed order syntaxes and neither could be retrieved live (UNECE service returned HTTP 403; x12.org did not expose the 850 transaction set on the page fetched). Their mapping is therefore absent rather than asserted, and the interoperability layer is weaker for classic EDI than for UBL and Peppol.","No source was verified for tax determination on orders (VAT category codes, reverse charge, place-of-supply), so tax is modelled only as an indicative amount and a code-list reference.","Consignment, vendor-managed inventory, scheduling agreements and just-in-time delivery call-offs are acknowledged as purchasing patterns but not modelled in detail; each may need its own contained model.","Services procurement (timesheets, milestones, statements of work) is treated identically to goods at the line level, which understates milestone-based acceptance and progress payment structures.","Electronic signature and sealing formats for orders, and the legal weight of each, are not covered.","Currency of account versus currency of settlement, and hedging or price-adjustment clauses, are only gestured at through the price-status question.","Public-sector specific order metadata (procurement procedure reference, CPV/UNSPSC classification obligations, contract award notice linkage) is not modelled.","ICC Incoterms 2020 official text was not fetched; UBL only cites CIF, FOB and EXW as example delivery-term alignments","United States UCC Article 2 and FAR/DFARS federal purchase orders were not independently retrieved as primary sources","ASC X12 850/855 TR3 content is membership-gated; North American EDI is an alignment gap rather than a canonical node","UN/CEFACT Buyer's Order CCL / SCRDM was not fetched beyond EDIFACT ORDERS D.99B","Standing, rush, subscription and digital-goods or SaaS order semantics lack first-party coverage here","Islamic financing purchase instruments and letter-of-credit specific order clauses are not modelled","Line-level cancellation as a first-class document distinct from Order Change is not specified by the cited UBL process","National commercial-books retention periods (often five to ten years) are jurisdiction-specific and not enumerated","GDPR and other privacy statutes are not cited; only the presence of contact personal data on Peppol/UBL parties is sourced"],"resources":{"spec":"/models/wm-eco-019-purchase-order/spec.yaml","agents":"/models/wm-eco-019-purchase-order/AGENTS.md","source":"https://github.com/ver-cy/world-models/tree/feat/mega-model-registry/research/runs/wm-eco-019"},"provenance":{"origin":"world-models research","builtFrom":["models/wm-eco-019-purchase-order/spec.yaml","ver-cy/world-models/card-supplements/wm-eco-019-purchase-order.json"],"providers":["Claude","Grok"],"researchStatus":"reviewable-draft","generatedAt":"2026-08-25T15:13:16Z","builder":"tools/build_cards.py@1.0.0"},"completeness":{"sections":{"classifiers":"filled","whatItIs":"filled","purpose":"filled","distinguishingFeatures":"filled","structure":"filled","agentConduct":"filled","ethics":"filled","owners":"filled","relations":"filled","interaction.identity":"filled","interaction.properties":"not-applicable","interaction.recognition":"filled","interaction.capabilities":"filled","interaction.hazards":"filled","interaction.interfaces":"filled","interaction.context":"filled","sources":"filled"},"notes":{"interaction.properties":"Institutional or informational subject: no invented physical properties.","_supplement":"Sections authored in card supplement 1.0.0 by Claude (Opus 5.5) (2026-10-05, unreviewed). Written from the published specification and established practice in the field; no new sources were read. Unreviewed."},"score":1.0}}