# Vercy AI instruction - YAML 1.2 (JSON-compatible) { "vercy": "1.0-draft", "publication": { "status": "published", "adjudicationStatus": "reviewable-draft", "publishableCanonical": false, "generatedAt": "2026-08-29T20:03:09Z", "synthesisSha256": "5213ae7dd05ea64832d47b25da182d983e0bcdce1166a19b73875bf1a6b04e8e", "providerMode": "single-provider-waiver", "providers": [ "Claude" ], "waivedProviders": [ "Grok" ] }, "metaModel": { "id": "WM-ECO-020", "registryId": "vr.wm-eco-020", "name": "Sales Order", "version": "0.3.0-research.1", "previousVersions": [], "entryKind": "aggregate", "family": "World Models", "category": "Society, people and institutions", "industry": [ "Cross-industry" ], "domain": [ "SOC.ECO.ORD" ], "tags": [ "sales", "order", "soc.eco.ord" ], "status": "published" }, "canonicalUrl": "https://ver.cy/models/wm-eco-020-sales-order/", "sourceUrl": "https://github.com/ver-cy/world-models/tree/feat/mega-model-registry/research/runs/wm-eco-020", "model": { "registry_id": "vr.wm-eco-020", "model_id": "WM-ECO-020", "name": "Sales Order", "entry_kind": "aggregate", "purpose": "Give an agent the context needed to understand, create, inspect and operate a seller-side sales order across acceptance, commitment, fulfilment and closure, independent of storage format or interface.", "scope_statement": "The sales order as held by the seller: the order record and its lines; the party roles and authority that bind it; the priced, delivery and payment terms it carries; the seller's disposition of the order (acceptance, amendment, rejection, counter-offer); state, change, cancellation and hold control; allocation and despatch linkage; delivered-versus-outstanding accounting; post-delivery claims; and closure. It carries references, bindings and recorded outcomes for neighbouring concerns and never reproduces their lifecycles or enforcement semantics.", "in_scope": [ "Seller-assigned order identity, versioning and line structure", "Party roles on the order and the authority under which it was committed or changed", "Priced quantities, allowances and charges, currencies, and the delivery and payment terms carried on the order", "Seller disposition at header and line level, including counter-offer and conditional acceptance", "Order and line state, permitted transitions, holds, blocks and exception paths", "Availability promise, allocation and fulfilment schedule lines derived from accepted lines", "Despatch linkage to order lines and delivered, outstanding and oversupply quantity accounting", "Post-delivery claims recorded against order lines, and order completion and closure", "Validation rule and code list bindings with recorded outcomes", "Provenance of the inbound order message and separation of event time from ingestion time", "Sensitivity classification, disclosable subsets and retention bindings for the order record" ], "out_of_scope": [ "Buyer-side requisition, approval and procurement budget lifecycle", "Invoice, credit note, tax determination and fiscal reporting", "Payment instrument issuance, settlement, dunning and credit scoring", "Carrier booking, transport documents, customs declarations and physical movement", "Inventory ledger balances, replenishment and warehouse location lifecycle", "Trade item master, classification and catalogue lifecycle", "Party master identity, deduplication and identifier-scheme registration", "Quotation negotiation and framework agreement lifecycle", "Reverse logistics execution and refund settlement", "Execution of validation rules, policy enforcement and audit-trail storage", "Revenue recognition and performance-obligation accounting" ], "boundary_notes": [ { "neighbor": "Buyer-side purchase order and procurement model", "distinction": "The same order document is read from the opposite role. This model begins when the seller receives or captures the order and owns only seller-side disposition, commitment and fulfilment; requisition, approval and buyer budget control stay with the procurement model.", "source_refs": [ "SRC-002", "SRC-004" ] }, { "neighbor": "Invoice and credit note model", "distinction": "Order tax totals and anticipated monetary totals are indicative buyer expectations, not fiscal determinations. The legally binding priced document, tax determination and e-invoicing compliance obligations belong to the invoice model.", "source_refs": [ "SRC-002", "SRC-012" ] }, { "neighbor": "Despatch, shipment and transport execution model", "distinction": "The order holds despatch and consignment references and the delivered, outstanding and oversupply accounting per line. Shipment structure, carrier detail and physical transport execution are owned by the despatch and transport models.", "source_refs": [ "SRC-005" ] }, { "neighbor": "Quotation, contract and framework agreement model", "distinction": "The order cites the upstream commercial basis and any call-off parameters, but negotiation, agreement lifecycle and term precedence remain with the agreement model.", "source_refs": [ "SRC-002", "SRC-004" ] }, { "neighbor": "Trade item and trade party master models", "distinction": "Order lines and party roles carry scheme-qualified references plus the snapshot actually agreed at order time. Master attribute stewardship and identifier-scheme governance stay with those models.", "source_refs": [ "SRC-002", "SRC-004", "SRC-005" ] }, { "neighbor": "Trade term rule set (delivery terms classifier)", "distinction": "The order binds a coded trade term rule to a named place and records the resulting obligation split. The rule set's content, versioning and interpretation are owned by its publisher, and transfer of title falls outside it.", "source_refs": [ "SRC-010" ] }, { "neighbor": "Applicable sales law and consumer protection regimes", "distinction": "The order records an applicability determination and citation only. Uniform international sales law does not cover consumer sales, so consumer duties come from jurisdictional instruments this model references but does not restate.", "source_refs": [ "SRC-009" ] }, { "neighbor": "Records management, data protection and audit models of the adopting Dimension", "distinction": "This model declares classification, retention triggers, tombstone content and evidence pointers. Execution of retention, erasure and audit-trail storage and immutability is owned by those models.", "source_refs": [ "SRC-006", "SRC-012" ] } ] }, "sources": [ { "id": "SRC-001", "title": "Universal Business Language Version 2.4", "organization": "OASIS Open", "url": "https://docs.oasis-open.org/ubl/os-UBL-2.4/UBL-2.4.html", "version_or_date": "OASIS Standard, 20 June 2024", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-29T09:12:00Z", "relevance": "Defines the order-to-invoice document family (Order, OrderResponse, OrderResponseSimple, OrderChange, OrderCancellation, DespatchAdvice, ReceiptAdvice) that bounds the seller-side ordering and fulfilment surface." }, { "id": "SRC-002", "title": "UBL-Order-2.4.xsd (UBL 2.4 Order document schema)", "organization": "OASIS Open", "url": "https://docs.oasis-open.org/ubl/os-UBL-2.4/xsd/maindoc/UBL-Order-2.4.xsd", "version_or_date": "UBL 2.4 OASIS Standard, 20 June 2024", "source_type": "schema", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-29T09:12:00Z", "relevance": "Normative element inventory and cardinality for the order header: ID, SalesOrderID, UUID, IssueDate and IssueTime, OrderTypeCode, currency codes, ValidityPeriod, document references, party roles, Delivery, DeliveryTerms, PaymentMeans and PaymentTerms, DestinationCountry, TaxTotal, AnticipatedMonetaryTotal and OrderLine." }, { "id": "SRC-003", "title": "UBL-OrderResponse-2.4.xsd (UBL 2.4 Order Response document schema)", "organization": "OASIS Open", "url": "https://docs.oasis-open.org/ubl/os-UBL-2.4/xsd/maindoc/UBL-OrderResponse-2.4.xsd", "version_or_date": "UBL 2.4 OASIS Standard, 20 June 2024", "source_type": "schema", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-29T09:12:00Z", "relevance": "Grounds the seller disposition surface: OrderResponseCode, SalesOrderID, mandatory OrderReference (1..n), LegalMonetaryTotal as the counter-offer total, and the party and terms restatement permitted on a response." }, { "id": "SRC-004", "title": "Peppol BIS Ordering 3.3", "organization": "OpenPeppol AISBL", "url": "https://docs.peppol.eu/poacc/upgrade-3/profiles/28-ordering/", "version_or_date": "Version 3.3, Post-Award Community profile (binds UBL 2.1)", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-29T09:12:00Z", "relevance": "Supplies the concrete disposition vocabulary (header codes AB, RE, AP and CA; line codes 1, 3, 5, 7 and 42), the all-lines-restated rule for amended responses, amount precision rules, item identification and framework agreement references." }, { "id": "SRC-005", "title": "Peppol BIS Despatch Advice 3.1", "organization": "OpenPeppol AISBL", "url": "https://docs.peppol.eu/poacc/upgrade-3/profiles/30-despatchadvice/", "version_or_date": "Version 3.1, Post-Award Community profile", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-29T09:12:00Z", "relevance": "Grounds order-to-fulfilment linkage: header versus line OrderReference, DeliveredQuantity, OutstandingQuantity and OutstandingReason, oversupply, lot, serial and expiry instance data, consignment and shipment identification, and the NA placeholder convention." }, { "id": "SRC-006", "title": "Order - Schema.org Type", "organization": "Schema.org Community Group", "url": "https://schema.org/Order", "version_or_date": "Schema.org v30.0, 2026-03-19", "source_type": "ontology", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-29T09:12:00Z", "relevance": "Public web vocabulary for consumer-facing order publication: orderNumber, orderDate, orderStatus, orderedItem, orderDelivery, partOfInvoice, paymentDueDate, seller and customer; used as an alignment target rather than an internal state machine." }, { "id": "SRC-007", "title": "OrderStatus - Schema.org Type", "organization": "Schema.org Community Group", "url": "https://www.schema.org/OrderStatus", "version_or_date": "Schema.org v30.0, 2026-03-19", "source_type": "classifier", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-29T09:12:00Z", "relevance": "Enumerates eight externally published order status members (OrderProcessing, OrderPaymentDue, OrderInTransit, OrderDelivered, OrderPickupAvailable, OrderProblem, OrderCancelled, OrderReturned) used to stress-test and bound this model's state vocabulary." }, { "id": "SRC-008", "title": "RFC 3339: Date and Time on the Internet: Timestamps", "organization": "Internet Engineering Task Force", "url": "https://www.rfc-editor.org/rfc/rfc3339", "version_or_date": "RFC 3339, July 2002", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-29T09:12:00Z", "relevance": "Fixes the timestamp profile: date-time with seconds present and an explicit numeric offset or the Z designator, plus the -00:00 convention where UTC is known but the local offset is not." }, { "id": "SRC-009", "title": "United Nations Convention on Contracts for the International Sale of Goods (CISG)", "organization": "United Nations Commission on International Trade Law (UNCITRAL)", "url": "https://uncitral.un.org/en/texts/salegoods/conventions/sale_of_goods/cisg", "version_or_date": "Vienna, 1980; entered into force 1 January 1988", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-29T09:12:00Z", "relevance": "Supplies the default legal frame for offer and acceptance, seller delivery and document obligations, conformity, passing of risk and avoidance, and evidences that consumer sales are excluded and property effects fall outside it." }, { "id": "SRC-010", "title": "Incoterms 2020 rules", "organization": "International Chamber of Commerce", "url": "https://iccwbo.org/business-solutions/incoterms-rules/incoterms-2020/", "version_or_date": "Incoterms 2020 edition, in force from 1 January 2020", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-29T09:12:00Z", "relevance": "Defines the eleven delivery term rules and their allocation of cost, risk, insurance and clearance obligations; the consolidated A9 and B9 cost article and the DAT-to-DPU change bound how delivery terms are recorded on an order." }, { "id": "SRC-011", "title": "UN/CEFACT Web Vocabularies (Buy-Ship-Pay)", "organization": "United Nations Economic Commission for Europe (UN/CEFACT)", "url": "https://vocabulary.uncefact.org/", "version_or_date": "Buy-Ship-Pay vocabulary D23B; UN/LOCODE v2023-2", "source_type": "ontology", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-29T09:12:00Z", "relevance": "Places ordering inside the buy-ship-pay reference data model, supporting the parent-model boundary and the treatment of the order as one phase of a wider trade transaction rather than a self-contained arc." }, { "id": "SRC-012", "title": "EN 16931 compliance", "organization": "European Commission, DIGITAL Building Blocks (eInvoicing)", "url": "https://ec.europa.eu/digital-building-blocks/sites/spaces/DIGITAL/pages/467108950/EN+16931+compliance", "version_or_date": "Last updated 5 March 2026", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-29T09:12:00Z", "relevance": "Demonstrates that conformance is asserted against a named core model or restricted specification with published rules, and confirms that the fiscal invoice, not the order, is the compliance-bearing document." } ], "structure": { "bundles": [ { "id": "order-identity-and-scope", "name": "Order Identity and Scope", "description": "What a sales order record is, how it is identified, what it points at, and how its lines are structured and addressed.", "rationale": "UBL 2.4 anchors ordering on distinct sender-assigned and seller-assigned identifiers plus explicit document references, and Peppol requires addressable lines for any line-level disposition. Without settled identity and line structure, no state, promise or fulfilment claim can attach to anything.", "source_refs": [ "SRC-001", "SRC-002", "SRC-004" ], "layers": [ { "id": "order-identification-and-references", "name": "Identification and Outbound References", "description": "Identifiers borne by the sales order and the references that place it inside a wider trade transaction.", "source_refs": [ "SRC-002", "SRC-003", "SRC-004", "SRC-011" ], "findings": [ { "id": "order-identifier-set", "name": "Order identifier set and authoritative key", "description": "The distinct identifiers a sales order carries - the buyer's order document identifier, the seller-assigned sales order identifier, an optional surrogate and buyer cross-references - and which one is authoritative for the seller.", "source_refs": [ "SRC-002", "SRC-003", "SRC-006" ], "questions": [ { "id": "oid-authoritative-key", "text": "Which identifier is the seller's authoritative master-system key for this order, and which are secondary cross-references?", "kind": "identity", "answer_data": [ "Seller-assigned sales order identifier", "Buyer order document identifier", "Identifier role classification per value" ] }, { "id": "oid-uniqueness-scope", "text": "Within which namespace, issuing entity and time window must the order identifier be unique?", "kind": "constraint", "answer_data": [ "Identifier scheme or namespace", "Uniqueness scope statement", "Reuse or recycling prohibition" ] }, { "id": "oid-surrogate-minting", "text": "When neither an authoritative nor a governed identifier exists, what surrogate is minted and by whom?", "kind": "provenance", "answer_data": [ "Surrogate value (UUID or ULID)", "Minting authority reference", "Minting timestamp" ] }, { "id": "oid-cross-reference-carriage", "text": "How are buyer-supplied references carried so they cannot be mistaken for the seller's own key?", "kind": "interoperability", "answer_data": [ "Customer reference text", "Accounting cost or cost-centre code", "Reference role marker" ] } ], "data_elements": [ { "id": "de-sales-order-id", "name": "Sales order identifier", "description": "Identifier assigned by the seller's system of record for orders; the authoritative key for this aggregate.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-002", "SRC-003" ] }, { "id": "de-buyer-order-id", "name": "Buyer order document identifier", "description": "Identifier of the buyer's order document being fulfilled, carried as a cross-reference only.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "de-order-surrogate-uuid", "name": "Order surrogate identifier", "description": "Globally unique surrogate minted by the adopting Dimension when no authoritative or governed identifier is available.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] } ], "artifacts": [ { "id": "sales-order-record", "name": "Sales order record", "description": "The canonical seller-side record of one order: header identifiers, party roles, terms, lines, current version and state.", "media_or_form": [ "structured record", "business document instance" ], "serial": false, "identity_strategy": "Keyed by the seller-assigned sales order identifier scoped to the issuing seller entity; the buyer order identifier and any minted surrogate are carried as cross-references and never promoted to the primary key.", "source_refs": [ "SRC-002", "SRC-003" ] } ], "inline_only_rationale": null }, { "id": "order-document-references", "name": "Outbound commercial and supporting document references", "description": "References from the sales order to quotations, contracts and framework agreements, catalogues, originating requisitions, prior order versions and supporting attachments.", "source_refs": [ "SRC-002", "SRC-004", "SRC-011" ], "questions": [ { "id": "odr-upstream-basis", "text": "Which upstream commercial document establishes the terms this order draws on?", "kind": "relationship", "answer_data": [ "Quotation document reference", "Contract or framework agreement identifier", "Catalogue reference" ] }, { "id": "odr-restatement-rule", "text": "How much of a referenced document may be restated on the order, and what governs a conflict between the two?", "kind": "composition", "answer_data": [ "Restated element list", "Reference-only element list", "Precedence rule on conflict" ] }, { "id": "odr-attachment-integrity", "text": "How are supporting attachments referenced and what integrity evidence accompanies them?", "kind": "evidence", "answer_data": [ "Additional document reference identifier", "External locator or binary object handle", "Content digest value" ] } ], "data_elements": [ { "id": "de-upstream-doc-reference", "name": "Upstream commercial document reference", "description": "Scheme-qualified reference to the quotation, contract, framework agreement or catalogue underpinning the order.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002", "SRC-004" ] }, { "id": "de-supporting-attachment-ref", "name": "Supporting attachment reference", "description": "Reference to a supporting document with its locator and content digest.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] } ], "artifacts": [], "inline_only_rationale": "These are pointers into sibling models that own their own lifecycles (quotation, contract and framework agreement, catalogue, requisition). The order stores only the reference, its type, any restated values and the precedence rule; materialising the referenced documents here would fork models this one merely cites." } ] }, { "id": "order-typing-and-line-structure", "name": "Typing and Line Structure", "description": "Classification of the order as a whole and the compositional structure of its addressable lines.", "source_refs": [ "SRC-002", "SRC-004", "SRC-006", "SRC-009" ], "findings": [ { "id": "order-type-and-sales-channel", "name": "Order type, buyer segment and commercial pattern", "description": "How the order is classified: order type code, sales channel and originating actor, whether the buyer acts as a business or a consumer, and the commercial pattern such as call-off, blanket, consignment or drop-ship.", "source_refs": [ "SRC-002", "SRC-004", "SRC-006", "SRC-009" ], "questions": [ { "id": "otc-type-code", "text": "Which order type code and pinned code list classify this order?", "kind": "classification", "answer_data": [ "Order type code", "Code list identifier", "Pinned code list version" ] }, { "id": "otc-buyer-segment", "text": "Is the buyer acting in a business or consumer capacity, and what evidence supports that determination?", "kind": "decision", "answer_data": [ "Buyer segment classification", "Evidence such as a registration or tax identifier", "Determination timestamp" ] }, { "id": "otc-commercial-pattern", "text": "What commercial pattern does the order follow and which pattern-specific parameters apply?", "kind": "classification", "answer_data": [ "Pattern code such as call-off, blanket or drop-ship", "Framework agreement reference", "Pattern parameters such as a call-off ceiling" ] }, { "id": "otc-channel-origin", "text": "Through which sales channel and originating actor did this order reach the seller?", "kind": "provenance", "answer_data": [ "Sales channel code", "Originator party reference", "Originating requisition reference" ] } ], "data_elements": [ { "id": "de-order-type-code", "name": "Order type code", "description": "Coded classification of the order, stored with its code list identifier and version.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "de-buyer-segment", "name": "Buyer capacity classification", "description": "Whether the buyer contracts as a business or a consumer, determining which legal regime binds.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "de-sales-channel", "name": "Sales channel code", "description": "The channel through which the order was received or captured.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006" ] } ], "artifacts": [], "inline_only_rationale": "Order typing is a set of coded header attributes plus a reference to a framework agreement held elsewhere. No separate object is produced, and the code lists themselves are governed by external classifier registries that own their own versioning." }, { "id": "order-line-structure", "name": "Order line and sub-line structure", "description": "The compositional structure of order lines: line identity and numbering, sub-lines for kits and bundles, the item reference, and the integrity rules that make line-level state and fulfilment addressable.", "source_refs": [ "SRC-001", "SRC-002", "SRC-004" ], "questions": [ { "id": "ols-line-identity", "text": "How is an individual order line identified so that responses, despatches and claims can address it precisely?", "kind": "identity", "answer_data": [ "Order line identifier", "Line number", "Parent line identifier for sub-lines" ] }, { "id": "ols-sub-line-composition", "text": "How are kits, bundles and component sub-lines composed beneath a parent line?", "kind": "composition", "answer_data": [ "Sub-line collection", "Component quantity per parent unit", "Composition type code" ] }, { "id": "ols-item-reference", "text": "How does a line point at the trade item without restating item master data?", "kind": "relationship", "answer_data": [ "Seller item identifier", "Standard item identifier and its scheme", "Item name or free-text description" ] }, { "id": "ols-line-count-integrity", "text": "What integrity rule ties the declared line count to the lines actually present?", "kind": "validation", "answer_data": [ "Declared line count", "Counted lines", "Mismatch handling rule" ] } ], "data_elements": [ { "id": "de-order-line-id", "name": "Order line identifier", "description": "Identifier of one addressable line, unique within an order version and never reused.", "value_kind": "identifier", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-002", "SRC-004" ] }, { "id": "de-line-item-reference", "name": "Line item reference", "description": "Scheme-qualified reference to the trade item ordered, resolved against the item master model.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-004" ] }, { "id": "de-line-count", "name": "Declared line count", "description": "Sender-declared number of order lines, used as an integrity check against the lines received.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] } ], "artifacts": [ { "id": "order-line-item-record", "name": "Order line item record", "description": "One addressable line of the sales order carrying the item reference, ordered quantity, price basis, its own state and its fulfilment progress.", "media_or_form": [ "structured record", "line-level entry" ], "serial": true, "identity_strategy": "Composite of the authoritative sales order identifier and the line identifier assigned by the issuing party; line numbers are never reused within an order version, and item and inventory keys remain references into their owning models.", "source_refs": [ "SRC-002", "SRC-004" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "parties-and-commercial-terms", "name": "Trade Parties and Commercial Terms", "description": "Who the order binds, who may commit and change it, and the priced, delivery, risk and payment terms it carries.", "rationale": "UBL 2.4 and Peppol BIS both require explicit party roles and terms structures on the order, while the trade term rules and uniform sales law determine how delivery, cost and risk obligations attach to those terms. These must be settled before any lifecycle or fulfilment claim is meaningful.", "source_refs": [ "SRC-002", "SRC-004", "SRC-009", "SRC-010" ], "layers": [ { "id": "trade-parties-and-ordering-authority", "name": "Party Roles and Ordering Authority", "description": "The party roles present on a sales order and the authority under which it was committed and may be amended.", "source_refs": [ "SRC-002", "SRC-003", "SRC-004", "SRC-005", "SRC-009" ], "findings": [ { "id": "party-roles-on-the-order", "name": "Party roles and identification schemes", "description": "The distinct roles a party can occupy on one order - buyer customer, seller supplier, originator, accounting customer, delivery party or consignee, invoicee, freight forwarder - and how each is identified under a declared scheme.", "source_refs": [ "SRC-002", "SRC-003", "SRC-004", "SRC-005" ], "questions": [ { "id": "pr-role-inventory", "text": "Which party roles are populated on this order and which are mandatory under the agreed profile?", "kind": "relationship", "answer_data": [ "Role code per party", "Party reference", "Mandatory or optional flag per profile" ] }, { "id": "pr-identification-scheme", "text": "Under which identifier scheme is each party identified, and is that scheme declared explicitly on the value?", "kind": "identity", "answer_data": [ "Party identifier value", "Scheme identifier such as an electronic address or location key scheme", "Scheme agency" ] }, { "id": "pr-multi-role-conflict", "text": "What applies when one legal entity occupies several roles, or when a role is delegated to a third party?", "kind": "exception", "answer_data": [ "Role-to-party mapping", "Delegation reference", "Conflict resolution rule" ] }, { "id": "pr-snapshot-precedence", "text": "When party details recorded on the order differ from the party master record, which prevails?", "kind": "quality", "answer_data": [ "Order-time party snapshot", "Master record reference", "Precedence and reconciliation rule" ] } ], "data_elements": [ { "id": "de-party-role-assignment", "name": "Party role assignment", "description": "A role code bound to a scheme-qualified party reference for this order.", "value_kind": "object", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-002", "SRC-004" ] }, { "id": "de-party-scheme-id", "name": "Party identifier scheme", "description": "The declared scheme under which a party identifier on the order is issued.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004", "SRC-005" ] } ], "artifacts": [], "inline_only_rationale": "Party roles are role assignments plus scheme-qualified references resolved against a party master model, together with the snapshot actually agreed. The order must not own party lifecycle, deduplication, scheme registration or master-data stewardship, so no party artifact is created here." }, { "id": "ordering-authority-and-mandate", "name": "Ordering authority, mandate and signature evidence", "description": "The authority basis under which the order was committed: who may place, change or cancel it, the mandate or agreement supporting that, and the signature or approval evidence bound to the order.", "source_refs": [ "SRC-002", "SRC-003", "SRC-004", "SRC-009" ], "questions": [ { "id": "oa-commit-authority", "text": "Who is authorised to commit the buyer to this order and under what mandate or value ceiling?", "kind": "authority", "answer_data": [ "Authorising person or role reference", "Mandate or agreement reference", "Authority scope such as a value ceiling" ] }, { "id": "oa-change-authority", "text": "Who may subsequently amend or cancel the order, and does that differ from who placed it?", "kind": "ownership", "answer_data": [ "Change authority role", "Cancellation authority role", "Difference statement" ] }, { "id": "oa-signature-scope", "text": "What signature or approval evidence is bound to the order and exactly what content does it attest?", "kind": "evidence", "answer_data": [ "Signature block reference", "Signatory identity reference", "Signed content scope and digest" ] }, { "id": "oa-authority-failure", "text": "How is an order handled when authority cannot be established or is later withdrawn?", "kind": "exception", "answer_data": [ "Authority verification outcome", "Hold or rejection disposition", "Notification record reference" ] } ], "data_elements": [ { "id": "de-ordering-mandate-ref", "name": "Ordering mandate reference", "description": "Reference to the mandate, delegation or agreement establishing authority to place or amend the order.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004", "SRC-009" ] }, { "id": "de-signature-scope-digest", "name": "Signed content digest", "description": "Digest over the exact order content a signature attests, enabling later verification by the referenced cryptographic component.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002", "SRC-003" ] } ], "artifacts": [ { "id": "order-signature-record", "name": "Order signature record", "description": "Signature or approval evidence bound to a specific order or order response, recording the signatory reference, the signed scope and the time of signing.", "media_or_form": [ "signature block", "detached signature object" ], "serial": true, "identity_strategy": "Identified by the sales order identifier plus a signature sequence value assigned by the owning Dimension; the signatory identity resolves to the party master model and is never minted here, and verification is performed by the referenced cryptographic component.", "source_refs": [ "SRC-002", "SRC-003" ] } ], "inline_only_rationale": null } ] }, { "id": "priced-delivery-and-payment-terms", "name": "Priced, Delivery and Payment Terms", "description": "Quantities, prices and totals carried on the order, the delivery terms bound to it, and the risk, title and payment conditions it references.", "source_refs": [ "SRC-002", "SRC-003", "SRC-004", "SRC-009", "SRC-010", "SRC-012" ], "findings": [ { "id": "quantity-price-and-monetary-terms", "name": "Quantity, price, adjustments and monetary totals", "description": "Ordered quantity with its unit of measure, net price and price base quantity, line and document allowances and charges, the document, pricing and tax currencies with exchange rates, and the anticipated versus confirmed totals.", "source_refs": [ "SRC-002", "SRC-003", "SRC-004", "SRC-012" ], "questions": [ { "id": "qp-quantity-measure", "text": "In which unit of measure and to what precision is each ordered quantity expressed?", "kind": "measurement", "answer_data": [ "Ordered quantity value", "Unit of measure code", "Pinned unit code list version" ] }, { "id": "qp-price-basis", "text": "What is the net price, over what base quantity, and after which line-level allowances?", "kind": "measurement", "answer_data": [ "Net price amount", "Price base quantity", "Line allowance and charge entries" ] }, { "id": "qp-currency-and-rate", "text": "Which currencies apply to the document, pricing and tax, and what exchange rates are recorded?", "kind": "constraint", "answer_data": [ "Document currency code", "Pricing and tax currency codes", "Recorded exchange rate values" ] }, { "id": "qp-total-divergence", "text": "How is a divergence between the buyer's anticipated total and the seller's confirmed total recorded and resolved?", "kind": "decision", "answer_data": [ "Anticipated monetary total", "Confirmed legal monetary total on the response", "Divergence disposition and authority" ] } ], "data_elements": [ { "id": "de-ordered-quantity", "name": "Ordered quantity", "description": "Quantity requested on a line, always paired with an explicit unit of measure code.", "value_kind": "quantity", "cardinality": "1", "required": true, "source_refs": [ "SRC-002", "SRC-004" ] }, { "id": "de-net-price", "name": "Net line price", "description": "Price per base quantity net of line-level allowances, in the pricing currency.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "de-anticipated-total", "name": "Anticipated monetary total", "description": "The buyer's expected order total, indicative only and superseded by the seller's confirmed total.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002", "SRC-003" ] } ], "artifacts": [], "inline_only_rationale": "Quantities, prices, adjustments and totals are computed attributes of the order and line records already declared in this model. The fiscal determination of tax and the legally binding priced document belong to the invoice model, so creating a priced artifact here would duplicate a compliance-bearing document this model only references." }, { "id": "delivery-terms-risk-and-payment", "name": "Delivery terms, risk and title basis, and payment conditions", "description": "The trade term rule and named place bound to the order, the resulting cost, insurance and clearance split, the recorded basis on which risk and separately title pass, and the payment means, payment terms and credit decision the order references.", "source_refs": [ "SRC-002", "SRC-003", "SRC-004", "SRC-009", "SRC-010" ], "questions": [ { "id": "dt-rule-and-place", "text": "Which delivery term rule applies, at which precisely named place, and under which rule set version?", "kind": "spatial", "answer_data": [ "Delivery term rule code", "Named place or port", "Rule set edition reference" ] }, { "id": "dt-obligation-split", "text": "How do cost, insurance and export or import clearance obligations divide between seller and buyer under the chosen rule?", "kind": "requirement", "answer_data": [ "Cost allocation statement", "Insurance obligation and cover level", "Clearance responsibility per party" ] }, { "id": "dt-risk-and-title", "text": "At which event does risk of loss pass, and which legal source determines when property in the goods passes?", "kind": "state", "answer_data": [ "Risk transfer trigger event and timestamp", "Applicable law reference for property transfer", "Retention-of-title clause reference" ] }, { "id": "dt-payment-and-credit", "text": "Which payment means and terms are stated on the order, and which credit or risk decision gates its acceptance?", "kind": "requirement", "answer_data": [ "Payment means code", "Payment terms text or code", "Credit decision reference, outcome and deciding model" ] }, { "id": "dt-term-precedence", "text": "What governs when header delivery terms conflict with line-level instructions or with a framework agreement?", "kind": "constraint", "answer_data": [ "Header delivery terms", "Line-level delivery terms", "Precedence rule and resolution outcome" ] } ], "data_elements": [ { "id": "de-delivery-term-rule", "name": "Delivery term rule binding", "description": "Coded trade term rule with its named place and the rule set edition it belongs to.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002", "SRC-010" ] }, { "id": "de-risk-transfer-trigger", "name": "Risk transfer trigger", "description": "The event at which risk of loss passes to the buyer, with its governing rule reference.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009", "SRC-010" ] }, { "id": "de-credit-decision-ref", "name": "Credit decision reference", "description": "Reference to the credit or risk decision that gates acceptance, held by the payment and credit model.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002", "SRC-003" ] }, { "id": "de-destination-country", "name": "Destination country code", "description": "Country recorded on the order for customs purposes, checked for consistency with the delivery location.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] } ], "artifacts": [], "inline_only_rationale": "Delivery terms are a coded binding to an externally governed rule set plus a named place; risk and title are legal effects determined by the contract and applicable law; payment means and terms are proposed conditions with a pointer to a credit decision held elsewhere. All are inline attributes and references. Transport execution, property adjudication, credit scoring and settlement belong to sibling models that own their evaluation and enforcement semantics." } ] } ] }, { "id": "order-lifecycle-and-state", "name": "Order Lifecycle and State", "description": "How a sales order is dispositioned, how header and line state evolve, how change, cancellation and holds are controlled, and which time points must be recorded.", "rationale": "Peppol BIS Ordering defines explicit header and line disposition codes with an all-lines-restated rule, UBL defines distinct change and cancellation documents, and uniform sales law makes acceptance the point of contract formation. This bundle is the operational core of a seller-side order model.", "source_refs": [ "SRC-001", "SRC-003", "SRC-004", "SRC-008", "SRC-009" ], "layers": [ { "id": "acceptance-and-contract-formation", "name": "Acceptance and Contract Formation", "description": "The seller's disposition of an incoming order and the evidence that a contract was formed on stated terms.", "source_refs": [ "SRC-003", "SRC-004", "SRC-006", "SRC-009" ], "findings": [ { "id": "order-response-disposition", "name": "Order response and disposition codes", "description": "The seller's response to an order at header level (received, accepted, accepted with amendment, rejected) and line level (added, changed, accepted, not accepted, already delivered), including counter-offers and response sequencing.", "source_refs": [ "SRC-003", "SRC-004" ], "questions": [ { "id": "ord-header-disposition", "text": "What header-level disposition does the seller assert and which pinned code list defines it?", "kind": "decision", "answer_data": [ "Order response code", "Code list identifier and version", "Responding party reference" ] }, { "id": "ord-line-disposition", "text": "Which disposition applies to each order line, and under what condition must all lines be restated?", "kind": "state", "answer_data": [ "Line status code per line", "All-lines-restated condition", "Changed element values per line" ] }, { "id": "ord-counter-offer", "text": "When a response amends quantity, price, item or delivery period, what makes it a counter-offer rather than an acceptance?", "kind": "decision", "answer_data": [ "Amended element list", "Prior agreement permitting amendment", "Counter-offer determination" ] }, { "id": "ord-response-sequencing", "text": "How are multiple responses to one order sequenced, and which is currently effective?", "kind": "lifecycle", "answer_data": [ "Response sequence value", "Response issue timestamp", "Effective response pointer" ] } ], "data_elements": [ { "id": "de-order-response-code", "name": "Order response code", "description": "Header-level disposition asserted by the seller, stored with its code list version.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-003", "SRC-004" ] }, { "id": "de-line-status-code", "name": "Line status code", "description": "Per-line disposition asserted by the seller on a response.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004" ] } ], "artifacts": [ { "id": "order-response-record", "name": "Order response record", "description": "One seller response to a sales order carrying the header disposition, per-line dispositions, amended values, totals and the responding party.", "media_or_form": [ "structured record", "business document instance" ], "serial": true, "identity_strategy": "Identified by a sender-assigned response identifier plus the referenced sales order identifier; effect ordering is determined by the recorded issue timestamp and the supersession pointer, not by the sequence value alone.", "source_refs": [ "SRC-003", "SRC-004" ] } ], "inline_only_rationale": null }, { "id": "contract-formation-evidence", "name": "Contract formation and confirmation evidence", "description": "Which message constituted the offer and which the acceptance, the immutable snapshot of agreed terms retained at that moment, and the durable confirmation issued to the buyer.", "source_refs": [ "SRC-004", "SRC-006", "SRC-009" ], "questions": [ { "id": "cf-offer-acceptance", "text": "Which message constituted the offer and which the acceptance, and at what instants did each occur?", "kind": "event", "answer_data": [ "Offer message reference and event timestamp", "Acceptance message reference and event timestamp", "Formation determination" ] }, { "id": "cf-agreed-snapshot", "text": "What immutable snapshot of agreed terms is retained at the moment of formation?", "kind": "evidence", "answer_data": [ "Agreed line set", "Agreed totals, delivery and payment terms", "Snapshot content digest" ] }, { "id": "cf-confirmation-delivery", "text": "What confirmation was issued to the buyer, through which channel, and was its receipt evidenced?", "kind": "provenance", "answer_data": [ "Confirmation record reference", "Delivery channel", "Receipt or acknowledgement evidence" ] }, { "id": "cf-formation-dispute", "text": "How is a dispute about whether a contract was formed recorded against the order?", "kind": "exception", "answer_data": [ "Dispute reference", "Contested element list", "Resolution outcome and authority" ] } ], "data_elements": [ { "id": "de-formation-timestamp", "name": "Contract formation timestamp", "description": "Event instant at which acceptance took effect, recorded with an explicit offset.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008", "SRC-009" ] }, { "id": "de-agreed-snapshot-digest", "name": "Agreed terms snapshot digest", "description": "Digest over the canonical form of the agreed terms at formation, enabling later comparison.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] } ], "artifacts": [ { "id": "order-confirmation-record", "name": "Order confirmation record", "description": "The durable confirmation issued to the buyer recording the agreed line set, totals, delivery commitment and terms at contract formation.", "media_or_form": [ "structured record", "human-readable rendering" ], "serial": false, "identity_strategy": "Identified by the authoritative sales order identifier; a confirmation reissued after an accepted change carries a version counter rather than a second key, and its formation instant is held as a timestamp attribute, never as part of the key.", "source_refs": [ "SRC-004", "SRC-009" ] } ], "inline_only_rationale": null } ] }, { "id": "state-change-and-exception-control", "name": "State, Change and Exception Control", "description": "The state vocabulary of an order and its lines, and the controls over amendment, cancellation and blocking conditions.", "source_refs": [ "SRC-001", "SRC-002", "SRC-004", "SRC-005", "SRC-006", "SRC-007" ], "findings": [ { "id": "order-and-line-state-model", "name": "Order and line state vocabulary and transitions", "description": "The state vocabulary for the order header and for each line, the permitted transitions and terminal states, how header state is derived from mixed line states, and where mapping to external status enumerations is lossy.", "source_refs": [ "SRC-001", "SRC-004", "SRC-006", "SRC-007" ], "questions": [ { "id": "sm-state-vocabulary", "text": "Which state vocabulary governs the order header and which governs each individual line?", "kind": "state", "answer_data": [ "Header state vocabulary", "Line state vocabulary", "Vocabulary owner and version" ] }, { "id": "sm-permitted-transitions", "text": "Which transitions are permitted, which are terminal, and what event triggers each?", "kind": "lifecycle", "answer_data": [ "Permitted transition set", "Terminal state list", "Trigger event per transition" ] }, { "id": "sm-header-derivation", "text": "How is header state derived when lines are in mixed states such as partly despatched and partly cancelled?", "kind": "constraint", "answer_data": [ "Derivation rule", "Line state distribution", "Derived header state" ] }, { "id": "sm-external-mapping", "text": "How does the internal state vocabulary map to externally published order status enumerations, and where is that mapping lossy?", "kind": "interoperability", "answer_data": [ "Internal state value", "External enumeration member", "Unmapped or lossy case list" ] } ], "data_elements": [ { "id": "de-header-state", "name": "Order header state", "description": "Current derived state of the order as a whole, from the model-owned vocabulary.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-004", "SRC-006" ] }, { "id": "de-line-state", "name": "Order line state", "description": "Current state of an individual order line, independently addressable from the header state.", "value_kind": "code", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-004", "SRC-005" ] } ], "artifacts": [], "inline_only_rationale": "No retrieved primary source publishes a normative seller-side order state machine: the disposition codes describe a response message and the public web enumeration is an unordered status list. The states and transitions are therefore a model-owned vocabulary declared inline and aligned outward. Emitting a state artifact would imply an event store whose execution, retention and audit semantics belong to the adopting Dimension." }, { "id": "change-and-cancellation-control", "name": "Change and cancellation control", "description": "How a buyer-requested change or cancellation is received, versioned, dispositioned and reflected on committed quantities, including the cut-off beyond which amendment is refused.", "source_refs": [ "SRC-001", "SRC-002", "SRC-004" ], "questions": [ { "id": "cc-change-target", "text": "What change is requested, against which order version, and on which lines and elements?", "kind": "process", "answer_data": [ "Change request reference", "Target order version", "Changed line and element set" ] }, { "id": "cc-versioning", "text": "How are successive order versions identified and which version is currently effective?", "kind": "lifecycle", "answer_data": [ "Order version counter", "Superseded version reference", "Effective-from timestamp" ] }, { "id": "cc-change-cutoff", "text": "At which fulfilment point does the order become unchangeable, and who may override that?", "kind": "constraint", "answer_data": [ "Cut-off condition", "Override authority role", "Override record reference" ] }, { "id": "cc-partial-cancellation", "text": "How is a partial cancellation represented so that the remaining lines stay valid and totals stay consistent?", "kind": "composition", "answer_data": [ "Cancelled line and quantity set", "Remaining committed quantities", "Recalculated totals" ] } ], "data_elements": [ { "id": "de-order-version-counter", "name": "Order version counter", "description": "Monotonically increasing counter identifying the commercial version of the order.", "value_kind": "number", "cardinality": "1", "required": true, "source_refs": [ "SRC-002", "SRC-004" ] }, { "id": "de-supersession-pointer", "name": "Supersession pointer", "description": "Reference from an effective version to the version it replaced, with the effective-from instant.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001", "SRC-004" ] } ], "artifacts": [ { "id": "order-change-request-record", "name": "Order change request record", "description": "A buyer-initiated request to amend an existing sales order, identifying the target version, the affected lines and the requested new values.", "media_or_form": [ "structured record", "business document instance" ], "serial": true, "identity_strategy": "Identified by a sender-assigned change identifier plus the target sales order identifier and version counter; the version counter carries no date component.", "source_refs": [ "SRC-001", "SRC-002" ] }, { "id": "order-cancellation-record", "name": "Order cancellation record", "description": "A request to cancel a sales order in whole or in part, carrying the cancellation reason and the affected line and quantity set.", "media_or_form": [ "structured record", "business document instance" ], "serial": true, "identity_strategy": "Identified by a sender-assigned cancellation identifier plus the target sales order identifier; partial cancellations additionally cite the affected line identifiers.", "source_refs": [ "SRC-001" ] } ], "inline_only_rationale": null }, { "id": "holds-blocks-and-exceptions", "name": "Holds, blocks and exception handling", "description": "Conditions that suspend progression of an order or line - credit hold, stock exception, screening block, validation failure - recorded as order state with a pointer to the deciding authority rather than as a decision made here.", "source_refs": [ "SRC-003", "SRC-004", "SRC-005" ], "questions": [ { "id": "hb-hold-taxonomy", "text": "Which hold or block types may be applied to this order or its lines, and at which scope?", "kind": "classification", "answer_data": [ "Hold type code", "Applicable scope, header or line", "Hold reason text" ] }, { "id": "hb-decision-owner", "text": "Which model or authority decided the hold, and where is that decision evidenced?", "kind": "ownership", "answer_data": [ "Deciding model or authority reference", "Decision identifier", "Decision event timestamp" ] }, { "id": "hb-release-conditions", "text": "What conditions release a hold, who may release it, and within what maximum duration?", "kind": "process", "answer_data": [ "Release condition set", "Release authority role", "Maximum hold duration" ] }, { "id": "hb-commitment-effect", "text": "What effect does an active hold have on allocated stock and on promised delivery dates?", "kind": "state", "answer_data": [ "Allocation retention flag", "Promise validity status", "Recomputed delivery commitment" ] } ], "data_elements": [ { "id": "de-hold-type", "name": "Hold type code", "description": "Coded reason class suspending progression of the order or line.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "de-hold-decision-ref", "name": "Hold decision reference", "description": "Pointer to the decision record held by the model or authority that made the determination.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003", "SRC-005" ] }, { "id": "de-hold-max-duration", "name": "Maximum hold duration", "description": "Longest period a hold may remain active before escalation is required.", "value_kind": "duration", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] } ], "artifacts": [ { "id": "order-hold-record", "name": "Order hold record", "description": "A recorded suspension of an order or line carrying the hold type, scope, reason, deciding authority reference, release conditions and effect on commitment.", "media_or_form": [ "structured record" ], "serial": true, "identity_strategy": "Composite of the sales order identifier, a hold sequence value and, where line-scoped, the line identifier; the underlying decision resolves to the deciding model and is never re-keyed here.", "source_refs": [ "SRC-004", "SRC-005" ] } ], "inline_only_rationale": null } ] }, { "id": "time-points-and-commitments", "name": "Time Points and Service Commitments", "description": "The instants and periods a sales order must record and the delivery commitment derived from them.", "source_refs": [ "SRC-002", "SRC-004", "SRC-005", "SRC-008" ], "findings": [ { "id": "order-time-points-and-commitments", "name": "Order time points, clock rules and delivery commitment", "description": "The distinct time points on a sales order - issue, receipt, acceptance, requested and promised delivery periods, validity, despatch and delivery - and the clock rules that make them comparable and auditable.", "source_refs": [ "SRC-002", "SRC-004", "SRC-005", "SRC-008" ], "questions": [ { "id": "tp-point-inventory", "text": "Which distinct time points must this order record, and which of them are mandatory?", "kind": "temporal", "answer_data": [ "Time point name and value", "Mandatory flag", "Recording party or system" ] }, { "id": "tp-event-versus-ingestion", "text": "Where do event time and observation or ingestion time diverge, and are both retained?", "kind": "provenance", "answer_data": [ "Event timestamp", "Observation or ingestion timestamp", "Divergence note and clock source" ] }, { "id": "tp-format-rule", "text": "In which format and with what offset are instants recorded, and how are date-only values kept distinct?", "kind": "constraint", "answer_data": [ "Timestamp format profile", "Explicit offset or Z designator", "Date-only element list" ] }, { "id": "tp-requested-versus-promised", "text": "How does the requested delivery period differ from the promised period, and which one binds?", "kind": "requirement", "answer_data": [ "Requested delivery period", "Promised or confirmed delivery period", "Binding determination" ] }, { "id": "tp-validity-expiry", "text": "What happens to an order whose validity period expires before any acceptance is issued?", "kind": "lifecycle", "answer_data": [ "Validity period", "Expiry disposition", "Expiry event timestamp" ] } ], "data_elements": [ { "id": "de-issue-instant", "name": "Document issue instant", "description": "Instant at which the order document was issued by the sender, with explicit offset.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-002", "SRC-008" ] }, { "id": "de-receipt-instant", "name": "Receipt or ingestion instant", "description": "Instant at which the seller's system received or captured the order, recorded separately from issue time.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-008" ] }, { "id": "de-requested-delivery-period", "name": "Requested delivery period", "description": "Period within which the buyer asks for delivery, expressed as dates unless an instant is genuinely meant.", "value_kind": "date", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004", "SRC-005" ] }, { "id": "de-validity-period", "name": "Order validity period", "description": "Period during which the order remains open for acceptance.", "value_kind": "date", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] } ], "artifacts": [], "inline_only_rationale": "Time points are typed attributes of the order, its lines and its responses rather than objects in their own right. Materialising them as an artifact would create a chronology store whose retention, immutability and audit execution are owned by the adopting Dimension's records and audit models, not by this one." } ] } ] }, { "id": "fulfilment-and-delivery", "name": "Fulfilment and Delivery", "description": "How accepted lines are sourced, promised and scheduled, how despatch is linked back to lines, and how delivered, outstanding, disputed and returned quantities resolve into closure.", "rationale": "The despatch advice profile defines delivered, outstanding and oversupply quantities against order lines with an explicit outstanding reason, and UBL defines receipt advice, giving a sourced basis for a seller-side fulfilment surface that stops short of transport execution.", "source_refs": [ "SRC-001", "SRC-004", "SRC-005" ], "layers": [ { "id": "allocation-and-despatch", "name": "Allocation, Scheduling and Despatch Linkage", "description": "The seller's commitment of supply to accepted lines and the linkage from those lines to despatch events.", "source_refs": [ "SRC-001", "SRC-004", "SRC-005" ], "findings": [ { "id": "availability-allocation-and-schedule", "name": "Availability promise, allocation and fulfilment schedule", "description": "How available supply is promised and allocated to accepted lines, how substitutions and splits are recorded, from which location each portion ships, and how competing claims on the same stock are resolved.", "source_refs": [ "SRC-004", "SRC-005" ], "questions": [ { "id": "al-promise-basis", "text": "On what availability basis was the delivery promise made, and when was it computed?", "kind": "measurement", "answer_data": [ "Promised quantity", "Availability basis reference", "Promise computation timestamp" ] }, { "id": "al-allocation-firmness", "text": "What quantity is allocated to this line, from which sourcing location, and is that allocation firm or provisional?", "kind": "state", "answer_data": [ "Allocated quantity", "Sourcing location reference", "Firm or provisional flag" ] }, { "id": "al-substitution-permission", "text": "Under what conditions may an item be substituted, and how is the replacement recorded against the original line?", "kind": "decision", "answer_data": [ "Substitution permission flag", "Replacement item reference", "Buyer approval evidence" ] }, { "id": "al-split-and-contention", "text": "Is partial shipment permitted, and how are competing claims on the same stock between orders resolved and recorded?", "kind": "exception", "answer_data": [ "Partial shipment permission", "Schedule line set with quantity per line", "Priority rule reference and reallocation record" ] } ], "data_elements": [ { "id": "de-allocated-quantity", "name": "Allocated quantity", "description": "Quantity committed to a line against the referenced inventory model, with its firmness flag.", "value_kind": "quantity", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004", "SRC-005" ] }, { "id": "de-sourcing-location-ref", "name": "Sourcing location reference", "description": "Scheme-qualified reference to the location from which a promised portion will ship.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "de-promised-delivery-period", "name": "Promised delivery period", "description": "The delivery window the seller commits to for a scheduled portion of a line.", "value_kind": "date", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004", "SRC-005" ] } ], "artifacts": [ { "id": "fulfilment-schedule-line-record", "name": "Fulfilment schedule line record", "description": "A planned shipment portion of an order line carrying the promised quantity, sourcing location, planned despatch window and allocation firmness.", "media_or_form": [ "structured record" ], "serial": true, "identity_strategy": "Composite of the sales order identifier, the order line identifier and a schedule sequence value assigned by the owning Dimension; inventory positions and location keys remain references into the models that own them.", "source_refs": [ "SRC-004", "SRC-005" ] } ], "inline_only_rationale": null }, { "id": "despatch-and-shipment-linkage", "name": "Despatch and shipment linkage", "description": "How a despatch event binds to specific order lines: despatch advice reference at header or line level, shipment and consignment identifiers, logistic unit keys, and any lot, serial or expiry data carried at line level.", "source_refs": [ "SRC-001", "SRC-005" ], "questions": [ { "id": "ds-order-linkage", "text": "How does each despatch line reference the originating order and line, including when one despatch covers several orders?", "kind": "relationship", "answer_data": [ "Despatch advice reference", "Order reference at header or line level", "Order line reference" ] }, { "id": "ds-shipment-keys", "text": "Which shipment, consignment and logistic unit identifiers are recorded, and under which schemes?", "kind": "identity", "answer_data": [ "Shipment identifier", "Consignment or shipment identification number", "Logistic unit identifier and scheme" ] }, { "id": "ds-instance-data", "text": "What lot, serial, expiry or best-before data is recorded for despatched items, and for what purpose?", "kind": "provenance", "answer_data": [ "Lot or batch number", "Serial identifier", "Expiry or best-before date" ] }, { "id": "ds-unmatched-despatch", "text": "How is a despatch handled when no order line reference exists, and what placeholder convention applies?", "kind": "exception", "answer_data": [ "Placeholder value convention", "Unmatched despatch disposition", "Manual reconciliation reference" ] } ], "data_elements": [ { "id": "de-despatch-advice-ref", "name": "Despatch advice reference", "description": "Reference to the despatch document issued by the despatching party for this shipment.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "de-consignment-id", "name": "Consignment or shipment identifier", "description": "Scheme-qualified transport grouping identifier carried on the order-side linkage.", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "de-item-instance-data", "name": "Item instance data", "description": "Lot, serial, expiry or best-before values recorded for despatched quantities on a line.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] } ], "artifacts": [ { "id": "despatch-linkage-record", "name": "Despatch linkage record", "description": "The order-side link to one despatch event, binding despatched quantities and instance data to specific order lines and to shipment and consignment identifiers.", "media_or_form": [ "structured record", "cross-document reference set" ], "serial": true, "identity_strategy": "Composite of the sales order identifier, the order line identifier and the despatch advice identifier assigned by the despatching party; shipment, consignment and logistic unit keys are carried as external references under their declared schemes.", "source_refs": [ "SRC-001", "SRC-005" ] } ], "inline_only_rationale": null } ] }, { "id": "delivery-outcome-and-closure", "name": "Delivery Outcome, Claims and Closure", "description": "Quantity accounting against ordered lines, discrepancy resolution, post-delivery claims, and the criteria that close an order.", "source_refs": [ "SRC-001", "SRC-004", "SRC-005", "SRC-006", "SRC-009" ], "findings": [ { "id": "delivered-outstanding-and-discrepancy", "name": "Delivered, outstanding and discrepancy accounting", "description": "The quantity accounting that tracks delivered, outstanding and over-supplied quantities per line, the reason for any shortfall, and reconciliation against the buyer's confirmed receipt.", "source_refs": [ "SRC-001", "SRC-005" ], "questions": [ { "id": "dd-quantity-accounting", "text": "For each line, what quantity is delivered, what remains outstanding, and what was supplied in excess?", "kind": "measurement", "answer_data": [ "Delivered quantity", "Outstanding quantity", "Oversupply quantity" ] }, { "id": "dd-shortfall-reason", "text": "Why is a quantity outstanding, and does a further delivery remain planned for it?", "kind": "exception", "answer_data": [ "Outstanding reason code", "Further delivery planned flag", "Revised delivery window" ] }, { "id": "dd-receipt-reconciliation", "text": "How is the buyer's confirmed receipt reconciled against what the seller despatched?", "kind": "validation", "answer_data": [ "Receipt advice reference", "Received quantity per line", "Discrepancy amount and type" ] }, { "id": "dd-discrepancy-disposition", "text": "Who decides the disposition of a confirmed discrepancy and which outcomes are permitted?", "kind": "decision", "answer_data": [ "Deciding role", "Disposition outcome code", "Downstream effect such as re-ship or short-close" ] } ], "data_elements": [ { "id": "de-delivered-quantity", "name": "Delivered quantity", "description": "Quantity actually despatched against a line in a given despatch.", "value_kind": "quantity", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "de-outstanding-quantity", "name": "Outstanding quantity", "description": "Quantity still to be delivered on a line, or zero where no further delivery is planned.", "value_kind": "quantity", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "de-outstanding-reason", "name": "Outstanding reason code", "description": "Coded reason distinguishing a backorder from a cancelled or unfulfillable remainder.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] } ], "artifacts": [ { "id": "delivery-discrepancy-record", "name": "Delivery discrepancy record", "description": "A recorded difference between ordered, despatched and received quantities on a line, with its reason, disposition and downstream effect.", "media_or_form": [ "structured record" ], "serial": true, "identity_strategy": "Composite of the sales order identifier, the order line identifier and a discrepancy sequence value; the referenced receipt advice retains the identifier assigned by its issuer.", "source_refs": [ "SRC-001", "SRC-005" ] } ], "inline_only_rationale": null }, { "id": "claims-and-order-closure", "name": "Post-delivery claims and order closure", "description": "Return requests, statutory withdrawal in consumer sales and non-conformity notices recorded against delivered lines, and the criteria and authority that close the order.", "source_refs": [ "SRC-001", "SRC-004", "SRC-005", "SRC-006", "SRC-009" ], "questions": [ { "id": "cl-claim-type-and-window", "text": "What type of post-delivery claim is raised, against which lines and quantities, and within what period from which triggering event?", "kind": "classification", "answer_data": [ "Claim type code", "Affected line and quantity", "Claim window duration, start event and expiry" ] }, { "id": "cl-claim-authorisation", "text": "What authorisation must exist before goods may be returned, and who issues it?", "kind": "authority", "answer_data": [ "Return authorisation reference", "Issuing role", "Authorisation conditions" ] }, { "id": "cl-completion-criteria", "text": "Which conditions must hold for the order to count as complete rather than merely despatched?", "kind": "constraint", "answer_data": [ "Completion criteria set", "Per-line completion status", "Completion determination timestamp" ] }, { "id": "cl-residual-and-reopening", "text": "How are residual outstanding quantities treated at closure, and under what conditions may a closed order reopen?", "kind": "lifecycle", "answer_data": [ "Residual quantity and short-close or carry-forward decision", "Authorising role", "Reopening condition and prior closure reference" ] }, { "id": "cl-execution-boundary", "text": "Which parts of a return are recorded here and which are executed by the logistics and settlement models?", "kind": "interoperability", "answer_data": [ "Order-side claim attributes", "Reverse logistics reference", "Refund or credit note reference" ] } ], "data_elements": [ { "id": "de-claim-type", "name": "Post-delivery claim type", "description": "Coded class of claim raised against delivered quantities, such as return, withdrawal or non-conformity.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006", "SRC-009" ] }, { "id": "de-claim-window", "name": "Claim window", "description": "Period within which a claim may be raised, with its triggering event reference.", "value_kind": "duration", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "de-closure-basis", "name": "Closure basis", "description": "The completion criteria satisfied, or the short-close decision and authority, that closed the order.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001", "SRC-005" ] } ], "artifacts": [ { "id": "order-claim-and-closure-record", "name": "Order claim and closure record", "description": "The order-side record of post-delivery claims and of the closure that ends the order's operational life, stating affected lines, claim windows, authorisation references, residual treatment and closing authority.", "media_or_form": [ "structured record", "cross-document reference set" ], "serial": true, "identity_strategy": "Claims are keyed by the sales order identifier, the line identifier and a claim sequence value; the closure entry is keyed by the sales order identifier with a closure version counter for a reopened and re-closed order. Return authorisations, reverse shipments and credit notes keep the identifiers assigned by their owning models.", "source_refs": [ "SRC-001", "SRC-005", "SRC-009" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "control-evidence-and-compliance", "name": "Control, Evidence and Compliance", "description": "The rule and code list bindings applied to an order, the provenance of its record, and the jurisdictional obligations attached to it.", "rationale": "Peppol binds business rules and pinned code lists to order documents, and the European e-invoicing framework shows that document conformance is asserted against a named published specification rather than assumed. The same discipline is applied here, with execution left to the components that own it.", "source_refs": [ "SRC-004", "SRC-005", "SRC-009", "SRC-012" ], "layers": [ { "id": "validation-and-conformance", "name": "Validation and Conformance Bindings", "description": "Rule sets, code list pinning and the recorded outcome of validating a sales order or response.", "source_refs": [ "SRC-004", "SRC-005", "SRC-012" ], "findings": [ { "id": "validation-and-code-list-conformance", "name": "Validation rule bindings and code list conformance", "description": "Which rule sets and code list versions a sales order is validated against, how outcomes are recorded, who executes validation, and what disposition follows a failure.", "source_refs": [ "SRC-004", "SRC-005", "SRC-012" ], "questions": [ { "id": "vc-rule-binding", "text": "Which rule sets and specification versions is this order validated against?", "kind": "validation", "answer_data": [ "Rule set identifier", "Specification version", "Customization and profile identifiers" ] }, { "id": "vc-code-list-pinning", "text": "Which code lists constrain coded values on the order, and which versions are pinned?", "kind": "interoperability", "answer_data": [ "Code list identifier per coded element", "Pinned code list version", "Non-conforming value handling" ] }, { "id": "vc-outcome-record", "text": "How is a validation outcome recorded, including severity and the locator of the failing element?", "kind": "quality", "answer_data": [ "Outcome severity", "Failed rule identifier", "Failing element locator" ] }, { "id": "vc-execution-owner", "text": "Which component executes validation, and where does this model's responsibility end?", "kind": "ownership", "answer_data": [ "Executing model or engine reference", "Ownership boundary statement", "Recorded outcome pointer" ] }, { "id": "vc-failure-disposition", "text": "What is the disposition of an order that fails validation, and may it be corrected in place?", "kind": "exception", "answer_data": [ "Failure disposition code", "Correction permission", "Resubmission reference" ] } ], "data_elements": [ { "id": "de-rule-set-binding", "name": "Rule set binding", "description": "Identifier and version of the rule set a document instance is validated against.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004", "SRC-012" ] }, { "id": "de-code-list-pin", "name": "Code list version pin", "description": "The pinned code list identifier and version applied to a coded element.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "de-validation-severity", "name": "Validation outcome severity", "description": "Severity classification of a recorded validation failure, distinguishing blocking from advisory.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004", "SRC-012" ] } ], "artifacts": [ { "id": "order-validation-outcome-record", "name": "Order validation outcome record", "description": "The recorded result of validating one order or response against a named rule set and pinned code list versions, listing failures with severity and element locators.", "media_or_form": [ "structured record", "report" ], "serial": true, "identity_strategy": "Composite of the validated document identifier, the rule set identifier and version, and a validation sequence value; the executing engine is cited as an external reference and is never identified as a component owned by this model.", "source_refs": [ "SRC-004", "SRC-012" ] } ], "inline_only_rationale": null } ] }, { "id": "provenance-and-obligations", "name": "Provenance and Jurisdictional Obligations", "description": "Where the order record came from, and which legal regime and obligations attach to it.", "source_refs": [ "SRC-002", "SRC-004", "SRC-006", "SRC-008", "SRC-009", "SRC-012" ], "findings": [ { "id": "order-provenance-and-message-trail", "name": "Order provenance and inbound message trail", "description": "The origin of the order record: inbound channel and capture method, syntax and version, sender and receiver identifiers, envelope reference, payload digest, and the separation of issue time from receipt time.", "source_refs": [ "SRC-002", "SRC-004", "SRC-008" ], "questions": [ { "id": "pv-origin-channel", "text": "Through which channel, capture method and syntax did this order enter the seller's system?", "kind": "provenance", "answer_data": [ "Inbound channel identifier", "Syntax and version", "Capture method such as machine-to-machine or manual entry" ] }, { "id": "pv-sender-receiver", "text": "Which sender and receiver identifiers and envelope references accompany the inbound message?", "kind": "identity", "answer_data": [ "Sender identifier and scheme", "Receiver identifier and scheme", "Transmission envelope reference" ] }, { "id": "pv-transformation-trail", "text": "What transformation was applied between the received message and the stored record, and is the original retained?", "kind": "evidence", "answer_data": [ "Transformation reference", "Original payload retention pointer", "Payload content digest" ] }, { "id": "pv-audit-boundary", "text": "Which provenance facts does this model emit, and which audit-trail guarantees are owned elsewhere?", "kind": "ownership", "answer_data": [ "Emitted provenance fact list", "Audit record pointer", "Ownership boundary statement" ] } ], "data_elements": [ { "id": "de-inbound-envelope-ref", "name": "Transmission envelope reference", "description": "Transport-assigned reference for the inbound message, used as the provenance key where available.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "de-payload-digest", "name": "Inbound payload digest", "description": "Digest over the received payload as transmitted, before any transformation.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002", "SRC-008" ] }, { "id": "de-syntax-and-version", "name": "Inbound syntax and version", "description": "The document syntax and version in which the order was received.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002", "SRC-004" ] } ], "artifacts": [ { "id": "inbound-order-message-record", "name": "Inbound order message record", "description": "The retained provenance record for one inbound order, change, cancellation or response message: channel, syntax, sender and receiver identifiers, envelope reference, receipt instant and payload digest.", "media_or_form": [ "structured record", "retained payload reference" ], "serial": true, "identity_strategy": "Identified by the transmission envelope reference where the transport assigns one, otherwise by a surrogate minted by the adopting Dimension and bound to the payload digest; the receipt instant is an attribute of the record and never part of its key.", "source_refs": [ "SRC-002", "SRC-004", "SRC-008" ] } ], "inline_only_rationale": null }, { "id": "jurisdictional-sales-obligations", "name": "Applicable legal regime and jurisdictional obligations", "description": "The determination of which sales-law regime governs the order, whether uniform international sales law applies or is excluded, and which consumer-facing duties attach - recorded as citable bindings, with unevidenced obligations flagged.", "source_refs": [ "SRC-006", "SRC-009", "SRC-012" ], "questions": [ { "id": "js-applicable-regime", "text": "Which legal regime governs this sale, and on what basis was that determined?", "kind": "authority", "answer_data": [ "Governing law reference", "Determination basis such as party establishment or buyer capacity", "Determination timestamp" ] }, { "id": "js-uniform-law-applicability", "text": "Does uniform international sales law apply here, or is it excluded by the parties or by the nature of the sale?", "kind": "constraint", "answer_data": [ "Applicability determination", "Exclusion or opt-out reference", "Reservation or exclusion reason code" ] }, { "id": "js-consumer-duties", "text": "Which consumer-facing duties attach before and after order placement in the applicable jurisdiction?", "kind": "requirement", "answer_data": [ "Duty identifier and legal citation", "Fulfilment evidence reference", "Applicable statutory deadline" ] }, { "id": "js-evidence-gap", "text": "Which asserted obligations lack a primary legal source and must be re-grounded before they are relied on?", "kind": "evidence", "answer_data": [ "Unevidenced obligation list", "Required primary source", "Gap severity" ] } ], "data_elements": [ { "id": "de-governing-law-ref", "name": "Governing law reference", "description": "Citation of the legal regime determined to govern this order.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "de-obligation-binding", "name": "Jurisdictional obligation binding", "description": "A citable duty attached to the order with its evidence pointer and applicable deadline.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006", "SRC-012" ] }, { "id": "de-obligation-evidence-gap", "name": "Obligation evidence gap flag", "description": "Marker that an asserted obligation lacks primary source support and must not be treated as satisfied.", "value_kind": "boolean", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009" ] } ], "artifacts": [], "inline_only_rationale": "Legal obligations are bindings to external instruments owned by legislators and regulators. This model records only the applicability determination, the citation and the evidence pointer. Restating statutory text here would create an unmaintainable jurisdiction-specific copy, and no primary consumer-protection legislative text was retrievable in this research pass, so the node is carried as a flagged gap rather than as canonical content." } ] } ] }, { "id": "interoperability-and-record-governance", "name": "Interoperability and Record Governance", "description": "How the order binds to external syntaxes and profiles, how repeated interchange is controlled, and how the record itself is classified and retained.", "rationale": "UBL and Peppol expose explicit customization and profile identifiers and permit multiple responses per order, while the timestamp profile fixes instant serialisation. Interchange behaviour and record governance must therefore be modelled explicitly rather than inferred from a storage format or transport.", "source_refs": [ "SRC-001", "SRC-004", "SRC-006", "SRC-008" ], "layers": [ { "id": "alignment-and-interchange", "name": "Standard Alignment and Interchange Control", "description": "Declared external alignments and the control of repeated, duplicated or out-of-order interchange.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003", "SRC-004", "SRC-005", "SRC-006", "SRC-007", "SRC-012" ], "findings": [ { "id": "standard-alignment-and-profile-binding", "name": "Standard alignment and profile binding", "description": "Declared alignments to external order vocabularies and syntaxes, the customization and profile identifiers that pin an agreed subset, the evidence required before a conformance claim, and where mapping loses meaning.", "source_refs": [ "SRC-001", "SRC-003", "SRC-004", "SRC-006", "SRC-007", "SRC-012" ], "questions": [ { "id": "sa-alignment-inventory", "text": "To which external order vocabularies and syntaxes is this model aligned, and at which versions?", "kind": "interoperability", "answer_data": [ "Aligned specification identifier", "Version or release", "Alignment scope" ] }, { "id": "sa-profile-pinning", "text": "Which customization and profile identifiers pin the agreed subset for a given exchange?", "kind": "constraint", "answer_data": [ "Customization identifier", "Profile identifier", "Profile execution identifier" ] }, { "id": "sa-conformance-evidence", "text": "What evidence must exist before conformance to an external specification may be asserted?", "kind": "evidence", "answer_data": [ "Conformance test reference", "Validation outcome reference", "Assertion scope and stated limits" ] }, { "id": "sa-mapping-loss", "text": "Where does mapping between aligned specifications lose or distort meaning, and what mitigates it?", "kind": "quality", "answer_data": [ "Element pair mapping", "Loss or distortion description", "Mitigation or fallback rule" ] } ], "data_elements": [ { "id": "de-customization-id", "name": "Customization identifier", "description": "Identifier of the agreed specification subset governing a document instance.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002", "SRC-004" ] }, { "id": "de-alignment-entry", "name": "Alignment entry", "description": "A declared alignment to an external specification with its version, scope and review date reference.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006", "SRC-012" ] } ], "artifacts": [], "inline_only_rationale": "Alignments are declarative statements pointing at externally versioned specifications that own their governance, publication and interpretation. The model records the alignment, the pinned profile identifiers and the conformance evidence pointer inline; producing a mapping artifact here would duplicate binding documents owned by those specifications." }, { "id": "interchange-idempotency-and-duplicates", "name": "Idempotency, sequencing and duplicate control", "description": "How repeated, out-of-order or duplicated order, change, cancellation and response messages are recognised and reconciled to a single sales order record without re-triggering commitments.", "source_refs": [ "SRC-002", "SRC-003", "SRC-004", "SRC-005" ], "questions": [ { "id": "ii-idempotency-key", "text": "Which key determines that two inbound messages describe the same order or the same response?", "kind": "identity", "answer_data": [ "Idempotency key composition", "Duplicate detection window", "Match outcome" ] }, { "id": "ii-ordering-rule", "text": "How are messages ordered when issue instants collide or arrive out of sequence?", "kind": "temporal", "answer_data": [ "Sequence value", "Tie-breaking rule", "Out-of-order handling" ] }, { "id": "ii-effective-record", "text": "When several responses or versions exist, which one is effective and how is that determined?", "kind": "state", "answer_data": [ "Effective version pointer", "Supersession chain", "Determination rule" ] }, { "id": "ii-replay-safety", "text": "What prevents a replayed message from re-triggering allocation, despatch or acceptance?", "kind": "security", "answer_data": [ "Replay detection mechanism", "Already-applied marker", "Rejection response" ] } ], "data_elements": [ { "id": "de-idempotency-key", "name": "Idempotency key", "description": "Composite key used to recognise a repeated inbound message as already applied.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-004" ] }, { "id": "de-applied-marker", "name": "Already-applied marker", "description": "Flag recording that an inbound message has been applied, preventing repeated effect.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003", "SRC-004" ] } ], "artifacts": [], "inline_only_rationale": "Idempotency keys, ordering rules, supersession pointers and applied markers are control attributes on records already declared in this model. Transport-level delivery guarantees, retries and their enforcement belong to the interface and messaging layer, which this model references rather than owns." } ] }, { "id": "confidentiality-and-retention", "name": "Record Confidentiality and Retention", "description": "Sensitivity classification of order content and the retention and disposition bindings that apply to the seller's own order records.", "source_refs": [ "SRC-004", "SRC-005", "SRC-006", "SRC-012" ], "findings": [ { "id": "order-confidentiality-and-retention", "name": "Order record sensitivity, disclosure and retention bindings", "description": "How order content is classified for sensitivity, which subset may be disclosed to fulfilment partners, which retention rules apply and from which trigger, and how erasure requests reconcile with retention obligations.", "source_refs": [ "SRC-004", "SRC-005", "SRC-006", "SRC-012" ], "questions": [ { "id": "cr-sensitivity-classes", "text": "Which sensitivity classes apply to elements of the order, including personal data in consumer orders?", "kind": "privacy", "answer_data": [ "Element sensitivity class", "Personal data flag", "Classification basis" ] }, { "id": "cr-partner-disclosure", "text": "Which subset of order content may be disclosed to a carrier, warehouse or drop-ship supplier?", "kind": "access", "answer_data": [ "Disclosable element set", "Recipient role", "Redaction or minimisation rule" ] }, { "id": "cr-retention-trigger", "text": "How long must each class of order record be retained and from which triggering event does that period run?", "kind": "retention", "answer_data": [ "Retention period per class", "Retention trigger event", "Legal or contractual basis" ] }, { "id": "cr-disposition-execution", "text": "Who executes disposition when retention expires, and what tombstone remains behind?", "kind": "ownership", "answer_data": [ "Executing policy or model reference", "Tombstone content", "Disposition evidence pointer" ] }, { "id": "cr-erasure-conflict", "text": "How is an erasure request reconciled with an open statutory retention obligation on the same order?", "kind": "exception", "answer_data": [ "Conflicting obligation pair", "Resolution decision and authority", "Restriction-of-processing marker" ] } ], "data_elements": [ { "id": "de-sensitivity-class", "name": "Element sensitivity class", "description": "Classification assigned to an order element governing its disclosure and retention treatment.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005", "SRC-006" ] }, { "id": "de-disclosable-subset", "name": "Disclosable subset definition", "description": "The declared element set releasable to a given partner role, defined in advance rather than per request.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "de-retention-binding", "name": "Retention binding", "description": "Retention period, trigger event and legal or contractual basis applying to a class of order record.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012" ] } ], "artifacts": [], "inline_only_rationale": "Sensitivity classes, disclosable subsets and retention bindings are policy declarations expressed as inline attributes and references. The adopting Dimension's records-management and data-protection models own execution of retention, erasure and tombstoning, so producing a disposition artifact here would imply this model performs actions it only declares and evidences." } ] } ] } ] }, "functions": [ { "id": "capture-sales-order", "name": "Capture sales order", "description": "Record an inbound buyer order or a seller-captured order as a sales order, assign the seller's authoritative identifier and retain inbound provenance.", "inputs": [ "Inbound order message or capture input", "Buyer and seller party references", "Ordered line set with item references, quantities and prices" ], "outputs": [ "Sales order record in an unaccepted state", "Inbound order message record", "Assigned seller sales order identifier" ], "preconditions": [ "Sender and receiver identifiers resolve under declared schemes", "At least one order line is present", "The buyer party resolves to the party master model" ], "effects": [ "A sales order record exists under a seller-assigned authoritative identifier", "Issue time and receipt time are recorded separately with explicit offsets", "No commercial commitment arises until a disposition is issued" ], "source_refs": [ "SRC-002", "SRC-004", "SRC-008" ] }, { "id": "validate-sales-order", "name": "Validate sales order", "description": "Bind an order or response to a named rule set and pinned code list versions and record the resulting outcome; execution is performed by the referenced validation component.", "inputs": [ "Sales order or order response record", "Rule set and specification version", "Pinned code list versions" ], "outputs": [ "Order validation outcome record", "Severity-classified failure list" ], "preconditions": [ "A customization or profile identifier is present or defaulted", "The referenced rule set version is resolvable" ], "effects": [ "The document carries a validation outcome pointer", "Documents failing at blocking severity are barred from acceptance", "Ownership of rule evaluation and enforcement remains with the referenced component" ], "source_refs": [ "SRC-004", "SRC-012" ] }, { "id": "issue-order-disposition", "name": "Issue order disposition", "description": "Issue the seller's response to an order - acknowledgement, acceptance, acceptance with amendment, rejection or counter-offer - at header and line level.", "inputs": [ "Sales order record", "Header disposition code", "Per-line disposition codes and amended values" ], "outputs": [ "Order response record", "Updated header and line states" ], "preconditions": [ "Blocking validation has passed, or the order is being rejected", "All lines are restated where the profile requires it for an amended response", "Prior agreement exists where amendment is permitted" ], "effects": [ "The effective response pointer advances", "Acceptance may form a contract and triggers confirmation", "Rejection moves the order to a terminal refused state" ], "source_refs": [ "SRC-003", "SRC-004", "SRC-009" ] }, { "id": "confirm-contract-formation", "name": "Confirm contract formation", "description": "Record formation of the contract and issue the durable confirmation of agreed terms to the buyer.", "inputs": [ "Accepted sales order record", "Agreed line set, totals, delivery and payment terms", "Buyer communication endpoint reference" ], "outputs": [ "Order confirmation record", "Formation determination citing offer and acceptance references" ], "preconditions": [ "An acceptance disposition exists", "The agreed snapshot is complete and internally consistent" ], "effects": [ "An immutable snapshot of agreed terms is retained with its digest", "The confirmation is issued and its delivery evidenced", "Further alteration requires the change-control function" ], "source_refs": [ "SRC-004", "SRC-006", "SRC-009" ] }, { "id": "apply-order-change-or-cancellation", "name": "Apply order change or cancellation", "description": "Record a buyer-requested amendment or cancellation against a target order version, disposition it, and produce the resulting effective version.", "inputs": [ "Order change request or cancellation record", "Target sales order identifier and version counter", "Seller disposition per affected line" ], "outputs": [ "New effective order version", "Order response record covering the request", "Recalculated committed quantities and totals" ], "preconditions": [ "The cited version is the currently effective one", "The change cut-off has not passed, or an override is authorised and recorded", "The requesting party holds change or cancellation authority" ], "effects": [ "The prior version is marked superseded with an effective-from timestamp", "Allocations and promises on affected lines are recomputed and released where cancelled", "Requests touching already-despatched quantities are routed to the post-delivery claim path" ], "source_refs": [ "SRC-001", "SRC-002", "SRC-004", "SRC-005" ] }, { "id": "commit-availability-and-schedule", "name": "Commit availability and schedule", "description": "Promise and allocate supply to accepted order lines and derive the fulfilment schedule lines.", "inputs": [ "Accepted order lines with requested delivery periods", "Availability basis reference", "Partial shipment permission and sourcing rules" ], "outputs": [ "Fulfilment schedule line records", "Promised delivery period per line", "Allocation firmness flags" ], "preconditions": [ "The line is accepted and carries no active blocking hold", "A sourcing location resolves for each promised quantity" ], "effects": [ "Promised delivery periods become the binding commitment where accepted", "Allocated quantities are reserved against the referenced inventory model", "Unfulfillable quantities are marked outstanding with a reason code" ], "source_refs": [ "SRC-004", "SRC-005" ] }, { "id": "record-despatch-against-order", "name": "Record despatch against order", "description": "Bind a despatch event to specific order lines and update delivered and outstanding quantity accounting.", "inputs": [ "Despatch advice reference and despatch lines", "Shipment and consignment identifiers", "Lot, serial and expiry data where carried" ], "outputs": [ "Despatch linkage record", "Updated delivered and outstanding quantities", "Revised line state" ], "preconditions": [ "Each despatch line resolves to an order line or is routed to unmatched handling", "Despatched quantity is within the permitted oversupply tolerance" ], "effects": [ "Delivered quantity increases and outstanding quantity decreases on the affected lines", "Evaluation of the risk transfer trigger becomes possible", "Transport execution and carrier documentation remain owned by the shipment model" ], "source_refs": [ "SRC-001", "SRC-005" ] }, { "id": "reconcile-and-close-order", "name": "Reconcile delivery and close order", "description": "Compare received against despatched quantities, record discrepancies and their disposition, resolve residual quantities and close the order.", "inputs": [ "Receipt advice reference and received quantities", "Despatch linkage records and open claim references", "Discrepancy tolerance rules and completion criteria" ], "outputs": [ "Delivery discrepancy records with dispositions", "Order claim and closure record", "Final header and line states" ], "preconditions": [ "A despatch linkage exists for the affected lines", "No blocking hold or unresolved discrepancy remains, or a short-close is authorised", "All lines have reached a terminal or short-closed state" ], "effects": [ "Discrepancies outside tolerance are raised for decision and their outcome recorded", "Residual outstanding quantities are short-closed or carried forward with the authorising role recorded", "The order enters a terminal closed state and the retention triggers defined by the adopting Dimension begin, with financial correction delegated to the invoice and settlement models" ], "source_refs": [ "SRC-001", "SRC-004", "SRC-005" ] } ], "composition": [ { "target": "WM-ECO-006", "relation": "CHILD", "purpose": "Positions the seller-side sales order as one phase of the broader trade transaction held by the parent model, which owns the end-to-end buy-ship-pay arc and the cross-phase agreement and party context.", "required": true, "source_refs": [ "SRC-001", "SRC-011" ] }, { "target": "Buyer-side purchase order and procurement model", "relation": "ALIGN", "purpose": "The same order document is read from the opposite role, so element-for-element alignment is required; requisition, approval and buyer budget lifecycle remain entirely with the procurement model.", "required": false, "source_refs": [ "SRC-002", "SRC-004" ] }, { "target": "Invoice and credit note model", "relation": "REFERENCE", "purpose": "The order carries indicative tax and anticipated totals and points at billing documents; tax determination, the fiscal document and its compliance obligations stay with the invoice model.", "required": true, "source_refs": [ "SRC-001", "SRC-012" ] }, { "target": "Despatch, shipment and transport execution model", "relation": "REFERENCE", "purpose": "The order holds despatch and consignment references plus delivered and outstanding accounting; carrier booking, transport documents and physical movement remain with the shipment model.", "required": true, "source_refs": [ "SRC-001", "SRC-005" ] }, { "target": "Trade party master model", "relation": "REFERENCE", "purpose": "Party roles resolve to master identities under declared schemes; party lifecycle, deduplication and scheme registration remain with the party model.", "required": true, "source_refs": [ "SRC-002", "SRC-004" ] }, { "target": "Trade item and catalogue model", "relation": "REFERENCE", "purpose": "Order lines reference trade items by seller and standard identifiers; item attributes, classification and catalogue lifecycle remain with the item model.", "required": true, "source_refs": [ "SRC-002", "SRC-004" ] }, { "target": "Quotation, contract and framework agreement model", "relation": "REFERENCE", "purpose": "The order cites its upstream commercial basis and any call-off parameters; negotiation, agreement lifecycle and term precedence remain with the agreement model.", "required": false, "source_refs": [ "SRC-002", "SRC-004" ] }, { "target": "Payment, credit and settlement model", "relation": "REFERENCE", "purpose": "The order carries proposed payment means and terms and a credit decision reference; scoring, instrument issuance, settlement and dunning remain with the payment model, which owns their evaluation and enforcement.", "required": false, "source_refs": [ "SRC-002", "SRC-003" ] }, { "target": "Inventory and availability model", "relation": "REFERENCE", "purpose": "Availability promises and allocations reference stock positions and sourcing locations; ledger balances, replenishment and location lifecycle remain with the inventory model.", "required": false, "source_refs": [ "SRC-004", "SRC-005" ] }, { "target": "Validation rule-set and conformance model", "relation": "REFERENCE", "purpose": "Supplies rule sets, pinned code list versions and the component that evaluates them; this model stores only the binding and the recorded outcome and never owns rule evaluation or enforcement.", "required": true, "source_refs": [ "SRC-004", "SRC-012" ] }, { "target": "Incoterms trade term rule set", "relation": "ALIGN", "purpose": "Delivery terms bind to a published trade term rule and named place with its cost, insurance and clearance split; the rule set's content and versioning stay with its publisher, and transfer of title falls outside it.", "required": false, "source_refs": [ "SRC-010" ] }, { "target": "Schema.org Order and OrderStatus vocabulary", "relation": "ALIGN", "purpose": "Provides a public web vocabulary for consumer-facing order publication; the mapping is partial and its status enumeration is not adopted as this model's internal state machine.", "required": false, "source_refs": [ "SRC-006", "SRC-007" ] }, { "target": "RFC 3339 timestamp profile", "relation": "ALIGN", "purpose": "Fixes serialisation of every instant recorded here, including the explicit offset requirement and the unknown-offset convention; the profile is owned by its publishing body.", "required": true, "source_refs": [ "SRC-008" ] }, { "target": "Uniform international sales law regime", "relation": "REFERENCE", "purpose": "Supplies default rules on offer and acceptance, delivery, conformity and passing of risk where applicable; applicability determination, exclusions and remedies adjudication remain outside this model.", "required": false, "source_refs": [ "SRC-009" ] }, { "target": "Records management, data protection and audit models of the adopting Dimension", "relation": "REFERENCE", "purpose": "Own execution of retention, erasure, tombstoning and audit-trail storage and immutability for order records; this model declares classification, trigger events, tombstone content and evidence pointers only.", "required": true, "source_refs": [ "SRC-006", "SRC-012" ] } ], "serviceLayers": { "dimension": { "owner_package_requirements": [ "Name a single accountable owner and a named deputy for the sales order package, because acceptance decisions create binding commercial commitments.", "Declare the seller legal entities and selling channels in scope, since sales order identifier uniqueness is scoped to the issuing seller entity.", "Pin the external specification versions bound by the package - order syntax and profile, code lists, trade term rule set and timestamp profile - and record the date each pin was last reviewed.", "Declare which sibling models supply party, item, inventory, agreement, invoice, payment, shipment, validation and records-management context, and forbid local forks of them." ], "namespace_guidance": "Use a stable, dereferenceable namespace under the adopting Dimension's authority, segmented per seller legal entity where identifier uniqueness is entity-scoped, for example /sales-order//. Never encode a date, environment name, storage technology or transport protocol in the namespace. External identifiers - customization and profile identifiers, party and item schemes, trade term rule codes, code list keys - are referenced under their publishers' namespaces and are never re-minted locally.", "registry_links": [ "Registry entry vr.wm-eco-020 at navigation path NAV.SOC.ECO.ORD, with parent WM-ECO-006.", "Composition links to the party, item, inventory, agreement, invoice, payment, shipment, validation and records-management models must be registered before any implementation claims completeness.", "External specification pins - order syntax and profile, code lists, trade term rule set, timestamp profile and web order vocabulary - must be registered as alignment entries carrying version and review date." ] }, "canon_and_patch": { "canonicalization_rules": [ "The canonical sales order is the seller's record keyed by the seller-assigned sales order identifier; received message payloads are provenance, never the canonical record.", "Every coded value is stored together with its code list identifier and pinned version; a bare code is not canonical.", "Amounts are stored with an explicit currency code at the precision the pinned profile requires, and quantities are stored with an explicit unit of measure code.", "All instants are canonicalised to the timestamp profile with an explicit offset; date-only values stay dates and are never widened to instants by assuming a local midnight.", "Party and item values are canonicalised to a scheme-qualified reference plus the snapshot actually agreed at order time; snapshots are never silently refreshed from master data." ], "patch_rules": [ "An accepted order is amended only by a recorded change or cancellation citing the target version counter; in-place mutation of an accepted version is prohibited.", "Each accepted amendment produces a new effective version with an effective-from timestamp and a supersession pointer to the version it replaces, which remains readable.", "Corrections to provenance or classification metadata that do not alter agreed commercial terms are applied as metadata patches with their own provenance entry and do not increment the commercial version counter.", "A patch that would alter an already-despatched quantity is rejected and routed to the post-delivery claim path." ], "compatibility_rules": [ "Adding an optional element, or adding a value to an extensible code list, is a minor change; removing an element, narrowing cardinality or retiring a code is breaking and requires a new major version.", "Changing which identifier is authoritative, or changing the composition of the idempotency key, is always breaking.", "A profile may only narrow this model; it must not introduce elements or semantics absent from the base model.", "Conformance to an external specification is asserted only with a cited validation outcome; version pins are reviewed on a recorded schedule and a superseded pin is flagged rather than silently upgraded." ] }, "artifact_rules": { "identity_priority": [ "Authoritative master-system identifier: the sales order identifier assigned by the seller's system of record for orders, scoped to the issuing seller legal entity, is the primary key for every artifact in this model.", "Governed global identifier or IRI: a scheme-qualified identifier issued under an external governed scheme - such as a party, location or trade item key resolved under its declared scheme - or a dereferenceable IRI minted in the owning Dimension's registered namespace.", "UUID or ULID assigned by the adopting Dimension where neither an authoritative master-system identifier nor a governed global identifier exists, recorded together with its minting authority and minting instant.", "Buyer order references, customer references and accounting cost codes are cross-references only and must never be promoted to a primary key. A date, a delivery period, an issue date or a version effective-from instant is never an identifier." ], "timestamp_rule": "All instants are recorded as RFC 3339 date-time values with seconds present and an explicit numeric offset or the Z designator; a local offset is never omitted or inferred from the reader's environment, and the -00:00 form is used only where UTC is known but the local offset is not. Event time (when the business fact occurred - order issue, acceptance, despatch, delivery, claim) is recorded separately from observation or ingestion time (when the seller's system received or captured the fact) wherever the two can differ, and both are retained on inbound and fulfilment records. Date-only values such as a requested delivery date remain dates and are never widened into instants by assuming a local midnight.", "serial_naming_rule": "Serial artifacts are named by their parent key plus a monotonically increasing, zero-padded sequence value assigned by the owning Dimension, for example /response/0007 or //schedule/003. Sequence values are never reused after deletion or void, never encode a date or any business meaning, and never by themselves determine effect: ordering for effect is decided by the recorded event timestamp together with the supersession pointer.", "integrity_rule": "Every artifact records a content digest over its canonical form, the identifier and version of the specification it was produced under, and a pointer to its validation outcome. Cross-artifact references cite the target identifier and, where the target is versioned, the exact version. A reference that cannot be resolved marks the referring record as degraded rather than silently dropping it. Digest and signature verification are performed by the referenced validation and cryptographic components; this model stores only the recorded outcome." }, "policies": [ "Acceptance is the only act creating commercial commitment: no fulfilment function may allocate, promise or despatch against an order that has not received an acceptance disposition.", "External specifications are alignments, not conformance: a conformance claim is published only alongside a cited validation outcome against a named specification version.", "Boundary discipline: this model records references, bindings and outcomes for tax determination, payment settlement, transport execution, inventory balances, rule evaluation and audit trails, and never reproduces those models' lifecycles, evaluation or enforcement semantics.", "Jurisdictional and consumer obligations are recorded as citable bindings; any obligation lacking a primary legal source is flagged as an evidence gap and is not treated as satisfied.", "Order content carrying personal data is minimised before disclosure to fulfilment partners against a disclosable subset declared in advance, not decided per request." ], "crud": { "read": [ "A read returns the currently effective order version by default; historical versions are retrievable only by explicit version citation.", "Line-scoped reads return the line's own state together with its contribution to the derived header state, so partial fulfilment is never misread as whole-order completion.", "Reads by a fulfilment partner role return only the declared disclosable subset, with personal data minimised.", "Every coded value is returned with its code list identifier and pinned version, and every instant with its explicit offset." ], "create": [ "A sales order is created only with a resolvable buyer party reference, at least one line, and a seller-assigned authoritative identifier; issue time and receipt time are recorded separately at creation.", "Creation retains an inbound message provenance record with a payload digest before any transformation is applied.", "Duplicate detection runs against the declared idempotency key before a record is created; a matched duplicate returns the existing record rather than creating a second one.", "Serial child artifacts - responses, holds, schedule lines, despatch linkages, discrepancies, claims, validation outcomes - are created only against an existing effective parent order." ], "update": [ "Commercial terms of an accepted order are updated only through a recorded change or cancellation citing the target version; direct field mutation is prohibited.", "Each accepted change creates a new effective version with an effective-from timestamp and a supersession pointer, leaving the superseded version readable.", "State transitions are permitted only along the declared transition set; a rejected transition is recorded as an exception rather than silently ignored.", "Metadata corrections that do not alter agreed commercial terms are applied as metadata patches with their own provenance entry and do not increment the commercial version counter." ], "delete": [ "Sales order records are not hard-deleted while any statutory, contractual or dispute-related retention obligation remains open; the default disposition is retain-then-dispose, never delete-on-request.", "An order created in error and never accepted is voided rather than removed: it is marked void with a reason and a voiding authority, and its identifier is retired and never reused.", "On expiry of the applicable retention period, disposition removes or irreversibly redacts the order payload and leaves a tombstone carrying the sales order identifier, the version counter at disposal, the disposition instant with explicit offset, the retention basis and the executing policy reference, so inbound references degrade explicitly instead of dangling.", "Retention periods, erasure decisions and execution of disposal are owned by the adopting Dimension's records-management and data-protection policy and, where the record is also an accounting or fiscal record, by the invoice and settlement models; this model declares only the classification, the trigger event, the tombstone contract and the evidence pointer, and never executes or enforces deletion itself.", "Serial child artifacts are disposed with their parent order unless an independent retention obligation applies, in which case each carries its own retention basis and its own tombstone." ] }, "roles": [ { "name": "Sales order model steward", "responsibilities": [ "Maintains scope, boundary notes, out-of-scope list and composition links", "Reviews and re-pins external specification and code list versions on a recorded schedule", "Adjudicates whether a proposed element belongs in this model or in a sibling model" ] }, { "name": "Order acceptance authority", "responsibilities": [ "Issues header and line dispositions, including rejection and counter-offer", "Authorises overrides of the change cut-off and records the justification", "Owns the evidence that a contract was formed on stated terms" ] }, { "name": "Fulfilment planner", "responsibilities": [ "Commits availability and produces fulfilment schedule lines", "Decides substitutions and split shipments within declared permissions", "Records short-close and carry-forward decisions on residual quantities" ] }, { "name": "Interoperability custodian", "responsibilities": [ "Maintains syntax and profile bindings and pinned code list versions", "Registers alignment entries and records known mapping loss", "Publishes the validation outcomes that support any conformance claim" ] }, { "name": "Records and data protection custodian", "responsibilities": [ "Classifies order content sensitivity and maintains disclosable subsets per partner role", "Applies retention triggers and requests disposition under the adopting Dimension's policy", "Reconciles erasure requests against open statutory and contractual retention obligations" ] } ], "access": { "default_rule": "Deny by default. Read and write access is granted per role and per scope against the least-privileged subset needed for a declared task; the effective grant is the intersection of the role's scope and the disclosable subset declared for the requester's relationship to the order.", "scopes": [ "bundle", "layer", "finding", "artifact" ], "exceptions": [ "Fulfilment and logistics partners receive an artifact-scoped minimised subset - line item reference, quantity, delivery location and window, handling instructions - and never receive pricing, payment terms, credit decisions or allocation detail.", "The buyer party receives its own order, responses, confirmations, despatch linkages and discrepancy outcomes, but not internal sourcing locations, allocation firmness or hold decision detail.", "Break-glass read of a held or disputed order is permitted to a named dispute-resolution role, is time-boxed, and is recorded with the invoking identity and stated justification.", "Statutory or regulatory disclosure overrides sensitivity restrictions only on a cited legal basis recorded against the order." ], "audit_requirements": [ "Every acceptance, amendment, cancellation, hold, release, short-close, closure and disposition records the acting identity, the authority basis and the event instant with an explicit offset.", "Every break-glass or statutory-disclosure access records the invoking identity, the justification, the scope accessed and the time window.", "Audit-trail storage, immutability guarantees, retention and inspection are owned by the adopting Dimension's audit model; this model emits the required facts and holds a pointer to the resulting audit record, and implements no audit semantics of its own." ] }, "agents_bootstrap": { "filename": "AGENTS.md", "required_fields": [ "Name", "Type", "Specification URL", "Storage type URL", "Interface URL", "Processes URL", "Registry ID", "Model ID", "Owner and steward", "Composition links", "Pinned external specification and code list versions", "Access default and disclosable subsets", "Retention and disposition policy reference" ], "read_order": [ "AGENTS.md - resolve Name, Type, Specification URL, Storage type URL, Interface URL and Processes URL before touching any record.", "Model scope, out-of-scope list and boundary notes - confirm the request belongs to this model rather than a sibling.", "Composition links and pinned external specification and code list versions - resolve every referenced model and version before interpreting coded values.", "Service layers - identity priority, timestamp rule, canonicalisation and patch rules, access default and CRUD rules - apply before any read or write.", "Bundles, layers and findings in declared order - the question set defines the answerable surface.", "Coverage - known omissions, conflicts and regional assumptions - treat listed gaps as unanswered rather than inferring an answer." ] } }, "coverage": { "claim": "Covers the seller-side sales order aggregate to the depth supported by the twelve retrieved sources: identity and line structure, party roles and ordering authority, priced, delivery, risk and payment terms, seller disposition and contract formation, state, change, cancellation and hold control, allocation and despatch linkage, delivered-versus-outstanding accounting, post-delivery claims and closure, plus validation, provenance and interchange bindings. The evidence base is European-profile weighted (UBL and Peppol) and does not represent North American transaction-set ordering practice. The access, ownership and retention rows assert posed questions and declared bindings only, not declared and evidenced controls; consumer-protection duties are a flagged gap, and UN/EDIFACT, X12, GS1 and EPCIS were not retrieved. No universal completeness, no conformance to any external specification, and no independent second-provider review is claimed.", "confidence": "medium", "checklist": [ { "dimension": "identity", "status": "covered", "notes": "Seller-assigned sales order identifier is the authoritative key scoped to the issuing seller entity; buyer references, customer references and accounting codes are cross-references only, and line identity is composite. Grounded in the order and order-response schemas." }, { "dimension": "lifecycle", "status": "covered", "notes": "Disposition, contract formation, change, cancellation, hold, allocation, despatch, discrepancy, claim and closure are modelled with version counters and supersession pointers. The state vocabulary itself is model-owned; no retrieved primary source publishes a normative seller-side state machine." }, { "dimension": "relationships", "status": "covered", "notes": "Party, item, agreement, inventory, despatch, invoice, payment, validation and records-management links are modelled as references with explicit ownership boundaries and no reproduction of target lifecycles." }, { "dimension": "temporal", "status": "covered", "notes": "Issue, receipt, acceptance, requested and promised delivery periods, validity, despatch, delivery, claim windows and closure instants, under an RFC 3339 profile with explicit offsets and event time separated from ingestion time." }, { "dimension": "provenance", "status": "covered", "notes": "Inbound channel, capture method, syntax and version, sender and receiver identifiers, envelope reference, payload digest and transformation trail are retained, with audit-trail guarantees explicitly attributed elsewhere." }, { "dimension": "ownership", "status": "covered", "notes": "Ordering authority and mandate, change and cancellation authority, hold decision owner, discrepancy and short-close deciding roles, closure authority and five steward roles are declared." }, { "dimension": "validation", "status": "covered", "notes": "Rule set and code list pinning with severity-classified recorded outcomes; execution is attributed to a referenced validation component and never claimed by this model." }, { "dimension": "access", "status": "covered", "notes": "Deny-by-default with role and scope grants across bundle, layer, finding and artifact, a pre-declared disclosable subset for fulfilment partners, buyer-facing subset limits, and time-boxed break-glass." }, { "dimension": "retention and deletion", "status": "covered", "notes": "Retain-then-dispose default, void rather than delete for never-accepted records, an explicit tombstone contract with disposition instant and retention basis, and execution attributed to the adopting Dimension's records policy and the fiscal-record models." }, { "dimension": "interoperability", "status": "covered", "notes": "Alignments to two order syntaxes, a public web order vocabulary, a trade term rule set and the timestamp profile, with profile pinning, recorded mapping loss and a conformance-evidence requirement." }, { "dimension": "state and exception handling", "status": "covered", "notes": "Holds and blocks, unmatched despatches, oversupply, outstanding reasons, discrepancy dispositions, expired validity, authority failure and reopening are modelled as first-class exception paths." }, { "dimension": "measurement and quantity", "status": "covered", "notes": "Ordered, allocated, promised, delivered, outstanding, oversupplied and claimed quantities each carry an explicit unit of measure with a pinned code list version; amounts carry explicit currency and precision." }, { "dimension": "spatial", "status": "covered", "notes": "Named place for the delivery term rule, delivery location reference, sourcing location reference and destination country for customs purposes, with a header-versus-line consistency check." }, { "dimension": "consumer protection obligations", "status": "gap", "notes": "Distance-selling duties, order-confirmation requirements, statutory withdrawal periods and delivery deadlines are modelled only as citable bindings with an evidence-gap flag. No primary legislative text was retrievable in this pass, so this node is marked a gap rather than presented as canonical." } ], "known_omissions": [ "No primary retrieval of UN/EDIFACT ORDERS and ORDRSP message directories or UNTDID code lists 1001, 1225 and 4343; the UNECE service host returned HTTP 403. Disposition semantics are grounded via the Peppol profile instead.", "No primary retrieval of ASC X12 850, 855, 860, 865, 869 or 870; the published transaction set page did not expose the supply chain subcommittee entries, leaving North American EDI ordering practice unrepresented.", "No primary retrieval of GS1 EDI Order or the GS1 General Specifications identification keys; gs1.org returned HTTP 403. GS1 key usage (GTIN, GLN, SSCC, GSIN, GINC) is evidenced only indirectly through the Peppol despatch advice profile.", "No primary retrieval of EPCIS 2.0 or the Core Business Vocabulary; the reference host served an unparsable binary. Traceability linkage is grounded only through line-level lot, serial and expiry data in the despatch profile.", "No primary retrieval of consumer-protection legislative text; the EU legal database returned an empty document body, so consumer duties are carried as flagged bindings only.", "Revenue recognition and performance-obligation accounting are entirely absent and belong to a finance model.", "Subscription, recurring and standing-order specialisations, and service orders for non-goods deliverables, are only lightly covered by the commercial pattern classification.", "Order status inquiry and order status report messaging patterns are not grounded in any retrieved primary source." ], "conflicts": [ "Identity anchoring conflicts: the order document standards treat the order as buyer-issued with a sender-assigned document identifier and an optional seller-assigned SalesOrderID, whereas the public web order vocabulary treats the order as a seller-side record keyed by orderNumber. This model resolves in favour of the seller-assigned identifier and records the buyer identifier as a cross-reference, which is a deliberate choice rather than a neutral reading.", "Response dispositions and order states are not interchangeable: the header codes AB, RE, AP and CA and the line codes 1, 3, 5, 7 and 42 describe a response message, while the eight published web status members describe an order's condition. No lossless one-to-one mapping exists, and any mapping asserted by an implementation must be recorded as lossy.", "Title transfer has no owner in either cited framework: the trade term rules allocate cost, risk, insurance and clearance but not property, and the uniform sales law instrument leaves property effects to national law. Any system inferring title transfer from delivery terms alone is unsupported.", "Order tax figures conflict with fiscal authority: the order schema permits TaxTotal and an anticipated monetary total, but the European e-invoicing framework makes the invoice the compliance-bearing document, so order-level tax values are indicative and may legitimately diverge from the invoice.", "Version skew between base standard and deployed profile: the retrieved order and order-response schemas are UBL 2.4 (June 2024) while the retrieved ordering and despatch profiles bind UBL 2.1, so elements present in 2.4 may be unavailable in a conforming exchange.", "Syntax workarounds conflict with clean optionality: the despatch profile mandates the dummy value NA for a missing shipment identifier and for a missing order line reference. This model treats absence as absence and records NA as a syntax-level artefact, not as semantic content." ], "regional_assumptions": [ "The ordering and despatch profiles are European public-procurement oriented and authoritative only within that network; their disposition codes and business rules should not be assumed elsewhere.", "The uniform international sales law instrument applies only to international business-to-business sales between Contracting States, is subject to party exclusion and to state reservations, and expressly does not cover consumer sales.", "The e-invoicing compliance framework cited binds EU public contracting authorities; the order-versus-invoice boundary it evidences is argued to generalise, but the obligation itself does not.", "Consumer distance-selling duties - pre-contractual information, explicit order acknowledgement, durable-medium confirmation, withdrawal periods and statutory delivery deadlines - are jurisdiction-specific and carried here only as flagged bindings without primary textual support.", "North American ordering practice, which relies on a different transaction set family, is not represented; adopters in that region should expect additional identity and acknowledgement semantics." ], "adversarial_checks": [ "Tested whether a canonical order state machine could be asserted: rejected. No retrieved primary source publishes a normative seller-side state machine, so the state vocabulary is declared model-owned and inline, with external enumerations treated as lossy alignment targets rather than conformance.", "Tested whether carrying TaxTotal on the order justifies owning tax determination: rejected. The fiscal document, tax calculation and reporting obligations were moved to a required REFERENCE link to the invoice model and to a boundary note.", "Tested whether recording a validation outcome implies owning a rules engine: rejected. The finding, its artifact identity strategy and the corresponding function all attribute evaluation and enforcement to a referenced validation component; only the binding and the recorded outcome are held here.", "Tested whether binding a delivery term rule implies determining transfer of title: rejected on the strength of both the trade term publisher's scope and the sales-law instrument's exclusion of property effects; title basis is recorded as a citation to applicable law.", "Tested whether despatch, lot and serial data implies owning a traceability event store: rejected. Only order-line linkage and instance data carried on the despatch are retained; event-store semantics were placed out of scope.", "Tested whether provenance and message-trail content implies owning an audit trail: rejected. Audit storage, immutability, retention and inspection are attributed to the adopting Dimension's audit model, with this model emitting facts and holding a pointer.", "Tested whether the buyer's purchase order should be modelled here because the same document instance is exchanged: rejected. The document is read from the seller role only, and requisition, approval and budget lifecycle were placed out of scope behind an ALIGN link to the procurement model.", "Tested whether hold and credit-block content implies owning credit decisioning: rejected. Holds are recorded as order state with a pointer to the deciding authority; scoring and credit policy remain with the payment and credit model." ] }, "researchAdjudication": { "providerMode": "single-provider-waiver", "activeProviders": [ "claude" ], "waivedProviders": [ "grok" ], "providerPolicy": { "contract_version": "1.0.0", "mode": "single-provider-waiver", "effective_at": "2026-08-29T09:06:27Z", "scope": "Queued subject-model research from WM-XCT-013 onward", "active_providers": [ "claude" ], "waived_providers": [ { "provider": "grok", "authorized_by": "repository owner", "authorized_at": "2026-08-29T09:06:27Z", "reason": "The repository owner explicitly instructed the research queue to continue without Grok after repeated structured-output failures." } ], "review_rule": "Claude-only results require a separate no-tools adversarial audit and remain reviewable drafts with a visible single-provider hold." }, "boundaryDecision": { "entry_kind": "aggregate", "status": "reclassified", "rationale": "The result's aggregate-root claim is substantively supported by its own evidence: a single seller-assigned authoritative key scoped to the issuing seller entity, order lines with composite (non-independent) identity, and all fourteen artifacts — responses, change and cancellation records, holds, schedule lines, despatch linkage, discrepancy and claim/closure records — keyed through the order header with no standalone lifecycle. That is one transactional consistency boundary, not a document description. However the frozen registry record carries entry_kind 'standalone-mm' in the same-named field, so the two disagree on their face. This audit affirms 'aggregate' as the modelling shape and marks the registry value for reconciliation; if the registry enumeration does not admit 'aggregate', the synthesizer must record a documented mapping rather than silently overwrite the frozen record, and the registry's existing review_state 'boundary-review-required' stays open until that mapping is registered." }, "decisions": [ { "concept": "Aggregate root: sales order header as the consistency boundary", "disposition": "accepted", "rationale": "Every emitted artifact resolves through the order header or an order line; none carries independent identity or an externally addressable lifecycle. The scope statement and the fourteen-artifact accounting are mutually consistent (24 findings, 13 with artifacts, 11 with explicit inline_only_rationale), so the root claim holds on the result's own evidence." }, { "concept": "Splitting fulfilment-and-delivery into a second aggregate", "disposition": "rejected", "rationale": "Tested whether schedule lines, despatch linkage, discrepancy and claim/closure records form an independent fulfilment aggregate. They are keyed by order line, have no identity outside the order, and shipment structure, carrier detail and transport execution are already disclaimed to the despatch model. Splitting would create a second root with no key of its own." }, { "concept": "Registry entry_kind 'standalone-mm' versus result entry_kind 'aggregate'", "disposition": "reclassified — reconcile, do not overwrite", "rationale": "Same field name, different values, and the pack supplies no enumeration mapping. The audit cannot verify that 'aggregate' is admissible in the registry enum without tools, so synthesis must publish the mapping decision explicitly and keep boundary-review-required open rather than silently restamping the frozen record." }, { "concept": "Ownership of availability computation and stock allocation", "disposition": "accepted with required narrowing", "rationale": "The function 'commit-availability-and-schedule' says the model promises and allocates supply, with no execution disclaimer, while 'validate-sales-order' explicitly attributes execution to a referenced component and out_of_scope excludes inventory ledger balances. The asymmetry must be closed: the order holds the recorded allocation outcome, firmness and reservation pointer; availability determination and stock reservation belong to the inventory model." }, { "concept": "Question al-split-and-contention (cross-order stock contention)", "disposition": "reclassified — narrow to recorded outcome plus deciding authority", "rationale": "A single order aggregate cannot observe or adjudicate competing claims from other orders. As written the question reaches outside the boundary the model otherwise defends. It should follow the hold pattern already used at hb-decision-owner: record the outcome and a pointer to the deciding authority, not the resolution rule." }, { "concept": "Missing boundary notes for named neighbours", "disposition": "deferred — required before promotion out of draft", "rationale": "out_of_scope and adversarial_checks name an inventory/availability model, a payment and credit model and a reverse-logistics/returns model, but boundary_notes covers only eight other neighbours and omits all three. Neighbours that carry rejected ownership claims must have an explicit distinction recorded, otherwise the rejections are asserted without a stated counterpart." }, { "concept": "Coverage checklist rows for access, ownership and retention", "disposition": "rejected as stated — restate before publication", "rationale": "The checklist asserts deny-by-default grants across bundle, layer, finding and artifact, time-boxed break-glass, five steward roles, retain-then-dispose defaults and an explicit tombstone contract. None of these appear anywhere in the emitted structure, which contains only questions, artifacts and inline rationales. The rows describe resolutions to questions the model merely poses, and must be restated as posed questions and declared bindings." }, { "concept": "Authority tiering of SRC-010, SRC-011 and SRC-012", "disposition": "rejected as tier-1 primary normative text", "rationale": "The Incoterms citation is a publisher overview page rather than the rule text, the UN/CEFACT citation is a vocabulary portal root that cannot evidence the stated D23B and UN/LOCODE version pins, and the EN 16931 citation is a Commission summary page rather than the CEN standard. Each is a legitimate pointer but cannot bear tier-1 primary weight for the obligation-split and fiscal-boundary claims that rest on it." }, { "concept": "Artifact identity: order-confirmation-record marked serial: false", "disposition": "rejected", "rationale": "Change and cancellation control produces successive effective versions and ord-response-sequencing contemplates multiple responses to one order, so a durable confirmation can legitimately be issued more than once against the same order. A non-serial confirmation contradicts the model's own amendment and re-confirmation paths." }, { "concept": "Artifact identity: order-claim-and-closure-record", "disposition": "rejected as a single artifact", "rationale": "It conflates post-delivery claims, which are repeating and many-per-order, with closure, which is a terminal singleton subject to a defined reopening condition. One serial flag cannot express both cardinalities, and downstream retention and disposition rules differ between them." }, { "concept": "Typed REQUIRED/REFERENCE/ALIGN links asserted in adversarial_checks", "disposition": "deferred — publish boundary notes as prose only", "rationale": "The frozen relationship contract is an empty array and the registry's aligned_model_ids, contains_ids and relations_ref are all blank, yet the narrative claims a required REFERENCE link to the invoice model and an ALIGN link to the procurement model. No typed link may be published as registered until the contract records it." }, { "concept": "No function applies or releases a hold despite order-hold-record existing", "disposition": "deferred — cannot be added under single-provider rules", "rationale": "The holds finding emits an artifact with no producing or releasing function, and post-delivery claim capture is not covered by 'reconcile-and-close-order'. Both are genuine gaps, but add_functions must remain empty in waiver mode, so they are recorded for a follow-up pass rather than synthesised in." }, { "concept": "The six self-declared conflicts in the result", "disposition": "accepted as disclosed modelling choices", "rationale": "Identity anchoring, response-code versus status-enumeration non-interchangeability, ownerless title transfer, indicative order tax, UBL 2.4 versus 2.1 profile skew and the NA placeholder convention are each stated with their resolution and their cost. Disclosed and reasoned divergence is not an unresolved contradiction and does not block a reviewable draft." }, { "concept": "Composition role under parent WM-ECO-006", "disposition": "deferred", "rationale": "The registry records parent_ids WM-ECO-006 with empty composition_role and default_link_type, and the result never states how this aggregate composes beneath that parent. An aggregate-root claim is incomplete until its position relative to its declared parent is stated." }, { "concept": "Retention and deletion attributed to the adopting Dimension", "disposition": "accepted", "rationale": "The inline_only_rationale correctly holds that declaring classification, retention triggers and tombstone content is not the same as executing retention, erasure or audit storage. That boundary is consistent with the records-management boundary note and with the provenance finding's audit-boundary question." } ], "publicationHolds": [ "Single-provider hold: the repository owner waived Grok on 2026-08-29T09:06:27Z after repeated structured-output failures, so this result has had no independent second-provider review. Every publication artifact must carry that waiver, its authorising party and its timestamp visibly, and the record stays a reviewable draft.", "Live source verification hold: all twelve source URLs and their version pins must be re-fetched and confirmed live before publication, including the UBL 2.4 OASIS Standard of 20 June 2024, the Peppol Ordering 3.3 and Despatch Advice 3.1 profiles, the Schema.org v30.0 snapshot dated 2026-03-19 and the EN 16931 page last updated 5 March 2026.", "Source re-tiering hold: SRC-010, SRC-011 and SRC-012 are publisher overview, vocabulary-portal and summary pages, not normative text, and may not be published at authority tier 1 as primary sources until the underlying normative documents are retrieved or the tier is lowered.", "Coverage checklist restatement hold: the access, ownership and retention-and-deletion rows assert declared controls, steward roles, break-glass and tombstone contracts that do not exist in the emitted structure. They must be restated as posed questions and declared bindings, or the missing declarations materialised, before the checklist is published.", "Relationship contract hold: the frozen contract is empty and no neighbour model is identified by registry ID, so the eight boundary notes and the REQUIRED/ALIGN links named in the adversarial checks publish as prose only and must not be rendered as registered typed relations.", "Entry-kind reconciliation hold: the registry record states standalone-mm while the result states aggregate; the registry review_state boundary-review-required stays open and the mapping decision must be visible in the published draft.", "Consumer-protection evidence hold: distance-selling duties, order-acknowledgement requirements, withdrawal periods and statutory delivery deadlines carry no primary legislative text and must stay marked as an evidence gap, never rendered as canonical model content.", "Independent second-provider review was explicitly waived by the repository owner; this Claude-only result remains a reviewable draft." ], "deferredResearch": [ "Retry the eight declared retrieval failures that were caused by transport errors rather than absence: UN/EDIFACT ORDERS and ORDRSP directories with UNTDID code lists 1001, 1225 and 4343 (HTTP 403), ASC X12 850, 855, 860, 865, 869 and 870, GS1 EDI Order and General Specifications identification keys (HTTP 403), and EPCIS 2.0 with the Core Business Vocabulary (unparsable binary payload).", "Retrieve primary consumer-protection legislative text to close the single checklist gap, so that pre-contractual information, explicit order acknowledgement, durable-medium confirmation, withdrawal periods and statutory delivery deadlines can be grounded rather than carried as flagged bindings.", "Deepen access, privacy, security and retention coverage: the 100-question set contains one access, one privacy, one retention and one security question for an aggregate that carries consumer personal data, signature evidence, payment terms and a partner disclosure subset. Determine whether the thinness is a tagging artefact or genuine under-coverage before promotion.", "Resolve the inventory and availability boundary: retrieve a primary availability-to-promise or allocation source so that promise basis, allocation firmness, substitution and cross-order contention can be attributed to a named neighbouring model rather than absorbed by the order.", "Register the neighbouring models by ID — invoice, despatch and transport, procurement, quotation and framework agreement, trade item and party master, inventory, payment and credit, returns, records management — and populate the relationship contract, aligned_model_ids and the composition role beneath parent WM-ECO-006.", "Add hold application and release, and post-delivery claim capture, as functions in a follow-up pass; both were identified here but could not be added under the single-provider waiver rules.", "Ground order status inquiry and status report messaging patterns, and the subscription, standing-order and service-order specialisations, which the result acknowledges are only lightly covered by the commercial pattern classification." ] }, "statistics": { "sources": 12, "bundles": 6, "layers": 13, "findings": 24, "questions": 100, "artifacts": 14, "functions": 8 } }