# Vercy AI instruction - YAML 1.2 (JSON-compatible) { "vercy": "1.0-draft", "publication": { "status": "published", "adjudicationStatus": "reviewable-draft", "publishableCanonical": false, "generatedAt": "2026-08-25T15:13:16Z", "synthesisSha256": "c3fa95a41f07cc17f11f1405021d0a05c31606919e925b320ca5306cb692746d", "providerMode": "dual-provider", "providers": [ "Claude", "Grok" ], "waivedProviders": [] }, "metaModel": { "id": "WM-ECO-019", "registryId": "vr.wm-eco-019", "name": "Purchase 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": [ "purchase", "order", "soc.eco.ord" ], "status": "published" }, "canonicalUrl": "https://ver.cy/models/wm-eco-019-purchase-order/", "sourceUrl": "https://github.com/ver-cy/world-models/tree/feat/mega-model-registry/research/runs/wm-eco-019", "model": { "registry_id": "vr.wm-eco-019", "model_id": "WM-ECO-019", "name": "Purchase Order", "entry_kind": "aggregate", "purpose": "Give an agent the context needed to interpret, create, validate and operate a purchase order as a buyer-issued commitment instrument, and to track it through response, amendment, fulfilment linkage and closure, independently of storage format or interface.", "scope_statement": "Covers the purchase order as an identifiable commercial instrument issued by a buyer to a seller: identity and revision, classification and purchasing pattern, parties and commitment authority, line-item and commercial terms content, delivery instruction, lifecycle from issue through response, amendment, cancellation and closure, and the governance layers (provenance, retention, access, interoperability) needed to operate it. It stops where a distinct instrument or sibling model takes over: the quotation that may precede it, the contract or framework agreement it draws on, the fulfilment obligations it creates, and the invoice and payment that settle it. Registry entry_kind 'standalone-mm' is expressed here as 'aggregate' because the order header is the aggregate root and order lines have no identity outside it.", "in_scope": [ "Order header identity, document versioning and revision control", "Order classification and purchasing pattern (standalone, call-off/release against a framework, change, consignment, drop-ship)", "Buyer, seller and ancillary party roles and their identification schemes", "Order line composition: item identification, ordered quantity, unit of measure, packaging", "Price basis, allowances and charges, currency and anticipated monetary totals as stated on the order", "Payment terms and means, and references to governing contract terms and clauses", "Delivery destination, requested delivery schedule, delivery terms and risk-transfer point", "Order lifecycle states, order response and acceptance semantics, amendment, cancellation and closure", "Provenance, transmission evidence, time semantics, retention, access control and syntax interoperability" ], "out_of_scope": [ "Invoice content, tax determination and payment execution (settlement instruments reference the order but are modelled separately)", "Quotation and RFQ content and seller price-offer logic (WM-ECO-021)", "Product catalogue and item master data content beyond the identifiers cited on the order", "Physical fulfilment execution, despatch, transport and receipt/inspection events (WM-ECO-024)", "Contract clause corpus, framework agreement negotiation and master terms body (WM-ECO-006)", "Supplier onboarding, qualification and party master data management", "Requisition, budget encumbrance and internal spend approval policy beyond the authority actually asserted on the order" ], "boundary_notes": [ { "neighbor": "Quotation / RFQ (WM-ECO-021)", "distinction": "A quotation is seller-originated and, under FAR 13, is not an offer that the buyer can accept to form a contract; the purchase order is the buyer-originated instrument. UBL keeps Quotation and Order as separate documents linked by QuotationDocumentReference, so quotation content stays in the sibling model and only the reference is held here.", "source_refs": [ "SRC-001", "SRC-003" ] }, { "neighbor": "Fulfilment obligation (WM-ECO-024)", "distinction": "The order states requested delivery; the obligations it creates and the performance events that discharge them (despatch, receipt, acceptance of goods) belong to the contained model. UBL and Peppol model despatch advice and receipt as separate documents.", "source_refs": [ "SRC-001", "SRC-002" ] }, { "neighbor": "Contract / framework agreement (WM-ECO-006)", "distinction": "The order references a contract rather than restating it; UBL Order carries a Contract reference, and FAR treats a blanket purchase agreement and the calls placed against it as different objects. Clause bodies and negotiated terms live in the parent model.", "source_refs": [ "SRC-001", "SRC-003" ] }, { "neighbor": "Invoice and settlement", "distinction": "The invoice references the order (EN 16931 BT-13 purchase order reference, BT-14 sales order reference); invoice content, tax breakdown and payment status are not order content, and the order carries only anticipated, not settled, monetary totals.", "source_refs": [ "SRC-001", "SRC-010" ] }, { "neighbor": "Transport and delivery-terms rules", "distinction": "Incoterms 2020 allocate delivery, cost and risk between seller and buyer but are a referenced trade-term code plus named place; the ICC rules themselves are external and are not restated in this model, and they do not determine price, title transfer or payment.", "source_refs": [ "SRC-009" ] }, { "neighbor": "Order response document", "distinction": "An order response is a distinct document with its own identity and its own customization identifier in Peppol; this model holds the resulting acceptance state and the response reference on the order, not the response document's internal model.", "source_refs": [ "SRC-001", "SRC-002" ] }, { "neighbor": "Party master data and identifier registries", "distinction": "GS1 allocates and governs GLNs and ISO 6523 ICD schemes qualify party identifiers; the order cites identifiers under a declared scheme but does not own their allocation, reuse policy or registry lifecycle.", "source_refs": [ "SRC-008", "SRC-002" ] } ] }, "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, approved 20 June 2024", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T09:00:00Z", "relevance": "Normative document models for Order, OrderResponse, OrderResponseSimple, OrderChange and OrderCancellation, including header business information entities (ID, UUID, IssueDate/IssueTime, OrderTypeCode, ValidityPeriod, party roles, Delivery, DeliveryTerms, PaymentMeans, PaymentTerms, AllowanceCharge, TaxTotal, AnticipatedMonetaryTotal) and OrderLine/LineItem structure." }, { "id": "SRC-002", "title": "Peppol BIS Ordering 3.3", "organization": "OpenPeppol AISBL (Post-Award Community)", "url": "https://docs.peppol.eu/poacc/upgrade-3/profiles/28-ordering/", "version_or_date": "BIS Ordering 3.3", "source_type": "first-party-doc", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-25T09:00:00Z", "relevance": "Cross-border ordering profile: Order (Trdm01) and Order Response (Trdm76), header response codes AB/RE/AP/CA and line response codes 1/3/5/7/42, the rule that one order response refers to exactly one order, line identifier matching, item identifier or item name requirement, and ProfileID/CustomizationID declarations." }, { "id": "SRC-003", "title": "Federal Acquisition Regulation Part 13 - Simplified Acquisition Procedures", "organization": "U.S. Federal Acquisition Regulatory Council (acquisition.gov)", "url": "https://www.acquisition.gov/far/part-13", "version_or_date": "FAC 2026-01, effective 13 March 2026", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T09:00:00Z", "relevance": "Normative treatment of a purchase order as a unilateral offer that becomes a binding contract only on supplier acceptance, acceptance by performance, withdrawal before acceptance, modification numbering (13.302-3), cancellation and termination of accepted versus unaccepted orders (13.302-4), blanket purchase agreements and calls, and forms OF 347 / SF 1449." }, { "id": "SRC-004", "title": "Federal Acquisition Regulation Subpart 4.7 - Contractor Records Retention", "organization": "U.S. Federal Acquisition Regulatory Council (acquisition.gov)", "url": "https://www.acquisition.gov/far/subpart-4.7", "version_or_date": "FAC 2026-01, effective 13 March 2026", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T09:00:00Z", "relevance": "Retention obligations: 3 years after final payment as the baseline (4.703), purchase orders in financial and cost accounting records retained 4 years (4.705-1), purchase order files and receiving/inspection reports retained 4 years (4.705-3), and calculation of retention from the end of the fiscal year in which the entry is made (4.704)." }, { "id": "SRC-005", "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": "Adopted 11 April 1980; entered into force 1 January 1988", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T09:00:00Z", "relevance": "Contract formation through exchange of offer and acceptance for international B2B sales of goods, seller obligations (deliver conforming goods, hand over documents, transfer property) and buyer obligations (pay the price, take delivery), and remedies including avoidance for fundamental breach." }, { "id": "SRC-006", "title": "RFC 3339 - Date and Time on the Internet: Timestamps", "organization": "Internet Engineering Task Force (IETF)", "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-25T09:00:00Z", "relevance": "Internet profile of ISO 8601: date-time = full-date 'T' full-time, mandatory time-offset of 'Z' or a numeric offset, seconds required with optional fractional seconds, and the rule that unqualified local time is unacceptable." }, { "id": "SRC-007", "title": "UN/CEFACT Web Vocabularies (Buy-Ship-Pay Reference Data Model)", "organization": "UNECE / UN/CEFACT", "url": "https://vocabulary.uncefact.org/", "version_or_date": "Buy-Ship-Pay vocabulary D23B", "source_type": "ontology", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T09:00:00Z", "relevance": "Linked-data vocabulary for the Buy-Ship-Pay international trade and transport reference data model, providing a syntax-neutral semantic anchor for trade transaction, party, trade line item, delivery and payment concepts used across ordering messages." }, { "id": "SRC-008", "title": "Global Location Number (GLN)", "organization": "GS1 Australia (GS1 Member Organisation)", "url": "https://www.gs1au.org/what-we-do/standards/global-location-number-gln", "version_or_date": "Accessed 25 August 2026; GLN non-reuse policy effective 1 July 2022", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-25T09:00:00Z", "relevance": "GLN 13-digit structure (GS1 Company Prefix, location reference, check digit), the five things a GLN identifies (fixed physical location, mobile physical location, digital location, legal entity, function), application identifiers 410 ship-to / 411 bill-to / 412 purchased-from / 414 physical location / 417 party, non-reuse policy, and ISO 6523 ICD 0088 compatibility." }, { "id": "SRC-009", "title": "Incoterms rules", "organization": "International Chamber of Commerce (ICC)", "url": "https://iccwbo.org/business-solutions/incoterms-rules/", "version_or_date": "Incoterms 2020, in force from 1 January 2020", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-25T09:00:00Z", "relevance": "Eleven three-letter trade terms (EXW, FCA, CPT, CIP, DAP, DPU, DDP, FAS, FOB, CFR, CIF) that allocate tasks, costs and risks in delivery of goods between seller and buyer in B2B sale contracts." }, { "id": "SRC-010", "title": "Peppol BIS Billing 3.0 - cac:OrderReference", "organization": "OpenPeppol AISBL", "url": "https://docs.peppol.eu/poacc/billing/3.0/syntax/ubl-invoice/cac-OrderReference/", "version_or_date": "Peppol BIS Billing 3.0, May 2026 release", "source_type": "first-party-doc", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-25T09:00:00Z", "relevance": "Downstream reference integrity: BT-13 purchase order reference issued by the buyer (cbc:ID, 1..1 within OrderReference) and BT-14 sales order reference issued by the seller (cbc:SalesOrderID, 0..1), with the 'NA' filler convention where only a sales order reference exists." }, { "id": "SRC-011", "title": "Blanket order", "organization": "Wikimedia Foundation", "url": "https://en.wikipedia.org/wiki/Blanket_order", "version_or_date": "Accessed 25 August 2026", "source_type": "secondary", "primary_source": false, "authority_tier": 4, "accessed_at": "2026-08-25T09:00:00Z", "relevance": "Used only to surface competing industry terminology - blanket order, standing order, call-off order, release order - which no consulted primary source normalises into a single controlled vocabulary; cited to mark a gap, not to assert canonical structure." }, { "id": "SRC-012", "title": "UBL 2.4 os - UBL-Order-2.4 data model", "organization": "OASIS Open", "url": "https://docs.oasis-open.org/ubl/os-UBL-2.4/mod/summary/reports/UBL-Order-2.4.html", "version_or_date": "UBL 2.4 os, rendering 20240625-1548z", "source_type": "schema", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T16:10:00Z", "relevance": "Atomic Order ABIEs and BBIEs: buyer-assigned ID and Purchase Order Number, UUID, issue date and time, type code, parties, quotation and contract references, delivery terms, payment means and terms, tax total, anticipated monetary total and mandatory OrderLine." }, { "id": "SRC-013", "title": "Peppol Order transaction 3.7 (T01) syntax binding to UBL Order", "organization": "OpenPeppol AISBL Post-Award Community", "url": "https://docs.peppol.eu/poacc/upgrade-3/syntax/Order/", "version_or_date": "Peppol Order transaction 3.7 (T01), November 2025 Release", "source_type": "schema", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T16:25:00Z", "relevance": "Mandatory and optional order elements used in operational Peppol exchange, including CustomizationID, ProfileID, order identifier, issue date and time, currency, buyer, seller and order lines, plus fatal business rules." }, { "id": "SRC-014", "title": "UN/EDIFACT Message ORDERS — Purchase order message, Release 99B", "organization": "United Nations Economic Commission for Europe (UN/CEFACT)", "url": "https://service.unece.org/trade/untdid/d99b/trmd/orders_c.htm", "version_or_date": "D.99B, 1999-09-11, Revision 11", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T16:30:00Z", "relevance": "Functional definition of the Purchase order message as details of goods or services ordered under conditions agreed between seller and buyer; header, detail and summary structure; message type ORDERS." }, { "id": "SRC-015", "title": "UNCITRAL Digest of Case Law on the United Nations Convention on Contracts for the International Sale of Goods", "organization": "United Nations Commission on International Trade Law", "url": "https://uncitral.un.org/sites/uncitral.un.org/files/media-documents/uncitral/en/cisg_digest_2016.pdf", "version_or_date": "2016 edition", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T17:00:00Z", "relevance": "CISG Part II formation: a purchase order may be an offer if sufficiently definite as to goods, quantity and price (art. 14); acceptance by statement or conduct (art. 18); silence is not in itself acceptance; contract is concluded when acceptance becomes effective (art. 23)." }, { "id": "SRC-016", "title": "UNCITRAL Model Law on Electronic Commerce with Guide to Enactment 1996, with additional article 5 bis as adopted in 1998", "organization": "United Nations Commission on International Trade Law", "url": "https://uncitral.un.org/sites/uncitral.un.org/files/media-documents/uncitral/en/19-04970_ebook.pdf", "version_or_date": "1996 Model Law; article 5 bis 1998; UN publication 19-04970", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T16:50:00Z", "relevance": "Legal recognition of EDI data messages, writing and signature functional equivalents, retention of data messages (art. 10), formation and validity of contracts by data message (art. 11), acknowledgement of receipt (art. 14), and time and place of dispatch and receipt (art. 15)." } ], "structure": { "bundles": [ { "id": "order-identity-and-classification", "name": "Order identity and classification", "description": "What this order is, how it is uniquely referenced, how its revisions are distinguished, and what kind of purchasing instrument it is.", "rationale": "Every downstream document, response and match depends on resolving a reference to exactly one order and one revision; Peppol requires the order identifier on every response and FAR requires each modification to identify the order it changes.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003", "SRC-010" ], "layers": [ { "id": "order-identity-and-versioning", "name": "Order identity and versioning", "description": "Identifiers that name the order and its successive revisions across buyer and seller systems.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003", "SRC-010" ], "findings": [ { "id": "order-identifier-and-scheme", "name": "Order identifier and issuing scheme", "description": "The buyer-assigned order number is the operative identity; UBL additionally allows a UUID, and the seller may hold a separate sales order identifier that must be correlated back.", "source_refs": [ "SRC-001", "SRC-002", "SRC-010" ], "questions": [ { "id": "q-who-assigns-order-number", "text": "Which system of record assigns the authoritative order number, and in what domain is that number unique?", "kind": "identity", "answer_data": [ "issuing system of record", "identifier scheme or namespace", "uniqueness domain (buyer-internal, buyer-supplier pair, global)", "format and check-character rules" ] }, { "id": "q-uuid-versus-order-number", "text": "Is a globally unique document identifier carried alongside the human-visible order number, and which governs when the two disagree?", "kind": "identity", "answer_data": [ "UUID/ULID/IRI value", "precedence rule", "population policy (always, on exchange only)" ] }, { "id": "q-sales-order-correlation", "text": "How is the seller's own sales order identifier captured and correlated to the buyer's order number?", "kind": "relationship", "answer_data": [ "sales order identifier", "source of the value (order response, acknowledgement)", "correlation timestamp" ] }, { "id": "q-reference-form-downstream", "text": "In what exact form must a despatch advice or invoice quote this order so the reference resolves without ambiguity?", "kind": "interoperability", "answer_data": [ "reference field mapping (e.g. BT-13, BT-14)", "whether revision must be quoted", "filler convention when absent" ] } ], "data_elements": [ { "id": "de-order-id", "name": "Order identifier", "description": "Buyer-assigned purchase order number that identifies the order to both parties.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-002" ] }, { "id": "de-order-id-scheme", "name": "Order identifier scheme", "description": "Scheme or namespace qualifying the order identifier so it can be resolved outside the issuing system.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "de-order-uuid", "name": "Order document UUID", "description": "Globally unique document instance identifier, distinct from the business order number.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "de-sales-order-id", "name": "Sales order identifier", "description": "Seller-assigned identifier for the same commercial transaction.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-010" ] } ], "artifacts": [ { "id": "purchase-order-instrument", "name": "Purchase order instrument", "description": "The issued order itself as an addressable business record, in whatever syntax it is projected.", "media_or_form": [ "structured business document instance", "human-readable rendition", "printed or signed order form" ], "serial": false, "identity_strategy": "Buyer-assigned order identifier qualified by its issuing scheme; document UUID retained as a secondary handle where the syntax carries one.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003" ] } ], "inline_only_rationale": null }, { "id": "order-revision-and-versioning", "name": "Order revision and document versioning", "description": "How successive states of the same order are distinguished, which revision is in force, and how superseded revisions remain retrievable as evidence.", "source_refs": [ "SRC-001", "SRC-003", "SRC-004" ], "questions": [ { "id": "q-revision-numbering", "text": "How is a revision of the order numbered, and is that number part of the order's identity or an attribute of it?", "kind": "identity", "answer_data": [ "revision or modification number", "numbering series rule", "whether references must cite the revision" ] }, { "id": "q-current-revision-determination", "text": "Which single revision is currently in force at any given instant, and how is that determined?", "kind": "state", "answer_data": [ "in-force revision pointer", "effective-from and effective-to instants", "supersession chain" ] }, { "id": "q-superseded-retrieval", "text": "Are superseded revisions retained in full or reconstructed from a change log, and for how long?", "kind": "retention", "answer_data": [ "retention mode (full snapshot vs derived)", "retention period", "retrieval interface" ] }, { "id": "q-revision-integrity", "text": "What evidence proves that a stored revision has not been altered since it was issued?", "kind": "evidence", "answer_data": [ "content digest or seal", "sealing time", "verification procedure" ] } ], "data_elements": [ { "id": "de-revision-number", "name": "Revision or modification number", "description": "Sequence number distinguishing this issued state of the order from prior states.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "de-supersedes-ref", "name": "Superseded revision reference", "description": "Pointer to the revision this one replaces.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001", "SRC-003" ] }, { "id": "de-revision-effective-from", "name": "Revision effective-from instant", "description": "Instant from which this revision is the operative statement of the order.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006" ] } ], "artifacts": [ { "id": "order-revision-series", "name": "Order revision series", "description": "The ordered set of issued revisions of one order, each independently retrievable as evidence of what was committed at a point in time.", "media_or_form": [ "structured document instances", "immutable snapshot store entries" ], "serial": true, "identity_strategy": "Order identifier plus zero-padded revision number in a monotonically increasing series; no date component in the name.", "source_refs": [ "SRC-003", "SRC-004" ] } ], "inline_only_rationale": null } ] }, { "id": "order-classification", "name": "Order classification", "description": "The kind of purchasing instrument the order is and the pattern of commitment it expresses.", "source_refs": [ "SRC-001", "SRC-003", "SRC-011" ], "findings": [ { "id": "order-type-and-purchasing-pattern", "name": "Order type and purchasing pattern", "description": "UBL carries an OrderTypeCode; FAR distinguishes a purchase order from a blanket purchase agreement and the calls placed against it, so the model must record both the coded type and the commitment pattern it implies.", "source_refs": [ "SRC-001", "SRC-003", "SRC-011" ], "questions": [ { "id": "q-order-type-code", "text": "Which controlled code expresses the order type, and from which code list is that value drawn?", "kind": "classification", "answer_data": [ "order type code value", "code list identifier and version", "fallback when the list has no matching value" ] }, { "id": "q-commitment-pattern", "text": "Does this order create a firm quantity commitment, a ceiling under which releases are drawn, or a release against an existing ceiling?", "kind": "definition", "answer_data": [ "commitment pattern", "committed quantity or value", "remaining ceiling if a drawdown" ] }, { "id": "q-callout-parent-link", "text": "If the order is a call-off or release, which framework instrument does it draw against and how is the drawdown recorded?", "kind": "composition", "answer_data": [ "framework agreement identifier", "call or release number", "drawn amount and residual balance" ] }, { "id": "q-type-drives-lifecycle", "text": "Does the order type change which lifecycle states, approvals or response rules apply?", "kind": "decision", "answer_data": [ "type-specific state set", "type-specific approval threshold", "type-specific response requirement" ] } ], "data_elements": [ { "id": "de-order-type-code", "name": "Order type code", "description": "Coded classification of the order document type.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "de-commitment-pattern", "name": "Commitment pattern", "description": "Whether the order is standalone firm, a framework ceiling, or a release against a ceiling.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003", "SRC-011" ] }, { "id": "de-framework-drawdown-ref", "name": "Framework drawdown reference", "description": "Reference to the framework instrument and the call sequence this order consumes.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] } ], "artifacts": [], "inline_only_rationale": "Classification is a coded attribute of the order header rather than a separately produced artefact; the values live inline on the purchase-order-instrument and in the referenced framework record, and creating a separate classification artefact would duplicate the code list governed elsewhere." }, { "id": "replenishment-and-call-off-patterns", "name": "Blanket, call-off, consignment and VMI patterns", "description": "Peppol documents blanket, call-off and consignment (type 227) orders, including vendor-managed inventory where withdrawal of stock auto-issues a consignment order. UBL describes VMI, cyclic replenishment and replenishment on customer demand as related processes that may use Order plus catalogue, despatch and inventory documents. These patterns are in the wide-union surface but are not default for every adoption.", "source_refs": [ "SRC-002", "SRC-001" ], "questions": [ { "id": "replenishment-and-call-off-patterns-q01", "text": "Is this a standalone order, a blanket, a call-off against a blanket or contract, a consignment or VMI withdrawal, or a rush or standing order?", "kind": "classification", "answer_data": [ "pattern_code", "blanket_order_ref", "call_off_ref", "consignment_flag" ] }, { "id": "replenishment-and-call-off-patterns-q02", "text": "If this is a call-off, which blanket quantities, dates and locations does it split, and what remaining blanket balance is left?", "kind": "process", "answer_data": [ "blanket_id", "called_off_quantity", "remaining_blanket_quantity", "call_off_dates" ] }, { "id": "replenishment-and-call-off-patterns-q03", "text": "If this is a VMI or consignment order, was it issued automatically on withdrawal, and does the seller still send an order response acknowledgement without treating it as a new offer negotiation?", "kind": "exception", "answer_data": [ "vmi_indicator", "auto_issued", "acknowledgement_only" ] } ], "data_elements": [ { "id": "replenishment-and-call-off-patterns-data01", "name": "Order pattern code", "description": "Classification of standalone, blanket, call-off, consignment, VMI or related pattern.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "replenishment-and-call-off-patterns-data02", "name": "Prior order or blanket reference", "description": "Reference to another order, used for call-off or replacement.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012" ] } ], "artifacts": [], "inline_only_rationale": "Blanket, call-off and VMI are classification and process patterns over the same order document type. They do not introduce a separate serial artefact beyond the issued order and its response." } ] } ] }, { "id": "parties-authority-and-legal-effect", "name": "Parties, authority and legal effect", "description": "Who the order binds, how those parties are identified, who inside the buyer had authority to commit, and what legal effect issuance and acceptance produce.", "rationale": "FAR treats a purchase order as an offer that binds only on acceptance and CISG makes formation turn on offer and acceptance, so party identity and commitment authority are load-bearing, not descriptive.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003", "SRC-005", "SRC-008" ], "layers": [ { "id": "party-roles-and-identification", "name": "Party roles and identification", "description": "The roles an order distinguishes and the schemes under which each participant is identified.", "source_refs": [ "SRC-001", "SRC-002", "SRC-008" ], "findings": [ { "id": "party-roles-on-the-order", "name": "Buyer, seller and ancillary party roles", "description": "UBL distinguishes BuyerCustomerParty, SellerSupplierParty, OriginatorCustomerParty and FreightForwarderParty, and GS1 application identifiers separate ship-to, bill-to and purchased-from, so role must be modelled separately from party.", "source_refs": [ "SRC-001", "SRC-008" ], "questions": [ { "id": "q-role-set", "text": "Which party roles does this order distinguish, and which of them are mandatory for it to be actionable?", "kind": "composition", "answer_data": [ "role list", "cardinality per role", "mandatory role set" ] }, { "id": "q-role-party-separation", "text": "Can one legal entity occupy several roles on the same order, and how is that represented without collapsing the roles?", "kind": "relationship", "answer_data": [ "party-to-role mapping", "multi-role representation rule" ] }, { "id": "q-originator-versus-buyer", "text": "Where the ordering party differs from the originating requester, which party carries the payment and which carries the requirement?", "kind": "ownership", "answer_data": [ "originator party", "buyer party", "accounting cost centre or code" ] } ], "data_elements": [ { "id": "de-party-role-code", "name": "Party role code", "description": "Coded role a party plays on the order (buyer, seller, originator, ship-to, bill-to, forwarder).", "value_kind": "code", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-001", "SRC-008" ] }, { "id": "de-party-ref", "name": "Party reference", "description": "Reference to the party occupying a role, resolved in the party master model.", "value_kind": "reference", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-001" ] }, { "id": "de-accounting-cost-code", "name": "Accounting cost code", "description": "Buyer-side cost allocation reference carried on the order header or line.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001" ] } ], "artifacts": [], "inline_only_rationale": "Party roles are inline associations on the order that resolve into an external party master model; materialising a separate party artefact here would duplicate data the party model owns and would create a second, competing source of party truth." }, { "id": "party-identifier-schemes", "name": "Party identifier schemes and electronic address", "description": "Party identifiers on an order are only resolvable when qualified by a scheme: GLN under ISO 6523 ICD 0088, other ICD-qualified registration identifiers, and Peppol electronic-address EAS codes for routing.", "source_refs": [ "SRC-002", "SRC-008" ], "questions": [ { "id": "q-party-scheme-qualifier", "text": "Under which registered scheme is each party identifier issued, and is the scheme code carried with the value?", "kind": "identity", "answer_data": [ "identifier value", "scheme or ICD code", "issuing registry" ] }, { "id": "q-identifier-reuse-policy", "text": "Does the issuing registry permit reuse of a retired party identifier, and how does that affect historic orders?", "kind": "constraint", "answer_data": [ "reuse policy", "retirement date if any", "historic resolution rule" ] }, { "id": "q-electronic-address-routing", "text": "Which electronic address routes the order to the seller, and is it distinct from the party's legal identifier?", "kind": "interoperability", "answer_data": [ "electronic address value", "address scheme code", "relationship to legal identifier" ] }, { "id": "q-tax-registration-on-order", "text": "Which tax or legal registration identifiers must appear on the order for the transaction to be lawful in the applicable jurisdictions?", "kind": "requirement", "answer_data": [ "registration identifier type", "jurisdiction", "mandatory or optional status" ] } ], "data_elements": [ { "id": "de-party-identifier", "name": "Party identifier", "description": "Scheme-qualified identifier for a party occupying an order role.", "value_kind": "identifier", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-002", "SRC-008" ] }, { "id": "de-party-scheme-code", "name": "Party identifier scheme code", "description": "ICD or equivalent code declaring which registry issued the party identifier.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002", "SRC-008" ] }, { "id": "de-electronic-address", "name": "Electronic address", "description": "Routing address for delivering the order to the receiving party, with its own scheme code.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] } ], "artifacts": [], "inline_only_rationale": "Scheme-qualified identifiers are reference data cited inline on the order; the authoritative artefacts are the external registries (GS1 GLN registry, ICD list, EAS list) which this model aligns to but does not reproduce or own." } ] }, { "id": "commitment-authority-and-formation", "name": "Commitment authority and contract formation", "description": "Who was entitled to bind the buyer, and what legal state the order creates before and after acceptance.", "source_refs": [ "SRC-003", "SRC-005" ], "findings": [ { "id": "commitment-authority-and-approval", "name": "Commitment authority and approval", "description": "An order commits funds only if issued by someone holding the authority to commit; FAR vests this in the contracting officer, and commercial buyers use delegated approval thresholds.", "source_refs": [ "SRC-003" ], "questions": [ { "id": "q-who-may-commit", "text": "Which named role holds authority to commit the buyer for this order's value and category?", "kind": "authority", "answer_data": [ "authorising role", "delegation instrument reference", "value and category limits" ] }, { "id": "q-approval-evidence", "text": "What record proves the approval was granted before issuance rather than reconstructed afterwards?", "kind": "evidence", "answer_data": [ "approver identity", "approval instant", "approval decision and any conditions" ] }, { "id": "q-authority-breach-handling", "text": "What happens to an order issued without adequate authority, and can it be ratified?", "kind": "exception", "answer_data": [ "exception classification", "ratification procedure", "ratifying authority" ] } ], "data_elements": [ { "id": "de-approver-identity", "name": "Approver identity", "description": "Identity of the person or role that authorised issuance of the order.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "de-approval-instant", "name": "Approval instant", "description": "Instant at which commitment approval was recorded.", "value_kind": "timestamp", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003", "SRC-006" ] }, { "id": "de-authority-limit", "name": "Authority limit", "description": "Monetary or categorical ceiling of the delegated authority relied on.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] } ], "artifacts": [ { "id": "order-approval-record", "name": "Order approval record", "description": "Record of the internal authorisation that permitted the order to be issued, held separately from the order sent to the seller.", "media_or_form": [ "approval log entry", "signed authorisation record", "workflow decision record" ], "serial": false, "identity_strategy": "Order identifier plus revision plus approval step reference; the approver identity resolves to the buyer's identity master system.", "source_refs": [ "SRC-003" ] } ], "inline_only_rationale": null }, { "id": "contract-formation-and-legal-effect", "name": "Contract formation and legal effect", "description": "The order is an offer until accepted; FAR permits acceptance by performance and allows withdrawal before acceptance, while CISG governs formation for cross-border sales of goods between contracting states.", "source_refs": [ "SRC-003", "SRC-005" ], "questions": [ { "id": "q-offer-or-acceptance", "text": "Does issuing this order constitute an offer, or an acceptance of a prior seller offer?", "kind": "definition", "answer_data": [ "formation posture", "prior offer reference if any", "governing rule relied on" ] }, { "id": "q-acceptance-mode", "text": "By which modes may the seller accept - express response, signature, or commencement of performance - and which mode was actually used?", "kind": "event", "answer_data": [ "permitted acceptance modes", "mode actually used", "acceptance instant and evidence" ] }, { "id": "q-withdrawal-before-acceptance", "text": "Until what moment may the buyer withdraw the order without liability, and how is withdrawal evidenced?", "kind": "lifecycle", "answer_data": [ "withdrawal window rule", "withdrawal notice reference", "liability position" ] }, { "id": "q-governing-law-and-terms-conflict", "text": "Which law governs the order, and how are conflicting buyer and seller standard terms resolved?", "kind": "constraint", "answer_data": [ "governing law and forum", "terms precedence clause", "conflict resolution outcome" ] } ], "data_elements": [ { "id": "de-formation-posture", "name": "Formation posture", "description": "Whether the order is an offer, an acceptance, or a release under a pre-formed contract.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003", "SRC-005" ] }, { "id": "de-governing-law", "name": "Governing law", "description": "Law stated as governing the resulting contract.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "de-acceptance-instant", "name": "Acceptance instant", "description": "Instant at which the seller's acceptance took effect.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003", "SRC-006" ] } ], "artifacts": [], "inline_only_rationale": "Legal effect is a derived interpretation over the order, the response and the governing terms rather than a separate produced object; the evidencing artefacts already exist as the order instrument, the order response record and the referenced terms attachment." } ] } ] }, { "id": "order-content-and-commercial-terms", "name": "Order content and commercial terms", "description": "What is being ordered, in what quantity, at what price, and on what payment and contractual terms.", "rationale": "UBL structures the order as header plus OrderLine/LineItem with pricing, allowances, tax and anticipated totals, and Peppol requires each line to carry an item identifier or item name; this is the substantive content that fulfilment and settlement are matched against.", "source_refs": [ "SRC-001", "SRC-002", "SRC-007" ], "layers": [ { "id": "line-item-structure", "name": "Line item structure", "description": "How the order decomposes into lines, and what each line identifies and quantifies.", "source_refs": [ "SRC-001", "SRC-002", "SRC-007" ], "findings": [ { "id": "order-line-identity-and-quantity", "name": "Order line identity, composition and ordered quantity", "description": "Lines carry a line identifier that responses must match, plus ordered quantity and unit of measure; Peppol requires all lines to be returned when an order is accepted with amendments.", "source_refs": [ "SRC-001", "SRC-002" ], "questions": [ { "id": "q-line-id-stability", "text": "Is the line identifier stable across revisions and responses, or reassigned when lines are added or removed?", "kind": "identity", "answer_data": [ "line identifier", "stability rule", "renumbering policy on amendment" ] }, { "id": "q-line-decomposition", "text": "May a line carry sub-lines or component items, and does a sub-line inherit the parent's terms?", "kind": "composition", "answer_data": [ "sub-line support", "inheritance rule", "aggregation rule for quantity and amount" ] }, { "id": "q-quantity-and-uom", "text": "In which unit of measure is the ordered quantity expressed, and from which code list is that unit drawn?", "kind": "measurement", "answer_data": [ "ordered quantity", "unit of measure code", "code list identifier" ] }, { "id": "q-packaging-basis", "text": "Is the quantity expressed in consumer units, trade units or packs, and how is the conversion recorded?", "kind": "measurement", "answer_data": [ "quantity basis", "pack size and hierarchy", "conversion factor" ] } ], "data_elements": [ { "id": "de-line-id", "name": "Order line identifier", "description": "Identifier of a line within the order, used for line-level response matching.", "value_kind": "identifier", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-001", "SRC-002" ] }, { "id": "de-ordered-quantity", "name": "Ordered quantity", "description": "Quantity requested on the line, with its unit of measure.", "value_kind": "quantity", "cardinality": "1", "required": true, "source_refs": [ "SRC-001" ] }, { "id": "de-quantity-uom-code", "name": "Unit of measure code", "description": "Coded unit in which the ordered quantity is expressed.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-007" ] } ], "artifacts": [ { "id": "order-line-register", "name": "Order line register", "description": "The enumerated set of lines belonging to one order revision, addressable for line-level response, amendment and matching.", "media_or_form": [ "line collection within the order document", "tabular line schedule" ], "serial": false, "identity_strategy": "Order identifier plus revision plus line identifier; lines have no identity independent of the order aggregate.", "source_refs": [ "SRC-001", "SRC-002" ] } ], "inline_only_rationale": null }, { "id": "item-identification-and-classification", "name": "Item identification and classification", "description": "Peppol requires an item identifier and/or item name per line; identifiers may be seller-assigned, buyer-assigned or standard trade item numbers, with optional classification codes.", "source_refs": [ "SRC-002", "SRC-008", "SRC-001" ], "questions": [ { "id": "q-item-identifier-precedence", "text": "Which item identifier governs when seller, buyer and standard trade item identifiers are all present and disagree?", "kind": "identity", "answer_data": [ "identifier values by type", "precedence rule", "reconciliation procedure" ] }, { "id": "q-item-name-sufficiency", "text": "When no coded item identifier exists, what description is sufficient for the line to be unambiguously fulfillable?", "kind": "requirement", "answer_data": [ "item name", "descriptive attributes", "specification reference" ] }, { "id": "q-item-classification-scheme", "text": "Under which classification scheme and version is the item categorised for reporting or regulatory purposes?", "kind": "classification", "answer_data": [ "classification code", "scheme name and version", "purpose of classification" ] }, { "id": "q-item-spec-attachment", "text": "Where the item is bespoke, which specification document forms part of the order and how is its version pinned?", "kind": "provenance", "answer_data": [ "specification reference", "version or revision", "attachment digest" ] } ], "data_elements": [ { "id": "de-item-identifier", "name": "Item identifier", "description": "Scheme-qualified identifier of the ordered item (seller, buyer or standard trade item number).", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002", "SRC-008" ] }, { "id": "de-item-name", "name": "Item name", "description": "Human-readable name of the ordered item or service.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "de-item-classification-code", "name": "Item classification code", "description": "Coded category of the item under a declared classification scheme.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] } ], "artifacts": [ { "id": "item-specification-attachment", "name": "Item specification attachment", "description": "Drawing, statement of work or technical specification incorporated into the order by reference for bespoke or engineered items.", "media_or_form": [ "attached specification document", "drawing or model file", "referenced external specification" ], "serial": false, "identity_strategy": "Specification identifier and version issued by its owning system, pinned by content digest at the moment of order issuance.", "source_refs": [ "SRC-001", "SRC-002" ] } ], "inline_only_rationale": null } ] }, { "id": "pricing-and-monetary-terms", "name": "Pricing and monetary terms", "description": "Price basis, adjustments, currency and the anticipated totals stated on the order.", "source_refs": [ "SRC-001", "SRC-005" ], "findings": [ { "id": "price-basis-amounts-and-totals", "name": "Price basis, allowances, currency and anticipated totals", "description": "UBL carries price with a base quantity, allowances and charges, tax totals and an AnticipatedMonetaryTotal; these are the buyer's expectation, not a settled amount, and CISG contemplates contracts where the price is not fixed at formation.", "source_refs": [ "SRC-001", "SRC-005" ], "questions": [ { "id": "q-price-base-quantity", "text": "Is the unit price stated against a base quantity other than one, and how is the line amount derived from it?", "kind": "measurement", "answer_data": [ "unit price", "price base quantity", "derivation formula for line amount" ] }, { "id": "q-price-firm-or-provisional", "text": "Is the price firm, indicative, or to be determined at delivery, and what rule fixes it if not firm?", "kind": "constraint", "answer_data": [ "price status", "price determination rule", "reference index or catalogue" ] }, { "id": "q-currency-and-conversion", "text": "In which currency is the order denominated, and is a second currency or conversion rate recorded?", "kind": "interoperability", "answer_data": [ "document currency code", "tax or payment currency if different", "conversion rate and its source" ] }, { "id": "q-totals-authority", "text": "Do the anticipated totals bind the seller, or is the line detail authoritative when totals and lines disagree?", "kind": "validation", "answer_data": [ "precedence rule", "rounding rule and scale", "tolerance for arithmetic difference" ] } ], "data_elements": [ { "id": "de-unit-price", "name": "Unit price", "description": "Price per base quantity for an ordered line.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "de-document-currency-code", "name": "Document currency code", "description": "Currency in which order amounts are expressed.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "de-allowance-charge", "name": "Allowance or charge", "description": "Deduction or addition applied at line or document level, with reason code and amount.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "de-anticipated-total", "name": "Anticipated monetary total", "description": "Expected payable total stated on the order before settlement.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001" ] } ], "artifacts": [], "inline_only_rationale": "Pricing values are inline attributes of the order header and lines. The order deliberately carries anticipated rather than settled amounts, so the authoritative monetary artefact is the invoice held by the settlement model; creating a pricing artefact here would assert settlement authority the order does not have." } ] }, { "id": "payment-and-contractual-terms", "name": "Payment and contractual terms", "description": "Payment expectations stated on the order and the external terms the order incorporates.", "source_refs": [ "SRC-001", "SRC-003", "SRC-009" ], "findings": [ { "id": "payment-terms-and-means", "name": "Payment terms and payment means", "description": "UBL carries PaymentTerms and PaymentMeans on the order, expressing the payment expectation set at commitment time rather than the payment itself.", "source_refs": [ "SRC-001" ], "questions": [ { "id": "q-payment-trigger-event", "text": "Which event starts the payment period - invoice date, delivery, or acceptance of goods?", "kind": "temporal", "answer_data": [ "trigger event type", "period length", "calendar or business-day basis" ] }, { "id": "q-payment-means-constraint", "text": "Does the order constrain the payment means or instrument the seller may use to collect?", "kind": "constraint", "answer_data": [ "payment means code", "account or instrument reference", "whether binding or indicative" ] }, { "id": "q-settlement-discount", "text": "Are early-settlement discounts or late-payment penalties stated, and on what base are they computed?", "kind": "requirement", "answer_data": [ "discount or penalty terms", "computation base", "applicability window" ] } ], "data_elements": [ { "id": "de-payment-terms", "name": "Payment terms", "description": "Stated conditions and period for payment of amounts arising from the order.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "de-payment-means-code", "name": "Payment means code", "description": "Coded instrument by which payment is expected to be made.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] } ], "artifacts": [], "inline_only_rationale": "Payment terms on an order are a stated expectation, not an executed instruction; the executable artefacts (payment instruction, remittance advice) belong to the settlement model, so representing one here would create a duplicate and potentially conflicting payment record." }, { "id": "framework-agreement-and-clause-references", "name": "Framework agreement and clause references", "description": "UBL Order carries a Contract reference, and FAR distinguishes a blanket purchase agreement from the calls placed against it; the order incorporates terms by reference rather than restating them.", "source_refs": [ "SRC-001", "SRC-003" ], "questions": [ { "id": "q-incorporated-terms", "text": "Which external terms documents are incorporated into this order, and at which version?", "kind": "provenance", "answer_data": [ "terms document reference", "version or edition", "incorporation clause text" ] }, { "id": "q-terms-precedence-order", "text": "What precedence applies between the order face, the incorporated terms and any framework agreement?", "kind": "constraint", "answer_data": [ "precedence sequence", "conflict examples", "resolution authority" ] }, { "id": "q-framework-consumption", "text": "How much of the framework's ceiling does this order consume, and who maintains the running balance?", "kind": "relationship", "answer_data": [ "consumed value or quantity", "residual balance", "balance-keeping system" ] } ], "data_elements": [ { "id": "de-contract-reference", "name": "Contract reference", "description": "Reference to the governing contract or framework agreement.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-003" ] }, { "id": "de-terms-version", "name": "Incorporated terms version", "description": "Edition or version of the terms document incorporated by reference.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] } ], "artifacts": [ { "id": "terms-incorporation-attachment", "name": "Terms incorporation attachment", "description": "The standard terms and conditions text or clause set attached to or referenced by the order at issuance.", "media_or_form": [ "attached terms document", "referenced clause library entry", "printed terms on an order form" ], "serial": false, "identity_strategy": "Terms document identifier and edition assigned by its owning legal system, pinned by digest at issuance so the incorporated version stays provable.", "source_refs": [ "SRC-001", "SRC-003" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "fulfilment-instruction-and-delivery", "name": "Fulfilment instruction and delivery", "description": "Where and when the buyer requires delivery, on what trade terms, and how the order links to the obligations it creates.", "rationale": "UBL carries Delivery and DeliveryTerms on both header and line, Incoterms allocate delivery and risk, and the registry records that this order contains fulfilment obligations (WM-ECO-024).", "source_refs": [ "SRC-001", "SRC-002", "SRC-009" ], "layers": [ { "id": "delivery-instructions-and-terms", "name": "Delivery instructions and terms", "description": "Destination, requested timing and the trade terms that allocate cost and risk.", "source_refs": [ "SRC-001", "SRC-008", "SRC-009" ], "findings": [ { "id": "delivery-destination-and-schedule", "name": "Delivery destination and requested schedule", "description": "The order states where delivery is required and when, at header or line level; GLN identifies ship-to locations and delivery windows are commonly expressed as periods rather than instants.", "source_refs": [ "SRC-001", "SRC-008" ], "questions": [ { "id": "q-destination-identification", "text": "How is each delivery destination identified, and does the identifier denote a legal entity, a function or a physical place?", "kind": "spatial", "answer_data": [ "location identifier and scheme", "location semantic type", "address and geocode if present" ] }, { "id": "q-schedule-granularity", "text": "Is the requested delivery expressed as a single date, a window, or a schedule of dated instalments per line?", "kind": "temporal", "answer_data": [ "requested delivery date or period", "instalment schedule", "time zone basis for the window" ] }, { "id": "q-header-versus-line-delivery", "text": "When header and line delivery instructions differ, which one governs for that line?", "kind": "constraint", "answer_data": [ "precedence rule", "override scope", "validation check" ] }, { "id": "q-schedule-change-authority", "text": "Who may change a requested delivery date without a formal order amendment, and within what limits?", "kind": "authority", "answer_data": [ "authorised role", "permitted shift range", "recording mechanism" ] } ], "data_elements": [ { "id": "de-delivery-location-id", "name": "Delivery location identifier", "description": "Scheme-qualified identifier of the requested delivery destination.", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-008" ] }, { "id": "de-requested-delivery-period", "name": "Requested delivery period", "description": "Date or period within which delivery is requested, at header or line level.", "value_kind": "date", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "de-delivery-address", "name": "Delivery address", "description": "Structured postal or physical address for the destination where an identifier alone is insufficient.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] } ], "artifacts": [ { "id": "delivery-schedule-annex", "name": "Delivery schedule annex", "description": "Instalment or call-off schedule attached to the order where delivery is staged over time rather than made once.", "media_or_form": [ "schedule table within the order", "attached delivery plan", "referenced release schedule" ], "serial": false, "identity_strategy": "Order identifier plus revision plus line identifier plus schedule sequence number; the annex has no identity apart from the order it serves.", "source_refs": [ "SRC-001" ] } ], "inline_only_rationale": null }, { "id": "delivery-terms-and-risk-transfer", "name": "Delivery terms and risk transfer", "description": "Incoterms 2020 supply eleven trade terms that allocate tasks, costs and risk between seller and buyer; a term is only meaningful with the named place and the rules edition.", "source_refs": [ "SRC-009", "SRC-001" ], "questions": [ { "id": "q-incoterm-and-named-place", "text": "Which trade term applies, under which rules edition, and at exactly which named place?", "kind": "classification", "answer_data": [ "trade term code", "rules edition", "named place or port" ] }, { "id": "q-risk-transfer-point", "text": "At what point does risk in the goods pass from seller to buyer under the stated term?", "kind": "state", "answer_data": [ "risk transfer event", "location of transfer", "evidence of the transfer event" ] }, { "id": "q-cost-allocation-split", "text": "Which costs - carriage, insurance, export and import clearance, duties - fall to each party under the stated term?", "kind": "requirement", "answer_data": [ "cost category allocation", "insurance obligation and level", "clearance responsibility" ] }, { "id": "q-title-versus-risk", "text": "Is transfer of title addressed anywhere on the order, given that the trade term does not determine it?", "kind": "ownership", "answer_data": [ "title transfer clause reference", "title transfer trigger", "retention of title provision" ] } ], "data_elements": [ { "id": "de-trade-term-code", "name": "Trade term code", "description": "Coded delivery term governing task, cost and risk allocation.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009", "SRC-001" ] }, { "id": "de-trade-term-named-place", "name": "Trade term named place", "description": "Named place or port that completes the trade term.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "de-trade-term-edition", "name": "Trade term rules edition", "description": "Edition of the trade term rules relied on, since terms differ between editions.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009" ] } ], "artifacts": [], "inline_only_rationale": "Delivery terms are a coded reference to an externally published rules set that the ICC owns and licenses; the order carries only the code, edition and named place inline, and reproducing the rules text as an artefact would misstate authorship and licensing." } ] }, { "id": "fulfilment-linkage-and-tolerances", "name": "Fulfilment linkage and tolerances", "description": "How the order's obligations are discharged, what variance is tolerated, and how fulfilment events attach back to lines.", "source_refs": [ "SRC-001", "SRC-002", "SRC-005" ], "findings": [ { "id": "tolerance-substitution-and-obligation-linkage", "name": "Tolerance, substitution and fulfilment obligation linkage", "description": "Peppol line response codes allow a line to be changed for quantity, delivery period, replacement item or price, or reported as already delivered, so the order must state permitted variance and carry links to the obligations and fulfilment events it generates.", "source_refs": [ "SRC-001", "SRC-002", "SRC-005" ], "questions": [ { "id": "q-quantity-tolerance", "text": "What over- or under-delivery tolerance is permitted per line before the delivery is non-conforming?", "kind": "constraint", "answer_data": [ "tolerance percentage or absolute band", "basis (per delivery, per line total)", "consequence of breach" ] }, { "id": "q-substitution-permission", "text": "May the seller substitute an equivalent item, and who decides equivalence?", "kind": "decision", "answer_data": [ "substitution permission flag", "equivalence criteria", "approving role" ] }, { "id": "q-partial-fulfilment-rule", "text": "Are partial deliveries permitted, and does a partial delivery close the line or leave a residual obligation?", "kind": "lifecycle", "answer_data": [ "partial delivery permission", "residual obligation rule", "line closure condition" ] }, { "id": "q-obligation-linkage", "text": "How does each fulfilment event attach back to the specific order line and schedule instalment it discharges?", "kind": "relationship", "answer_data": [ "fulfilment event reference", "line and instalment reference", "discharged quantity" ] } ], "data_elements": [ { "id": "de-quantity-tolerance", "name": "Quantity tolerance", "description": "Permitted variance between ordered and delivered quantity for a line.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "de-partial-delivery-flag", "name": "Partial delivery permitted flag", "description": "Whether the buyer accepts delivery in parts against a line.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "de-fulfilment-obligation-ref", "name": "Fulfilment obligation reference", "description": "Link from an order line or instalment to the obligation record it creates in the fulfilment model.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "de-outstanding-quantity", "name": "Outstanding quantity", "description": "Ordered quantity not yet discharged by accepted fulfilment events.", "value_kind": "quantity", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-002" ] } ], "artifacts": [], "inline_only_rationale": "The obligations and the events that discharge them are owned by the contained fulfilment model (WM-ECO-024); this finding contributes only the linking references and tolerance rules, so producing a fulfilment artefact here would create a second, divergent record of delivery state." } ] } ] }, { "id": "lifecycle-and-change-control", "name": "Lifecycle and change control", "description": "The states an order passes through, how a seller response moves it, and how it is amended, cancelled or closed.", "rationale": "Peppol defines explicit header and line response codes and FAR defines distinct procedures for modification and for cancellation of accepted versus unaccepted orders; the state model is normatively grounded, not conventional.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003" ], "layers": [ { "id": "lifecycle-states-and-responses", "name": "Lifecycle states and responses", "description": "The order state model and the response semantics that drive transitions.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003" ], "findings": [ { "id": "order-state-model-and-transitions", "name": "Order state model and transitions", "description": "An order moves from drafted through approved, issued, acknowledged, accepted or rejected, in fulfilment, and closed or cancelled; FAR makes acceptance the transition that converts an offer into a binding contract.", "source_refs": [ "SRC-002", "SRC-003" ], "questions": [ { "id": "q-state-set-and-terminality", "text": "Which states does an order occupy, and which of them are terminal?", "kind": "state", "answer_data": [ "state list with definitions", "terminal state set", "re-entry rules if any" ] }, { "id": "q-transition-triggers", "text": "Which event triggers each transition, and is the trigger internal to the buyer or an inbound seller message?", "kind": "lifecycle", "answer_data": [ "transition table", "trigger event type and source", "idempotency rule for repeated triggers" ] }, { "id": "q-state-derivation", "text": "Is the order state stored explicitly or derived from the event history, and which is authoritative on conflict?", "kind": "process", "answer_data": [ "storage mode", "derivation rule", "conflict precedence" ] }, { "id": "q-stalled-order-handling", "text": "What happens when no seller response arrives within the expected window?", "kind": "exception", "answer_data": [ "response deadline", "escalation or auto-lapse rule", "resulting state" ] } ], "data_elements": [ { "id": "de-order-state", "name": "Order state", "description": "Current lifecycle state of the order.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-002", "SRC-003" ] }, { "id": "de-state-entered-at", "name": "State entered at", "description": "Instant at which the order entered its current state.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-006" ] }, { "id": "de-line-state", "name": "Order line state", "description": "Per-line state where lines progress independently of the header.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] } ], "artifacts": [], "inline_only_rationale": "The state model is a rule set applied to the order aggregate, and the state values are inline attributes; the evidencing artefacts are the order revision series and the transmission and audit log, so a separate state artefact would only mirror them." }, { "id": "order-response-and-acceptance-semantics", "name": "Order response and acceptance semantics", "description": "Peppol defines header codes AB (received, not processed), RE (rejected), AP (accepted without change) and CA (accepted with line amendments, all lines required), and line codes 1 added, 3 changed, 5 accepted, 7 rejected, 42 already delivered; one response refers to exactly one order.", "source_refs": [ "SRC-002", "SRC-001", "SRC-003" ], "questions": [ { "id": "q-response-code-mapping", "text": "Which response codes are recognised at header and line level, and how does each map to an internal order state?", "kind": "classification", "answer_data": [ "header code set", "line code set", "code-to-state mapping" ] }, { "id": "q-conditional-acceptance-effect", "text": "When a response accepts with amendments, does the amended content become binding automatically or require buyer confirmation?", "kind": "decision", "answer_data": [ "binding rule", "confirmation requirement and mechanism", "default if buyer is silent" ] }, { "id": "q-multiple-responses", "text": "Can several responses relate to one order over time, and which one expresses the current position?", "kind": "relationship", "answer_data": [ "response sequence", "supersession rule", "current-position pointer" ] }, { "id": "q-acceptance-by-performance", "text": "How is acceptance recognised when the seller simply performs instead of sending a response?", "kind": "event", "answer_data": [ "performance evidence type", "instant of first performance", "state derivation rule" ] } ], "data_elements": [ { "id": "de-response-header-code", "name": "Order response header code", "description": "Coded seller position on the order as a whole.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "de-response-line-code", "name": "Order response line code", "description": "Coded seller position on an individual order line.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "de-response-document-ref", "name": "Order response reference", "description": "Reference to the response document that carried the seller position.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-002" ] } ], "artifacts": [ { "id": "order-response-record", "name": "Order response record", "description": "The seller's recorded position on the order, retained as the evidence that establishes or refuses contract formation.", "media_or_form": [ "structured order response document", "acknowledgement message", "countersigned order copy" ], "serial": true, "identity_strategy": "Response document identifier assigned by the seller's system of record, bound to exactly one order identifier and revision; sequence number distinguishes successive responses.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003" ] } ], "inline_only_rationale": null }, { "id": "issue-time-and-validity-window", "name": "Issue time and validity window", "description": "UBL requires IssueDate assigned by the sender and permits IssueTime and ValidityPeriod. Peppol requires IssueDate and permits IssueTime. These are event times of issuance, not identifiers.", "source_refs": [ "SRC-012", "SRC-013" ], "questions": [ { "id": "issue-time-and-validity-window-q01", "text": "When did the buyer issue this order, as an event timestamp distinct from when a gateway or agent later observed or ingested it?", "kind": "temporal", "answer_data": [ "issue_event_time", "observation_or_ingestion_time" ] }, { "id": "issue-time-and-validity-window-q02", "text": "For what period is the order valid as an offer, and what happens if the seller responds after that window?", "kind": "lifecycle", "answer_data": [ "validity_start", "validity_end", "late_response_rule" ] }, { "id": "issue-time-and-validity-window-q03", "text": "How is the Peppol date-without-timezone issue date combined with optional issue time into an RFC 3339 event time with seconds and explicit offset for this Dimension?", "kind": "constraint", "answer_data": [ "normalized_issue_timestamp", "source_date", "source_time", "assumed_offset_rule" ] } ], "data_elements": [ { "id": "issue-time-and-validity-window-data01", "name": "Order issue date", "description": "Date assigned by the sender on which the document was issued; Peppol mandatory; UBL mandatory.", "value_kind": "date", "cardinality": "1", "required": true, "source_refs": [ "SRC-012", "SRC-013" ] }, { "id": "issue-time-and-validity-window-data02", "name": "Order issue time", "description": "Time assigned by the buyer on which the order was issued.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012", "SRC-013" ] }, { "id": "issue-time-and-validity-window-data03", "name": "Validity period", "description": "Period for which the order is valid as an offer.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012", "SRC-013" ] }, { "id": "issue-time-and-validity-window-data04", "name": "Observation or ingestion time", "description": "Time the Dimension observed or ingested the order, recorded separately from issue event time when they differ.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-016" ] } ], "artifacts": [ { "id": "issue-time-and-validity-window-artifact01", "name": "Order issuance event record", "description": "Audit record of issuance combining business event time with gateway observation or ingestion time.", "media_or_form": [ "event log", "message-level acknowledgement", "application response" ], "serial": true, "identity_strategy": "Key by buyer order identifier plus issuance event timestamp; do not use the date alone as identity.", "source_refs": [ "SRC-013", "SRC-016" ] } ], "inline_only_rationale": null } ] }, { "id": "amendment-cancellation-and-closure", "name": "Amendment, cancellation and closure", "description": "Controlled change to an issued order and the routes by which it ends.", "source_refs": [ "SRC-001", "SRC-003" ], "findings": [ { "id": "amendment-and-change-control", "name": "Amendment and change control", "description": "UBL provides an OrderChange document and FAR requires each modification to identify the order being changed and to carry an appropriate modification number, with contractor acceptance required only in defined cases.", "source_refs": [ "SRC-001", "SRC-003" ], "questions": [ { "id": "q-amendable-fields", "text": "Which fields may be amended after issuance, and which require a new order instead?", "kind": "constraint", "answer_data": [ "amendable field set", "re-issue trigger conditions", "justification requirement" ] }, { "id": "q-amendment-acceptance-needed", "text": "Does the amendment require the seller's written acceptance to take effect, or does it bind unilaterally?", "kind": "authority", "answer_data": [ "acceptance requirement rule", "legal basis", "evidence of acceptance" ] }, { "id": "q-amendment-numbering", "text": "How is each amendment numbered and linked to the order and revision it changes?", "kind": "identity", "answer_data": [ "modification number", "referenced order identifier and revision", "numbering series rule" ] }, { "id": "q-amendment-effect-on-fulfilment", "text": "What happens to fulfilment already in progress or already delivered when an amendment takes effect?", "kind": "process", "answer_data": [ "in-flight fulfilment treatment", "already-delivered line handling", "effective-from instant" ] } ], "data_elements": [ { "id": "de-modification-number", "name": "Modification number", "description": "Identifier of an amendment to an issued order.", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "de-amendment-reason-code", "name": "Amendment reason code", "description": "Coded reason for the change to the order.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "de-amendment-effective-from", "name": "Amendment effective-from instant", "description": "Instant from which the amended terms apply.", "value_kind": "timestamp", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003", "SRC-006" ] } ], "artifacts": [ { "id": "order-change-notice", "name": "Order change notice", "description": "The instrument that communicates an amendment to an issued order and identifies the order and revision it changes.", "media_or_form": [ "structured order change document", "numbered modification form", "countersigned amendment" ], "serial": true, "identity_strategy": "Order identifier plus modification number in a monotonically increasing series assigned by the issuing buyer system.", "source_refs": [ "SRC-001", "SRC-003" ] } ], "inline_only_rationale": null }, { "id": "cancellation-and-closure", "name": "Cancellation, termination and closure", "description": "FAR distinguishes cancelling an order the supplier has not accepted from terminating one already accepted, and UBL provides an OrderCancellation document; closure is a separate, non-adversarial end state.", "source_refs": [ "SRC-001", "SRC-003" ], "questions": [ { "id": "q-cancel-versus-terminate", "text": "Has the seller accepted the order, and does that make this a cancellation of an unaccepted offer or a termination of a contract?", "kind": "decision", "answer_data": [ "acceptance status at the moment of ending", "route selected", "procedural basis" ] }, { "id": "q-cancellation-cost-claim", "text": "Does the seller claim costs incurred before cancellation, and how is that claim recorded against the order?", "kind": "exception", "answer_data": [ "cost claim indicator", "claimed amount", "settlement route" ] }, { "id": "q-closure-criteria", "text": "What conditions must all lines satisfy before the order may be closed as complete?", "kind": "lifecycle", "answer_data": [ "per-line closure criteria", "residual quantity and value thresholds", "closing role" ] }, { "id": "q-reopening-a-closed-order", "text": "May a closed or cancelled order be reopened, and what evidence must the reopening record carry?", "kind": "exception", "answer_data": [ "reopening permission", "authorising role", "reopening reason and instant" ] } ], "data_elements": [ { "id": "de-cancellation-reason-code", "name": "Cancellation reason code", "description": "Coded reason for cancelling or terminating the order.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001", "SRC-003" ] }, { "id": "de-closure-instant", "name": "Closure instant", "description": "Instant at which the order reached a terminal state.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003", "SRC-006" ] }, { "id": "de-termination-route", "name": "Termination route", "description": "Whether the ending was a cancellation of an unaccepted offer or a termination of an accepted contract.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] } ], "artifacts": [ { "id": "order-cancellation-notice", "name": "Order cancellation notice", "description": "Written notice that cancels an unaccepted order or initiates termination of an accepted one, retained as evidence of the ending and its route.", "media_or_form": [ "structured order cancellation document", "written notice to the supplier", "termination notice record" ], "serial": false, "identity_strategy": "Order identifier plus revision plus cancellation notice reference issued by the buyer's system of record.", "source_refs": [ "SRC-001", "SRC-003" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "governance-evidence-and-interoperability", "name": "Governance, evidence and interoperability", "description": "Provenance and time semantics, retention and access, and the syntax and validation rules that let the order cross system boundaries.", "rationale": "FAR 4.7 sets explicit retention periods for purchase order files, RFC 3339 constrains how time is recorded, and Peppol and UBL constrain how the order is validated and referenced downstream; these are operating requirements, not documentation.", "source_refs": [ "SRC-001", "SRC-002", "SRC-004", "SRC-006", "SRC-010" ], "layers": [ { "id": "provenance-and-audit-evidence", "name": "Provenance and audit evidence", "description": "Where the order's content came from, when things happened, and what proves it.", "source_refs": [ "SRC-002", "SRC-003", "SRC-004", "SRC-006" ], "findings": [ { "id": "provenance-transmission-and-time-semantics", "name": "Provenance, transmission evidence and time semantics", "description": "An order needs a recorded origin (requisition, quotation, catalogue), proof of transmission and receipt, and time values that separate when something happened from when it was observed; RFC 3339 requires an explicit offset and forbids unqualified local time.", "source_refs": [ "SRC-001", "SRC-002", "SRC-004", "SRC-006" ], "questions": [ { "id": "q-content-origin", "text": "From which upstream record did each part of the order's content originate, and was any value manually overridden?", "kind": "provenance", "answer_data": [ "upstream record references (requisition, quotation, catalogue)", "field-level origin map", "override flag, actor and reason" ] }, { "id": "q-transmission-evidence", "text": "What evidence proves the order was transmitted to, and received by, the intended seller?", "kind": "evidence", "answer_data": [ "transport receipt or acknowledgement", "sender and receiver addresses", "transmission and receipt instants" ] }, { "id": "q-event-versus-ingestion-time", "text": "Where an order event time and the time it was recorded differ, are both retained and which is used for deadline calculation?", "kind": "temporal", "answer_data": [ "event instant", "observation or ingestion instant", "deadline calculation basis" ] }, { "id": "q-actor-attribution", "text": "Which actor - human, service account or agent - performed each recorded action on the order?", "kind": "security", "answer_data": [ "actor identifier and type", "action performed", "authentication assurance level" ] } ], "data_elements": [ { "id": "de-issue-instant", "name": "Order issue instant", "description": "Instant at which the order was issued to the seller.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-006" ] }, { "id": "de-recorded-instant", "name": "Recorded or ingestion instant", "description": "Instant at which the order or an event on it was recorded by the holding system, held separately from the event instant.", "value_kind": "timestamp", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006" ] }, { "id": "de-source-record-ref", "name": "Source record reference", "description": "Reference to the upstream record from which order content was derived.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "de-transmission-receipt-ref", "name": "Transmission receipt reference", "description": "Reference to the transport-level acknowledgement evidencing delivery of the order.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] } ], "artifacts": [ { "id": "transmission-and-audit-log", "name": "Transmission and audit log", "description": "Append-only record of actions and exchanges affecting the order, including transmission acknowledgements and actor attribution.", "media_or_form": [ "append-only log entries", "transport acknowledgement records", "exported audit trail" ], "serial": true, "identity_strategy": "Order identifier plus monotonically increasing sequence number per entry; entries are never renumbered and each carries its own actor and instant.", "source_refs": [ "SRC-002", "SRC-004", "SRC-006" ] } ], "inline_only_rationale": null }, { "id": "signature-attachment-and-integrity-evidence", "name": "Signatures, attachments and validation", "description": "UBL supports enveloped XML digital signatures and XAdES. Peppol permits Base64 attachments or URI links and recommends embedded objects; attachments are additional information, not order copies. Peppol fatal rules require CustomizationID, ProfileID, ID, IssueDate, DocumentCurrencyCode, Buyer, Seller and OrderLine, and forbid extra elements and schemaLocation. UBL conformance is XSD plus additional document constraints; senders must manifest all calculated values.", "source_refs": [ "SRC-001", "SRC-002", "SRC-013" ], "questions": [ { "id": "signature-attachment-and-integrity-evidence-q01", "text": "Is the order signed, with which signature profile, and what integrity hash binds the signature to the issued content?", "kind": "evidence", "answer_data": [ "signature_present", "signature_profile", "digest_value", "signer_certificate" ] }, { "id": "signature-attachment-and-integrity-evidence-q02", "text": "Which additional binary or URI attachments accompany the order, and are they supporting drawings rather than a second copy of the order?", "kind": "evidence", "answer_data": [ "attachment_list", "mime_code", "filename", "uri_or_embedded" ] }, { "id": "signature-attachment-and-integrity-evidence-q03", "text": "Which XSD, Schematron and profile business rules were applied, and did the instance pass the fatal Peppol and UBL constraints?", "kind": "validation", "answer_data": [ "validation_profile", "fatal_errors", "warnings", "validated_at" ] }, { "id": "signature-attachment-and-integrity-evidence-q04", "text": "Are all fixed and calculated amounts manifested by the sender so the receiver is not required to recompute the calculation model?", "kind": "quality", "answer_data": [ "manifest_values_complete", "recalculation_forbidden" ] } ], "data_elements": [ { "id": "signature-attachment-and-integrity-evidence-data01", "name": "Document signature", "description": "A signature applied to the order document.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-012" ] }, { "id": "signature-attachment-and-integrity-evidence-data02", "name": "Embedded or referenced attachment", "description": "Binary object or external URI supporting the order, with mime code and filename.", "value_kind": "binary", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "signature-attachment-and-integrity-evidence-data03", "name": "Validation result", "description": "Outcome of XSD and business-rule validation against the applicable profile.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-013", "SRC-001" ] } ], "artifacts": [ { "id": "signature-attachment-and-integrity-evidence-artifact01", "name": "Signed order instance", "description": "Order payload plus optional enveloped or detached signature.", "media_or_form": [ "UBL Order with Signature", "XAdES", "ASiC-S container" ], "serial": true, "identity_strategy": "Identify by buyer order number and document UUID; integrity is the signature digest over the canonical payload.", "source_refs": [ "SRC-001" ] }, { "id": "signature-attachment-and-integrity-evidence-artifact02", "name": "Validation report", "description": "Machine report of schema and Schematron evaluation.", "media_or_form": [ "Schematron SVRL", "application response" ], "serial": true, "identity_strategy": "Identify by validated document UUID plus validator profile identifier and validation event time.", "source_refs": [ "SRC-013" ] } ], "inline_only_rationale": null } ] }, { "id": "retention-access-and-confidentiality", "name": "Retention, access and confidentiality", "description": "How long the order and its evidence are kept, and who may see or change them.", "source_refs": [ "SRC-003", "SRC-004" ], "findings": [ { "id": "retention-and-disposition", "name": "Retention and disposition", "description": "FAR 4.703 sets a baseline of three years after final payment, 4.705-1 requires four years for purchase orders in financial records and 4.705-3 four years for purchase order files, calculated from the end of the fiscal year in which the entry is made; intermingled categories take the longest applicable period.", "source_refs": [ "SRC-004" ], "questions": [ { "id": "q-retention-clock-start", "text": "From which event does the retention clock start for this order, and does a fiscal-year rule apply?", "kind": "retention", "answer_data": [ "clock-start event", "fiscal-year rounding rule", "computed disposition date" ] }, { "id": "q-longest-period-rule", "text": "When the order file mixes record categories with different periods, which period governs the whole file?", "kind": "constraint", "answer_data": [ "category inventory", "applicable periods", "governing period selected" ] }, { "id": "q-litigation-hold", "text": "What suspends disposition, and how is a hold recorded and released?", "kind": "exception", "answer_data": [ "hold trigger and scope", "authorising role", "hold placement and release instants" ] }, { "id": "q-disposition-evidence", "text": "What proves that an order and its attachments were actually disposed of at the end of retention?", "kind": "evidence", "answer_data": [ "disposition method", "executing actor", "disposition certificate reference" ] } ], "data_elements": [ { "id": "de-retention-period", "name": "Retention period", "description": "Duration for which the order and its file must be retained.", "value_kind": "duration", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "de-disposition-due-date", "name": "Disposition due date", "description": "Computed date on which the order becomes eligible for disposal.", "value_kind": "date", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "de-hold-status", "name": "Legal hold status", "description": "Whether disposition is suspended and under what authority.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] } ], "artifacts": [ { "id": "retention-and-disposition-record", "name": "Retention and disposition record", "description": "Record of the retention rule applied to an order file, any holds placed on it, and the eventual disposition action.", "media_or_form": [ "retention schedule assignment entry", "hold register entry", "disposition certificate" ], "serial": false, "identity_strategy": "Order identifier plus retention rule identifier from the governing schedule; disposition actions carry their own executing-actor and instant.", "source_refs": [ "SRC-004" ] } ], "inline_only_rationale": null }, { "id": "access-and-commercial-confidentiality", "name": "Access control and commercial confidentiality", "description": "Order content is commercially sensitive - negotiated prices, volumes and supplier terms - and access differs sharply between the buyer, the seller and third parties such as auditors or forwarders.", "source_refs": [ "SRC-002", "SRC-003", "SRC-004" ], "questions": [ { "id": "q-visibility-per-party", "text": "Which fields is each counterparty entitled to see, and which are buyer-internal only?", "kind": "access", "answer_data": [ "field-level visibility matrix by role", "redaction rules", "projection definitions per audience" ] }, { "id": "q-third-party-disclosure", "text": "Under what authority may the order be disclosed to an auditor, forwarder or regulator, and is disclosure logged?", "kind": "privacy", "answer_data": [ "disclosure basis", "recipient identity", "disclosure log entry" ] }, { "id": "q-mutation-rights", "text": "Which roles may change an issued order, and does the seller ever gain write rights over any part of it?", "kind": "ownership", "answer_data": [ "write permission matrix", "seller-writable fields if any", "approval requirement for changes" ] }, { "id": "q-personal-data-on-order", "text": "Does the order carry personal data such as named contacts or delivery recipients, and what minimisation applies?", "kind": "privacy", "answer_data": [ "personal data inventory", "lawful basis", "minimisation and masking rules" ] } ], "data_elements": [ { "id": "de-confidentiality-classification", "name": "Confidentiality classification", "description": "Sensitivity label applied to the order or specific fields.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "de-access-grant", "name": "Access grant", "description": "Recorded grant of read or write access to a party or role over a scope of the order.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004" ] } ], "artifacts": [ { "id": "access-authorisation-register", "name": "Access authorisation register", "description": "Record of who was granted what access to the order and its attachments, and of disclosures to third parties.", "media_or_form": [ "authorisation register entries", "disclosure log", "policy binding record" ], "serial": false, "identity_strategy": "Order identifier plus subject identifier plus scope; subject identities resolve to the controlling identity master system rather than to local names.", "source_refs": [ "SRC-003", "SRC-004" ] } ], "inline_only_rationale": null } ] }, { "id": "interoperability-and-validation", "name": "Interoperability and validation", "description": "How the order is bound to an exchange syntax and profile, and how it is validated and matched.", "source_refs": [ "SRC-001", "SRC-002", "SRC-007", "SRC-010" ], "findings": [ { "id": "syntax-binding-profile-and-code-lists", "name": "Syntax binding, profile declaration and code lists", "description": "Peppol requires ProfileID and CustomizationID on both order and response and binds them to UBL 2.1; UBL 2.4 is a later document model, and UN/CEFACT Buy-Ship-Pay provides a syntax-neutral semantic anchor, so a projection must declare both its syntax and its profile.", "source_refs": [ "SRC-001", "SRC-002", "SRC-007" ], "questions": [ { "id": "q-profile-declaration", "text": "Which profile and customization identifiers does an exchanged projection of this order declare?", "kind": "interoperability", "answer_data": [ "profile identifier", "customization identifier", "syntax and version bound to them" ] }, { "id": "q-code-list-versioning", "text": "Which code lists and versions do the coded fields draw on, and how are version changes handled?", "kind": "validation", "answer_data": [ "code list inventory with versions", "version pinning rule", "migration procedure" ] }, { "id": "q-semantic-anchor", "text": "To which syntax-neutral semantic model do the order's terms map, so that two syntaxes can be compared?", "kind": "interoperability", "answer_data": [ "semantic model and version", "term-to-concept mapping", "unmapped term list" ] }, { "id": "q-lossy-projection", "text": "Which fields are lost or approximated when the order is projected into a narrower syntax, and is that loss recorded?", "kind": "quality", "answer_data": [ "unsupported field list per target syntax", "approximation rule", "loss record location" ] } ], "data_elements": [ { "id": "de-profile-identifier", "name": "Profile identifier", "description": "Identifier of the business process profile an exchanged order projection conforms to.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "de-customization-identifier", "name": "Customization identifier", "description": "Identifier of the specific transaction specification the projection conforms to.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "de-code-list-version", "name": "Code list version", "description": "Version of a code list from which a coded value on the order is drawn.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-002" ] } ], "artifacts": [ { "id": "syntax-profile-binding-manifest", "name": "Syntax and profile binding manifest", "description": "Declaration of which syntaxes, profiles and code list versions a given order projection was produced against, retained so the projection can be re-validated later.", "media_or_form": [ "binding manifest record", "profile declaration inside the exchanged document", "mapping specification reference" ], "serial": false, "identity_strategy": "Profile and customization identifiers as issued by the governing authority, plus the order identifier and revision the projection was produced from.", "source_refs": [ "SRC-001", "SRC-002", "SRC-007" ] } ], "inline_only_rationale": null }, { "id": "validation-matching-and-reference-integrity", "name": "Validation, matching and downstream reference integrity", "description": "Beyond syntax validity, an order must satisfy business rules (each line carries an item identifier and/or name; a response refers to exactly one order) and must remain resolvable from downstream documents that quote it as BT-13 or BT-14.", "source_refs": [ "SRC-002", "SRC-010", "SRC-001" ], "questions": [ { "id": "q-rule-severity", "text": "Which validation rules are fatal, which are warnings, and who may waive a warning?", "kind": "validation", "answer_data": [ "rule inventory with severity", "waiver authority", "waiver record" ] }, { "id": "q-match-tolerance", "text": "On what criteria and within what tolerance is the order matched to receipt and invoice before payment is released?", "kind": "measurement", "answer_data": [ "match criteria set", "quantity and price tolerances", "match outcome states" ] }, { "id": "q-broken-reference", "text": "What happens when a downstream document quotes an order reference that does not resolve, or resolves to a superseded revision?", "kind": "exception", "answer_data": [ "resolution failure classification", "fallback or filler convention", "exception routing" ] }, { "id": "q-round-trip-fidelity", "text": "How is it verified that an order re-imported from an exchanged projection is semantically identical to the source?", "kind": "quality", "answer_data": [ "comparison method", "canonical form used", "tolerated differences" ] } ], "data_elements": [ { "id": "de-validation-result", "name": "Validation result", "description": "Outcome of applying a validation rule set to an order or projection, with rule identifiers and severities.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "de-match-status", "name": "Match status", "description": "Result of matching the order against receipt and invoice records.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-010" ] }, { "id": "de-downstream-reference", "name": "Downstream reference", "description": "Reference quoted by a downstream document that must resolve back to this order.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-010" ] } ], "artifacts": [ { "id": "validation-and-match-exception-report", "name": "Validation and match exception report", "description": "Report of validation failures and match exceptions raised against an order, retained as evidence of control operation.", "media_or_form": [ "validation report record", "match exception list", "control evidence export" ], "serial": true, "identity_strategy": "Order identifier plus revision plus run sequence number of the validating or matching process; each run is retained rather than overwritten.", "source_refs": [ "SRC-002", "SRC-010" ] } ], "inline_only_rationale": null } ] } ] } ] }, "functions": [ { "id": "resolve-order-reference", "name": "Resolve order reference", "description": "Bind an inbound reference to exactly one order and, where required, one revision.", "inputs": [ "order identifier", "identifier scheme", "optional revision selector", "optional counterparty context" ], "outputs": [ "resolved order aggregate reference", "resolved revision", "resolution confidence and failure reason" ], "preconditions": [ "identifier scheme is registered", "caller is authorised to read the order" ], "effects": [ "records a resolution attempt in the audit log", "raises a broken-reference exception when no unique match exists" ], "source_refs": [ "SRC-001", "SRC-002", "SRC-010" ] }, { "id": "compose-purchase-order", "name": "Compose purchase order", "description": "Assemble a draft order from upstream demand, catalogue and framework terms, recording field-level provenance.", "inputs": [ "requisition or demand reference", "optional quotation reference", "optional framework agreement reference", "party roles", "line items with quantities" ], "outputs": [ "draft order aggregate", "provenance map", "unresolved-field list" ], "preconditions": [ "parties resolve under declared identifier schemes", "currency and unit-of-measure code lists are available" ], "effects": [ "creates a draft order in non-committed state", "links the draft to its upstream sources" ], "source_refs": [ "SRC-001", "SRC-002", "SRC-007" ] }, { "id": "validate-order", "name": "Validate order", "description": "Apply syntax, profile and business rules to an order and classify each failure by severity.", "inputs": [ "order aggregate", "target profile and customization identifiers", "code list versions" ], "outputs": [ "validation result set with rule identifiers and severities", "fatal or passable verdict" ], "preconditions": [ "profile binding is declared", "rule set version is pinned" ], "effects": [ "produces a retained validation report", "blocks issuance while fatal failures remain unwaived" ], "source_refs": [ "SRC-001", "SRC-002" ] }, { "id": "authorise-and-issue-order", "name": "Authorise and issue order", "description": "Record commitment approval and issue the order to the seller as an offer, capturing transmission evidence.", "inputs": [ "validated draft order", "authorising role and delegation reference", "seller electronic address" ], "outputs": [ "issued order revision", "approval record", "transmission receipt reference" ], "preconditions": [ "approver holds authority for the order value and category", "validation returned no unwaived fatal failures" ], "effects": [ "moves the order to issued state", "starts any response deadline", "makes the order revision immutable" ], "source_refs": [ "SRC-002", "SRC-003" ] }, { "id": "register-order-response", "name": "Register order response", "description": "Record a seller response against exactly one order and apply its header and line codes to order state.", "inputs": [ "order reference", "response document reference", "header response code", "line response codes" ], "outputs": [ "updated order and line states", "derived acceptance position", "discrepancy list where lines were changed" ], "preconditions": [ "the response refers to exactly one order", "every referenced line identifier exists on that order" ], "effects": [ "may transition the order to accepted, conditionally accepted or rejected", "supersedes any earlier response as the current position" ], "source_refs": [ "SRC-001", "SRC-002", "SRC-003" ] }, { "id": "record-acceptance-by-performance", "name": "Record acceptance by performance", "description": "Derive acceptance from the seller commencing performance where no express response was sent.", "inputs": [ "order reference", "fulfilment or performance event evidence" ], "outputs": [ "derived acceptance state", "acceptance instant and evidence reference" ], "preconditions": [ "the order is in issued state and not withdrawn", "acceptance by performance is permitted for this order" ], "effects": [ "transitions the order to accepted", "closes the withdrawal window" ], "source_refs": [ "SRC-003", "SRC-005" ] }, { "id": "amend-order", "name": "Amend order", "description": "Issue a numbered modification that identifies the order and revision it changes and determines whether seller acceptance is required.", "inputs": [ "order and revision reference", "changed fields", "amendment reason code", "effective-from instant" ], "outputs": [ "new order revision", "order change notice", "acceptance requirement determination" ], "preconditions": [ "the changed fields are amendable rather than re-issue triggers", "the amending actor holds authority for the resulting value" ], "effects": [ "supersedes the prior revision from the effective-from instant", "retains the prior revision as evidence", "may reopen the seller response cycle" ], "source_refs": [ "SRC-001", "SRC-003" ] }, { "id": "release-call-off-against-framework", "name": "Release call-off against framework", "description": "Draw a release order against a framework agreement's ceiling and update the residual balance.", "inputs": [ "framework agreement reference", "requested lines and quantities", "release sequence context" ], "outputs": [ "release order", "consumed value or quantity", "residual framework balance" ], "preconditions": [ "the framework is in force at the release instant", "the requested draw does not exceed the residual balance" ], "effects": [ "decrements the framework residual balance", "links the release to its framework instrument" ], "source_refs": [ "SRC-003", "SRC-011" ] }, { "id": "link-fulfilment-and-match", "name": "Link fulfilment and match", "description": "Attach fulfilment events to lines and instalments, compute outstanding quantities, and match order to receipt and invoice within tolerance.", "inputs": [ "order reference", "fulfilment event references", "receipt records", "invoice references" ], "outputs": [ "outstanding quantity per line", "match status", "match exception list" ], "preconditions": [ "fulfilment events carry a resolvable line and instalment reference", "tolerances are configured for the order" ], "effects": [ "updates line fulfilment state", "raises match exceptions that block settlement" ], "source_refs": [ "SRC-001", "SRC-002", "SRC-010" ] }, { "id": "cancel-or-terminate-order", "name": "Cancel or terminate order", "description": "End an order by the route appropriate to its acceptance status and record any resulting cost claim.", "inputs": [ "order reference", "acceptance status", "reason code", "notice content" ], "outputs": [ "cancellation or termination notice", "terminal order state", "cost claim record where asserted" ], "preconditions": [ "the ending actor holds authority", "the order is not already in a terminal state" ], "effects": [ "moves the order to cancelled or terminated", "stops further fulfilment linkage", "selects the cancellation or termination procedure" ], "source_refs": [ "SRC-001", "SRC-003" ] }, { "id": "close-order", "name": "Close order", "description": "Close an order once every line satisfies its closure criteria and no residual obligation remains.", "inputs": [ "order reference", "per-line outstanding quantities and values", "closure thresholds" ], "outputs": [ "closed order state", "closure instant", "residual write-off record where thresholds allow" ], "preconditions": [ "no line has an unresolved match exception", "no open legal hold prevents closure" ], "effects": [ "moves the order to closed", "starts the retention clock where closure is the clock-start event" ], "source_refs": [ "SRC-002", "SRC-004" ] }, { "id": "apply-retention-and-disposition", "name": "Apply retention and disposition", "description": "Compute the disposition date from the governing retention rule, honour holds, and evidence eventual disposal.", "inputs": [ "order file inventory by record category", "clock-start event", "applicable retention rules", "hold register" ], "outputs": [ "governing retention period", "disposition due date", "disposition certificate on execution" ], "preconditions": [ "the clock-start event has occurred", "no active hold covers the order file" ], "effects": [ "schedules or executes disposition", "records the longest applicable period for intermingled categories" ], "source_refs": [ "SRC-004" ] }, { "id": "project-order-to-syntax", "name": "Project order to syntax", "description": "Render the order into a target exchange syntax and profile, declaring the binding and recording any information loss.", "inputs": [ "order aggregate and revision", "target syntax and profile", "code list versions" ], "outputs": [ "syntax projection", "binding manifest", "field loss record" ], "preconditions": [ "a mapping exists from the semantic model to the target syntax", "required profile identifiers are available" ], "effects": [ "produces an exchangeable projection without mutating the source order", "records which fields could not be represented" ], "source_refs": [ "SRC-001", "SRC-002", "SRC-007" ] }, { "id": "calculate-anticipated-totals", "name": "Calculate anticipated totals", "description": "Sender computes and manifests line extension, header allowances and charges and anticipated payable amounts using the Peppol formulae, without requiring the receiver to recompute.", "inputs": [ "line amounts", "header allowances and charges", "estimated tax if used" ], "outputs": [ "manifest AnticipatedMonetaryTotal", "allowance and charge totals" ], "preconditions": [ "Line amounts are present when totals are stated", "Currency is the document currency" ], "effects": [ "Places all calculated values in the instance so a receiver print or matching process need not know the calculation model" ], "source_refs": [ "SRC-002", "SRC-001" ] }, { "id": "conclude-contract-on-acceptance", "name": "Conclude contract on acceptance", "description": "Record that an acceptance has become effective, distinguishing CISG reach-the-offeror timing from MLEC dispatch and receipt of the data message.", "inputs": [ "issued order that is an offer", "seller acceptance statement or qualifying conduct", "applicable formation law" ], "outputs": [ "contract-concluded state", "acceptance effective time", "dispatch and receipt times of the acceptance message" ], "preconditions": [ "Order was a sufficiently definite offer or a call-off under an existing contract", "Acceptance indicates assent and is not a material counter-offer unless treated as a new offer" ], "effects": [ "Creates the contractual obligation described by UBL ordering and Peppol acceptance", "Leaves a rejected order without residual obligations" ], "source_refs": [ "SRC-015", "SRC-002", "SRC-016" ] } ], "composition": [ { "target": "WM-ECO-006", "relation": "CHILD", "purpose": "The purchase order is a specialised instrument under the parent commercial agreement model; the parent owns clause bodies, negotiated terms and agreement lifecycle, while this model owns the order instrument itself.", "required": true, "source_refs": [ "SRC-001", "SRC-003" ] }, { "target": "WM-ECO-024", "relation": "COMPOSE", "purpose": "Order lines and delivery instalments generate fulfilment obligations owned by the contained model; this model contributes the obligation-creating terms and the linking references, not the fulfilment events.", "required": true, "source_refs": [ "SRC-001", "SRC-002" ] }, { "target": "WM-ECO-021", "relation": "REFERENCE", "purpose": "An order may originate from an accepted quotation; the quotation reference is retained here while quotation content and pricing logic stay in the sibling model.", "required": false, "source_refs": [ "SRC-001", "SRC-003" ] }, { "target": "Invoice and settlement model (not yet registered in vr.wm-eco)", "relation": "REFERENCE", "purpose": "Invoices quote the order as EN 16931 BT-13 and may carry BT-14; the reference integrity rules live here but invoice content and tax determination do not. The target model identifier is a registry gap.", "required": false, "source_refs": [ "SRC-010" ] }, { "target": "OASIS Universal Business Language 2.4 Order document model", "relation": "ALIGN", "purpose": "Alignment target for header business information entities, OrderLine/LineItem structure and the OrderResponse, OrderChange and OrderCancellation companions. Alignment only; no conformance claim is made.", "required": false, "source_refs": [ "SRC-001" ] }, { "target": "OpenPeppol BIS Ordering 3.3", "relation": "ALIGN", "purpose": "Alignment target for order and order response exchange, header and line response codes, one-response-per-order rule, line identifier matching and profile/customization declaration.", "required": false, "source_refs": [ "SRC-002" ] }, { "target": "UN/CEFACT Buy-Ship-Pay Reference Data Model (vocabulary D23B)", "relation": "ALIGN", "purpose": "Syntax-neutral semantic anchor for trade transaction, party, trade line item and delivery concepts, used to compare projections across syntaxes.", "required": false, "source_refs": [ "SRC-007" ] }, { "target": "GS1 identification keys (GLN and trade item keys)", "relation": "ALIGN", "purpose": "Alignment target for scheme-qualified party, location and item identifiers, including ISO 6523 ICD 0088 compatibility and the GLN non-reuse policy.", "required": false, "source_refs": [ "SRC-008" ] }, { "target": "ICC Incoterms 2020 rules", "relation": "ALIGN", "purpose": "Alignment target for the delivery term code, named place and rules edition that allocate task, cost and risk; the rules text itself remains external.", "required": false, "source_refs": [ "SRC-009" ] }, { "target": "United Nations Convention on Contracts for the International Sale of Goods", "relation": "ALIGN", "purpose": "Alignment target for offer-and-acceptance formation semantics and buyer/seller obligations in cross-border sales, where the convention applies and has not been excluded.", "required": false, "source_refs": [ "SRC-005" ] }, { "target": "IETF RFC 3339 date-time profile", "relation": "ALIGN", "purpose": "Alignment target for every timestamp on the order, requiring explicit seconds and an explicit offset or Z rather than unqualified local time.", "required": false, "source_refs": [ "SRC-006" ] }, { "target": "US Federal Acquisition Regulation Parts 4 and 13", "relation": "ALIGN", "purpose": "Jurisdiction-specific alignment for offer/acceptance treatment, modification numbering, cancellation versus termination, and purchase order file retention periods. Applies to US federal acquisition only.", "required": false, "source_refs": [ "SRC-003", "SRC-004" ] } ], "serviceLayers": { "dimension": { "owner_package_requirements": [ "A single adopting Dimension must own the order identifier scheme and declare its uniqueness domain before any order is issued, so that every downstream reference resolves deterministically.", "The owning package must publish the profile and customization identifiers, code list versions and validation rule sets it accepts, and version them independently of the order records themselves.", "The owning package must declare the retention rule set applied to order files and the authority under which it is set, since retention periods are jurisdiction-specific and not derivable from the order content.", "The owning package must name the roles holding commitment authority and the thresholds attached to them, and must keep that delegation record separate from the order sent to the seller." ], "namespace_guidance": "Use one namespace per adopting Dimension for locally minted order identifiers and keep it distinct from the namespaces of externally governed schemes (GS1 GLN, ISO 6523 ICD, Peppol EAS, profile and customization identifiers). Never mint a local identifier inside an external namespace; qualify every borrowed identifier with its issuing scheme code so provenance stays visible. Local artefact and revision names must be scheme-qualified and must not embed dates.", "registry_links": [ "vr.wm-eco-019 - this model's registry entry", "WM-ECO-006 - parent commercial agreement model", "WM-ECO-024 - contained fulfilment obligation model", "WM-ECO-021 - referenced quotation model", "planning/VERCY-MODEL-RELATIONS.csv - typed edge register for these links" ] }, "canon_and_patch": { "canonicalization_rules": [ "Canonical form is the order aggregate with header and lines in declared line-identifier order, all timestamps normalised to RFC 3339 with explicit seconds and offset, all codes carried with their scheme and version, and all monetary amounts carried with their currency and stated scale.", "Absent optional values are omitted rather than represented as empty, null or filler strings; where a target syntax forces a filler such as 'NA' for a mandatory element, the filler is a projection artefact and must not be canonicalised back into the source.", "Party, location and item identifiers are canonicalised as the pair of scheme code and value, never as the bare value, so that identical values from different registries never collide." ], "patch_rules": [ "An issued order revision is immutable; changes are expressed as a new revision plus a numbered change notice that identifies the order and the revision it changes, not as an in-place edit.", "A patch must state its effective-from instant separately from its recording instant, and must declare whether it binds unilaterally or requires counterparty acceptance to take effect.", "Patches that alter fields outside the amendable set are rejected and must be re-expressed as a new order; the rejection reason is retained.", "Line identifiers are not renumbered by a patch; added lines take new identifiers and removed lines are marked rather than deleted, so prior responses and fulfilment links remain resolvable." ], "compatibility_rules": [ "Adding an optional element or a new code value to a code list is backward compatible; removing an element, narrowing cardinality, or changing the meaning of an existing code is breaking and requires a new profile or customization identifier.", "Projections must declare the profile, customization and code list versions they were produced against; a consumer that does not recognise the declared version must fail closed rather than guess.", "Semantic mappings to external alignment targets may be revised without changing the model's own identifiers, but any revision that changes an existing mapping must be recorded with its effective-from instant.", "Information lost in a narrower projection must be recorded in a loss record; a round trip that silently drops fields is treated as a compatibility defect, not an acceptable approximation." ] }, "artifact_rules": { "identity_priority": [ "Authoritative master-system identifier: the purchase order number assigned by the buyer's system of record, qualified by its issuing scheme, which is the identifier both parties and all downstream documents cite.", "Governed global identifier or IRI: a scheme-qualified identifier issued by an external authority (for example a GS1 GLN for a party or location under ISO 6523 ICD 0088, or a profile/customization IRI for a projection) where the object is governed outside the buyer.", "UUID or ULID minted by the adopting Dimension, used only where neither a master-system identifier nor a governed global identifier exists; it is a handle, never a substitute for the order number in counterparty-facing references.", "A date, an issue period, a fiscal year or any date-bearing string is never an identifier and must not be embedded in one; ordering and recency are expressed by explicit timestamps and revision sequence numbers." ], "timestamp_rule": "Every time value on an order is recorded as an RFC 3339 date-time with explicit seconds and an explicit numeric offset or 'Z'; unqualified local time is not accepted. Event time (issue, transmission, acceptance, amendment effective-from, closure) is recorded separately from observation or ingestion time whenever the two differ, and both are retained rather than the later overwriting the earlier. Where a requested delivery window is a local wall-clock period, the IANA time zone identifier is recorded alongside the offset so the window survives daylight-saving changes; deadline calculations must state which of the two times they are computed from.", "serial_naming_rule": "Serial artefacts (order revisions, change notices, order responses, audit entries, validation runs) are named as the order identifier plus a zero-padded, monotonically increasing sequence number within their own series. Sequence numbers are never reused, never renumbered and never contain a date, fiscal period or year component; a gap in a series is itself evidence and must be explained rather than closed by renumbering.", "integrity_rule": "Each issued revision, response, change notice and attachment is sealed with a content digest computed over its canonical form at the moment of issuance, and the digest is stored with the actor, event instant and recording instant. Incorporated external documents (terms, specifications) are pinned by digest so the version actually incorporated stays provable. Audit and transmission logs are append-only; corrections are added as new entries that reference the entry they correct, and any verification failure is raised as an exception rather than repaired silently." }, "policies": [ "An order is treated as an offer that does not bind the seller until acceptance is recorded, by express response or by evidenced performance; systems must not report a contract as formed on issuance alone.", "Anticipated monetary totals on an order are never treated as settled amounts; settlement authority rests with the invoice and payment records held by the settlement model.", "No order is issued while an unwaived fatal validation failure stands, and every waiver records the waiving role, the rule waived and the reason.", "Commitment authority is verified against a delegation record at the moment of issuance, not inferred from job title or from prior orders.", "Order content is treated as commercially confidential by default; counterparty-facing projections are produced by an explicit projection definition rather than by sharing the internal record.", "Retention and disposition follow the longest applicable period where record categories are intermingled, and disposition is suspended by any active hold.", "Treat silent non-response as non-acceptance unless a proven practice or usage to the contrary is recorded for those parties", "Accept-with-change is forbidden unless a prior agreement defines how buyer assent to the change is obtained", "Tax figures on an order are estimates and must not be filed as a tax return from this model", "Cancellation is a new event document; it is not physical deletion of the retained original", "Personal contact data on the order is collected only for ordering, delivery and invoice-matching purposes" ], "crud": { "read": [ "Resolve an order by its scheme-qualified identifier and return the revision in force at a stated instant, or a named historic revision.", "Return a role-scoped projection of an order that omits fields the requesting party is not entitled to see, with the projection definition identified in the response.", "Return the fulfilment and match position of an order without exposing the underlying fulfilment model's internal records.", "Return the full revision series, response history and audit trail for an order to an auditor scope, including superseded revisions." ], "create": [ "Compose a draft order with field-level provenance from upstream demand, quotation, catalogue or framework sources.", "Issue a validated draft as an immutable revision after recording commitment approval and capturing transmission evidence.", "Create a release order against a framework agreement, decrementing its residual balance atomically with the release.", "Register an inbound order response, change notice or fulfilment linkage as a new record bound to exactly one order." ], "update": [ "Supersede an issued revision by creating a new numbered revision plus a change notice; never edit an issued revision in place.", "Apply a seller response to derive order and line state without mutating the order's issued content.", "Update derived state (outstanding quantity, match status, disposition due date) as a computed projection that can be rebuilt from the event history.", "Record a waiver, hold, or access grant as an additive entry that references, but does not alter, the order revision it concerns." ], "delete": [ "Logical deletion only during the draft state, before any revision has been issued or transmitted.", "Issued revisions, responses, change notices and audit entries are never deleted; an order that should not have been issued is cancelled or terminated by the route matching its acceptance status.", "Physical destruction occurs only through the retention and disposition function, after the governing period has elapsed and with no active hold, and produces a retained disposition certificate.", "Attachments incorporated by reference are disposed of under the retention rule of the order file they belong to, and their digests are retained after the content is destroyed so past incorporation stays provable." ] }, "roles": [ { "name": "Order owner (buyer-side requisitioner or category owner)", "responsibilities": [ "Define the requirement, item identification and requested delivery on the draft order.", "Confirm that the order draws on the correct framework agreement or quotation.", "Decide on substitution and residual write-off within delegated limits." ] }, { "name": "Commitment authority (contracting officer or authorised approver)", "responsibilities": [ "Verify authority and thresholds before issuance and record the approval with its instant.", "Authorise amendments, cancellations and terminations and select the correct procedural route.", "Waive non-fatal validation findings with a recorded reason." ] }, { "name": "Order operations steward", "responsibilities": [ "Maintain the identifier scheme, revision series and line identifier stability rules.", "Register order responses and fulfilment linkages and resolve match exceptions.", "Close orders once closure criteria are met and start the retention clock." ] }, { "name": "Interoperability steward", "responsibilities": [ "Own profile, customization and code list version bindings and the mappings to external alignment targets.", "Review projections for information loss and maintain loss records.", "Fail closed on unrecognised profile or code list versions rather than guessing." ] }, { "name": "Records and retention officer", "responsibilities": [ "Assign the governing retention rule to each order file and compute disposition dates.", "Place and release holds and evidence every disposition action.", "Enforce the longest applicable period across intermingled record categories." ] }, { "name": "Access and confidentiality controller", "responsibilities": [ "Maintain the role-to-field visibility matrix and the counterparty projection definitions.", "Authorise and log third-party disclosures to auditors, forwarders and regulators.", "Review personal data carried on orders against minimisation requirements." ] } ], "access": { "default_rule": "Deny by default. Read access is granted per scope to identified subjects with a recorded basis; the seller sees only the counterparty projection of the orders addressed to it, and no counterparty holds write access to any part of an issued order.", "scopes": [ "bundle", "layer", "finding", "artifact" ], "exceptions": [ "Auditors and regulators may receive whole-order read access including superseded revisions and audit trails, under a recorded disclosure basis and with the disclosure logged.", "Freight forwarders and logistics providers may receive a delivery-only projection containing destination, schedule and delivery terms, with pricing and payment terms withheld.", "Legal hold overrides retention-driven disposal and may also override routine access restriction for the holding authority, for the duration of the hold.", "Emergency operational access may be granted to restore a stalled order flow; such access is time-boxed, notified to the access controller and reviewed after the fact.", "Where a framework agreement obliges disclosure of drawdown balances to the supplier, that specific derived value may be exposed without exposing the underlying release orders.", "Regulators or courts may compel disclosure of retained originals", "A consignee may be given delivery fields without price or allowance detail", "Unsigned Peppol orders remain valid under the Ordering BIS, which does not mandate eSignature" ], "audit_requirements": [ "Every read of a whole order, and every disclosure to a third party, is logged with subject identity, scope, basis and RFC 3339 instant.", "Every write, waiver, hold and access grant is logged as an append-only entry carrying actor identity, actor type (human, service account or agent) and authentication assurance.", "Access logs are retained for at least as long as the order file they concern, so that access can be reviewed for the whole retention period.", "Log entries are never edited; corrections are appended with a reference to the entry corrected, and gaps in a log sequence must be explained.", "Log issue, dispatch, receipt, validation, response, change, cancellation, access and deletion events with RFC 3339 event time and separate ingestion time when they differ", "Retain originator, addressee and message identifiers with the original data message" ] }, "agents_bootstrap": { "filename": "AGENTS.md", "required_fields": [ "Name", "Type", "Specification URL", "Storage type URL", "Interface URL", "Processes URL", "Model ID", "Registry ID", "Owner or maintainer", "Alignment targets and conformance status" ], "read_order": [ "AGENTS.md - identify the model, its type and where its contracts live", "Specification URL - read scope, boundaries and the bundle/layer/finding structure before acting", "Storage type URL - learn how the aggregate is persisted and how revisions are addressed, remembering that storage is a projection and not the semantics", "Interface URL - learn the read, create, update and delete operations and their access scopes", "Processes URL - learn the lifecycle, response, amendment, cancellation, closure, retention and validation procedures", "Registry and relations entries - resolve parent, contained and referenced models before crossing a boundary" ] } }, "coverage": { "claim": "Covers the purchase order as a buyer-issued commitment instrument across identity and revision, classification and replenishment pattern, parties and commitment authority, line and commercial content, delivery instruction, lifecycle and change control, and governance, anchored in UBL 2.4, Peppol BIS Ordering 3.3 and BIS Billing 3.0, US FAR Parts 4 and 13, CISG, Incoterms 2020, GS1 identification keys, UN/CEFACT Buy-Ship-Pay and RFC 3339, with signature, attachment and integrity evidence merged from the Grok pack. Alignment only; no conformance is claimed to any cited standard. Deliberately incomplete on classic EDI syntaxes (UN/EDIFACT ORDERS, ANSI X12 850/855/860/865), tax determination on orders, services procurement with milestone acceptance, public-sector procurement metadata, and retention law outside US federal contracting. Not a claim of universal or jurisdictional completeness.", "confidence": "medium", "checklist": [ { "dimension": "identity", "status": "covered", "notes": "Buyer-assigned order number as master-system identifier, optional document UUID, seller sales order identifier, line identifier stability, and scheme-qualified party, location and item identifiers. Grounded in SRC-001, SRC-002, SRC-008, SRC-010." }, { "dimension": "lifecycle", "status": "covered", "notes": "State model, response-driven transitions, acceptance by performance, amendment, cancellation versus termination, and closure. Grounded in SRC-002 response codes and SRC-003 sections 13.302-3 and 13.302-4." }, { "dimension": "relationships", "status": "covered", "notes": "Links to quotation, framework agreement, fulfilment obligations, order responses and downstream invoices, with typed composition entries and boundary notes. Grounded in SRC-001, SRC-002, SRC-003, SRC-010." }, { "dimension": "temporal", "status": "covered", "notes": "RFC 3339 with explicit seconds and offset, event time separated from observation or ingestion time, delivery windows as periods with IANA zone, retention clock computed from a fiscal-year rule. Grounded in SRC-006 and SRC-004." }, { "dimension": "provenance", "status": "covered", "notes": "Field-level origin mapping from requisition, quotation and catalogue, override recording, transmission evidence and actor attribution. Grounded in SRC-001, SRC-002, SRC-004." }, { "dimension": "ownership", "status": "covered", "notes": "Buyer, seller, originator and cost-centre separation, commitment authority and delegation, and write-permission boundaries that keep counterparties read-only. Grounded in SRC-001, SRC-003, SRC-008." }, { "dimension": "validation", "status": "covered", "notes": "Syntax and profile validation, business rules such as item identifier or name per line and one response per order, severity classification, waiver authority, and three-way match tolerance. Grounded in SRC-001, SRC-002, SRC-010." }, { "dimension": "access", "status": "covered", "notes": "Deny-by-default with scoped counterparty, forwarder and auditor projections, disclosure logging and personal-data minimisation. Partly grounded in SRC-003 and SRC-004; field-level confidentiality matrices are common practice rather than normative." }, { "dimension": "retention and deletion", "status": "covered", "notes": "Explicit periods from FAR 4.703 (3 years after final payment), 4.705-1 and 4.705-3 (4 years for purchase orders and purchase order files), fiscal-year clock start under 4.704, longest-period rule for intermingled categories, holds, and immutability of issued revisions. Grounded in SRC-004." }, { "dimension": "interoperability", "status": "covered", "notes": "Profile and customization declaration, code list versioning, syntax-neutral semantic anchoring to Buy-Ship-Pay, projection loss records, and BT-13/BT-14 downstream reference integrity. Grounded in SRC-001, SRC-002, SRC-007, SRC-010." }, { "dimension": "classification", "status": "covered", "notes": "Order type code and commitment pattern, with the caveat that the blanket/standing/call-off/release vocabulary is not normalised by any consulted primary source. Grounded in SRC-001 and SRC-003, gap flagged via SRC-011." }, { "dimension": "authority and commitment", "status": "covered", "notes": "Delegated authority thresholds, approval evidence, ratification of unauthorised commitments, and the offer/acceptance legal posture. Grounded in SRC-003 and SRC-005." }, { "dimension": "measurement and quantity", "status": "covered", "notes": "Ordered quantity, unit of measure code lists, packaging basis and conversion, price base quantity, and delivery tolerance bands. Grounded in SRC-001, SRC-002, SRC-007." }, { "dimension": "spatial", "status": "covered", "notes": "Delivery destination identified by scheme-qualified location identifier with a declared semantic type (legal entity, function, fixed or mobile physical location, digital location), plus trade-term named place. Grounded in SRC-008 and SRC-009." }, { "dimension": "evidence and quality", "status": "covered", "notes": "Content digests over canonical form, append-only audit trail, transmission receipts, retained validation runs and round-trip fidelity checks. Partly grounded in SRC-002 and SRC-004; digest-sealing specifics are engineering practice, not a normative requirement of any cited source." }, { "dimension": "security", "status": "gap", "notes": "Transport security, signature formats, non-repudiation levels and key management for sealed order revisions are referenced only in outline. No consulted primary source was verified for these, so this dimension is marked a gap rather than presented as canonical." }, { "dimension": "exception handling", "status": "covered", "notes": "Stalled responses, broken or superseded references, unauthorised commitments, cost claims on cancellation, and match exceptions each have dedicated questions. Grounded in SRC-002, SRC-003, SRC-010." }, { "dimension": "privacy", "status": "not-applicable", "notes": "A purchase order is a B2B instrument and personal data is incidental (named contacts, delivery recipients). The model raises minimisation as a question but deliberately does not model a data-protection regime; that belongs to a dedicated sibling model." } ], "known_omissions": [ "UN/EDIFACT ORDERS and ANSI ASC X12 850/855/860/865 are the two most widely deployed order syntaxes and neither could be retrieved live (UNECE service returned HTTP 403; x12.org did not expose the 850 transaction set on the page fetched). Their mapping is therefore absent rather than asserted, and the interoperability layer is weaker for classic EDI than for UBL and Peppol.", "No source was verified for tax determination on orders (VAT category codes, reverse charge, place-of-supply), so tax is modelled only as an indicative amount and a code-list reference.", "Consignment, vendor-managed inventory, scheduling agreements and just-in-time delivery call-offs are acknowledged as purchasing patterns but not modelled in detail; each may need its own contained model.", "Services procurement (timesheets, milestones, statements of work) is treated identically to goods at the line level, which understates milestone-based acceptance and progress payment structures.", "Electronic signature and sealing formats for orders, and the legal weight of each, are not covered.", "Currency of account versus currency of settlement, and hedging or price-adjustment clauses, are only gestured at through the price-status question.", "Public-sector specific order metadata (procurement procedure reference, CPV/UNSPSC classification obligations, contract award notice linkage) is not modelled.", "ICC Incoterms 2020 official text was not fetched; UBL only cites CIF, FOB and EXW as example delivery-term alignments", "United States UCC Article 2 and FAR/DFARS federal purchase orders were not independently retrieved as primary sources", "ASC X12 850/855 TR3 content is membership-gated; North American EDI is an alignment gap rather than a canonical node", "UN/CEFACT Buyer's Order CCL / SCRDM was not fetched beyond EDIFACT ORDERS D.99B", "Standing, rush, subscription and digital-goods or SaaS order semantics lack first-party coverage here", "Islamic financing purchase instruments and letter-of-credit specific order clauses are not modelled", "Line-level cancellation as a first-class document distinct from Order Change is not specified by the cited UBL process", "National commercial-books retention periods (often five to ten years) are jurisdiction-specific and not enumerated", "GDPR and other privacy statutes are not cited; only the presence of contact personal data on Peppol/UBL parties is sourced" ], "conflicts": [ "FAR 13 states that a quotation is not an offer and cannot be accepted by the government to form a binding contract, whereas under CISG a sufficiently definite communication indicating intent to be bound can be an offer regardless of what it is called. The formation posture must therefore be recorded explicitly per order rather than inferred from the document type.", "UBL treats order references as optional in several places, while Peppol BIS Billing makes cbc:ID within cac:OrderReference 1..1 and prescribes an 'NA' filler when only a sales order reference exists. A filler value that is syntactically valid but semantically empty conflicts with the canonicalisation rule that absent values are omitted; the model resolves this by treating the filler as a projection artefact only.", "Peppol BIS Ordering 3.3 binds to UBL 2.1 while UBL 2.4 is the current OASIS Standard, so the alignment targets are at different versions of the same document model and cannot both be conformed to simultaneously without a declared profile.", "Incoterms 2020 allocate delivery, cost and risk but do not determine transfer of title; commercial practice frequently conflates the two, and orders that state a trade term but no title clause leave ownership transfer undefined.", "FAR 4.703 sets a 3-year baseline after final payment while 4.705-1 and 4.705-3 set 4 years for purchase order records, so a single order file can attract different periods; the model adopts the longest-applicable-period rule to resolve this.", "Industry terminology for framework purchasing (blanket order, standing order, call-off, release order) is used inconsistently and no consulted primary source normalises it; the model separates the coded order type from the commitment pattern instead of picking a winner.", "UN/EDIFACT document-name 105 Purchase Order is an internal enterprise document, while UBL alternative business term Purchase Order and common commercial usage mean the exchanged buyer-to-seller Order (typically code 220). This model follows the exchanged-commitment sense and maps 105 to originator requisition.", "CISG art. 18: silence or inactivity is not in itself acceptance, but some courts give effect to commercial letters of confirmation where a usage exists under art. 9. Adopters must record which rule they apply.", "Peppol dates shall not include timezone information, while this Dimension requires RFC 3339 timestamps with seconds and explicit offset; date-only source values must be normalised, not treated as already conformant.", "UBL DocumentCurrencyCode is optional on Order; Peppol T01 makes it fatal-mandatory.", "Peppol states TAX on orders is informative and does not affect terms of trade; some tax administrations may still treat a stated VAT amount as a representation. Do not claim tax-document status.", "UBL full Order Response replaces the entire order state; Peppol also allows partial acceptance and multiple responses for one order. Both patterns must be recorded rather than collapsed.", "ISO/IEC 19845 has frozen earlier UBL versions; OASIS UBL 2.4 is the OASIS Standard used here and is not automatically the ISO edition.", "Peppol Ordering does not mandate eSignature; UBL defines a signature extension. Unsigned orders can be valid in Peppol and still lack non-repudiation evidence." ], "regional_assumptions": [ "FAR Parts 4 and 13 govern US federal acquisition only. Their treatment of purchase orders as unilateral offers, modification numbering, cancellation versus termination, and the 3- and 4-year retention periods should not be assumed to apply to commercial buyers or to other jurisdictions.", "Peppol BIS Ordering and BIS Billing reflect European post-award practice and their profile identifiers, EAS electronic address codes and ICD party schemes are governed by OpenPeppol; they carry no authority outside that network.", "CISG applies only between parties whose places of business are in different contracting states (or where private international law points to one), and parties may exclude it by agreement; a purchase order under a domestic contract is governed by domestic sale-of-goods law instead.", "GLN allocation, prefix length and the non-reuse policy effective 1 July 2022 are administered by GS1 Member Organisations; details cited here come from GS1 Australia and may differ in presentation, though not in the underlying standard, elsewhere.", "Retention periods for commercial (non-government) purchase orders are set by national commercial, tax and accounting law and are not covered by any source consulted here.", "Incoterms 2020 is the current edition but earlier editions remain in lawful use where a contract names them, so the edition must always be recorded with the term.", "Peppol BIS Ordering is written for EU and EEA public eProcurement and B2B/B2G; it is an alignment, not a global mandate.", "CISG applies to international sales of goods between contracting states and not automatically to services-only orders or to states that reserved Part II.", "VAT, GST and sales-tax treatment of estimated tax on orders is regime-specific.", "UN/EDIFACT ORDERS remains widely used in global retail and manufacturing independently of Peppol.", "Public-sector buyers may be subject to EU procurement directives when using this BIS, as Peppol itself warns." ], "adversarial_checks": [ "Is any structural node presented as canonical without primary support? The blanket/standing/call-off vocabulary is the weakest point; it is deliberately split into a coded order type (SRC-001) plus a commitment pattern, with the terminology inconsistency recorded as a conflict citing a secondary source, rather than asserted as a controlled list.", "Does the model duplicate a sibling? Fulfilment events, invoice content, quotation pricing and contract clause bodies were each tested for leakage and pushed out to WM-ECO-024, the settlement model, WM-ECO-021 and WM-ECO-006 respectively; only linking references and the terms that create obligations remain here, and boundary notes state the distinction for each.", "Does the model assume acceptance is automatic on issuance? Explicitly not: FAR treats the order as a unilateral offer, so the state model separates issued from accepted, provides acceptance by performance as a distinct function, and a policy forbids reporting a contract as formed on issuance alone.", "Does the model smuggle format into semantics? Profile and customization identifiers, UBL element names and the 'NA' filler convention are confined to the interoperability layer and the projection function; the canonicalisation rules explicitly treat syntax fillers as projection artefacts that must not be read back into the source.", "Could a date be doing an identifier's job anywhere? Identity priority forbids date-bearing identifiers, the serial naming rule forbids date, fiscal period or year components in sequence numbers, and revision currency is expressed by an effective-from timestamp plus a supersession chain rather than by comparing issue dates.", "Is the retention claim overstated? The cited periods are US federal contractor obligations only. They are labelled as such in the regional assumptions, the conflict between the 3-year and 4-year rules is recorded, and commercial retention law is listed as a known omission rather than filled in by analogy.", "Would the model survive an order whose line has no coded item identifier? Yes: Peppol requires an item identifier and/or an item name, so the item finding asks what description is sufficient for a line to be fulfillable and provides a specification attachment artefact for bespoke items.", "Do not treat the seller sales-order identifier as the purchase-order identity.", "Do not treat an internal requisition or EDIFACT 105 document as the exchanged buyer-to-seller order.", "Do not claim CISG governs a services-only purchase order without evidence that the applicable law so provides.", "Do not treat silent non-response as acceptance unless a sourced practice or usage is recorded.", "Do not use issue date, delivery date or tax period as an identifier.", "Do not claim UBL or Peppol conformance unless the cited XSD and fatal business rules were actually evaluated.", "Do not collapse despatch advice, invoice or payment into this model because they carry an order reference.", "Do not treat cancellation as deletion of the retained original data message.", "Do not assume accept-with-change is allowed without a prior agreement on how buyer assent is obtained." ] }, "researchAdjudication": { "providerMode": "dual-provider", "activeProviders": [ "claude", "grok" ], "waivedProviders": [], "providerPolicy": {}, "boundaryDecision": { "entry_kind": "aggregate", "status": "accepted", "rationale": "Both providers independently converged on 'aggregate' for registry entry vr.wm-eco-019, and the reasoning holds under scrutiny: the order header is the aggregate root and order lines carry no identity outside it, so lines cannot be addressed, versioned or retained independently. The registry's 'standalone-mm' entry is expressed as an aggregate rather than reclassified. The boundary is drawn at the exchanged buyer-to-seller commitment: quotation content goes to WM-ECO-021, fulfilment execution events to WM-ECO-024, clause bodies and framework negotiation to WM-ECO-006, and invoice, tax breakdown and payment to the settlement model, with only typed references retained here. Grok's UN/EDIFACT document-name distinction is folded into the boundary rationale rather than the node set: code 105 denotes an internal enterprise purchase order and maps to an originator requisition reference, while this model is the exchanged commitment (UBL Order, typically code 220). Claude's out-of-scope entry for requisition and internal spend approval already excludes the 105 sense; the code-level trap is recorded so a synthesizer does not silently admit requisitions as order instances." }, "decisions": [ { "concept": "Base provider selection", "disposition": "Claude adopted as base", "rationale": "Selected on boundary quality, not node count. Claude supplies seven neighbour-specific boundary notes each with source refs, a clean in-scope/out-of-scope split, and an explicit aggregate-root rationale. Grok's structure blurs two seams by placing delivery terms inside a payment and accounting layer and by pulling obligation content into a line-composition-and-fulfilment bundle that leans into contained sibling WM-ECO-024." }, { "concept": "Entry kind", "disposition": "Accepted as aggregate", "rationale": "Independent convergence by both providers, and the underlying test is satisfied: order lines have no identity, version or retention life outside the header, so the header is the aggregate root rather than a container of standalone entities." }, { "concept": "Order validity window as offer expiry", "disposition": "Accepted from Grok into lifecycle-states-and-responses", "rationale": "Materially absent from the base, which handles response timeouts but not the stated ValidityPeriod that causes an offer to lapse. Evidence-backed in UBL and Peppol and non-duplicative of the base state model." }, { "concept": "Consignment and vendor-managed inventory replenishment patterns", "disposition": "Accepted from Grok into order-classification", "rationale": "Replaces the base's weakest support, a tier-4 encyclopaedia citation, with Peppol and UBL primary evidence, and closes a gap the base itself listed as a known omission including auto-issued consignment orders on stock withdrawal." }, { "concept": "Signature, attachment and integrity evidence", "disposition": "Accepted from Grok into provenance-and-audit-evidence", "rationale": "Directly fills the base's self-declared security gap with primary evidence, including the operationally important caveat that Peppol Ordering does not mandate eSignature so a conformant order may still carry no non-repudiation evidence." }, { "concept": "Grok seller-response-lifecycle finding", "disposition": "Rejected as duplicative", "rationale": "The base already carries order-state-model-and-transitions and order-response-and-acceptance-semantics with the full Peppol header and line code set, multiple-response handling and acceptance by performance. Admitting this would create two competing state accounts in one model." }, { "concept": "Grok access-privacy-and-retention finding", "disposition": "Rejected as duplicative; MLEC retention basis deferred", "rationale": "It overlaps two base findings, retention-and-disposition and access-and-commercial-confidentiality, so importing it whole would duplicate a layer. Its one materially additive element, the UNCITRAL MLEC art. 10 requirement to retain a data message in accessible integrity-preserving form, is genuinely absent from the base's US-FAR-only retention and is carried to deferred research instead of smuggled in behind duplicate structure." }, { "concept": "Grok related-document-graph finding", "disposition": "Rejected as substantially covered", "rationale": "The base distributes this coverage across framework-agreement-and-clause-references, the provenance content-origin question naming requisition, quotation and catalogue, and BT-13/BT-14 downstream reference integrity. Only the Project and Catalogue typed references are genuinely new, which is too thin to justify a finding and is deferred instead." }, { "concept": "Grok master-order-identity finding", "disposition": "Rejected as duplicative; CopyIndicator deferred", "rationale": "The base's order-identifier-and-scheme already establishes buyer number as operative identity with UUID and seller sales-order alias. The one unmatched element, the UBL copy indicator distinguishing an original issued order from a copy, is deferred as an attribute-level question rather than admitted as structure." }, { "concept": "Syntax names inside artifact media_or_form", "disposition": "Base format-neutral naming retained", "rationale": "Grok names UBL Order, Peppol T01 and EDIFACT LIN groups directly in artifact forms. The base confines syntax to the interoperability layer and the projection function, which better preserves the shared rule that format must not leak into semantics; the merged model keeps the base convention for all accepted nodes." }, { "concept": "Incoterms treatment", "disposition": "Base treatment retained", "rationale": "The base cites the ICC source and models the trade term as a code plus edition plus named place with risk transfer distinguished from title transfer. Grok explicitly did not fetch the ICC text and treats CIF/FOB/EXW only as UBL example alignments, so the base account is better grounded." }, { "concept": "UN/EDIFACT 105 versus 220 document-name trap", "disposition": "Folded into boundary rationale, not admitted as a node", "rationale": "The clarification that code 105 is an internal enterprise purchase order while the exchanged commitment is typically 220 protects the model boundary, but it is boundary-note material rather than a finding, and the base already excludes requisitions from scope." }, { "concept": "Anticipated totals calculation function", "disposition": "Accepted from Grok", "rationale": "No base function computes or manifests monetary totals, leaving the base's own question about totals-versus-lines authority without an operation that produces the values it arbitrates." }, { "concept": "Contract conclusion function", "disposition": "Accepted from Grok", "rationale": "The base records acceptance modes but never fixes the moment of conclusion; separating reach-the-offeror timing from data-message dispatch and receipt is what makes the base's own prohibition on reporting formation at issuance enforceable." }, { "concept": "UBL full Order Response replace-whole-state semantics", "disposition": "Deferred, not resolved in this pass", "rationale": "Grok records that a full UBL Order Response proposes to replace the entire order while Peppol also permits partial and multiple responses. The base covers multiple responses but not replace-whole-state, and collapsing the two patterns would misstate one of them, so both must be modelled after verification." } ], "publicationHolds": [ "Source verification hold: all sixteen unique URLs across both packs must be re-fetched and version-pinned before publication. Specifically unresolved between the packs is the UNECE endpoint service.unece.org/trade/untdid/d99b/trmd/orders_c.htm, which the base pack reports as returning HTTP 403 while the Grok pack cites it as retrieved at D.99B revision 11 dated 1999-09-11; no EDIFACT alignment may be published until that retrieval is independently reproduced.", "Version-pin hold on Peppol releases: the same Peppol BIS Ordering 3.3 URL is labelled 'BIS Ordering 3.3' by one pack and 'November 2025 / DEV 2026-Q2 documentation' by the other, and the same BIS Billing 3.0 OrderReference URL is labelled 'May 2026 release' versus 'November 2025 Release'. The live release label and the profile's bound UBL version must be confirmed before any profile or customization identifier is stated as canonical.", "Authority-tier reconciliation hold: the packs disagree on whether OpenPeppol BIS Ordering and BIS Billing are tier 1 or tier 2 sources. Tier assignment drives how strongly Peppol-derived rules may be asserted and must be settled before publication.", "Multi-profile validation hold: the merged model has only been exercised against an EU/Peppol profile and a US federal FAR profile. It must additionally be run against a US commercial non-FAR buyer profile, a retail or manufacturing classic-EDI profile, and a services-procurement profile with milestone acceptance before any claim of cross-domain applicability is published.", "Retention scope hold: every retention period in the base derives from US federal contractor obligations under FAR 4.703, 4.705-1 and 4.705-3. Retention must not be published as a general rule until a jurisdiction-neutral basis and at least one national commercial-books regime are verified; the base pack itself lists commercial retention law as an unfilled omission.", "Tax representation hold: neither pack verified a source for tax determination on orders. Peppol's position that order TAX is informative and does not affect terms of trade must be published with the caveat that some tax administrations may still treat a stated amount as a representation, and no tax-document status may be claimed." ], "deferredResearch": [ "UN/EDIFACT ORDERS D.99B and ANSI ASC X12 850/855/860/865 mapping to the model's semantics. The base could not retrieve either (UNECE 403, x12.org did not expose the 850 transaction set) and X12 TR3 content is membership-gated, so classic EDI remains an alignment gap rather than a modelled node; this is the largest interoperability weakness in the merged model.", "UNCITRAL Model Law on Electronic Commerce art. 10 as a jurisdiction-neutral retention basis requiring data messages to be retained in accessible, integrity-preserving form with origin, destination and dispatch and receipt times, together with at least one national commercial-books retention regime, to break the merged model's dependence on US federal retention periods.", "Reconciliation of UBL full Order Response replace-entire-order-state semantics against Peppol partial acceptance and multiple responses per order, so both patterns are represented without collapsing either into the other.", "Typed related-document references for Catalogue and Project on the order, plus UBL CopyIndicator original-versus-copy semantics, both present in the Grok pack but too narrow to admit as structure in this pass.", "Tax determination on orders including VAT category codes, reverse charge and place-of-supply rules, for which neither provider verified any primary source.", "Services procurement modelled distinctly from goods, covering statements of work, milestone-based acceptance and progress payments, which the base currently treats identically to goods at line level.", "Public-sector order metadata including procurement procedure reference, CPV or UNSPSC classification obligations and contract award notice linkage, absent from both packs.", "Electronic signature and sealing formats for orders and the legal weight of each beyond the UBL XAdES and Peppol non-mandate facts merged in this pass, including transport security, non-repudiation levels and key management for sealed revisions." ] }, "statistics": { "sources": 16, "bundles": 6, "layers": 14, "findings": 27, "questions": 102, "artifacts": 18, "functions": 15 } }