# Vercy AI instruction - YAML 1.2 (JSON-compatible)
{
  "vercy": "1.0-draft",
  "publication": {
    "status": "published",
    "adjudicationStatus": "reviewable-draft",
    "publishableCanonical": false,
    "generatedAt": "2026-08-29T13:11:16Z",
    "synthesisSha256": "df6fcfb7256248f972c023b82964a190247234fe12fa0bf874505e5fae2ff775",
    "providerMode": "single-provider-waiver",
    "providers": [
      "Claude"
    ],
    "waivedProviders": [
      "Grok"
    ]
  },
  "metaModel": {
    "id": "WM-ACT-031",
    "registryId": "vr.wm-act-031",
    "name": "Milestone / Deliverable",
    "version": "0.3.0-research.1",
    "previousVersions": [],
    "entryKind": "entity",
    "family": "World Models",
    "category": "Activities and processes",
    "industry": [
      "Cross-industry"
    ],
    "domain": [
      "ACT.MIL"
    ],
    "tags": [
      "milestone",
      "deliverable",
      "act.mil"
    ],
    "status": "published"
  },
  "canonicalUrl": "https://ver.cy/models/wm-act-031-milestone-deliverable/",
  "sourceUrl": "https://github.com/ver-cy/world-models/tree/feat/mega-model-registry/research/runs/wm-act-031",
  "model": {
    "registry_id": "vr.wm-act-031",
    "model_id": "WM-ACT-031",
    "name": "Milestone / Deliverable",
    "entry_kind": "entity",
    "purpose": "Represent a planned achievement (milestone) and an accepted output (deliverable) as governed records inside a project or programme, so an agent can define, schedule, produce, verify, accept, report and retire them without owning project, schedule-network, contract, approval-engine or repository semantics.",
    "scope_statement": "This model covers the record of a single milestone or deliverable: its identity and designation, its typology and definitional scope, its baseline/forecast/actual date commitments, its position against stages and gates, the parties accountable for producing it, its composition and artifact manifest, its declared acceptance criteria and means of verification, the recorded acceptance outcome and evidence reference, its status lifecycle, its provenance and revision lineage, its sensitivity/dissemination classification, and its mappings to external delivery-reporting standards. It deliberately stops at the record boundary: schedule calculation, approval execution, file storage, contractual remedy and audit-trail keeping belong to referenced models.",
    "in_scope": [
      "Milestone record: control point that charts progress, normally zero-duration, with baseline planned, forecast and actual dates and a met/not-met status",
      "Deliverable record: unique and verifiable output submitted for acceptance, with type, dissemination level, due date, submission and acceptance dates",
      "Declared acceptance criteria and means of verification attached to the record",
      "Recorded acceptance outcome (accepted, rejected, conditionally accepted) and the reference to acceptance evidence produced by the accepting authority",
      "Composition of a deliverable into sub-deliverables and its artifact manifest with media/form and integrity digests",
      "Status lifecycle, delay/variance explanation, supersession, grouping and cancellation of the record",
      "Sensitivity and dissemination classification of the record and its artifacts",
      "Provenance of generation, attribution and revision lineage",
      "External identifier bindings and alignment mappings to delivery-reporting standards"
    ],
    "out_of_scope": [
      "Project charter, business case, objectives, funding decisions and overall project lifecycle (owned by WM-ACT-005 Project)",
      "Schedule network logic, activity durations, calendars, float and critical-path calculation (owned by the schedule/activity model; this model only references the driving activity and carries a criticality flag)",
      "Execution of approval or gate decisions, delegation chains and the decision audit trail (owned by the approval/decision-authority model)",
      "Inspection, test and quality-assurance execution and the resulting inspection records (owned by the quality/verification model)",
      "Contract formation, payment triggers, warranty and remedy for latent defect or fraud (owned by the contract/agreement model)",
      "Physical storage, versioning, replication and retention execution of files (owned by the document/artifact repository model)",
      "Outcome and benefit realisation measurement after outputs are used (owned by the benefits/outcome model)",
      "Party, organisation and role registries (owned by the party model)",
      "Requirement catalogues and requirement traceability matrices (owned by the requirement/specification model)",
      "Runtime access-control enforcement and access audit records"
    ],
    "boundary_notes": [
      {
        "neighbor": "WM-ACT-005 Project (parent, CONTAINS)",
        "distinction": "The project owns objectives, stages, funding, assurance planning and controlled closure; this model owns one delivery record within that structure. GovS 002 requires that a project comprise stages preceded by gates and that deliverables and milestones be defined and agreed for all stages: the stage/gate structure is the project's, the individual milestone record is this model's.",
        "source_refs": [
          "SRC-009",
          "SRC-011"
        ]
      },
      {
        "neighbor": "Schedule / activity-network model",
        "distinction": "GAO best practice treats activities (with duration, logic, resources and float) and milestones (zero-duration events) as distinct schedule objects. Sequencing, duration estimation, critical-path and schedule-risk calculation stay in the schedule model; this model carries only the milestone's baseline/forecast/actual dates, a criticality flag and a reference to the driving activity or work package.",
        "source_refs": [
          "SRC-004",
          "SRC-010"
        ]
      },
      {
        "neighbor": "Approval / decision-authority model",
        "distinction": "FAR 46.502 makes acceptance the act of an authorised representative, and delegation of that responsibility binds the accepting party. This model records who the acceptance authority reference is and what outcome was recorded; it does not evaluate criteria, execute the decision, resolve delegation, or keep the decision audit trail.",
        "source_refs": [
          "SRC-001",
          "SRC-009"
        ]
      },
      {
        "neighbor": "Document / artifact repository model",
        "distinction": "The repository owns byte storage, format conversion, versioning and physical disposition. This model carries the artifact manifest: reference, media type, language, publication date and integrity digest, following the OCDS Document pattern and RFC 9530 digest semantics.",
        "source_refs": [
          "SRC-005",
          "SRC-012"
        ]
      },
      {
        "neighbor": "Contract / agreement model",
        "distinction": "FAR 46.501 gives acceptance a contractual effect (acknowledgment of conformance, subject to latent-defect and fraud exceptions). The legal consequence, payment trigger and remedy belong to the contract model; this model records the acceptance event reference and the clause citation only.",
        "source_refs": [
          "SRC-001"
        ]
      },
      {
        "neighbor": "Quality / verification model",
        "distinction": "NASA life-cycle reviews use entrance and success criteria evaluated by review boards. This model declares the acceptance criteria and means of verification attached to a record and points at the verification evidence; it does not run reviews, tests or inspections nor own their results.",
        "source_refs": [
          "SRC-011",
          "SRC-009"
        ]
      },
      {
        "neighbor": "Benefits / outcome model",
        "distinction": "GovS 002 separates output (product created), outcome (state after outputs are used) and benefit (measurable value). This model stops at the output/achievement record; outcome and benefit measurement are modelled elsewhere and only referenced.",
        "source_refs": [
          "SRC-009"
        ]
      }
    ]
  },
  "sources": [
    {
      "id": "SRC-001",
      "title": "Federal Acquisition Regulation, Part 46 — Quality Assurance",
      "organization": "U.S. General Services Administration / FAR Council (Acquisition.gov)",
      "url": "https://www.acquisition.gov/far/part-46",
      "version_or_date": "Current consolidated FAR text as published on Acquisition.gov, accessed 2026-08-29",
      "source_type": "legislation",
      "primary_source": true,
      "authority_tier": 1,
      "accessed_at": "2026-08-29T00:00:00Z",
      "relevance": "Normative definition of acceptance (46.101), when acceptance occurs and how it is evidenced (46.501), who may accept (46.502), place of acceptance (46.503), certificates of conformance (46.504) and the latent-defect/fraud limits on the effect of acceptance."
    },
    {
      "id": "SRC-002",
      "title": "Continuous reporting on milestones & deliverables — EU Funding & Tenders Online Manual",
      "organization": "European Commission",
      "url": "https://webgate.ec.europa.eu/funding-tenders-opportunities/spaces/OM/pages/1867968/Continuous+reporting+on+milestones+deliverables",
      "version_or_date": "Online Manual page, last modified 2021-06-04",
      "source_type": "public-authority",
      "primary_source": true,
      "authority_tier": 1,
      "accessed_at": "2026-08-29T00:00:00Z",
      "relevance": "Defines milestones as control points that chart progress and deliverables as outputs to be submitted; requires achievement status plus estimated completion date when a milestone is not achieved, and explanations for missing, late, cancelled or grouped deliverables; describes periodic snapshots of continuously reported data."
    },
    {
      "id": "SRC-003",
      "title": "Completing the Deliverables — EU Funding & Tenders IT How To",
      "organization": "European Commission",
      "url": "https://webgate.ec.europa.eu/funding-tenders-opportunities/spaces/IT/pages/19693685/Completing+the+Deliverables",
      "version_or_date": "IT How To guidance page, accessed 2026-08-29",
      "source_type": "first-party-doc",
      "primary_source": true,
      "authority_tier": 1,
      "accessed_at": "2026-08-29T00:00:00Z",
      "relevance": "Concrete deliverable record fields (number/name, work package, lead beneficiary, dissemination level, due date with revision, delivery date, approval date, status, uploaded file, delay justification); status set Pending / Draft / Submitted / Accepted or Rejected; one file per deliverable with a fixed format list; classified-information exception; submission restricted to coordinator contacts."
    },
    {
      "id": "SRC-004",
      "title": "GAO Schedule Assessment Guide: Best Practices for Project Schedules (GAO-16-89G)",
      "organization": "U.S. Government Accountability Office",
      "url": "https://www.gao.gov/products/gao-16-89g",
      "version_or_date": "GAO-16-89G, published 2015-12-22",
      "source_type": "public-authority",
      "primary_source": true,
      "authority_tier": 1,
      "accessed_at": "2026-08-29T00:00:00Z",
      "relevance": "Best practices for reliable schedules: capturing all activities, sequencing, resources, durations, baselining, critical path, float, schedule risk analysis and progress updates; establishes the activity/milestone distinction and the role of a baseline against which performance is measured."
    },
    {
      "id": "SRC-005",
      "title": "Open Contracting Data Standard 1.1.5 — Schema reference (Milestone and Document building blocks)",
      "organization": "Open Contracting Partnership",
      "url": "https://standard.open-contracting.org/latest/en/schema/reference/",
      "version_or_date": "OCDS version 1.1.5",
      "source_type": "schema",
      "primary_source": true,
      "authority_tier": 2,
      "accessed_at": "2026-08-29T00:00:00Z",
      "relevance": "Machine-readable milestone structure: id, title, type, description, code, dueDate, dateMet, dateModified, status; and Document structure: id, documentType, title, description, url, datePublished, dateModified, format (IANA media types), language (ISO 639-1 / BCP 47)."
    },
    {
      "id": "SRC-006",
      "title": "Open Contracting Data Standard 1.1.5 — Codelists (milestoneStatus, milestoneType, documentType)",
      "organization": "Open Contracting Partnership",
      "url": "https://standard.open-contracting.org/latest/en/schema/codelists/",
      "version_or_date": "OCDS version 1.1.5",
      "source_type": "classifier",
      "primary_source": true,
      "authority_tier": 2,
      "accessed_at": "2026-08-29T00:00:00Z",
      "relevance": "Closed milestoneStatus codelist (scheduled, met, notMet, partiallyMet), open milestoneType codelist (preProcurement, approval, engagement, assessment, delivery, reporting, financing, payment) and documentType values such as completionCertificate, physicalProgressReport and finalAudit."
    },
    {
      "id": "SRC-007",
      "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-29T00:00:00Z",
      "relevance": "Normative timestamp grammar requiring a seconds element and an explicit time-offset of 'Z' or +/-HH:MM, and the '-00:00' convention for an unknown local offset; basis for the model's timestamp rule."
    },
    {
      "id": "SRC-008",
      "title": "PROV-O: The PROV Ontology",
      "organization": "World Wide Web Consortium (W3C)",
      "url": "https://www.w3.org/TR/prov-o/",
      "version_or_date": "W3C Recommendation, 30 April 2013; namespace http://www.w3.org/ns/prov#",
      "source_type": "ontology",
      "primary_source": true,
      "authority_tier": 1,
      "accessed_at": "2026-08-29T00:00:00Z",
      "relevance": "Entity/Activity/Agent starting-point classes with wasGeneratedBy, used, wasAttributedTo, wasAssociatedWith, wasDerivedFrom, actedOnBehalfOf, startedAtTime/endedAtTime and the qualified Generation, Attribution, Association, Derivation and Revision terms used for deliverable provenance and lineage."
    },
    {
      "id": "SRC-009",
      "title": "Government Functional Standard GovS 002: Project delivery",
      "organization": "UK Government Project Delivery Function (Cabinet Office / NISTA)",
      "url": "https://projectdelivery.gov.uk/library-products/government-functional-standard-govs-002-project-delivery/",
      "version_or_date": "Version 2.1, published 2025-09-01 (page last modified 2026-03-29)",
      "source_type": "standard",
      "primary_source": true,
      "authority_tier": 1,
      "accessed_at": "2026-08-29T00:00:00Z",
      "relevance": "Definitions of output, outcome, benefit and deliverable; requirement that a project comprise stages each preceded by a gate; that changes to a baselined plan be controlled with named change authority (7.7); that assurance reviews precede significant decisions and gates (4.2.3); and that closure be controlled with confirmation of outputs delivered and transfer of residual responsibilities (6.4.8, 8.8)."
    },
    {
      "id": "SRC-010",
      "title": "Programme and project data standard (HTML)",
      "organization": "UK Government Project Delivery Function (NISTA)",
      "url": "https://projectdelivery.gov.uk/library-products/programme-and-project-data-standard-html/",
      "version_or_date": "Published 2025-12-11, status: under consultation",
      "source_type": "schema",
      "primary_source": true,
      "authority_tier": 2,
      "accessed_at": "2026-08-29T00:00:00Z",
      "relevance": "Named milestone data fields with definitions and update frequency (Milestone ID, title, planned/baseline date, forecast date, actual date, category, status, description, critical status, restricted status, protected status, comment), the status value set On track / Off track / Completed / Superseded, the category set Assurance / Delivery / Business case, and validation rules including 'actual date must be on or before today'."
    },
    {
      "id": "SRC-011",
      "title": "NPR 7120.5F — NASA Space Flight Program and Project Management Requirements, Chapter 2",
      "organization": "National Aeronautics and Space Administration (NASA)",
      "url": "https://nodis3.gsfc.nasa.gov/displayDir.cfm?Internal_ID=N_PR_7120_005F_&page_name=Chapter2",
      "version_or_date": "NPR 7120.5F w/Change 4, effective 2021-08-03, expiration 2027-02-03",
      "source_type": "public-authority",
      "primary_source": true,
      "authority_tier": 1,
      "accessed_at": "2026-08-29T00:00:00Z",
      "relevance": "Decision-gate semantics: Key Decision Points A-F where a Decision Authority determines readiness to progress; life-cycle reviews (MCR, SRR, PDR, CDR, ORR, DR) assessed against defined criteria; required authority documents per phase; and the Agency Baseline Commitment as the baseline against which performance is measured, with rebaselining thresholds."
    },
    {
      "id": "SRC-012",
      "title": "RFC 9530 — Digest Fields",
      "organization": "Internet Engineering Task Force (IETF)",
      "url": "https://www.rfc-editor.org/rfc/rfc9530.html",
      "version_or_date": "RFC 9530, Standards Track, February 2024",
      "source_type": "standard",
      "primary_source": true,
      "authority_tier": 1,
      "accessed_at": "2026-08-29T00:00:00Z",
      "relevance": "Content-Digest and Repr-Digest fields, the IANA 'Hash Algorithms for HTTP Digest Fields' registry with Active/Deprecated status, and the explicit limitation that digests detect corruption across hops but do not by themselves protect against malicious tampering; basis for the artifact integrity rule."
    }
  ],
  "structure": {
    "bundles": [
      {
        "id": "identity-and-definition",
        "name": "Identity and definition",
        "description": "What this record is, how it is uniquely designated, and whether it is a planned achievement, an accepted output, or both.",
        "rationale": "Delivery data standards require a unique, stable milestone or deliverable identifier and a definitional statement before any date, status or acceptance data is meaningful; conflating milestone and deliverable is the most common modelling error in this domain.",
        "source_refs": [
          "SRC-002",
          "SRC-005",
          "SRC-010"
        ],
        "layers": [
          {
            "id": "identity-and-naming",
            "name": "Identity and naming",
            "description": "Stable identification and human-facing designation of the record within and beyond its owning project.",
            "source_refs": [
              "SRC-005",
              "SRC-010"
            ],
            "findings": [
              {
                "id": "record-identity",
                "name": "Record identity and identifier scope",
                "description": "How a milestone or deliverable record is uniquely identified, at what scope that identifier is unique, and how locally scoped numbering relates to organisation-wide or global identifiers.",
                "source_refs": [
                  "SRC-005",
                  "SRC-010",
                  "SRC-003"
                ],
                "questions": [
                  {
                    "id": "q-identity-authoritative",
                    "text": "Which system holds the authoritative identifier for this milestone or deliverable record, and what is that identifier?",
                    "kind": "identity",
                    "answer_data": [
                      "master system name or code",
                      "authoritative identifier value",
                      "identifier issuance date-time"
                    ]
                  },
                  {
                    "id": "q-identity-scope",
                    "text": "At what scope is the identifier guaranteed unique: within the work package, within the project, or across the whole organisation?",
                    "kind": "constraint",
                    "answer_data": [
                      "uniqueness scope code",
                      "scope owner reference",
                      "collision-handling rule reference"
                    ]
                  },
                  {
                    "id": "q-identity-alternates",
                    "text": "What alternate or legacy identifiers refer to the same record, and which of them are safe to publish?",
                    "kind": "interoperability",
                    "answer_data": [
                      "alternate identifier list with issuing scheme",
                      "publishable flag per identifier",
                      "supersedes/superseded-by identifier links"
                    ]
                  },
                  {
                    "id": "q-identity-stability",
                    "text": "Under what circumstances may the identifier change, and what must happen to references if it does?",
                    "kind": "lifecycle",
                    "answer_data": [
                      "identifier immutability rule",
                      "retired identifier register entry",
                      "reference-repair obligation reference"
                    ]
                  }
                ],
                "data_elements": [
                  {
                    "id": "de-record-id",
                    "name": "Record identifier",
                    "description": "Authoritative identifier for the milestone or deliverable record, unique at a declared scope; the UK data standard requires a unique alphanumeric milestone code, OCDS requires uniqueness within the containing block.",
                    "value_kind": "identifier",
                    "cardinality": "1",
                    "required": true,
                    "source_refs": [
                      "SRC-005",
                      "SRC-010"
                    ]
                  },
                  {
                    "id": "de-identifier-scope",
                    "name": "Identifier uniqueness scope",
                    "description": "Declared scope within which the identifier is unique (work package, project, organisation, global).",
                    "value_kind": "code",
                    "cardinality": "1",
                    "required": true,
                    "source_refs": [
                      "SRC-005",
                      "SRC-010"
                    ]
                  },
                  {
                    "id": "de-alternate-ids",
                    "name": "Alternate identifiers",
                    "description": "Identifiers for the same record issued by other schemes, each qualified by issuing scheme and publishability.",
                    "value_kind": "collection",
                    "cardinality": "0..n",
                    "required": false,
                    "source_refs": [
                      "SRC-003",
                      "SRC-005"
                    ]
                  }
                ],
                "artifacts": [],
                "inline_only_rationale": "Identity is reference data carried on the record itself; no separate artifact is produced, and identifier minting for the adopting Dimension is governed by the dimension registry rather than by a deliverable file."
              },
              {
                "id": "designation-and-numbering",
                "name": "Designation, numbering and titling",
                "description": "The human-readable designation of the record: title, structured number derived from work-package position, and free-text description that distinguishes it from neighbouring records.",
                "source_refs": [
                  "SRC-003",
                  "SRC-005",
                  "SRC-010"
                ],
                "questions": [
                  {
                    "id": "q-designation-title",
                    "text": "What short title identifies this record to a reader who does not know its identifier?",
                    "kind": "definition",
                    "answer_data": [
                      "title text",
                      "language tag",
                      "title revision date-time"
                    ]
                  },
                  {
                    "id": "q-designation-number",
                    "text": "How is the display number constructed from the work-package or stage position, and who controls that numbering convention?",
                    "kind": "classification",
                    "answer_data": [
                      "display number string",
                      "numbering convention reference",
                      "numbering authority reference"
                    ]
                  },
                  {
                    "id": "q-designation-description",
                    "text": "What description states the content of this record beyond its title, and how detailed must it be to be unambiguous?",
                    "kind": "definition",
                    "answer_data": [
                      "description text",
                      "minimum-detail rule reference",
                      "distinguishing statement against sibling records"
                    ]
                  }
                ],
                "data_elements": [
                  {
                    "id": "de-title",
                    "name": "Title",
                    "description": "Brief summary that identifies the milestone or deliverable, as required by the UK milestone title field and OCDS milestone.title.",
                    "value_kind": "text",
                    "cardinality": "1",
                    "required": true,
                    "source_refs": [
                      "SRC-005",
                      "SRC-010"
                    ]
                  },
                  {
                    "id": "de-display-number",
                    "name": "Display number",
                    "description": "Structured, human-facing number such as an EU deliverable number derived from work-package position; distinct from the authoritative identifier.",
                    "value_kind": "text",
                    "cardinality": "0..1",
                    "required": false,
                    "source_refs": [
                      "SRC-003"
                    ]
                  },
                  {
                    "id": "de-description",
                    "name": "Description",
                    "description": "Narrative detail beyond the title, corresponding to the UK milestone description field and OCDS milestone.description.",
                    "value_kind": "text",
                    "cardinality": "0..1",
                    "required": false,
                    "source_refs": [
                      "SRC-005",
                      "SRC-010"
                    ]
                  }
                ],
                "artifacts": [],
                "inline_only_rationale": "Titles, numbers and descriptions are literal field values on the record; expressing them as artifacts would duplicate the record itself and fragment search."
              }
            ]
          },
          {
            "id": "typology-and-scope",
            "name": "Typology and definitional scope",
            "description": "Whether the record is a control point, a submitted output or both, and what its declared content boundary is.",
            "source_refs": [
              "SRC-002",
              "SRC-006",
              "SRC-009"
            ],
            "findings": [
              {
                "id": "milestone-deliverable-distinction",
                "name": "Milestone versus deliverable determination",
                "description": "Whether the record is a milestone (a control point charting progress, normally of zero duration, that may span several work packages), a deliverable (a discrete output submitted for acceptance), or a deliverable-linked milestone that carries both roles.",
                "source_refs": [
                  "SRC-002",
                  "SRC-004",
                  "SRC-009"
                ],
                "questions": [
                  {
                    "id": "q-kind-determination",
                    "text": "Is this record a control point, a submitted output, or a control point whose achievement is evidenced by a submitted output?",
                    "kind": "classification",
                    "answer_data": [
                      "record kind code (milestone | deliverable | deliverable-linked milestone)",
                      "determination rationale text",
                      "determining authority reference"
                    ]
                  },
                  {
                    "id": "q-kind-duration",
                    "text": "Does this record occupy elapsed time in the plan, or is it a zero-duration event marking completion of other work?",
                    "kind": "temporal",
                    "answer_data": [
                      "zero-duration flag",
                      "driving activity reference",
                      "elapsed-work ownership statement"
                    ]
                  },
                  {
                    "id": "q-kind-span",
                    "text": "Does this record belong to exactly one work package, or does it act as a convergence point across several?",
                    "kind": "composition",
                    "answer_data": [
                      "primary work-package reference",
                      "additional contributing work-package references",
                      "convergence rationale text"
                    ]
                  },
                  {
                    "id": "q-kind-submission",
                    "text": "Must something be submitted to an external party for this record to be complete, or is internal declaration of achievement sufficient?",
                    "kind": "requirement",
                    "answer_data": [
                      "submission-required flag",
                      "receiving party reference",
                      "internal-declaration rule reference"
                    ]
                  }
                ],
                "data_elements": [
                  {
                    "id": "de-record-kind",
                    "name": "Record kind",
                    "description": "Discriminator between milestone, deliverable and deliverable-linked milestone, following the EU distinction between control points and submitted outputs.",
                    "value_kind": "code",
                    "cardinality": "1",
                    "required": true,
                    "source_refs": [
                      "SRC-002",
                      "SRC-009"
                    ]
                  },
                  {
                    "id": "de-zero-duration-flag",
                    "name": "Zero-duration flag",
                    "description": "Indicates the record is a schedule event rather than work with duration, consistent with GAO's separation of activities from milestones.",
                    "value_kind": "boolean",
                    "cardinality": "0..1",
                    "required": false,
                    "source_refs": [
                      "SRC-004"
                    ]
                  },
                  {
                    "id": "de-submission-required",
                    "name": "Submission required flag",
                    "description": "Whether completion requires submission of an output to a receiving party.",
                    "value_kind": "boolean",
                    "cardinality": "0..1",
                    "required": false,
                    "source_refs": [
                      "SRC-002",
                      "SRC-003"
                    ]
                  }
                ],
                "artifacts": [],
                "inline_only_rationale": "This is a typing decision expressed as coded fields and a rationale note; it produces no separate deliverable object of its own."
              },
              {
                "id": "type-and-category-classification",
                "name": "Type, category and purpose classification",
                "description": "Classification of the record by delivery purpose and by governance category, using controlled vocabularies that can be bound to external codelists.",
                "source_refs": [
                  "SRC-006",
                  "SRC-010",
                  "SRC-009"
                ],
                "questions": [
                  {
                    "id": "q-type-purpose",
                    "text": "What is the delivery purpose of this record, expressed against a controlled type vocabulary?",
                    "kind": "classification",
                    "answer_data": [
                      "purpose type code",
                      "vocabulary identifier and version",
                      "open or closed vocabulary flag"
                    ]
                  },
                  {
                    "id": "q-type-governance",
                    "text": "Which governance category does the record fall into: assurance gate, delivery point, or business-case decision?",
                    "kind": "authority",
                    "answer_data": [
                      "governance category code",
                      "associated gate or review reference",
                      "category assignment date-time"
                    ]
                  },
                  {
                    "id": "q-type-extension",
                    "text": "When no vocabulary code fits, how may the adopting Dimension extend the vocabulary without breaking exchange?",
                    "kind": "interoperability",
                    "answer_data": [
                      "extension namespace",
                      "extension code definition text",
                      "mapping to nearest standard code"
                    ]
                  }
                ],
                "data_elements": [
                  {
                    "id": "de-purpose-type",
                    "name": "Purpose type",
                    "description": "Coded delivery purpose; OCDS supplies an open milestoneType codelist (preProcurement, approval, engagement, assessment, delivery, reporting, financing, payment) suitable as a binding target.",
                    "value_kind": "code",
                    "cardinality": "0..n",
                    "required": false,
                    "source_refs": [
                      "SRC-006"
                    ]
                  },
                  {
                    "id": "de-governance-category",
                    "name": "Governance category",
                    "description": "Coded governance category; the UK data standard uses Assurance (gate reviews), Delivery and Business case.",
                    "value_kind": "code",
                    "cardinality": "0..1",
                    "required": false,
                    "source_refs": [
                      "SRC-010"
                    ]
                  }
                ],
                "artifacts": [],
                "inline_only_rationale": "Classification values are codes bound to external codelists held by their publishers; the model carries the binding, not a copy of the codelist as an artifact."
              },
              {
                "id": "definitional-scope-statement",
                "name": "Definitional scope and exclusions",
                "description": "The explicit statement of what the record includes and excludes, so that acceptance can be judged against a bounded content definition rather than an implied one.",
                "source_refs": [
                  "SRC-009",
                  "SRC-011",
                  "SRC-001"
                ],
                "questions": [
                  {
                    "id": "q-scope-inclusions",
                    "text": "What content or achievement is inside the declared boundary of this record?",
                    "kind": "definition",
                    "answer_data": [
                      "inclusion statement text",
                      "referenced requirement identifiers",
                      "scope agreement date-time"
                    ]
                  },
                  {
                    "id": "q-scope-exclusions",
                    "text": "What closely related content is explicitly excluded, and where does it belong instead?",
                    "kind": "constraint",
                    "answer_data": [
                      "exclusion statement text",
                      "owning record or model reference per exclusion"
                    ]
                  },
                  {
                    "id": "q-scope-change",
                    "text": "Who may change the declared scope after agreement, and what evidence of that change must the record carry?",
                    "kind": "authority",
                    "answer_data": [
                      "scope change authority reference",
                      "change decision reference",
                      "effective date-time of scope change"
                    ]
                  }
                ],
                "data_elements": [
                  {
                    "id": "de-scope-statement",
                    "name": "Scope statement",
                    "description": "Declared content boundary of the record, used as the frame for acceptance criteria.",
                    "value_kind": "text",
                    "cardinality": "1",
                    "required": true,
                    "source_refs": [
                      "SRC-009"
                    ]
                  },
                  {
                    "id": "de-scope-exclusions",
                    "name": "Declared exclusions",
                    "description": "Named items outside the boundary with a pointer to where they are owned.",
                    "value_kind": "collection",
                    "cardinality": "0..n",
                    "required": false,
                    "source_refs": [
                      "SRC-009"
                    ]
                  },
                  {
                    "id": "de-requirement-refs",
                    "name": "Requirement references",
                    "description": "References to requirement records the deliverable is intended to satisfy; the requirement text itself stays in the requirement model.",
                    "value_kind": "reference",
                    "cardinality": "0..n",
                    "required": false,
                    "source_refs": [
                      "SRC-009",
                      "SRC-011"
                    ]
                  }
                ],
                "artifacts": [],
                "inline_only_rationale": "The scope statement is definitional text on the record plus pointers to requirement records; the requirement specification itself is owned by the referenced requirement model."
              }
            ]
          }
        ]
      },
      {
        "id": "schedule-commitment",
        "name": "Schedule commitment and plan position",
        "description": "The date commitments carried by the record, its position against stages and gates, and how those commitments may be changed.",
        "rationale": "Every delivery data standard reviewed separates a baseline date that must not drift from a forecast date that is updated and an actual date recorded once; without that triad, variance reporting and gate readiness are undefined.",
        "source_refs": [
          "SRC-004",
          "SRC-005",
          "SRC-010",
          "SRC-011"
        ],
        "layers": [
          {
            "id": "date-commitments",
            "name": "Date commitments",
            "description": "Baseline, forecast and actual date values and the time semantics that make them comparable.",
            "source_refs": [
              "SRC-005",
              "SRC-007",
              "SRC-010"
            ],
            "findings": [
              {
                "id": "baseline-date-commitment",
                "name": "Baseline planned date commitment",
                "description": "The initial committed completion date, the baseline it belongs to, and the rule that it does not change outside a controlled rebaselining.",
                "source_refs": [
                  "SRC-010",
                  "SRC-004",
                  "SRC-011"
                ],
                "questions": [
                  {
                    "id": "q-baseline-date",
                    "text": "What is the baseline planned completion date for this record, and which baseline version does it belong to?",
                    "kind": "temporal",
                    "answer_data": [
                      "baseline planned date",
                      "baseline version identifier",
                      "baseline approval reference"
                    ]
                  },
                  {
                    "id": "q-baseline-immutability",
                    "text": "What rule prevents the baseline date from being edited in place, and how is an attempted edit rejected?",
                    "kind": "constraint",
                    "answer_data": [
                      "immutability rule text",
                      "update frequency declaration (once)",
                      "rejection handling reference"
                    ]
                  },
                  {
                    "id": "q-baseline-source",
                    "text": "Which approved plan or commitment document established this baseline date?",
                    "kind": "provenance",
                    "answer_data": [
                      "source plan reference",
                      "commitment instrument reference",
                      "commitment date-time"
                    ]
                  }
                ],
                "data_elements": [
                  {
                    "id": "de-baseline-date",
                    "name": "Baseline planned date",
                    "description": "Initial date on which the record is planned to complete; the UK data standard states this is the baseline date, should not change, and is set once.",
                    "value_kind": "date",
                    "cardinality": "0..1",
                    "required": false,
                    "source_refs": [
                      "SRC-010"
                    ]
                  },
                  {
                    "id": "de-baseline-version",
                    "name": "Baseline version reference",
                    "description": "Reference to the approved baseline the date belongs to, such as an agency baseline commitment established at a decision gate.",
                    "value_kind": "reference",
                    "cardinality": "0..1",
                    "required": false,
                    "source_refs": [
                      "SRC-011",
                      "SRC-004"
                    ]
                  }
                ],
                "artifacts": [],
                "inline_only_rationale": "The baseline date is a scalar commitment on the record; the approved baseline plan itself is a document owned by the project and schedule models and is referenced, not embedded."
              },
              {
                "id": "forecast-and-actual-dates",
                "name": "Forecast, due and actual dates",
                "description": "The currently expected completion date, any externally binding due date, and the recorded actual achievement or delivery date, together with their update cadences.",
                "source_refs": [
                  "SRC-003",
                  "SRC-005",
                  "SRC-010"
                ],
                "questions": [
                  {
                    "id": "q-forecast-current",
                    "text": "What is the current forecast completion date, and when was it last revised?",
                    "kind": "temporal",
                    "answer_data": [
                      "forecast date",
                      "forecast revision date-time",
                      "revision reason code"
                    ]
                  },
                  {
                    "id": "q-due-binding",
                    "text": "Is there a contractually or grant-binding due date distinct from the internal forecast, and may it be revised?",
                    "kind": "constraint",
                    "answer_data": [
                      "due date",
                      "binding instrument reference",
                      "due-date revision permission flag"
                    ]
                  },
                  {
                    "id": "q-actual-recording",
                    "text": "What actual date is recorded for achievement or delivery, and what validation applies to it?",
                    "kind": "event",
                    "answer_data": [
                      "actual date",
                      "validation rule (not later than current date)",
                      "recording party reference"
                    ]
                  },
                  {
                    "id": "q-date-multiplicity",
                    "text": "Which distinct dates must be kept separate for this record: delivery, approval, and achievement?",
                    "kind": "temporal",
                    "answer_data": [
                      "delivery date",
                      "approval date",
                      "achievement date",
                      "separation rationale text"
                    ]
                  }
                ],
                "data_elements": [
                  {
                    "id": "de-forecast-date",
                    "name": "Forecast date",
                    "description": "Date on which the record is currently expected to complete; updated on change.",
                    "value_kind": "date",
                    "cardinality": "0..1",
                    "required": false,
                    "source_refs": [
                      "SRC-010"
                    ]
                  },
                  {
                    "id": "de-due-date",
                    "name": "Due date",
                    "description": "Externally scheduled completion date, corresponding to OCDS milestone.dueDate and the EU deliverable due date, which may be revised where the instrument permits.",
                    "value_kind": "date",
                    "cardinality": "0..1",
                    "required": false,
                    "source_refs": [
                      "SRC-003",
                      "SRC-005"
                    ]
                  },
                  {
                    "id": "de-actual-date",
                    "name": "Actual completion date",
                    "description": "Date the record was completed or met, corresponding to OCDS milestone.dateMet and the UK milestone actual date, constrained to be no later than the current date.",
                    "value_kind": "date",
                    "cardinality": "0..1",
                    "required": false,
                    "source_refs": [
                      "SRC-005",
                      "SRC-010"
                    ]
                  },
                  {
                    "id": "de-delivery-and-approval-dates",
                    "name": "Delivery and approval date-times",
                    "description": "Separate date-times for submission of a deliverable and for the acceptance decision recorded against it, as distinguished in EU continuous reporting.",
                    "value_kind": "timestamp",
                    "cardinality": "0..n",
                    "required": false,
                    "source_refs": [
                      "SRC-003"
                    ]
                  }
                ],
                "artifacts": [],
                "inline_only_rationale": "These are scalar temporal values on the record; the schedule model owns the network calculation that produces forecasts and this model stores only the resulting values."
              },
              {
                "id": "time-semantics",
                "name": "Time value semantics and precision",
                "description": "How date and timestamp values are expressed, whether a value is a calendar date or an instant, and how event time is distinguished from the time the fact was observed or ingested.",
                "source_refs": [
                  "SRC-007",
                  "SRC-005",
                  "SRC-002"
                ],
                "questions": [
                  {
                    "id": "q-time-format",
                    "text": "In what format and precision is each temporal value recorded, and what offset is attached?",
                    "kind": "constraint",
                    "answer_data": [
                      "value type (calendar date or instant)",
                      "RFC 3339 formatted value",
                      "offset or Z designator"
                    ]
                  },
                  {
                    "id": "q-time-event-vs-observation",
                    "text": "When did the achievement actually occur, and when was that fact recorded in the system?",
                    "kind": "provenance",
                    "answer_data": [
                      "event date-time",
                      "observation or ingestion timestamp",
                      "recording actor reference"
                    ]
                  },
                  {
                    "id": "q-time-unknown-offset",
                    "text": "How is a timestamp recorded when the instant is known in UTC but the local offset is not?",
                    "kind": "exception",
                    "answer_data": [
                      "unknown-offset convention (-00:00)",
                      "fallback precision statement",
                      "data quality flag"
                    ]
                  },
                  {
                    "id": "q-time-snapshot",
                    "text": "How are date values frozen when a reporting snapshot is taken, so that later revisions do not rewrite reported history?",
                    "kind": "temporal",
                    "answer_data": [
                      "snapshot identifier",
                      "snapshot timestamp",
                      "frozen value set reference"
                    ]
                  }
                ],
                "data_elements": [
                  {
                    "id": "de-event-timestamp",
                    "name": "Event timestamp",
                    "description": "RFC 3339 date-time with seconds and explicit offset for the moment the modelled event occurred.",
                    "value_kind": "timestamp",
                    "cardinality": "0..1",
                    "required": false,
                    "source_refs": [
                      "SRC-007"
                    ]
                  },
                  {
                    "id": "de-observation-timestamp",
                    "name": "Observation or ingestion timestamp",
                    "description": "RFC 3339 date-time recording when the fact entered this model, kept separate from event time.",
                    "value_kind": "timestamp",
                    "cardinality": "0..1",
                    "required": false,
                    "source_refs": [
                      "SRC-007",
                      "SRC-008"
                    ]
                  },
                  {
                    "id": "de-last-modified",
                    "name": "Record last-modified timestamp",
                    "description": "When the record was last reviewed or modified, mirroring OCDS milestone.dateModified.",
                    "value_kind": "timestamp",
                    "cardinality": "0..1",
                    "required": false,
                    "source_refs": [
                      "SRC-005"
                    ]
                  }
                ],
                "artifacts": [],
                "inline_only_rationale": "Time semantics are a serialization and precision contract over existing fields; there is no artifact, and the values themselves are already carried by the date findings."
              }
            ]
          },
          {
            "id": "plan-position",
            "name": "Plan position, criticality and baseline change",
            "description": "Where the record sits relative to stages, gates and the critical path, and how its committed dates may lawfully move.",
            "source_refs": [
              "SRC-004",
              "SRC-009",
              "SRC-011"
            ],
            "findings": [
              {
                "id": "gate-and-stage-association",
                "name": "Stage and decision-gate association",
                "description": "The stage the record belongs to and the decision gate or life-cycle review whose readiness it supports, without taking ownership of the gate decision itself.",
                "source_refs": [
                  "SRC-009",
                  "SRC-011",
                  "SRC-006"
                ],
                "questions": [
                  {
                    "id": "q-gate-which",
                    "text": "Which stage does this record belong to, and which gate or life-cycle review consumes it as evidence of readiness?",
                    "kind": "relationship",
                    "answer_data": [
                      "stage reference",
                      "gate or review reference",
                      "evidence role code"
                    ]
                  },
                  {
                    "id": "q-gate-criteria-ref",
                    "text": "Which entrance or success criteria of that gate does this record contribute to satisfying?",
                    "kind": "requirement",
                    "answer_data": [
                      "criteria identifiers",
                      "contribution statement text",
                      "criteria owner reference"
                    ]
                  },
                  {
                    "id": "q-gate-authority",
                    "text": "Who is the decision authority for the associated gate, and where is their decision recorded?",
                    "kind": "authority",
                    "answer_data": [
                      "decision authority reference",
                      "decision record reference in the approval model",
                      "decision date-time"
                    ]
                  }
                ],
                "data_elements": [
                  {
                    "id": "de-stage-ref",
                    "name": "Stage reference",
                    "description": "Reference to the project stage in which the record falls; stages and their gates are owned by the project model.",
                    "value_kind": "reference",
                    "cardinality": "0..1",
                    "required": false,
                    "source_refs": [
                      "SRC-009"
                    ]
                  },
                  {
                    "id": "de-gate-ref",
                    "name": "Gate or life-cycle review reference",
                    "description": "Reference to the decision point (for example a Key Decision Point or assurance gate) that consumes this record as readiness evidence.",
                    "value_kind": "reference",
                    "cardinality": "0..n",
                    "required": false,
                    "source_refs": [
                      "SRC-011",
                      "SRC-010"
                    ]
                  }
                ],
                "artifacts": [],
                "inline_only_rationale": "Only the association is modelled here; gate entrance and success criteria packages and the decision itself are owned by the project governance and approval models and are referenced."
              },
              {
                "id": "criticality-and-schedule-linkage",
                "name": "Criticality and schedule linkage",
                "description": "The record's declared criticality and its link to the driving schedule activity, kept as a reference so that network logic and float remain in the schedule model.",
                "source_refs": [
                  "SRC-004",
                  "SRC-010"
                ],
                "questions": [
                  {
                    "id": "q-crit-flag",
                    "text": "Is this record on the critical path as most recently calculated, and when was that determination made?",
                    "kind": "state",
                    "answer_data": [
                      "critical flag",
                      "determination timestamp",
                      "calculating system reference"
                    ]
                  },
                  {
                    "id": "q-crit-driver",
                    "text": "Which schedule activity or work package drives the completion of this record?",
                    "kind": "relationship",
                    "answer_data": [
                      "driving activity reference",
                      "work package reference",
                      "dependency type code"
                    ]
                  },
                  {
                    "id": "q-crit-consequence",
                    "text": "What is the declared consequence if this record slips, expressed without recomputing the schedule here?",
                    "kind": "constraint",
                    "answer_data": [
                      "consequence statement text",
                      "dependent record references",
                      "escalation route reference"
                    ]
                  }
                ],
                "data_elements": [
                  {
                    "id": "de-critical-flag",
                    "name": "Critical status flag",
                    "description": "Indicator that the milestone lies on the critical path, mirroring the UK milestone critical status field; the calculation itself belongs to the schedule model.",
                    "value_kind": "boolean",
                    "cardinality": "0..1",
                    "required": false,
                    "source_refs": [
                      "SRC-010",
                      "SRC-004"
                    ]
                  },
                  {
                    "id": "de-driving-activity-ref",
                    "name": "Driving activity reference",
                    "description": "Reference to the activity or work package whose completion the record marks.",
                    "value_kind": "reference",
                    "cardinality": "0..n",
                    "required": false,
                    "source_refs": [
                      "SRC-004"
                    ]
                  }
                ],
                "artifacts": [],
                "inline_only_rationale": "Criticality is a flag carried from a calculation performed elsewhere; storing schedule network artifacts here would duplicate the schedule model's ownership."
              },
              {
                "id": "baseline-change-control",
                "name": "Baseline change and rebaselining",
                "description": "How a committed baseline date or scope is lawfully changed: the change authority reference, the trigger threshold and the preservation of the superseded commitment.",
                "source_refs": [
                  "SRC-009",
                  "SRC-011",
                  "SRC-004"
                ],
                "questions": [
                  {
                    "id": "q-rebaseline-trigger",
                    "text": "What condition triggers a rebaseline of this record rather than a simple forecast revision?",
                    "kind": "decision",
                    "answer_data": [
                      "trigger condition text",
                      "threshold value and unit",
                      "threshold source reference"
                    ]
                  },
                  {
                    "id": "q-rebaseline-authority",
                    "text": "Which authority may approve a change to the baselined commitment, and where is that authority defined?",
                    "kind": "authority",
                    "answer_data": [
                      "change authority reference",
                      "authority definition reference",
                      "approval record reference"
                    ]
                  },
                  {
                    "id": "q-rebaseline-history",
                    "text": "How is the superseded baseline preserved so that historic variance remains reconstructible?",
                    "kind": "provenance",
                    "answer_data": [
                      "prior baseline value",
                      "supersession timestamp",
                      "retained baseline series reference"
                    ]
                  },
                  {
                    "id": "q-rebaseline-scope",
                    "text": "Does the change affect the date only, or also the declared scope and acceptance criteria?",
                    "kind": "composition",
                    "answer_data": [
                      "changed aspect codes",
                      "revised scope statement reference",
                      "revised criteria reference"
                    ]
                  }
                ],
                "data_elements": [
                  {
                    "id": "de-baseline-change-ref",
                    "name": "Baseline change reference",
                    "description": "Reference to the approved change that moved the baseline; GovS 002 requires changes to a baselined plan to be controlled by a named change authority.",
                    "value_kind": "reference",
                    "cardinality": "0..n",
                    "required": false,
                    "source_refs": [
                      "SRC-009"
                    ]
                  },
                  {
                    "id": "de-baseline-history",
                    "name": "Retained baseline series",
                    "description": "Ordered set of superseded baseline values with the timestamp at which each was replaced.",
                    "value_kind": "collection",
                    "cardinality": "0..n",
                    "required": false,
                    "source_refs": [
                      "SRC-011",
                      "SRC-004"
                    ]
                  }
                ],
                "artifacts": [],
                "inline_only_rationale": "The change request and its approval are records of the change-control and approval models; this model retains only the value history and the pointer to the authorising decision."
              }
            ]
          }
        ]
      },
      {
        "id": "production-and-form",
        "name": "Production responsibility and material form",
        "description": "Who is answerable for producing the record, what work produces it, how it decomposes, and what material or informational form it takes.",
        "rationale": "Acceptance is meaningless without a named producing party and an unambiguous manifest of what was tendered; funder portals and contracting schemas both bind a lead party and a file manifest to each deliverable.",
        "source_refs": [
          "SRC-003",
          "SRC-005",
          "SRC-001"
        ],
        "layers": [
          {
            "id": "responsibility-and-work-linkage",
            "name": "Responsibility and work linkage",
            "description": "The parties answerable for the record and the work structure that produces it.",
            "source_refs": [
              "SRC-003",
              "SRC-009"
            ],
            "findings": [
              {
                "id": "accountable-and-producing-parties",
                "name": "Accountable and producing parties",
                "description": "The single accountable party for the record, any contributing producers, and the party permitted to submit it, all held as references to a party model.",
                "source_refs": [
                  "SRC-003",
                  "SRC-009",
                  "SRC-008"
                ],
                "questions": [
                  {
                    "id": "q-party-accountable",
                    "text": "Which single party is accountable for this record being achieved or delivered?",
                    "kind": "ownership",
                    "answer_data": [
                      "accountable party reference",
                      "role code",
                      "accountability start date-time"
                    ]
                  },
                  {
                    "id": "q-party-contributors",
                    "text": "Which other parties contribute to producing the record, and in what capacity?",
                    "kind": "relationship",
                    "answer_data": [
                      "contributing party references",
                      "contribution role codes",
                      "contribution period"
                    ]
                  },
                  {
                    "id": "q-party-submitter",
                    "text": "Which party is permitted to submit the record to the receiving authority, and is that permission exclusive?",
                    "kind": "access",
                    "answer_data": [
                      "authorised submitter reference",
                      "exclusivity flag",
                      "permission source reference"
                    ]
                  },
                  {
                    "id": "q-party-change",
                    "text": "How is a change of accountable party recorded without losing the earlier attribution?",
                    "kind": "provenance",
                    "answer_data": [
                      "prior party reference",
                      "handover timestamp",
                      "handover rationale text"
                    ]
                  }
                ],
                "data_elements": [
                  {
                    "id": "de-accountable-party",
                    "name": "Accountable party reference",
                    "description": "Reference to the lead party accountable for the record, corresponding to the lead beneficiary field in EU continuous reporting.",
                    "value_kind": "reference",
                    "cardinality": "1",
                    "required": true,
                    "source_refs": [
                      "SRC-003"
                    ]
                  },
                  {
                    "id": "de-contributing-parties",
                    "name": "Contributing party references",
                    "description": "Other parties that contribute to production, each with a role code.",
                    "value_kind": "collection",
                    "cardinality": "0..n",
                    "required": false,
                    "source_refs": [
                      "SRC-003",
                      "SRC-008"
                    ]
                  },
                  {
                    "id": "de-authorised-submitter",
                    "name": "Authorised submitter reference",
                    "description": "Party permitted to submit the deliverable; EU portals restrict submission to coordinator contacts.",
                    "value_kind": "reference",
                    "cardinality": "0..1",
                    "required": false,
                    "source_refs": [
                      "SRC-003"
                    ]
                  }
                ],
                "artifacts": [],
                "inline_only_rationale": "Parties are references into a party/organisation model that owns their identity, contact data and role registry; this model stores only the binding and its validity period."
              },
              {
                "id": "work-package-linkage",
                "name": "Work package and activity linkage",
                "description": "How the record attaches to the work breakdown: its owning work package, contributing tasks, and any cross-package convergence.",
                "source_refs": [
                  "SRC-002",
                  "SRC-003",
                  "SRC-004"
                ],
                "questions": [
                  {
                    "id": "q-wp-owning",
                    "text": "Which work package owns this record, and which task within it produces the output?",
                    "kind": "composition",
                    "answer_data": [
                      "work package reference",
                      "task reference",
                      "ownership assertion date-time"
                    ]
                  },
                  {
                    "id": "q-wp-cross",
                    "text": "Which additional work packages must converge for this record to be achieved?",
                    "kind": "relationship",
                    "answer_data": [
                      "contributing work package references",
                      "convergence condition text"
                    ]
                  },
                  {
                    "id": "q-wp-effort",
                    "text": "Where is the effort and resource assignment for the producing work recorded, given it is not held here?",
                    "kind": "interoperability",
                    "answer_data": [
                      "schedule or resource model reference",
                      "linkage key",
                      "synchronisation rule"
                    ]
                  }
                ],
                "data_elements": [
                  {
                    "id": "de-work-package-ref",
                    "name": "Owning work package reference",
                    "description": "Reference to the work package to which a deliverable is tied; EU practice ties every deliverable to a work package and ideally to a task.",
                    "value_kind": "reference",
                    "cardinality": "0..1",
                    "required": false,
                    "source_refs": [
                      "SRC-002",
                      "SRC-003"
                    ]
                  },
                  {
                    "id": "de-contributing-wp-refs",
                    "name": "Contributing work package references",
                    "description": "Additional work packages a milestone spans when it acts as a cross-package checkpoint.",
                    "value_kind": "collection",
                    "cardinality": "0..n",
                    "required": false,
                    "source_refs": [
                      "SRC-002"
                    ]
                  }
                ],
                "artifacts": [],
                "inline_only_rationale": "Work packages, tasks, effort and resources are owned by the project and schedule models; only the linkage keys are held here to avoid duplicating the work breakdown."
              }
            ]
          },
          {
            "id": "composition-and-form",
            "name": "Composition and material form",
            "description": "How a deliverable decomposes and what tangible or informational artifacts constitute it.",
            "source_refs": [
              "SRC-003",
              "SRC-005",
              "SRC-012"
            ],
            "findings": [
              {
                "id": "deliverable-composition",
                "name": "Composition, grouping and part-whole structure",
                "description": "Whether the record is atomic or composed of sub-deliverables, how grouped deliverables are represented, and the rule for whether a parent is complete when only some parts are.",
                "source_refs": [
                  "SRC-002",
                  "SRC-006",
                  "SRC-009"
                ],
                "questions": [
                  {
                    "id": "q-comp-parts",
                    "text": "What sub-deliverables or component achievements make up this record?",
                    "kind": "composition",
                    "answer_data": [
                      "child record references",
                      "part role codes",
                      "required or optional flag per part"
                    ]
                  },
                  {
                    "id": "q-comp-completion-rule",
                    "text": "What rule determines whether the parent is complete, partially met, or not met given the state of its parts?",
                    "kind": "constraint",
                    "answer_data": [
                      "roll-up rule text",
                      "allowed parent status values",
                      "partially-met definition"
                    ]
                  },
                  {
                    "id": "q-comp-grouping",
                    "text": "When several planned deliverables are merged into one submission, how is that grouping recorded against the original plan entries?",
                    "kind": "exception",
                    "answer_data": [
                      "grouped-into record reference",
                      "grouping justification text",
                      "affected original entries"
                    ]
                  },
                  {
                    "id": "q-comp-cycles",
                    "text": "What prevents circular or contradictory part-whole links between records?",
                    "kind": "validation",
                    "answer_data": [
                      "acyclicity constraint statement",
                      "validation failure code",
                      "responsible validator reference"
                    ]
                  }
                ],
                "data_elements": [
                  {
                    "id": "de-child-records",
                    "name": "Component record references",
                    "description": "References to sub-deliverables or component milestones that constitute this record.",
                    "value_kind": "collection",
                    "cardinality": "0..n",
                    "required": false,
                    "source_refs": [
                      "SRC-009"
                    ]
                  },
                  {
                    "id": "de-grouping-note",
                    "name": "Grouping or merge note",
                    "description": "Explanation where deliverables are cancelled or grouped, which EU continuous reporting requires in the comments column.",
                    "value_kind": "text",
                    "cardinality": "0..1",
                    "required": false,
                    "source_refs": [
                      "SRC-002"
                    ]
                  },
                  {
                    "id": "de-rollup-rule",
                    "name": "Completion roll-up rule",
                    "description": "Declared rule mapping component states to the parent status value, including partially met.",
                    "value_kind": "text",
                    "cardinality": "0..1",
                    "required": false,
                    "source_refs": [
                      "SRC-006"
                    ]
                  }
                ],
                "artifacts": [],
                "inline_only_rationale": "Composition is a graph of references between records of this same model plus a roll-up rule; no separate artifact is produced by declaring structure."
              },
              {
                "id": "artifact-manifest-and-form",
                "name": "Artifact manifest, media form and integrity",
                "description": "The manifest of concrete artifacts that constitute or evidence the deliverable, including media type, language, publication date, format constraints imposed by the receiving system, and integrity digests.",
                "source_refs": [
                  "SRC-003",
                  "SRC-005",
                  "SRC-012"
                ],
                "questions": [
                  {
                    "id": "q-manifest-what",
                    "text": "Which concrete artifacts constitute or evidence this deliverable, and what is each one's media type and language?",
                    "kind": "composition",
                    "answer_data": [
                      "artifact references",
                      "IANA media type per artifact",
                      "BCP 47 or ISO 639-1 language tag per artifact"
                    ]
                  },
                  {
                    "id": "q-manifest-constraints",
                    "text": "What format, count or packaging constraints does the receiving system impose on the submission?",
                    "kind": "constraint",
                    "answer_data": [
                      "permitted format list",
                      "maximum artifact count",
                      "packaging rule such as single archive"
                    ]
                  },
                  {
                    "id": "q-manifest-integrity",
                    "text": "How can a consumer verify that a retrieved artifact is the exact one that was tendered?",
                    "kind": "evidence",
                    "answer_data": [
                      "digest algorithm identifier from the active registry",
                      "digest value",
                      "digest computation timestamp"
                    ]
                  },
                  {
                    "id": "q-manifest-nondigital",
                    "text": "Where the deliverable is physical or an event rather than a file, what stands in for the artifact manifest?",
                    "kind": "exception",
                    "answer_data": [
                      "non-digital form description",
                      "surrogate evidence artifact reference",
                      "location or place reference"
                    ]
                  }
                ],
                "data_elements": [
                  {
                    "id": "de-artifact-refs",
                    "name": "Artifact references",
                    "description": "Ordered references to artifacts constituting the deliverable, following the OCDS Document pattern of id, title, url, format and language.",
                    "value_kind": "collection",
                    "cardinality": "0..n",
                    "required": false,
                    "source_refs": [
                      "SRC-005"
                    ]
                  },
                  {
                    "id": "de-media-type",
                    "name": "Media type",
                    "description": "IANA media type of each artifact; receiving systems may restrict the permitted set.",
                    "value_kind": "code",
                    "cardinality": "0..n",
                    "required": false,
                    "source_refs": [
                      "SRC-005",
                      "SRC-003"
                    ]
                  },
                  {
                    "id": "de-integrity-digest",
                    "name": "Integrity digest",
                    "description": "Algorithm identifier and value from the IANA hash-algorithm registry for HTTP digest fields, used to detect corruption between systems.",
                    "value_kind": "text",
                    "cardinality": "0..n",
                    "required": false,
                    "source_refs": [
                      "SRC-012"
                    ]
                  }
                ],
                "artifacts": [
                  {
                    "id": "deliverable-artifact",
                    "name": "Deliverable artifact",
                    "description": "The concrete tendered output itself: a report, dataset, data management plan, software build, prototype, publication or physical item, referenced by the record and stored in the repository model.",
                    "media_or_form": [
                      "document",
                      "dataset",
                      "software or build package",
                      "audiovisual or web publication",
                      "physical item or demonstrator",
                      "event or service performance"
                    ],
                    "serial": true,
                    "identity_strategy": "Carry the repository's authoritative artifact identifier where one exists; otherwise a governed persistent identifier such as a DOI or handle; otherwise a UUID or ULID minted by the adopting Dimension, always paired with an integrity digest.",
                    "source_refs": [
                      "SRC-003",
                      "SRC-005",
                      "SRC-012"
                    ]
                  },
                  {
                    "id": "submission-manifest",
                    "name": "Submission manifest",
                    "description": "The list that binds the deliverable record to the exact set of artifacts tendered on a given submission, with formats, digests and packaging, so a later retrieval can be checked against what was submitted.",
                    "media_or_form": [
                      "structured manifest record",
                      "packaged archive index"
                    ],
                    "serial": true,
                    "identity_strategy": "Composite of the deliverable record identifier and the submission sequence number, with the submission timestamp recorded as a separate attribute; the date is never used as the identifier.",
                    "source_refs": [
                      "SRC-003",
                      "SRC-012"
                    ]
                  }
                ],
                "inline_only_rationale": null
              }
            ]
          }
        ]
      },
      {
        "id": "acceptance",
        "name": "Acceptance criteria, decision and evidence",
        "description": "What must be true for the record to be accepted, who may accept, what outcome was recorded, and what evidence stands behind it.",
        "rationale": "Acceptance is a defined act with named authority, place and documentary evidence in procurement regulation, and a status transition with an approval date in funder portals; without modelling it explicitly a deliverable record cannot distinguish submitted from accepted.",
        "source_refs": [
          "SRC-001",
          "SRC-003",
          "SRC-009"
        ],
        "layers": [
          {
            "id": "criteria-and-verification",
            "name": "Criteria and means of verification",
            "description": "The declared conditions for acceptance and the declared way in which satisfaction of those conditions will be shown.",
            "source_refs": [
              "SRC-001",
              "SRC-009",
              "SRC-011"
            ],
            "findings": [
              {
                "id": "acceptance-criteria-definition",
                "name": "Acceptance criteria definition",
                "description": "The set of conditions that must be met before the record is accepted, their source, their measurability, and whether they apply to the product, to the process that produced it, or to both.",
                "source_refs": [
                  "SRC-001",
                  "SRC-009",
                  "SRC-011"
                ],
                "questions": [
                  {
                    "id": "q-criteria-conditions",
                    "text": "What conditions must be satisfied before this record can be accepted?",
                    "kind": "requirement",
                    "answer_data": [
                      "criterion statements",
                      "criterion identifiers",
                      "mandatory or desirable flag per criterion"
                    ]
                  },
                  {
                    "id": "q-criteria-measurability",
                    "text": "For each criterion, what makes satisfaction objectively determinable rather than a matter of opinion?",
                    "kind": "measurement",
                    "answer_data": [
                      "measure or test reference",
                      "threshold value and unit",
                      "tolerance statement"
                    ]
                  },
                  {
                    "id": "q-criteria-source",
                    "text": "From which requirement, specification, review criterion or contract clause is each criterion derived?",
                    "kind": "provenance",
                    "answer_data": [
                      "source reference per criterion",
                      "derivation note",
                      "source version identifier"
                    ]
                  },
                  {
                    "id": "q-criteria-agreement",
                    "text": "When and by whom were the criteria agreed, and can they be changed after work has started?",
                    "kind": "authority",
                    "answer_data": [
                      "agreement date-time",
                      "agreeing parties references",
                      "post-agreement change rule reference"
                    ]
                  }
                ],
                "data_elements": [
                  {
                    "id": "de-criteria",
                    "name": "Acceptance criteria set",
                    "description": "Conditions required to be met before the deliverable is accepted, each with an identifier and a mandatory/desirable flag.",
                    "value_kind": "collection",
                    "cardinality": "0..n",
                    "required": false,
                    "source_refs": [
                      "SRC-001",
                      "SRC-009"
                    ]
                  },
                  {
                    "id": "de-criteria-scope",
                    "name": "Criterion application scope",
                    "description": "Whether a criterion applies to the product tendered, to the process by which it was produced, or to both.",
                    "value_kind": "code",
                    "cardinality": "0..n",
                    "required": false,
                    "source_refs": [
                      "SRC-001"
                    ]
                  },
                  {
                    "id": "de-criteria-agreement-time",
                    "name": "Criteria agreement timestamp",
                    "description": "RFC 3339 timestamp of when the criteria set became binding.",
                    "value_kind": "timestamp",
                    "cardinality": "0..1",
                    "required": false,
                    "source_refs": [
                      "SRC-007",
                      "SRC-009"
                    ]
                  }
                ],
                "artifacts": [],
                "inline_only_rationale": "Criteria are structured statements on the record with pointers to their source requirements; the requirement and contract documents that originate them are owned by other models."
              },
              {
                "id": "means-of-verification",
                "name": "Means of verification declaration",
                "description": "The declared method by which achievement will be demonstrated for a milestone, or conformance shown for a deliverable, distinguishing declaration of method from execution of the check.",
                "source_refs": [
                  "SRC-002",
                  "SRC-011",
                  "SRC-001"
                ],
                "questions": [
                  {
                    "id": "q-mov-method",
                    "text": "By what declared means will achievement or conformance be demonstrated for this record?",
                    "kind": "validation",
                    "answer_data": [
                      "verification method code",
                      "method description text",
                      "expected evidence type"
                    ]
                  },
                  {
                    "id": "q-mov-who",
                    "text": "Which party performs the verification, and is that party independent of the producing party?",
                    "kind": "quality",
                    "answer_data": [
                      "verifying party reference",
                      "independence flag",
                      "independence basis text"
                    ]
                  },
                  {
                    "id": "q-mov-timing",
                    "text": "At what point relative to delivery is verification performed: before, at, or after delivery?",
                    "kind": "process",
                    "answer_data": [
                      "verification timing code",
                      "timing rule reference",
                      "expected verification window"
                    ]
                  },
                  {
                    "id": "q-mov-shortcut",
                    "text": "Under what conditions may a supplier attestation substitute for full verification before acceptance?",
                    "kind": "exception",
                    "answer_data": [
                      "attestation permitted flag",
                      "attestation instrument reference",
                      "conditions and limits text"
                    ]
                  }
                ],
                "data_elements": [
                  {
                    "id": "de-verification-method",
                    "name": "Verification method",
                    "description": "Declared means of verification for a milestone or deliverable, such as inspection, test, demonstration, review or document submission.",
                    "value_kind": "code",
                    "cardinality": "0..n",
                    "required": false,
                    "source_refs": [
                      "SRC-002",
                      "SRC-011"
                    ]
                  },
                  {
                    "id": "de-verification-timing",
                    "name": "Verification timing",
                    "description": "Whether verification and acceptance occur before, at, or after delivery, as FAR permits depending on contract provisions.",
                    "value_kind": "code",
                    "cardinality": "0..1",
                    "required": false,
                    "source_refs": [
                      "SRC-001"
                    ]
                  },
                  {
                    "id": "de-attestation-permitted",
                    "name": "Supplier attestation permitted flag",
                    "description": "Whether a certificate of conformance may substitute for quality-assurance actions by the receiving party before acceptance.",
                    "value_kind": "boolean",
                    "cardinality": "0..1",
                    "required": false,
                    "source_refs": [
                      "SRC-001"
                    ]
                  }
                ],
                "artifacts": [],
                "inline_only_rationale": "This finding declares the intended verification method and timing as coded fields; the executed test, inspection or review record is owned by the quality/verification model."
              }
            ]
          },
          {
            "id": "acceptance-decision-and-evidence",
            "name": "Acceptance decision and evidence",
            "description": "The recorded acceptance outcome, the authority and place attached to it, and the documentary evidence referenced.",
            "source_refs": [
              "SRC-001",
              "SRC-003",
              "SRC-006"
            ],
            "findings": [
              {
                "id": "acceptance-authority-and-locus",
                "name": "Acceptance authority and place of acceptance",
                "description": "Who is entitled to accept, how delegation is reflected as a reference, and where acceptance takes place, since place determines which quality-assurance regime applies.",
                "source_refs": [
                  "SRC-001",
                  "SRC-003"
                ],
                "questions": [
                  {
                    "id": "q-auth-who",
                    "text": "Which role is entitled to accept this record on behalf of the receiving party?",
                    "kind": "authority",
                    "answer_data": [
                      "acceptance authority role reference",
                      "authorising instrument reference",
                      "effective period"
                    ]
                  },
                  {
                    "id": "q-auth-delegation",
                    "text": "Has acceptance responsibility been assigned to another office or agency, and where is that assignment recorded?",
                    "kind": "ownership",
                    "answer_data": [
                      "delegated office reference",
                      "assignment record reference in the authority model",
                      "binding effect statement"
                    ]
                  },
                  {
                    "id": "q-auth-place",
                    "text": "At what place is acceptance to occur, and does that follow source or destination quality assurance?",
                    "kind": "spatial",
                    "answer_data": [
                      "place of acceptance",
                      "source or destination code",
                      "contract clause reference"
                    ]
                  }
                ],
                "data_elements": [
                  {
                    "id": "de-acceptance-authority",
                    "name": "Acceptance authority reference",
                    "description": "Reference to the role or office entitled to accept; FAR places acceptance responsibility on the contracting officer unless assigned, in which case the assignee's acceptance binds the receiving party.",
                    "value_kind": "reference",
                    "cardinality": "0..1",
                    "required": false,
                    "source_refs": [
                      "SRC-001"
                    ]
                  },
                  {
                    "id": "de-place-of-acceptance",
                    "name": "Place of acceptance",
                    "description": "Named location at which acceptance occurs, following source or destination quality assurance.",
                    "value_kind": "text",
                    "cardinality": "0..1",
                    "required": false,
                    "source_refs": [
                      "SRC-001"
                    ]
                  }
                ],
                "artifacts": [],
                "inline_only_rationale": "Authority and delegation are references into the approval/authority model that owns actor registration and delegation chains; only the binding and the place value are carried here."
              },
              {
                "id": "acceptance-outcome-and-conditions",
                "name": "Acceptance outcome, conditions and rejection",
                "description": "The recorded outcome of the acceptance act, including conditional acceptance, rejection with reasons, resubmission expectations, and the declared effect and limits of acceptance.",
                "source_refs": [
                  "SRC-001",
                  "SRC-003",
                  "SRC-006"
                ],
                "questions": [
                  {
                    "id": "q-outcome-value",
                    "text": "What acceptance outcome is recorded against this record, and at what date-time?",
                    "kind": "decision",
                    "answer_data": [
                      "outcome code (accepted | rejected | conditionally accepted | withdrawn)",
                      "approval or rejection date-time",
                      "recording actor reference"
                    ]
                  },
                  {
                    "id": "q-outcome-conditions",
                    "text": "If acceptance was conditional, which conditions remain open and by when must they be closed?",
                    "kind": "state",
                    "answer_data": [
                      "open condition statements",
                      "condition due dates",
                      "condition closure references"
                    ]
                  },
                  {
                    "id": "q-outcome-rejection",
                    "text": "If the record was rejected, what reasons were given and what resubmission is expected?",
                    "kind": "exception",
                    "answer_data": [
                      "rejection reason codes and text",
                      "resubmission required flag",
                      "expected resubmission date"
                    ]
                  },
                  {
                    "id": "q-outcome-effect",
                    "text": "What does acceptance acknowledge, and what defects does it not waive?",
                    "kind": "constraint",
                    "answer_data": [
                      "effect statement text",
                      "reserved-rights statement covering latent defects, fraud and gross mistakes",
                      "governing clause reference"
                    ]
                  }
                ],
                "data_elements": [
                  {
                    "id": "de-acceptance-outcome",
                    "name": "Acceptance outcome code",
                    "description": "Recorded outcome of the acceptance act; EU continuous reporting records Accepted or Rejected decisions by the responsible officer with an approval date.",
                    "value_kind": "code",
                    "cardinality": "0..1",
                    "required": false,
                    "source_refs": [
                      "SRC-003",
                      "SRC-001"
                    ]
                  },
                  {
                    "id": "de-open-conditions",
                    "name": "Open acceptance conditions",
                    "description": "Conditions attached to a conditional acceptance, each with a due date and a closure reference.",
                    "value_kind": "collection",
                    "cardinality": "0..n",
                    "required": false,
                    "source_refs": [
                      "SRC-001",
                      "SRC-009"
                    ]
                  },
                  {
                    "id": "de-reserved-rights",
                    "name": "Reserved rights statement",
                    "description": "Statement that acceptance is conclusive except as provided by the governing instrument, notably for latent defects, fraud and gross mistakes amounting to fraud.",
                    "value_kind": "text",
                    "cardinality": "0..1",
                    "required": false,
                    "source_refs": [
                      "SRC-001"
                    ]
                  }
                ],
                "artifacts": [],
                "inline_only_rationale": "The outcome is a coded field with timestamps and reason text; the decision act, its audit trail and any contractual remedy are executed and retained by the approval and contract models."
              },
              {
                "id": "acceptance-evidence-record",
                "name": "Acceptance evidence reference",
                "description": "The documentary evidence that acceptance occurred: acceptance certificates, receiving reports, completion certificates or portal-generated decision exports, referenced with enough metadata to be retrieved and checked.",
                "source_refs": [
                  "SRC-001",
                  "SRC-006",
                  "SRC-003"
                ],
                "questions": [
                  {
                    "id": "q-evidence-what",
                    "text": "What document evidences that acceptance occurred, and under what document type is it classified?",
                    "kind": "evidence",
                    "answer_data": [
                      "evidence artifact reference",
                      "document type code",
                      "issuing party reference"
                    ]
                  },
                  {
                    "id": "q-evidence-retrieval",
                    "text": "Where is the evidence held and how is it retrieved and integrity-checked by a consuming agent?",
                    "kind": "interoperability",
                    "answer_data": [
                      "repository reference",
                      "retrieval locator",
                      "digest algorithm and value"
                    ]
                  },
                  {
                    "id": "q-evidence-absence",
                    "text": "What is recorded when acceptance is asserted but no evidence document exists?",
                    "kind": "quality",
                    "answer_data": [
                      "evidence-absent flag",
                      "justification text",
                      "data quality severity code"
                    ]
                  }
                ],
                "data_elements": [
                  {
                    "id": "de-evidence-refs",
                    "name": "Acceptance evidence references",
                    "description": "References to evidence documents such as an acceptance certificate executed on an inspection or receiving report, or a completion certificate.",
                    "value_kind": "reference",
                    "cardinality": "0..n",
                    "required": false,
                    "source_refs": [
                      "SRC-001",
                      "SRC-006"
                    ]
                  },
                  {
                    "id": "de-evidence-type",
                    "name": "Evidence document type",
                    "description": "Coded document type for the evidence, bindable to open document-type codelists such as completionCertificate or finalAudit.",
                    "value_kind": "code",
                    "cardinality": "0..n",
                    "required": false,
                    "source_refs": [
                      "SRC-006"
                    ]
                  }
                ],
                "artifacts": [
                  {
                    "id": "acceptance-certificate",
                    "name": "Acceptance or receiving evidence document",
                    "description": "The document by which acceptance is ordinarily evidenced, such as an acceptance certificate executed on an inspection or receiving report form, a commercial shipping document or packing list, or a completion certificate.",
                    "media_or_form": [
                      "signed certificate",
                      "inspection or receiving report",
                      "commercial shipping document or packing list",
                      "portal-generated decision export"
                    ],
                    "serial": true,
                    "identity_strategy": "Carry the issuing system's authoritative document identifier; otherwise a governed persistent identifier; otherwise a UUID or ULID minted by the adopting Dimension. The issue timestamp is a separate attribute and is never used as the identifier.",
                    "source_refs": [
                      "SRC-001",
                      "SRC-006"
                    ]
                  }
                ],
                "inline_only_rationale": null
              }
            ]
          }
        ]
      },
      {
        "id": "state-and-provenance",
        "name": "State, change and provenance",
        "description": "The lifecycle states the record moves through, how progress and variance are reported, and how generation, attribution and revision are traced.",
        "rationale": "Reviewed sources define three overlapping but distinct state vocabularies (schedule status, submission status, achievement status); an interoperable model must hold them separately and trace who produced and revised what.",
        "source_refs": [
          "SRC-003",
          "SRC-006",
          "SRC-008",
          "SRC-010"
        ],
        "layers": [
          {
            "id": "lifecycle-and-status",
            "name": "Lifecycle and status",
            "description": "The permitted states of the record and the reporting of progress and variance against commitment.",
            "source_refs": [
              "SRC-003",
              "SRC-006",
              "SRC-010"
            ],
            "findings": [
              {
                "id": "lifecycle-states",
                "name": "Lifecycle states and transitions",
                "description": "The distinct state vocabularies applying to a record (schedule status, submission status, achievement status), their permitted transitions, and the rules that prevent contradictory combinations.",
                "source_refs": [
                  "SRC-003",
                  "SRC-006",
                  "SRC-010"
                ],
                "questions": [
                  {
                    "id": "q-state-vocabularies",
                    "text": "Which state vocabularies apply to this record, and what is the current value in each?",
                    "kind": "state",
                    "answer_data": [
                      "schedule status value (on track, off track, completed, superseded)",
                      "submission status value (pending, draft, submitted, accepted, rejected)",
                      "achievement status value (scheduled, met, not met, partially met)"
                    ]
                  },
                  {
                    "id": "q-state-transitions",
                    "text": "Which state transitions are permitted, and which are forbidden or require an authorised exception?",
                    "kind": "lifecycle",
                    "answer_data": [
                      "permitted transition pairs",
                      "forbidden transition pairs",
                      "exception authority reference"
                    ]
                  },
                  {
                    "id": "q-state-consistency",
                    "text": "What consistency rules bind the state vocabularies to each other and to the recorded dates?",
                    "kind": "validation",
                    "answer_data": [
                      "cross-vocabulary consistency rules",
                      "date-versus-status constraints",
                      "violation severity code"
                    ]
                  },
                  {
                    "id": "q-state-terminal",
                    "text": "Which states are terminal, and what may still be modified on a record in a terminal state?",
                    "kind": "constraint",
                    "answer_data": [
                      "terminal state list",
                      "post-terminal mutable field list",
                      "reopening rule reference"
                    ]
                  }
                ],
                "data_elements": [
                  {
                    "id": "de-schedule-status",
                    "name": "Schedule status",
                    "description": "Delivery-tracking status; the UK data standard uses On track, Off track, Completed, Superseded, updated on change.",
                    "value_kind": "code",
                    "cardinality": "0..1",
                    "required": false,
                    "source_refs": [
                      "SRC-010"
                    ]
                  },
                  {
                    "id": "de-submission-status",
                    "name": "Submission status",
                    "description": "Portal submission status; EU continuous reporting uses Pending, Draft, Submitted and an Accepted/Rejected officer decision.",
                    "value_kind": "code",
                    "cardinality": "0..1",
                    "required": false,
                    "source_refs": [
                      "SRC-003"
                    ]
                  },
                  {
                    "id": "de-achievement-status",
                    "name": "Achievement status",
                    "description": "Milestone achievement status from a closed vocabulary: scheduled, met, notMet, partiallyMet.",
                    "value_kind": "code",
                    "cardinality": "0..1",
                    "required": false,
                    "source_refs": [
                      "SRC-006"
                    ]
                  }
                ],
                "artifacts": [],
                "inline_only_rationale": "States are coded values plus a transition table held as configuration on the model; no artifact is generated by a state change, and the change audit trail belongs to the referenced audit-owning model."
              },
              {
                "id": "status-and-variance-reporting",
                "name": "Progress, variance and delay explanation",
                "description": "How progress against commitment is expressed, how variance between baseline, forecast and actual is derived, and what narrative explanation is required for late, missing or cancelled records.",
                "source_refs": [
                  "SRC-002",
                  "SRC-004",
                  "SRC-010"
                ],
                "questions": [
                  {
                    "id": "q-variance-measure",
                    "text": "How is variance between baseline, forecast and actual dates expressed for this record?",
                    "kind": "measurement",
                    "answer_data": [
                      "variance value and unit",
                      "variance calculation basis",
                      "calculation timestamp"
                    ]
                  },
                  {
                    "id": "q-variance-explanation",
                    "text": "What explanation is required when the record is late, missing, cancelled or grouped?",
                    "kind": "quality",
                    "answer_data": [
                      "explanation text",
                      "reason code",
                      "explaining party reference"
                    ]
                  },
                  {
                    "id": "q-variance-forecast-update",
                    "text": "When a milestone is not achieved, what estimated completion date must accompany the status?",
                    "kind": "temporal",
                    "answer_data": [
                      "revised estimated completion date",
                      "update timestamp",
                      "confidence qualifier"
                    ]
                  },
                  {
                    "id": "q-variance-snapshot",
                    "text": "How does a periodic report freeze the status values reported at that point?",
                    "kind": "process",
                    "answer_data": [
                      "snapshot identifier",
                      "reporting period reference",
                      "frozen field set"
                    ]
                  }
                ],
                "data_elements": [
                  {
                    "id": "de-variance",
                    "name": "Schedule variance",
                    "description": "Derived difference between committed and current or actual dates, used for performance measurement against an approved plan.",
                    "value_kind": "quantity",
                    "cardinality": "0..1",
                    "required": false,
                    "source_refs": [
                      "SRC-004",
                      "SRC-010"
                    ]
                  },
                  {
                    "id": "de-delay-explanation",
                    "name": "Delay or exception explanation",
                    "description": "Narrative explanation required for missing, late, cancelled or grouped items, and the estimated completion date where a milestone was not achieved.",
                    "value_kind": "text",
                    "cardinality": "0..1",
                    "required": false,
                    "source_refs": [
                      "SRC-002",
                      "SRC-003"
                    ]
                  },
                  {
                    "id": "de-report-snapshot-ref",
                    "name": "Reporting snapshot reference",
                    "description": "Reference to the periodic snapshot in which these values were reported; EU continuous reporting takes a snapshot at each periodic report.",
                    "value_kind": "reference",
                    "cardinality": "0..n",
                    "required": false,
                    "source_refs": [
                      "SRC-002"
                    ]
                  }
                ],
                "artifacts": [],
                "inline_only_rationale": "Variance values and explanations are fields on the record; the periodic or progress report document that publishes them is produced and owned by the reporting model and only referenced here."
              }
            ]
          },
          {
            "id": "provenance-and-change",
            "name": "Provenance and change history",
            "description": "Traceability of who generated and revised the record and its artifacts, and how supersession and cancellation are represented.",
            "source_refs": [
              "SRC-008",
              "SRC-002",
              "SRC-010"
            ],
            "findings": [
              {
                "id": "generation-and-attribution",
                "name": "Generation and attribution provenance",
                "description": "Which activity generated the record or its artifacts, which agents were responsible, and on whose behalf they acted, expressed so it can be projected onto a standard provenance vocabulary.",
                "source_refs": [
                  "SRC-008",
                  "SRC-003"
                ],
                "questions": [
                  {
                    "id": "q-prov-generation",
                    "text": "Which activity generated this record or artifact, and when did that activity start and end?",
                    "kind": "provenance",
                    "answer_data": [
                      "generating activity reference",
                      "activity start date-time",
                      "activity end date-time"
                    ]
                  },
                  {
                    "id": "q-prov-attribution",
                    "text": "To which agent is the record or artifact attributed, and on whose behalf did that agent act?",
                    "kind": "ownership",
                    "answer_data": [
                      "attributed agent reference",
                      "delegation chain reference",
                      "attribution qualification note"
                    ]
                  },
                  {
                    "id": "q-prov-inputs",
                    "text": "Which prior entities were used or consumed in producing this record?",
                    "kind": "relationship",
                    "answer_data": [
                      "used entity references",
                      "usage role codes",
                      "usage time"
                    ]
                  }
                ],
                "data_elements": [
                  {
                    "id": "de-generating-activity",
                    "name": "Generating activity reference",
                    "description": "Reference to the activity that generated the record or artifact, aligned to the provenance ontology generation relation.",
                    "value_kind": "reference",
                    "cardinality": "0..1",
                    "required": false,
                    "source_refs": [
                      "SRC-008"
                    ]
                  },
                  {
                    "id": "de-attributed-agent",
                    "name": "Attributed agent reference",
                    "description": "Agent to whom the entity is attributed, optionally qualified with delegation.",
                    "value_kind": "reference",
                    "cardinality": "0..n",
                    "required": false,
                    "source_refs": [
                      "SRC-008"
                    ]
                  }
                ],
                "artifacts": [],
                "inline_only_rationale": "Provenance is expressed as typed reference triples that project onto an external provenance vocabulary; materialising it as an artifact would create a second, divergent copy of the same assertions."
              },
              {
                "id": "revision-supersession-and-cancellation",
                "name": "Revision, supersession and cancellation",
                "description": "How successive versions of the record and its artifacts relate, how a record is marked superseded or cancelled, and what must survive so historical reports stay reconstructible.",
                "source_refs": [
                  "SRC-008",
                  "SRC-010",
                  "SRC-002"
                ],
                "questions": [
                  {
                    "id": "q-rev-lineage",
                    "text": "Which earlier record or artifact is this one a revision of, and what changed between them?",
                    "kind": "provenance",
                    "answer_data": [
                      "prior version reference",
                      "revision relation type",
                      "change summary text"
                    ]
                  },
                  {
                    "id": "q-rev-supersede",
                    "text": "When a record is superseded, what marks it and where does the successor reference point?",
                    "kind": "lifecycle",
                    "answer_data": [
                      "superseded status value",
                      "successor record reference",
                      "supersession timestamp"
                    ]
                  },
                  {
                    "id": "q-rev-cancel",
                    "text": "On what grounds may a planned record be cancelled rather than completed, and who may cancel it?",
                    "kind": "decision",
                    "answer_data": [
                      "cancellation reason code and text",
                      "cancelling authority reference",
                      "cancellation date-time"
                    ]
                  },
                  {
                    "id": "q-rev-history",
                    "text": "Which historical values must remain immutable after supersession so that past reports still reconcile?",
                    "kind": "retention",
                    "answer_data": [
                      "immutable field list",
                      "retention obligation reference",
                      "reconciliation rule"
                    ]
                  }
                ],
                "data_elements": [
                  {
                    "id": "de-prior-version",
                    "name": "Prior version reference",
                    "description": "Reference to the revised entity, aligned to the provenance revision relation.",
                    "value_kind": "reference",
                    "cardinality": "0..1",
                    "required": false,
                    "source_refs": [
                      "SRC-008"
                    ]
                  },
                  {
                    "id": "de-supersession",
                    "name": "Supersession link",
                    "description": "Successor record reference with a timestamp; the UK milestone status vocabulary includes Superseded as an explicit value.",
                    "value_kind": "reference",
                    "cardinality": "0..1",
                    "required": false,
                    "source_refs": [
                      "SRC-010"
                    ]
                  },
                  {
                    "id": "de-cancellation-reason",
                    "name": "Cancellation reason",
                    "description": "Coded and narrative reason for cancelling a planned deliverable or milestone, which continuous reporting requires to be explained.",
                    "value_kind": "text",
                    "cardinality": "0..1",
                    "required": false,
                    "source_refs": [
                      "SRC-002"
                    ]
                  }
                ],
                "artifacts": [],
                "inline_only_rationale": "Version lineage is a set of links and immutable retained values on the records themselves; the physical version store for files is owned by the repository model."
              }
            ]
          }
        ]
      },
      {
        "id": "classification-access-and-exchange",
        "name": "Classification, access and exchange",
        "description": "How sensitivity and publication constraints are declared, how retention and disposition are deferred to their owners, and how the record is exchanged with external systems.",
        "rationale": "Delivery records routinely carry per-item sensitivity markings that govern whether artifacts may be uploaded or published at all, and they must be projected into at least one external reporting schema without loss of the acceptance and date semantics.",
        "source_refs": [
          "SRC-003",
          "SRC-005",
          "SRC-010"
        ],
        "layers": [
          {
            "id": "classification-and-access",
            "name": "Sensitivity classification and publication",
            "description": "Per-record sensitivity markings and the publication constraints they imply.",
            "source_refs": [
              "SRC-003",
              "SRC-010"
            ],
            "findings": [
              {
                "id": "sensitivity-classification",
                "name": "Sensitivity and dissemination classification",
                "description": "The classification carried by each record and artifact, ranging from fully public through restricted-by-agreement to formally classified material that must not enter ordinary systems, and the handling rule attached to each level.",
                "source_refs": [
                  "SRC-003",
                  "SRC-010"
                ],
                "questions": [
                  {
                    "id": "q-class-level",
                    "text": "What dissemination or sensitivity level is assigned to this record and to each of its artifacts?",
                    "kind": "privacy",
                    "answer_data": [
                      "classification level code per item",
                      "classification vocabulary reference",
                      "classifying authority reference"
                    ]
                  },
                  {
                    "id": "q-class-handling",
                    "text": "What handling rule follows from the assigned level, including any prohibition on uploading the artifact at all?",
                    "kind": "security",
                    "answer_data": [
                      "handling rule text",
                      "prohibited channel list",
                      "alternative transmission instruction"
                    ]
                  },
                  {
                    "id": "q-class-granularity",
                    "text": "Is classification set per item rather than inherited wholesale from the parent project, and how are conflicts resolved?",
                    "kind": "constraint",
                    "answer_data": [
                      "per-item classification flag",
                      "inheritance rule",
                      "conflict resolution rule"
                    ]
                  },
                  {
                    "id": "q-class-review",
                    "text": "When is a classification reviewed or downgraded, and what triggers that review?",
                    "kind": "lifecycle",
                    "answer_data": [
                      "review trigger condition",
                      "review due date",
                      "downgrade decision reference"
                    ]
                  }
                ],
                "data_elements": [
                  {
                    "id": "de-classification-level",
                    "name": "Classification level",
                    "description": "Per-record and per-artifact dissemination level; EU deliverables carry a dissemination level and classified items are excluded from normal upload channels.",
                    "value_kind": "code",
                    "cardinality": "0..1",
                    "required": false,
                    "source_refs": [
                      "SRC-003"
                    ]
                  },
                  {
                    "id": "de-restricted-flags",
                    "name": "Restricted and protected flags",
                    "description": "Boolean markings such as the UK milestone restricted status (sensitive designation) and protected status.",
                    "value_kind": "boolean",
                    "cardinality": "0..n",
                    "required": false,
                    "source_refs": [
                      "SRC-010"
                    ]
                  },
                  {
                    "id": "de-handling-instruction",
                    "name": "Handling instruction",
                    "description": "Instruction for transmitting or withholding the artifact when normal channels are prohibited.",
                    "value_kind": "text",
                    "cardinality": "0..1",
                    "required": false,
                    "source_refs": [
                      "SRC-003"
                    ]
                  }
                ],
                "artifacts": [],
                "inline_only_rationale": "Classification is metadata expressed as codes and flags; enforcement of the resulting access decision is executed by the access-control and repository models, which this model only references."
              },
              {
                "id": "publication-binding",
                "name": "Publication and open-availability binding",
                "description": "Whether and where a record or artifact is published to a public audience, under what condition, and how the public projection is kept consistent with the governed record.",
                "source_refs": [
                  "SRC-003",
                  "SRC-005",
                  "SRC-002"
                ],
                "questions": [
                  {
                    "id": "q-pub-eligibility",
                    "text": "Is this record or artifact eligible for public publication, and on what basis?",
                    "kind": "access",
                    "answer_data": [
                      "publication eligibility flag",
                      "basis reference (classification level, agreement clause)",
                      "eligibility decision date-time"
                    ]
                  },
                  {
                    "id": "q-pub-location",
                    "text": "Where is the published version located, and when was it first published?",
                    "kind": "spatial",
                    "answer_data": [
                      "publication locator",
                      "first publication date",
                      "publishing party reference"
                    ]
                  },
                  {
                    "id": "q-pub-consistency",
                    "text": "How is the published projection kept consistent with the governed record after later revisions?",
                    "kind": "interoperability",
                    "answer_data": [
                      "synchronisation rule",
                      "published version identifier",
                      "divergence detection method"
                    ]
                  }
                ],
                "data_elements": [
                  {
                    "id": "de-publication-flag",
                    "name": "Publication eligibility flag",
                    "description": "Whether the item may be published openly, derived from its dissemination level.",
                    "value_kind": "boolean",
                    "cardinality": "0..1",
                    "required": false,
                    "source_refs": [
                      "SRC-003"
                    ]
                  },
                  {
                    "id": "de-publication-locator",
                    "name": "Publication locator and date",
                    "description": "Public URL and first publication date for a published artifact, following the document publication metadata pattern.",
                    "value_kind": "reference",
                    "cardinality": "0..n",
                    "required": false,
                    "source_refs": [
                      "SRC-005"
                    ]
                  }
                ],
                "artifacts": [],
                "inline_only_rationale": "Publication is a binding of eligibility, locator and date onto an existing artifact; the published copy is stored and served by the repository or publication model, not created here."
              }
            ]
          },
          {
            "id": "retention-and-interoperability",
            "name": "Retention deferral and interoperability",
            "description": "Where deletion and retention authority sits, and how the record maps onto external identifiers and exchange schemas.",
            "source_refs": [
              "SRC-002",
              "SRC-005",
              "SRC-009"
            ],
            "findings": [
              {
                "id": "retention-and-disposition-reference",
                "name": "Retention and disposition reference",
                "description": "The retention obligation applying to the record and its artifacts, the instrument that sets it, and the explicit statement that disposition is executed by the repository and records-management owners rather than here.",
                "source_refs": [
                  "SRC-009",
                  "SRC-002",
                  "SRC-001"
                ],
                "questions": [
                  {
                    "id": "q-ret-obligation",
                    "text": "Which instrument sets the retention obligation for this record and for how long after which trigger event?",
                    "kind": "retention",
                    "answer_data": [
                      "retention instrument reference",
                      "retention period and unit",
                      "retention trigger event"
                    ]
                  },
                  {
                    "id": "q-ret-owner",
                    "text": "Which model or policy executes disposition when the retention period expires?",
                    "kind": "ownership",
                    "answer_data": [
                      "executing model or policy reference",
                      "disposition method code",
                      "confirmation-of-disposition record reference"
                    ]
                  },
                  {
                    "id": "q-ret-hold",
                    "text": "What legal hold, audit or dispute condition suspends disposition, and who may set or lift it?",
                    "kind": "exception",
                    "answer_data": [
                      "hold flag and reason",
                      "hold authority reference",
                      "hold review date"
                    ]
                  },
                  {
                    "id": "q-ret-tombstone",
                    "text": "What must remain discoverable after the record's content is disposed of?",
                    "kind": "constraint",
                    "answer_data": [
                      "tombstone field set",
                      "tombstone retention period",
                      "reference-integrity rule"
                    ]
                  }
                ],
                "data_elements": [
                  {
                    "id": "de-retention-ref",
                    "name": "Retention obligation reference",
                    "description": "Pointer to the governing retention instrument (grant or contract record-keeping clause, or the adopting Dimension's records policy) with period and trigger.",
                    "value_kind": "reference",
                    "cardinality": "0..1",
                    "required": false,
                    "source_refs": [
                      "SRC-009",
                      "SRC-002"
                    ]
                  },
                  {
                    "id": "de-hold-flag",
                    "name": "Disposition hold flag",
                    "description": "Indicator that disposition is suspended pending audit, dispute or investigation, with the authority that set it.",
                    "value_kind": "boolean",
                    "cardinality": "0..1",
                    "required": false,
                    "source_refs": [
                      "SRC-001",
                      "SRC-009"
                    ]
                  }
                ],
                "artifacts": [],
                "inline_only_rationale": "This model records the obligation and its trigger only; the disposition act, its certificate and the deletion audit trail are executed and retained by the records-management and repository models."
              },
              {
                "id": "external-mapping-and-exchange",
                "name": "External identifier binding and exchange mapping",
                "description": "How the record is bound to identifiers and structures in external delivery-reporting systems, which fields map losslessly, and where mapping is lossy and must be flagged.",
                "source_refs": [
                  "SRC-005",
                  "SRC-006",
                  "SRC-010",
                  "SRC-003"
                ],
                "questions": [
                  {
                    "id": "q-map-targets",
                    "text": "Which external schemas is this record required to be projected into, and at which version of each?",
                    "kind": "interoperability",
                    "answer_data": [
                      "target schema identifiers",
                      "target schema versions",
                      "projection obligation source"
                    ]
                  },
                  {
                    "id": "q-map-fields",
                    "text": "Which local fields map one-to-one onto the target schema, and which require transformation?",
                    "kind": "interoperability",
                    "answer_data": [
                      "field mapping table entries",
                      "transformation rule per mapped field",
                      "unmapped field list"
                    ]
                  },
                  {
                    "id": "q-map-loss",
                    "text": "Where does projection lose meaning, and how is that loss declared to the consumer?",
                    "kind": "quality",
                    "answer_data": [
                      "lossy mapping declarations",
                      "loss severity code",
                      "compensating annotation"
                    ]
                  },
                  {
                    "id": "q-map-codelists",
                    "text": "How are local status and type codes reconciled with closed external codelists that cannot be extended?",
                    "kind": "classification",
                    "answer_data": [
                      "local-to-external code mappings",
                      "unmappable code handling rule",
                      "extension namespace for open codelists"
                    ]
                  }
                ],
                "data_elements": [
                  {
                    "id": "de-external-bindings",
                    "name": "External identifier bindings",
                    "description": "Identifiers of the same record in external systems (funder portal, contracting publication, departmental data return) with the issuing scheme named.",
                    "value_kind": "collection",
                    "cardinality": "0..n",
                    "required": false,
                    "source_refs": [
                      "SRC-003",
                      "SRC-005",
                      "SRC-010"
                    ]
                  },
                  {
                    "id": "de-mapping-declarations",
                    "name": "Mapping declarations",
                    "description": "Declared field-level mappings to external schemas with transformation rules and lossiness flags.",
                    "value_kind": "collection",
                    "cardinality": "0..n",
                    "required": false,
                    "source_refs": [
                      "SRC-005",
                      "SRC-006"
                    ]
                  }
                ],
                "artifacts": [],
                "inline_only_rationale": "Mappings are declarative configuration attached to the model; the serialized exchange payloads are transient projections in a storage or interface layer rather than governed artifacts of this model."
              }
            ]
          }
        ]
      }
    ]
  },
  "functions": [
    {
      "id": "register-record",
      "name": "Register milestone or deliverable record",
      "description": "Create a governed record for a planned achievement or an output, establishing identity, kind, designation, scope and owning work-package linkage.",
      "inputs": [
        "record kind",
        "title and description",
        "scope statement",
        "owning project reference",
        "owning work package reference",
        "accountable party reference"
      ],
      "outputs": [
        "registered record with authoritative identifier",
        "identifier uniqueness scope declaration",
        "creation provenance entry"
      ],
      "preconditions": [
        "Owning project reference resolves",
        "Accountable party reference resolves",
        "Record kind is determinable against the milestone/deliverable distinction"
      ],
      "effects": [
        "Record exists in its initial planned state",
        "Identifier reserved at the declared uniqueness scope"
      ],
      "source_refs": [
        "SRC-002",
        "SRC-005",
        "SRC-010"
      ]
    },
    {
      "id": "set-baseline-commitment",
      "name": "Set baseline date commitment",
      "description": "Attach a baseline planned date and its baseline version reference to the record, after which the value is immutable outside a controlled rebaseline.",
      "inputs": [
        "baseline planned date",
        "baseline version reference",
        "approving plan reference"
      ],
      "outputs": [
        "baseline planned date set once",
        "baseline provenance link"
      ],
      "preconditions": [
        "Record is registered",
        "No baseline date is already set for this baseline version",
        "Approving plan reference resolves"
      ],
      "effects": [
        "Baseline value becomes immutable in place",
        "Variance calculation becomes possible"
      ],
      "source_refs": [
        "SRC-010",
        "SRC-004",
        "SRC-011"
      ]
    },
    {
      "id": "revise-forecast",
      "name": "Revise forecast date",
      "description": "Record a new expected completion date with reason and revision timestamp, preserving the previous forecast in the value history.",
      "inputs": [
        "new forecast date",
        "revision reason code and text",
        "revising party reference"
      ],
      "outputs": [
        "updated forecast date",
        "forecast revision history entry",
        "recomputed variance value"
      ],
      "preconditions": [
        "Record is not in a terminal state",
        "Baseline commitment exists or is explicitly absent"
      ],
      "effects": [
        "Forecast value updated",
        "Variance and schedule status may change"
      ],
      "source_refs": [
        "SRC-010",
        "SRC-004"
      ]
    },
    {
      "id": "declare-acceptance-criteria",
      "name": "Declare acceptance criteria and means of verification",
      "description": "Attach the conditions required before acceptance, their derivation sources, and the declared verification method, timing and independence expectation.",
      "inputs": [
        "criterion statements with identifiers",
        "criterion source references",
        "verification method code",
        "verification timing code"
      ],
      "outputs": [
        "criteria set bound to the record",
        "criteria agreement timestamp",
        "verification declaration"
      ],
      "preconditions": [
        "Scope statement exists",
        "Criterion source references resolve"
      ],
      "effects": [
        "Acceptance becomes assessable against declared conditions by the verifying party named in the quality model"
      ],
      "source_refs": [
        "SRC-001",
        "SRC-009",
        "SRC-011"
      ]
    },
    {
      "id": "bind-artifact-manifest",
      "name": "Bind artifact manifest to record",
      "description": "Attach the set of artifacts constituting or evidencing the deliverable, with media type, language, locator and integrity digest, subject to receiving-system format constraints.",
      "inputs": [
        "artifact references",
        "media type per artifact",
        "language tag per artifact",
        "digest algorithm and value per artifact"
      ],
      "outputs": [
        "submission manifest",
        "per-artifact integrity assertions",
        "format constraint validation result"
      ],
      "preconditions": [
        "Record kind permits artifacts",
        "Classification permits the chosen transmission channel",
        "Digest algorithm is Active in the governing hash registry"
      ],
      "effects": [
        "Manifest becomes the reference set for acceptance and later retrieval verification"
      ],
      "source_refs": [
        "SRC-003",
        "SRC-005",
        "SRC-012"
      ]
    },
    {
      "id": "record-submission",
      "name": "Record submission event",
      "description": "Record that the deliverable was tendered to the receiving party, capturing the submission timestamp, submitting party and manifest version.",
      "inputs": [
        "submitting party reference",
        "submission timestamp",
        "manifest reference"
      ],
      "outputs": [
        "submission event entry",
        "submission status transition",
        "delivery date value"
      ],
      "preconditions": [
        "Submitting party is the recorded authorised submitter",
        "Manifest is bound",
        "Record is not already accepted"
      ],
      "effects": [
        "Submission status advances",
        "Record becomes awaitable for an acceptance outcome"
      ],
      "source_refs": [
        "SRC-003",
        "SRC-002"
      ]
    },
    {
      "id": "record-acceptance-outcome",
      "name": "Record acceptance outcome",
      "description": "Store the outcome reached by the acceptance authority together with its timestamp, conditions, reasons and evidence reference; this function stores the decision, it does not evaluate criteria or execute the decision.",
      "inputs": [
        "outcome code",
        "decision timestamp",
        "acceptance authority reference",
        "evidence artifact reference",
        "conditions or rejection reasons"
      ],
      "outputs": [
        "acceptance outcome recorded",
        "approval or rejection date",
        "evidence binding"
      ],
      "preconditions": [
        "Acceptance criteria are declared",
        "Acceptance authority reference resolves in the authority model",
        "A decision record exists in the owning approval model"
      ],
      "effects": [
        "Submission status reflects the outcome",
        "Open conditions become trackable",
        "No enforcement or contractual remedy is applied by this model"
      ],
      "source_refs": [
        "SRC-001",
        "SRC-003",
        "SRC-009"
      ]
    },
    {
      "id": "record-achievement",
      "name": "Record achievement and actual date",
      "description": "Record that a milestone was met, partially met or not met, with the actual date and, where not achieved, a revised estimated completion date and explanation.",
      "inputs": [
        "achievement status value",
        "actual date",
        "explanation text where not achieved"
      ],
      "outputs": [
        "achievement status set",
        "actual date recorded",
        "variance updated"
      ],
      "preconditions": [
        "Actual date is not later than the current date",
        "Component records satisfy the declared roll-up rule"
      ],
      "effects": [
        "Record advances toward a terminal state",
        "Reported progress changes"
      ],
      "source_refs": [
        "SRC-006",
        "SRC-010",
        "SRC-002"
      ]
    },
    {
      "id": "supersede-or-cancel",
      "name": "Supersede, group or cancel record",
      "description": "Mark a record superseded by a successor, merged into a grouped submission, or cancelled, with reason, authority reference and preservation of historical values.",
      "inputs": [
        "disposition kind",
        "successor or grouping record reference",
        "reason text",
        "authorising reference"
      ],
      "outputs": [
        "status set to superseded or cancelled",
        "lineage link created",
        "retained historical values"
      ],
      "preconditions": [
        "Authorising reference resolves",
        "Historical reported values are retained immutably"
      ],
      "effects": [
        "Record leaves the active plan",
        "Past reports remain reconcilable"
      ],
      "source_refs": [
        "SRC-010",
        "SRC-002",
        "SRC-008"
      ]
    },
    {
      "id": "project-to-external-schema",
      "name": "Project record to an external delivery schema",
      "description": "Produce a projection of the record into a named external schema version, applying declared field mappings and flagging lossy elements.",
      "inputs": [
        "target schema identifier and version",
        "field mapping declarations",
        "record snapshot reference"
      ],
      "outputs": [
        "projected payload",
        "lossiness report",
        "unmapped field list"
      ],
      "preconditions": [
        "Mapping declarations exist for the target version",
        "Classification permits export to the target audience"
      ],
      "effects": [
        "External system receives a conformant projection",
        "Loss of meaning is declared rather than silent"
      ],
      "source_refs": [
        "SRC-005",
        "SRC-006",
        "SRC-010"
      ]
    }
  ],
  "composition": [
    {
      "target": "WM-ACT-005 Project",
      "relation": "CHILD",
      "purpose": "The project contains milestones and deliverables; the project owns objectives, stages, gates, funding and controlled closure, while this model owns the individual delivery record.",
      "required": true,
      "source_refs": [
        "SRC-009",
        "SRC-011"
      ]
    },
    {
      "target": "Schedule and activity-network model (sibling; identifier assigned by the adopting Dimension)",
      "relation": "REFERENCE",
      "purpose": "Carry references to the driving activity or work package and a criticality flag only; sequencing, durations, float, critical-path and schedule-risk calculation remain in the schedule model.",
      "required": false,
      "source_refs": [
        "SRC-004",
        "SRC-010"
      ]
    },
    {
      "target": "Party and organisation role model (sibling)",
      "relation": "REFERENCE",
      "purpose": "Resolve accountable, contributing, submitting and accepting parties without duplicating party identity, contact or role registries.",
      "required": true,
      "source_refs": [
        "SRC-003",
        "SRC-008"
      ]
    },
    {
      "target": "Document and artifact repository model (sibling)",
      "relation": "REFERENCE",
      "purpose": "Store and serve the artifacts named in the manifest; this model carries locators, media types, languages and digests, not the bytes, the versioning engine or disposition execution.",
      "required": false,
      "source_refs": [
        "SRC-005",
        "SRC-012"
      ]
    },
    {
      "target": "Approval and decision-authority model (sibling)",
      "relation": "REFERENCE",
      "purpose": "Bind the acceptance authority and the decision record; evaluation, delegation resolution, execution and the decision audit trail remain owned there.",
      "required": false,
      "source_refs": [
        "SRC-001",
        "SRC-009"
      ]
    },
    {
      "target": "Quality, inspection and verification model (sibling)",
      "relation": "REFERENCE",
      "purpose": "Point at executed inspections, tests, demonstrations and review outcomes that evidence the declared means of verification; test execution and results are not owned here.",
      "required": false,
      "source_refs": [
        "SRC-001",
        "SRC-011"
      ]
    },
    {
      "target": "Contract and agreement model (sibling)",
      "relation": "REFERENCE",
      "purpose": "Cite the clause that makes a due date or acceptance binding and gives acceptance its legal effect; payment triggers, warranties and remedies remain in the contract model.",
      "required": false,
      "source_refs": [
        "SRC-001"
      ]
    },
    {
      "target": "Requirement and specification model (sibling)",
      "relation": "REFERENCE",
      "purpose": "Derive acceptance criteria from requirement records by reference; requirement text, versioning and traceability matrices are not reproduced here.",
      "required": false,
      "source_refs": [
        "SRC-009",
        "SRC-011"
      ]
    },
    {
      "target": "Records-management and retention policy of the adopting Dimension",
      "relation": "REFERENCE",
      "purpose": "Supply the retention period, trigger and disposition method; this model records the obligation and any hold, and never performs deletion of referenced artifacts.",
      "required": true,
      "source_refs": [
        "SRC-009",
        "SRC-002"
      ]
    },
    {
      "target": "W3C PROV-O (namespace http://www.w3.org/ns/prov#)",
      "relation": "MIX-IN",
      "purpose": "Project generation, attribution, association, derivation and revision assertions onto a standard provenance vocabulary rather than defining a private one.",
      "required": false,
      "source_refs": [
        "SRC-008"
      ]
    },
    {
      "target": "Open Contracting Data Standard 1.1 Milestone and Document building blocks",
      "relation": "ALIGN",
      "purpose": "Alignment target for milestone identity, dueDate, dateMet, dateModified, status and document metadata; treated as an alignment, with the closed milestoneStatus codelist recorded as a constraint rather than a claim of conformance.",
      "required": false,
      "source_refs": [
        "SRC-005",
        "SRC-006"
      ]
    },
    {
      "target": "UK Programme and project data standard — Milestone entity",
      "relation": "ALIGN",
      "purpose": "Alignment target for the baseline/forecast/actual date triad, status and category vocabularies, criticality and restricted/protected flags; the source is under consultation, so alignment is provisional.",
      "required": false,
      "source_refs": [
        "SRC-010"
      ]
    },
    {
      "target": "EU Funding & Tenders continuous reporting deliverable and milestone structures",
      "relation": "ALIGN",
      "purpose": "Alignment target for the deliverable submission lifecycle, dissemination level, lead beneficiary, delivery and approval dates, and delay explanation obligations.",
      "required": false,
      "source_refs": [
        "SRC-002",
        "SRC-003"
      ]
    },
    {
      "target": "RFC 3339 date-time profile",
      "relation": "ALIGN",
      "purpose": "Bind all instant-valued fields to a profile requiring seconds and an explicit offset, and adopt the unknown-local-offset convention.",
      "required": true,
      "source_refs": [
        "SRC-007"
      ]
    }
  ],
  "serviceLayers": {
    "dimension": {
      "owner_package_requirements": [
        "The adopting Dimension names one owner for the Milestone / Deliverable model and one delegated data owner per portfolio or programme that instantiates it, and records both as references into the party model.",
        "The owner package declares the identifier minting authority and uniqueness scope for milestone and deliverable identifiers before any record is created, and publishes the retired-identifier register.",
        "The owner package declares the bound codelist versions for record kind, purpose type, governance category and the three status vocabularies, together with the local-to-external mapping tables and their review cadence.",
        "The owner package names the records-management policy that owns retention and disposition execution, and the approval model that owns acceptance decision execution, so that this model never assumes either."
      ],
      "namespace_guidance": "Use a stable namespace of the form <dimension-namespace>/act/milestone-deliverable/ for local terms, and reserve sub-namespaces for locally minted status, type and category codes. Do not mint local terms where an external codelist already provides a code; where an external codelist is closed, map into it and keep the local value in an extension namespace rather than overloading a standard code.",
      "registry_links": [
        "Registry entry vr.wm-act-031 with nav path NAV.ACT.MIL and domain tag ACT.MIL",
        "Parent registry entry WM-ACT-005 (Project), which contains this model",
        "IANA media types registry and the IANA hash-algorithms registry for HTTP digest fields, referenced for artifact form and integrity"
      ]
    },
    "canon_and_patch": {
      "canonicalization_rules": [
        "Canonical form is the record graph, not any serialization: field order, whitespace and container format carry no meaning, and JSON, YAML, Markdown, tabular exports, Git objects, MCP resources and document databases are projections.",
        "All instant-valued fields are canonicalized to RFC 3339 with seconds present and an explicit offset or Z; calendar-date fields are canonicalized to full-date form and are never widened to instants by inventing a time.",
        "Codes are canonicalized as a pair of vocabulary identifier plus code value; a bare code without its vocabulary is not canonical.",
        "References are canonicalized as typed pointers of target model identifier plus target record identifier; embedded copies of referenced records are never canonical and must be regenerated from the target on read."
      ],
      "patch_rules": [
        "Patches are expressed against stable field paths in the canonical graph; a patch that would alter a baseline planned date in place is rejected and must be reissued as a rebaseline carrying an authorising reference.",
        "A patch that changes a status value must carry the transition it asserts and be validated against the permitted transition table before application.",
        "Patches that add or remove artifacts must update the submission manifest and the affected digests in the same change unit, so a manifest never references an artifact without an integrity assertion.",
        "Values frozen into a reporting snapshot are not patchable; corrections are issued as a new value with an observation timestamp and a correction note, leaving the snapshot intact."
      ],
      "compatibility_rules": [
        "Adding an optional field, an optional reference, or a value to an open codelist is a compatible change; removing a field, narrowing cardinality, or removing a code is breaking.",
        "Changing the meaning of an existing status value is breaking even if the token is unchanged, and requires a new vocabulary version.",
        "Projections into external schemas declare the target schema version explicitly; a target version bump that changes required fields is treated as breaking for the projection even when the local model is unchanged.",
        "Records created under an earlier vocabulary version retain that version binding; readers must resolve codes against the version recorded on the record, not against the current default."
      ]
    },
    "artifact_rules": {
      "identity_priority": [
        "The authoritative master-system identifier issued by the system of record that owns the artifact or delivery record (for example the funder portal deliverable identifier, the repository document identifier, or the acceptance certificate number issued by the accepting authority).",
        "A governed global identifier or IRI from a recognised scheme (for example a DOI, handle or other persistent identifier) where no master-system identifier exists.",
        "A UUID or ULID minted by the adopting Dimension, recorded together with the minting authority and the scope in which it is unique.",
        "A display number such as a structured deliverable number is a human-facing designation only and is never promoted to an identifier; a date or date-time is never an identifier."
      ],
      "timestamp_rule": "All instant-valued fields use RFC 3339 date-time with the seconds element present and an explicit time offset (a numeric +/-HH:MM offset or Z); where the instant is known in UTC but the local offset is not, use the -00:00 convention and set a data-quality flag. Event time (when the achievement, submission or acceptance occurred) and observation or ingestion time (when the fact was recorded in this model) are stored in separate fields and are never collapsed into one value; where they differ, both are required. Purely calendar commitments such as a baseline planned date, forecast date and due date are stored as full-date values without an invented time-of-day and are never silently converted into instants.",
      "serial_naming_rule": "Serial artifacts are named as <record-identifier>-<artifact-role>-<zero-padded sequence>, where the sequence increments monotonically per record and role and never restarts. The submission or issue timestamp is stored as a separate attribute and must not appear in the name, so no identifier carries a date-like component; superseded sequence numbers are retained and never reused.",
      "integrity_rule": "Every artifact reference carries at least one digest expressed as an algorithm identifier from the Active entries of the IANA hash algorithms registry for HTTP digest fields plus its value, computed over the complete selected representation. Digests detect corruption across systems but do not by themselves prove authenticity; where non-repudiation is required the record must additionally reference a signature or acceptance certificate held by the issuing authority. A manifest entry whose digest cannot be verified on retrieval is flagged as unverifiable and must not be reported as accepted evidence."
    },
    "policies": [
      "Separation of duties: the party that records a submission must not be the party recorded as the acceptance authority for the same record; where the adopting Dimension cannot avoid this, the record must carry an explicit conflict declaration.",
      "No silent completion: a status of met, completed or accepted requires a recorded actual or decision date and, for deliverables, a bound manifest or an explicit justification for its absence.",
      "Baseline integrity: baseline planned dates are set once and changed only through a rebaseline that names an authorising reference and retains the superseded value.",
      "Classification precedence: the most restrictive classification among a record and its artifacts governs handling; classification is set per item and is not inherited wholesale from the parent project.",
      "Reference not replication: any concept owned by a referenced model is carried as a typed reference plus subject-specific parameters, never as a local copy of that model's lifecycle, evaluation, enforcement or audit semantics."
    ],
    "crud": {
      "read": [
        "Reads resolve the canonical record graph and dereference typed references on demand; a reader that cannot resolve a reference reports it as unresolved rather than substituting a stale embedded copy.",
        "Reads honour the effective classification: items whose classification prohibits the requesting channel are withheld with an explicit access-denied marker rather than silently omitted from result sets.",
        "Historical reads against a reporting snapshot return the frozen values of that snapshot, with later corrections listed separately and never merged into the snapshot."
      ],
      "create": [
        "Creating a record requires kind, title, scope statement, owning project reference and accountable party reference; an identifier is minted according to the identity priority and its uniqueness scope is recorded.",
        "Creating an artifact manifest entry requires media type, locator and at least one integrity digest, and must pass the receiving system's format and count constraints where one is declared.",
        "Creation records both the event time asserted by the creator and the ingestion timestamp assigned by the model."
      ],
      "update": [
        "Updates are patches against the canonical graph, validated against permitted state transitions, baseline immutability and cross-vocabulary consistency rules before application.",
        "Every update records the updating party, the reason where a reason is required (forecast revision, delay, cancellation, rebaseline) and the observation timestamp, and preserves the prior value in the retained history.",
        "Updates may not alter values frozen into a reporting snapshot; corrections are appended as new values with a correction note."
      ],
      "delete": [
        "Hard deletion of a milestone or deliverable record is prohibited while any retention obligation, disposition hold, unresolved acceptance condition or inbound reference is active; the default disposition is logical retirement via the cancelled or superseded status rather than removal.",
        "When a record's content is disposed of, a tombstone is retained containing the identifier, uniqueness scope, record kind, owning project reference, terminal status, terminal date values and the disposition reference, so inbound references and past reports remain resolvable; the tombstone retention period is set by the governing records policy.",
        "This model does not execute deletion of referenced artifacts: disposition of artifact bytes is performed by the document and artifact repository model, and the retention period, trigger and disposition method are owned by the adopting Dimension's records-management policy or by the record-keeping clause of the governing grant or contract instrument. This model records only the obligation reference, the hold flag and the resulting disposition reference.",
        "Deletion or disposition of the acceptance decision record and its audit trail is out of scope entirely and is owned by the approval and decision-authority model; this model may lose its evidence pointer only by recording an explicit evidence-absent flag with justification."
      ]
    },
    "roles": [
      {
        "name": "Model steward",
        "responsibilities": [
          "Maintain the model definition, its bundles, layers, findings and functions, and keep every node's source references current.",
          "Adjudicate boundary disputes with the project, schedule, approval, repository and contract models and move target-owned concepts out of this model.",
          "Approve vocabulary and mapping version changes and classify them as compatible or breaking."
        ]
      },
      {
        "name": "Delivery data owner (per portfolio or programme)",
        "responsibilities": [
          "Own the correctness of milestone and deliverable records for their scope, including baseline integrity and timely forecast revision.",
          "Name the accountable party for each record and ensure explanations exist for late, missing, cancelled or grouped items.",
          "Authorise rebaselines within delegated limits and escalate beyond them."
        ]
      },
      {
        "name": "Acceptance liaison",
        "responsibilities": [
          "Bind the acceptance authority reference and the decision record produced by the approval model onto the delivery record.",
          "Ensure declared acceptance criteria and means of verification exist before submission and that evidence references are recorded after a decision.",
          "Track open conditions from conditional acceptances to closure without asserting authority over the decision itself."
        ]
      },
      {
        "name": "Classification and access custodian",
        "responsibilities": [
          "Assign and review per-record and per-artifact classification and the restricted and protected flags.",
          "Apply handling rules including prohibitions on ordinary transmission channels for classified material.",
          "Approve publication eligibility and monitor divergence between the governed record and any public projection."
        ]
      },
      {
        "name": "Interoperability maintainer",
        "responsibilities": [
          "Maintain field mappings to external delivery-reporting schemas and their version bindings.",
          "Declare and publish lossy mappings and unmappable local codes.",
          "Validate projections before export and detect target-schema version drift."
        ]
      }
    ],
    "access": {
      "default_rule": "Default access is deny-by-default at record granularity: a principal may read a milestone or deliverable record only where the adopting Dimension's access policy grants it for the owning project scope and the record's effective classification permits the requesting channel. Write access is further restricted to the roles named for the specific operation. These are declarative requirements only: evaluation and enforcement are performed by the referenced access-control model.",
      "scopes": [
        "bundle",
        "layer",
        "finding",
        "artifact"
      ],
      "exceptions": [
        "Records or artifacts marked as formally classified are excluded from ordinary storage and transmission channels altogether; the record carries a handling instruction and an explicit submit-without-upload marker instead of the artifact.",
        "Publicly disseminable deliverables may be read without project-scope membership once publication eligibility is recorded, but write access remains restricted.",
        "Submission is restricted to the recorded authorised submitter even where other principals hold write access to the record.",
        "Disposition holds grant audit and investigation principals read access to otherwise time-limited records for the duration of the hold.",
        "Break-glass access for incident response is permitted only where the adopting Dimension's access model provides it, and the record carries a flag that such access occurred; the access log itself is held by that model."
      ],
      "audit_requirements": [
        "Every recorded state transition, baseline change, submission, acceptance outcome, classification change and disposition action must carry the acting party reference, the reason where required, the event time and the ingestion timestamp on the record.",
        "The authoritative audit trail of who read or changed what is owned by the adopting Dimension's audit and access-control models; this model must reference those entries and must not maintain a competing audit log.",
        "Reporting snapshots must be immutable and independently reconcilable against the record's retained value history.",
        "Evidence references must be resolvable and digest-verifiable at audit time, or explicitly flagged as unverifiable."
      ]
    },
    "agents_bootstrap": {
      "filename": "AGENTS.md",
      "required_fields": [
        "Name",
        "Type",
        "Specification URL",
        "Storage type URL",
        "Interface URL",
        "Processes URL",
        "Owner and steward references",
        "Bound codelist versions and identifier uniqueness scope"
      ],
      "read_order": [
        "Read AGENTS.md first and resolve Name and Type to confirm this is the Milestone / Deliverable model WM-ACT-031.",
        "Read the Specification URL for scope, boundaries and the bundle/layer/finding structure before writing anything.",
        "Read the Storage type URL to learn the concrete projection in use (document database, Git-backed files, tabular store or MCP resources) and treat it as a projection of the canonical graph.",
        "Read the Interface URL for the read and write operations exposed and their authorisation requirements.",
        "Read the Processes URL for the registration, baselining, submission, acceptance-recording, supersession and projection procedures, and for the referenced models that own approval, repository, audit and retention execution.",
        "Resolve the parent registry entry WM-ACT-005 and the referenced sibling models before creating records that depend on them."
      ]
    }
  },
  "coverage": {
    "claim": "Audited against the pack's own evidence only. The Claude result publishes a coherent record model for a single milestone or deliverable: identity and designation, milestone/deliverable typing, the baseline-forecast-due-actual date set with RFC 3339 semantics, stage and gate association, criticality and work-package linkage held as references, accountable and producing parties, part-whole composition and an artifact manifest with integrity digests, declared acceptance criteria and means of verification, acceptance authority, outcome and evidence reference, three separate status vocabularies, provenance and revision lineage, sensitivity classification, publication binding, retention obligation and external schema mapping. Execution semantics (schedule calculation, approval execution, verification execution, byte storage, disposition, audit-trail keeping) are referenced rather than owned, and that separation holds across all 28 findings with one exception recorded below. Coverage is claimed only for what the structure actually publishes: the checklist's assertions about deny-by-default access scoping, break-glass exceptions, model-steward and custodian roles and a digest-algorithm registry are not represented by any bundle, layer, finding or question and must not be presented as covered. No completeness is claimed for any jurisdiction, sector or contract form, nor for the ISO 21500/21502 and Horizon Europe codelist material the provider could not read. Single-provider mode: no node in this model has independent corroboration.",
    "confidence": "medium",
    "checklist": [
      {
        "dimension": "identity",
        "status": "covered",
        "notes": "Authoritative master-system identifier first, then governed global identifier, then Dimension-minted UUID/ULID; display numbers are designations only and dates are never identifiers. Uniqueness scope is an explicit field, grounded in the UK milestone ID rule and OCDS block-local uniqueness."
      },
      {
        "dimension": "lifecycle",
        "status": "covered",
        "notes": "Three separate state vocabularies are modelled (schedule status, submission status, achievement status) with a permitted-transition table, terminal states, supersession and cancellation. The gate decision that consumes a record is referenced, not owned."
      },
      {
        "dimension": "relationships",
        "status": "covered",
        "notes": "Links to project, stage, gate, work package, driving activity, parties, requirements, contract clause, component records and successor records are all typed references; no referenced model's internals are reproduced."
      },
      {
        "dimension": "temporal",
        "status": "covered",
        "notes": "Baseline, forecast, due, actual, delivery and approval dates are distinguished; RFC 3339 with seconds and explicit offset governs instants; event time is separated from observation/ingestion time; calendar commitments stay full-date; snapshots freeze reported values."
      },
      {
        "dimension": "provenance",
        "status": "covered",
        "notes": "Generation, attribution, delegation, use of prior inputs and revision lineage are modelled as reference triples projectable onto PROV-O, plus retained baseline and value history."
      },
      {
        "dimension": "ownership",
        "status": "covered",
        "notes": "Accountable party, contributing parties and authorised submitter are references into a party model; model steward, delivery data owner, acceptance liaison, classification custodian and interoperability maintainer roles are defined."
      },
      {
        "dimension": "validation",
        "status": "covered",
        "notes": "Declared acceptance criteria with measurability and source derivation, declared means of verification with timing and independence, cross-vocabulary consistency rules, the actual-date-not-in-the-future rule and acyclicity of part-whole links. Verification execution is referenced out."
      },
      {
        "dimension": "access",
        "status": "covered",
        "notes": "Deny-by-default at record granularity with bundle, layer, finding and artifact scopes; per-item dissemination and restricted/protected flags; explicit exceptions for classified material, public deliverables, submitter exclusivity, holds and break-glass. Enforcement is referenced, not owned."
      },
      {
        "dimension": "retention and deletion",
        "status": "covered",
        "notes": "Hard deletion prohibited while obligations, holds, open conditions or inbound references exist; tombstone field set defined; retention period, trigger and disposition execution explicitly owned by the adopting Dimension's records policy, the governing grant or contract clause and the repository model; acceptance-decision audit disposal is out of scope."
      },
      {
        "dimension": "interoperability",
        "status": "covered",
        "notes": "Explicit alignments to OCDS 1.1 Milestone/Document, the UK Programme and project data standard milestone entity, EU continuous reporting structures, PROV-O and RFC 3339, with declared field mappings, lossiness reporting and closed-codelist handling. Alignments are not claims of conformance."
      },
      {
        "dimension": "classification",
        "status": "covered",
        "notes": "Record kind, purpose type and governance category are separate coded axes bound to named vocabulary versions, with an extension rule for open codelists and a mapping rule for closed ones."
      },
      {
        "dimension": "composition",
        "status": "covered",
        "notes": "Part-whole decomposition, grouped submissions, roll-up rules producing partially-met states, and the artifact manifest as the material composition of a deliverable."
      },
      {
        "dimension": "authority and acceptance",
        "status": "covered",
        "notes": "Acceptance authority, delegation reference, place of acceptance, outcome codes including conditional acceptance, reserved rights for latent defects and fraud, and evidence documents, grounded in FAR Part 46 and EU portal decision recording."
      },
      {
        "dimension": "measurement and evidence",
        "status": "covered",
        "notes": "Variance between baseline, forecast and actual; criterion thresholds and tolerances; evidence document references with digest verification and an explicit evidence-absent quality flag."
      },
      {
        "dimension": "spatial",
        "status": "covered",
        "notes": "Place of acceptance is modelled because it determines the applicable quality-assurance regime, and publication location is modelled for public projections. No general geometry is carried, since delivery records are not intrinsically geospatial."
      },
      {
        "dimension": "security",
        "status": "covered",
        "notes": "Integrity digests from an active algorithm registry with an explicit statement that digests detect corruption but do not prove authenticity, plus prohibited-channel handling for classified material and a separation-of-duties policy."
      }
    ],
    "known_omissions": [
      "The exact Horizon Europe deliverable type codelist (report, dissemination, data, data management plan, other) and the exact dissemination-level tokens were seen only in secondary sources; the model therefore describes the axes generically and binds to the EU field names confirmed in first-party portal documentation rather than asserting the code tokens.",
      "ISO 21500:2021 and ISO 21502:2020 could not be read in full because ISO catalogue and preview content was not machine-retrievable in this session; they are not cited as a source of specific field definitions, and their alignment is deferred.",
      "Earned-value measurement techniques that attach credit to milestones (for example milestone weighting or 0/100 rules under ANSI/EIA-748) are not modelled; measurement is limited to date variance, and earned-value semantics are assumed to sit in a cost or performance-measurement model.",
      "Milestone-linked payment and performance-based payment mechanics are deliberately left to the contract model even though OCDS provides a payment milestone type.",
      "Agile increment semantics (definition of done, sprint goal, release increment) are not separately modelled; they are treated as an adopting-Dimension specialisation of acceptance criteria and record kind rather than as first-class structure.",
      "Multilingual titling and description beyond a single language tag per artifact is not modelled.",
      "No quantitative data-quality scoring scheme is specified beyond severity flags."
    ],
    "conflicts": [
      "Status vocabularies conflict across authorities: OCDS uses a closed set (scheduled, met, notMet, partiallyMet), the UK data standard uses On track, Off track, Completed, Superseded, and EU continuous reporting uses Pending, Draft, Submitted with an Accepted/Rejected officer decision. The model keeps three separate fields rather than forcing a single vocabulary, and records mapping loss where a closed codelist cannot absorb a local value.",
      "Date semantics conflict: OCDS types dueDate and dateMet as date-time, while the UK data standard types milestone dates as calendar dates (YYYY-MM-DD). The model treats plan commitments as calendar dates and decision or submission events as instants, and flags any projection that must widen or narrow precision.",
      "Baseline immutability conflicts with practice: the UK data standard states the baseline planned date should not change and is set once, while NASA explicitly provides for rebaselining above defined thresholds. The model resolves this by forbidding in-place edits and permitting an authorised rebaseline that retains the superseded value.",
      "Acceptance authority conflicts by regime: FAR vests acceptance in a contracting officer or an assigned office whose acceptance binds the government, whereas EU grant practice records acceptance by a programme officer against a submitted file. The model carries an authority reference and an authorising instrument rather than fixing a role.",
      "Milestone scope conflicts: EU guidance allows a milestone to span several work packages, while schedule-oriented guidance treats milestones as zero-duration events attached to specific activities. The model supports both via a primary work-package reference plus contributing references and a zero-duration flag."
    ],
    "regional_assumptions": [
      "FAR Part 46 acceptance semantics are United States federal procurement law; other jurisdictions and private contracts define acceptance differently, so acceptance authority, place and reserved-rights fields are parameterised rather than fixed.",
      "EU continuous reporting behaviour (submission statuses, one file per deliverable, coordinator-only submission, classified-material exception) reflects European Commission grant management and is treated as one alignment target, not as universal behaviour.",
      "UK GovS 002 stage-and-gate structure and the UK Programme and project data standard reflect UK central government practice; the latter is explicitly under consultation, so its field names are treated as provisional.",
      "NASA life-cycle reviews and Key Decision Points are agency-specific instances of the general gate pattern and are used only to justify the gate-association finding, not to impose a review taxonomy.",
      "Time-zone and calendar handling assumes the proleptic Gregorian calendar as used by RFC 3339; adopting Dimensions operating on other calendars must map into it explicitly."
    ],
    "adversarial_checks": [
      "Does any finding or function own a target model's lifecycle or operational semantics? The acceptance functions were narrowed to recording an outcome produced elsewhere; no function evaluates criteria, executes an approval, runs a test, enforces access or writes an audit trail. Criticality is carried as a flag from an external calculation, and retention is carried as an obligation reference with disposition executed elsewhere.",
      "Is the milestone/deliverable pair a false unification? Counterexample tested: a cross-work-package convergence checkpoint with no submitted artifact, and a submitted report that is not a schedule control point. Both are representable through the record-kind discriminator, the zero-duration flag and the submission-required flag, so the union is a discriminated union rather than a conflation.",
      "Could a single status field have sufficed? Counterexample tested: a deliverable submitted on time but rejected. Schedule status is Completed, submission status is Rejected and achievement status is notMet simultaneously; a single field would be forced to lie, which justifies three separate vocabularies.",
      "Is any structural node unsupported by a primary source? Each layer traces to at least one first-party or public-authority source. The weakest support is the definitional-scope-statement finding, which rests on the general requirement that deliverables be defined and agreed and on acceptance criteria presupposing a bounded scope; it is retained but flagged here as the least directly evidenced node.",
      "Does the model smuggle in benefits or outcomes? Checked against the output/outcome/benefit distinction: only the output or achievement record is modelled, and outcome and benefit measurement are placed in out_of_scope and in a boundary note.",
      "Could a date be used as an identifier anywhere? Serial naming uses a monotonic sequence with the timestamp held as a separate attribute, identity priority explicitly demotes dates and display numbers, and no local node identifier contains a date-like component.",
      "Does the artifact rule overreach into repository ownership? Only manifest metadata, media type, language, locator and digest are carried; bytes, versioning and disposition execution remain with the repository model, and unverifiable digests are flagged rather than resolved here."
    ]
  },
  "researchAdjudication": {
    "providerMode": "single-provider-waiver",
    "activeProviders": [
      "claude"
    ],
    "waivedProviders": [
      "grok"
    ],
    "providerPolicy": {
      "contract_version": "1.0.0",
      "mode": "single-provider-waiver",
      "effective_at": "2026-08-29T09:06:27Z",
      "scope": "Queued subject-model research from WM-XCT-013 onward",
      "active_providers": [
        "claude"
      ],
      "waived_providers": [
        {
          "provider": "grok",
          "authorized_by": "repository owner",
          "authorized_at": "2026-08-29T09:06:27Z",
          "reason": "The repository owner explicitly instructed the research queue to continue without Grok after repeated structured-output failures."
        }
      ],
      "review_rule": "Claude-only results require a separate no-tools adversarial audit and remain reviewable drafts with a visible single-provider hold."
    },
    "boundaryDecision": {
      "entry_kind": "entity",
      "status": "accepted",
      "rationale": "The aggregate root is one governed record of a planned achievement or an accepted output, which has stable identity, a lifecycle, revision lineage and an owner, so 'entity' is the correct ontological entry kind even though the milestone facet denotes a zero-duration event; event semantics are carried as attributes (actual date, achievement status, event-versus-observation time) rather than as a separate occurrence stream. The milestone/deliverable union survives adversarial challenge as a discriminated union rather than a conflation: the two tested counterexamples (a cross-work-package convergence checkpoint with no submitted artifact, and a submitted report that is not a schedule control point) are both representable through the record-kind discriminator, the zero-duration flag and the submission-required flag, and the two facets share one date set, one acceptance surface, one status triple and one provenance surface, so a split would fragment more than it separates. No second-provider evidence exists to justify a split, and this auditor may not add facts to support one. Ownership boundary is accepted: no finding or function evaluates criteria, executes an approval, runs a test, enforces access, calculates schedule network logic, stores bytes or executes disposition. The registry field entry_kind='standalone-mm' is a different vocabulary (registry entry type) and must not be overwritten with 'entity'; registry status='candidate' and review_state='boundary-review-required' must survive this audit unchanged."
    },
    "decisions": [
      {
        "concept": "Aggregate root: unified milestone/deliverable record",
        "disposition": "accepted as a discriminated union",
        "rationale": "Both tested counterexamples are representable via the record-kind discriminator, zero-duration flag and submission-required flag; the facets share the date set, acceptance surface, status triple and provenance surface, so splitting would fragment a genuinely shared record without any evidence in the pack supporting two roots."
      },
      {
        "concept": "Entry kind 'entity' versus frozen registry entry_kind 'standalone-mm'",
        "disposition": "accepted as entity; registry field left untouched",
        "rationale": "These are two vocabularies, not a contradiction: 'standalone-mm' classifies the registry entry, 'entity' classifies the modelled subject. The synthesizer must not write 'entity' into the registry entry_kind column nor advance status from 'candidate' or clear review_state 'boundary-review-required'."
      },
      {
        "concept": "Ownership of the acceptance-certificate artifact",
        "disposition": "flagged boundary defect; publish as reference-only or hold the artifact",
        "rationale": "The finding is titled 'Acceptance evidence reference' and its boundary note assigns production and retention of acceptance evidence to the approval and contract models, yet the pack declares acceptance-certificate as an owned serial artifact of this model. Both statements cannot be published unqualified; this is correctable by qualification, so it is not draft-blocking."
      },
      {
        "concept": "Coverage checklist over-claim against the published structure",
        "disposition": "coverage claim downgraded; checklist prose marked intended-not-published",
        "rationale": "The checklist asserts deny-by-default access at bundle/layer/finding/artifact scope, break-glass, model-steward, delivery-data-owner, acceptance-liaison, classification-custodian and interoperability-maintainer roles, and an active digest-algorithm registry, none of which exist as findings, layers or questions. Only 2 of 101 questions carry kind 'access' and neither asks who may read the record."
      },
      {
        "concept": "OCDS citations pinned to moving /latest/ locators",
        "disposition": "hold pending version-pinned URLs",
        "rationale": "SRC-005 and SRC-006 state version 1.1.5 but resolve to standard.open-contracting.org/latest/ paths, so the cited text can drift away from the pinned version silently and the citation is not reproducible as an artifact."
      },
      {
        "concept": "FAR claims made at section granularity on a part-level source record",
        "disposition": "deferred to live verification",
        "rationale": "Boundary notes make normative claims about FAR 46.501 contractual effect and 46.502 acceptance authority, while SRC-001 records only the Part 46 landing page with no version pin beyond an access date; the section text supporting the acceptance-authority and latent-defect/fraud reservations must be confirmed live."
      },
      {
        "concept": "SRC-010 (UK programme and project data standard) is under consultation yet grounds normative rules",
        "disposition": "retained as provisional; normative weight downgraded",
        "rationale": "It is authority tier 2, explicitly under consultation, cited on more than ten findings, and is the sole basis for the 'baseline set once' rule that the model then reconciles against NASA rebaselining and for the governance-category trichotomy; its field names and rules must not be published as settled."
      },
      {
        "concept": "Cross-aggregate roll-up in deliverable-composition",
        "disposition": "deferred; consistency boundary undeclared",
        "rationale": "Parent completion state is derived from sub-deliverable records that are themselves separate aggregate roots of this same model. The roll-up rule is declared but no transaction boundary, eventual-consistency semantics or staleness marker for the derived parent state is specified, which is a real modelling gap rather than a wording issue."
      },
      {
        "concept": "Retention disposition versus immutable historical values",
        "disposition": "deferred; precedence rule required",
        "rationale": "q-rev-history requires historical values to remain immutable so past reports reconcile, while retention-and-disposition-reference permits content disposition with a tombstone under an externally owned policy. Which values survive disposal, and whether variance history is inside the tombstone field set, is unstated."
      },
      {
        "concept": "Identity scope of the three serial artifacts",
        "disposition": "deferred; serial scope unstated",
        "rationale": "deliverable-artifact, submission-manifest and acceptance-certificate are all serial:true, but no question or finding declares the scope within which the serial sequence is unique, whereas record identity scope is explicit via q-identity-scope. Artifact identity is therefore weaker than record identity."
      },
      {
        "concept": "Findings with no corresponding function (classification, publication, retention hold, alternate identifiers)",
        "disposition": "rejected as an addition; recorded as a gap only",
        "rationale": "Single-provider mode forbids adding functions and this auditor may not add facts. The ten functions run registration through external projection but leave sensitivity-classification, publication-binding and retention-and-disposition-reference without any operation, and q-identity-alternates has no function that binds an alternate identifier."
      },
      {
        "concept": "Relationship contract covers only WM-ACT-005 CONTAINS while seven boundary notes reference unregistered neighbours",
        "disposition": "accepted as consistent but incomplete; no relations inferred",
        "rationale": "The contract is not contradicted, but the schedule/activity, approval, repository, contract, quality, benefits, party and requirement neighbours carry no model IDs, so the declared dependency surface cannot be validated against the registry. Inferring those relations would require adding facts, which is prohibited here."
      },
      {
        "concept": "Purpose asserts programme scope that the frozen contract does not carry",
        "disposition": "retain wording with a visible caveat; flag for owner",
        "rationale": "The purpose places the record 'inside a project or programme' while only Project (WM-ACT-005) CONTAINS is frozen; programme containment is unregistered and must not be read as an established relation in any published artifact."
      },
      {
        "concept": "Absent legacy source material",
        "disposition": "accepted as vacuous, reported as unverified",
        "rationale": "No previous-version material is registered, so legacy reconciliation is impossible rather than clean. The absence must be reported as unverified and must not be presented as evidence that the model is novel or non-duplicative, especially with factor_overlap recorded at 0.06 on low priority confidence."
      },
      {
        "concept": "Three separate status vocabularies",
        "disposition": "accepted",
        "rationale": "The submitted-on-time-but-rejected counterexample forces schedule status Completed, submission status Rejected and achievement status notMet simultaneously, so collapsing to one field would misreport; closed external codelists are handled by the declared mapping-loss rule rather than by forcing a single vocabulary."
      }
    ],
    "publicationHolds": [
      "Live source and version verification is outstanding for all twelve sources: confirm GovS 002 is still at version 2.1, that NPR 7120.5F w/Change 4 has not been superseded ahead of its 2027-02-03 expiry, that the current consolidated FAR Part 46 text still supports the 46.501 and 46.502 claims at section level, and that the two EU portal pages (SRC-002 last modified 2021-06-04, SRC-003 carrying only an access date) still describe current continuous-reporting behaviour.",
      "Independent second-provider review is absent under an explicit repository-owner waiver recorded at 2026-08-29T09:06:27Z naming Grok as waived after repeated structured-output failures. Every published artifact must carry a visible single-provider hold stating that no independent corroboration exists, and the result remains a reviewable draft rather than an approved model.",
      "SRC-005 and SRC-006 must be republished with version-pinned OCDS 1.1.5 locators before release; the current /latest/ URLs will drift away from the version asserted in the citation text.",
      "The coverage checklist must be reconciled with the published structure before release: the access, ownership-role and security entries describe policy that no finding, layer or question carries, and publishing them unqualified would overstate structural coverage.",
      "The acceptance-certificate artifact must be rendered reference-only or held: as published, the model simultaneously declares it an owned serial artifact and assigns its production and retention to the approval and contract models.",
      "SRC-010 must be labelled provisional wherever it is relied on, because it is explicitly under consultation and carries the baseline 'set once' rule and the governance-category vocabulary.",
      "This audit does not advance registry state: status must remain 'candidate' and review_state must remain 'boundary-review-required' until a human owner review closes the boundary question.",
      "Independent second-provider review was explicitly waived by the repository owner; this Claude-only result remains a reviewable draft."
    ],
    "deferredResearch": [
      "Confirm the Horizon Europe deliverable type codelist and dissemination-level tokens against first-party portal documentation; the pack deliberately describes the axes generically because only secondary sources were reachable.",
      "Complete the ISO 21500:2021 and ISO 21502:2020 alignment that could not be read in this session, and state explicitly whether either changes the milestone/deliverable typology or the acceptance vocabulary.",
      "Register model IDs for the schedule/activity, approval/decision-authority, document/artifact repository, contract/agreement, quality/verification, benefits/outcome, party and requirement neighbours so the seven boundary notes can be validated against the relationship contract instead of against prose.",
      "Decide the precedence rule between the immutable-history requirement (q-rev-history) and permitted content disposition under the retention obligation, and specify which retained values belong to the tombstone field set.",
      "Specify the consistency boundary for the part-whole roll-up: whether a parent's derived completion state is transactional with its children, eventually consistent, or explicitly marked stale.",
      "Declare the uniqueness scope of the serial identifiers for deliverable-artifact, submission-manifest and acceptance-certificate, mirroring the explicit record-level identifier scope.",
      "Decide whether access policy (read scoping, break-glass, separation of duties) becomes a published structural node of this model or is fully delegated to the access-control model, and align the coverage checklist to whichever is chosen.",
      "Resolve the deferred omissions the provider recorded: earned-value milestone credit semantics under ANSI/EIA-748, milestone-linked payment mechanics left to the contract model, agile increment semantics, multilingual titling beyond one language tag per artifact, and any quantitative data-quality scoring beyond severity flags.",
      "Re-examine whether nav_path NAV.ACT.MIL and domain_tags ACT.MIL leave the deliverable facet of a two-facet model discoverable, as a registry-owned naming decision."
    ]
  },
  "statistics": {
    "sources": 12,
    "bundles": 6,
    "layers": 12,
    "findings": 28,
    "questions": 101,
    "artifacts": 3,
    "functions": 10
  }
}