# Vercy AI instruction - YAML 1.2 (JSON-compatible) { "vercy": "1.0-draft", "publication": { "status": "published", "adjudicationStatus": "reviewable-draft", "publishableCanonical": false, "generatedAt": "2026-08-29T14:11:55Z", "synthesisSha256": "72366cc733f9d11956424b2aba762ed5a4a9b25cd349c80266e7371a87647464", "providerMode": "single-provider-waiver", "providers": [ "Claude" ], "waivedProviders": [ "Grok" ] }, "metaModel": { "id": "WM-ACT-032", "registryId": "vr.wm-act-032", "name": "Change Request", "version": "0.3.0-research.1", "previousVersions": [], "entryKind": "entity", "family": "World Models", "category": "Activities and processes", "industry": [ "Cross-industry" ], "domain": [ "ACT.CHG" ], "tags": [ "change", "request", "act.chg" ], "status": "published" }, "canonicalUrl": "https://ver.cy/models/wm-act-032-change-request/", "sourceUrl": "https://github.com/ver-cy/world-models/tree/feat/mega-model-registry/research/runs/wm-act-032", "model": { "registry_id": "vr.wm-act-032", "model_id": "WM-ACT-032", "name": "Change Request", "entry_kind": "entity", "purpose": "Represent a formal, identifiable proposal to alter a controlled subject (configuration item, document, requirement set, service or process), together with its classification, justification, impact and risk assessment, routing to a competent change authority, and the disposition recorded against it.", "scope_statement": "This model defines the change request as a record: what is proposed, against which baseline, why, with what assessed impact, to which authority it is routed, and what disposition and effectivity it carries. It is format-neutral: JSON, RDF/Turtle, Markdown, relational and document stores are projections. It owns the request-side view only. It does not own the requirement records it traces to (WM-REC-006), the decision that resolves it (WM-KNW-010), the configuration items and baselines it targets, the work that implements it, or the audit-trail store that evidences handling.", "in_scope": [ "Identity, origination and provenance of the change request record itself", "Statement of the proposed change as a delta from an approved baseline, and the set of affected items, documents, interfaces and sites", "Classification of the request: change type (standard, normal, emergency), instrument kind (permanent change, deviation, waiver), priority, urgency and claimed severity", "Justification, drivers and outgoing traceability references to requirements, defects, nonconformances and audit findings", "Impact, effort, risk, safety, security, privacy and regulatory-notification assessment content produced for this request", "Routing metadata: which change authority was selected, on which criteria values, and whether the package is admissible", "Disposition outcome recorded on the request, the binding to the authoritative decision record, and attached conditions and effectivity terms", "Request state model, permitted transitions, supersession, withdrawal and reopening", "Proposed implementation approach, backout intent, test intent and proposed window, as proposal content only", "Closure recording, realisation references, variance between proposed and realised change, and evidence references", "Retention class, legal-hold flags and confidentiality classification declared on the request record", "Status accounting extracts and population measures over change request records" ], "out_of_scope": [ "Requirement definition, requirement text, requirement versioning, requirement baselining and requirement lifecycle (owned by WM-REC-006)", "Decision semantics: deliberation, alternatives evaluation, decision rationale, decider mandate and decision-record lifecycle (owned by WM-KNW-010)", "Definition of change-authority mandates, delegation limits and decision rights; this model records only which authority was routed to", "Execution of the change: work orders, tasks, builds, change sets, releases, deployments and rollback execution", "Configuration item master data, baseline composition and the issuing of new baselines", "The audit-trail store and any evaluation, enforcement or attestation engine; access decisions are evaluated externally", "Incident, problem, defect and nonconformance triage and lifecycle", "Enterprise risk register lifecycle; only assessment outputs attached to this request are held here", "Contractual change orders, variation pricing and contract amendment execution", "Organisational (people-side) change adoption management", "Execution of retention schedules, disposal and destruction certification", "Person, role and organisation master data and identity proofing" ], "boundary_notes": [ { "neighbor": "WM-REC-006 Requirement", "distinction": "The request carries typed trace references (affects, implements, tracks) with a version binding, mirroring OSLC CM link semantics. Requirement content, state and re-baselining are read-only from here; a withdrawn requirement invalidates the local link, not the requirement.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003" ] }, { "neighbor": "WM-KNW-010 Decision", "distinction": "The request records the disposition value, the disposition timestamp and a reference to the decision record. Rationale, options considered, deliberation and the authority's mandate live in the decision model. Reversal is expressed here as a new state bound to a new decision reference, never as an edit of a prior outcome.", "source_refs": [ "SRC-001", "SRC-003", "SRC-012" ] }, { "neighbor": "Change implementation, work-order and release model", "distinction": "Everything before disposition is proposal content; everything after is execution. The request holds a proposed window, approach outline and backout intent; scheduling, task state, deployment and rollback execution belong to the executing model, referenced through a tracked change-set or work-record link.", "source_refs": [ "SRC-002", "SRC-004", "SRC-012" ] }, { "neighbor": "Configuration item and baseline model", "distinction": "Affected items and the target baseline are referenced by identifier and version. This model never asserts item structure or releases a new baseline; configuration identification and baseline release are separate configuration management activities.", "source_refs": [ "SRC-003", "SRC-007", "SRC-013" ] }, { "neighbor": "Deviation and waiver (concession) requests", "distinction": "A deviation authorises departure before manufacture or delivery, and a waiver accepts an already-nonconforming item; neither alters approved configuration documentation, whereas a change proposal does. The model classifies the instrument kind and holds expiry and quantity limits, but does not merge the two concepts.", "source_refs": [ "SRC-013", "SRC-007" ] }, { "neighbor": "Problem, defect and nonconformance records", "distinction": "An originating defect is a trigger reference (OSLC affectedByDefect). Defect triage, reproduction and closure remain with the originating model; closing a request does not close the defect.", "source_refs": [ "SRC-001", "SRC-002" ] }, { "neighbor": "Audit trail and status accounting store", "distinction": "Status accounting extracts produced here are read-only projections over request records at a stated as-at instant. Immutable event logging, tamper evidence and audit-record retention are owned by the adopting Dimension's audit store; a reference to it grants no audit-trail semantics.", "source_refs": [ "SRC-003", "SRC-005", "SRC-006" ] }, { "neighbor": "Records management and retention policy", "distinction": "The request declares a retention class, a legal-hold flag and a tombstone shape. Schedule authorship, disposal execution and destruction evidence are owned by the adopting Dimension's records policy and, where regulated, by the applicable quality management system regulation.", "source_refs": [ "SRC-011", "SRC-003" ] }, { "neighbor": "Service request / standard pre-approved request", "distinction": "A pre-authorised standard change is still a change request with an authority pre-bound by a change model; a service request that consumes an existing, unchanged service capability is not in scope.", "source_refs": [ "SRC-004", "SRC-012" ] } ] }, "sources": [ { "id": "SRC-001", "title": "OSLC Change Management Version 3.0. Part 1: Specification", "organization": "OASIS Open Projects (OSLC Open Project)", "url": "https://docs.oasis-open-projects.org/oslc-op/cm/v3.0/os/change-mgt-spec.html", "version_or_date": "Version 3.0, OASIS Standard, 26 May 2021", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-29T09:10:00Z", "relevance": "Normative resource model for a ChangeRequest: resource types (ChangeRequest, ChangeNotice, Defect, Enhancement, ReviewTask, Task), state handling, relationship properties and representation requirements. Primary anchor for identity, relationships and interoperability." }, { "id": "SRC-002", "title": "OSLC Change Management Version 3.0. Part 2: Vocabulary", "organization": "OASIS Open Projects (OSLC Open Project)", "url": "https://docs.oasis-open-projects.org/oslc-op/cm/v3.0/os/change-mgt-vocab.html", "version_or_date": "Version 3.0, OASIS Standard, 26 May 2021 (namespace http://open-services.net/ns/cm#)", "source_type": "schema", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-29T09:11:00Z", "relevance": "Field-level vocabulary: approved, authorizer, closed, closeDate, fixed, inProgress, reviewed, verified, state, status, priority, severity, parent, relatedChangeRequest, affectsRequirement, implementsRequirement, tracksRequirement, affectedByDefect, tracksChangeSet. Grounds candidate data elements and alignment mappings." }, { "id": "SRC-003", "title": "ISO 10007:2017 Quality management — Guidelines for configuration management", "organization": "International Organization for Standardization (ISO)", "url": "https://www.iso.org/standard/70400.html", "version_or_date": "Third edition, 2017-06; replaces ISO 10007:2003", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-29T09:12:00Z", "relevance": "Defines the configuration management process as configuration management planning, configuration identification, change control, configuration status accounting and configuration audit. Establishes change control and status accounting as the process context for a change request. Guidance, not certifiable." }, { "id": "SRC-004", "title": "ISO/IEC 20000-1:2018 Information technology — Service management — Part 1: Service management system requirements", "organization": "ISO/IEC JTC 1", "url": "https://www.iso.org/standard/70636.html", "version_or_date": "Edition 3, 2018-09; reviewed and confirmed 2023", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-29T09:13:00Z", "relevance": "Management-system requirements covering configuration, change, release and deployment within a service management system. Supports admissibility, routing and closure obligations expressed as requirements rather than practice." }, { "id": "SRC-005", "title": "NIST Special Publication 800-53 Revision 5, Update 1: Security and Privacy Controls for Information Systems and Organizations", "organization": "National Institute of Standards and Technology (NIST)", "url": "https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final", "version_or_date": "Rev. 5, September 2020, updates through 10 December 2020", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-29T09:14:00Z", "relevance": "Catalogue containing the Configuration Management (CM) control family, the reference point for documented change proposals, impact analysis and change approval expectations in security-regulated adopting Dimensions." }, { "id": "SRC-006", "title": "NIST Special Publication 800-128: Guide for Security-Focused Configuration Management of Information Systems", "organization": "National Institute of Standards and Technology (NIST)", "url": "https://csrc.nist.gov/pubs/sp/800/128/upd1/final", "version_or_date": "August 2011, updated 10 October 2019", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-29T09:15:00Z", "relevance": "Security-focused configuration management guidance covering configuration change control, security impact analysis and monitoring. Grounds the security-impact assessment finding and the separation of assessment from enforcement." }, { "id": "SRC-007", "title": "ECSS-M-ST-40C Rev.1 — Configuration and information management", "organization": "European Cooperation for Space Standardization (ECSS) / European Space Agency", "url": "https://ecss.nl/standard/ecss-m-st-40c-rev-1-configuration-and-information-management/", "version_or_date": "Rev.1, 6 March 2009", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-29T09:16:00Z", "relevance": "Requirements for configuration and information management across customer and supplier levels in space projects, including change and information control against baselines. Independent (non-US, non-IT) confirmation that change requests are baseline-relative and multi-party." }, { "id": "SRC-008", "title": "NPR 7123.1D — NASA Systems Engineering Processes and Requirements (Updated w/ Change 2)", "organization": "National Aeronautics and Space Administration (NASA)", "url": "https://nodis3.gsfc.nasa.gov/displayDir.cfm?t=NPR&c=7123&s=1D", "version_or_date": "Effective 5 July 2023; expiration 5 July 2028", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-29T09:17:00Z", "relevance": "Directive establishing configuration management and technical assessment as common technical processes with defined products and reviews. Supports assessment provenance, status accounting and the distinction between technical assessment and decision analysis." }, { "id": "SRC-009", "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": "July 2002, Proposed Standard", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-29T09:18:00Z", "relevance": "Normative timestamp format: seconds are part of the grammar and time-offset is either 'Z' or a numeric +/-HH:MM offset; '-00:00' denotes a known UTC instant with unknown local offset. Governs every time value in this model." }, { "id": "SRC-010", "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", "source_type": "ontology", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-29T09:19:00Z", "relevance": "Entity/Activity/Agent with wasAttributedTo, wasAssociatedWith, wasGeneratedBy, wasDerivedFrom, generatedAtTime and invalidatedAtTime. Alignment target for record-level provenance of requests and their assessments, keeping provenance format-neutral." }, { "id": "SRC-011", "title": "Quality Management System Regulation (QMSR)", "organization": "U.S. Food and Drug Administration (FDA)", "url": "https://www.fda.gov/medical-devices/postmarket-requirements-devices/quality-management-system-regulation-qmsr", "version_or_date": "Final rule published 2 February 2024 (89 FR 7496); effective 2 February 2026; incorporates ISO 13485:2016 by reference into 21 CFR part 820", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-29T09:20:00Z", "relevance": "Worked example of a jurisdiction where controlled change, change records and retention obligations are legally binding and where the regulation delegates detail to an incorporated international standard. Grounds regulatory-notification and retention findings, and the regional-assumption caveats." }, { "id": "SRC-012", "title": "Change enablement in ITIL 4 — Change Enablement in the Cloud (AWS Well-Architected)", "organization": "Amazon Web Services", "url": "https://docs.aws.amazon.com/wellarchitected/latest/change-enablement-in-the-cloud/change-enablement-in-itil4.html", "version_or_date": "Accessed 29 August 2026; cites ITIL 4 Change Enablement Practice Guide (PeopleCert)", "source_type": "first-party-doc", "primary_source": false, "authority_tier": 3, "accessed_at": "2026-08-29T09:21:00Z", "relevance": "Restates the ITIL 4 definition of a service change ('addition, modification, or removal of anything that could have a direct or indirect effect on services') and the purpose of change enablement (assess risk, authorise, manage the change schedule). Used because ITIL 4 itself is not openly published; treated as secondary evidence of common practice, not as a normative requirement." }, { "id": "SRC-013", "title": "MIL-HDBK-61A(SE) Configuration Management Guidance", "organization": "U.S. Department of Defense (Office of the Under Secretary of Defense, Systems Engineering); copy hosted by AcqNotes", "url": "https://www.acqnotes.com/Attachments/MIL-HDBK-61A%20(SE)Configuration%20Management%20Guidance.pdf", "version_or_date": "7 February 2001 (handbook); mirrored copy accessed 29 August 2026", "source_type": "secondary", "primary_source": false, "authority_tier": 3, "accessed_at": "2026-08-29T09:22:00Z", "relevance": "Used only for terminology discrimination between engineering change proposal, request for deviation and request for waiver, and for effectivity concepts (units, serials, lots). Cited as a mirrored copy, so treated as secondary; no process obligation is imported from it." } ], "structure": { "bundles": [ { "id": "request-identity-and-subject", "name": "Request Identity and Change Subject", "description": "What a change request instance is, how it is identified and originated, and exactly which controlled subject, baseline and scope the proposal targets.", "rationale": "Change control begins with unambiguous identification of the proposal and of the items and baseline it would alter; without both, the request cannot be routed, assessed, traced or reported. ISO 10007 places change control after configuration identification for this reason, and OSLC gives the ChangeRequest a resource identity independent of any store.", "source_refs": [ "SRC-001", "SRC-003", "SRC-007" ], "layers": [ { "id": "identity-and-origination", "name": "Identity and Origination", "description": "The identifiers that make a request addressable and the provenance of its raising.", "source_refs": [ "SRC-001", "SRC-003", "SRC-010" ], "findings": [ { "id": "request-identity", "name": "Change request identity and addressability", "description": "The authoritative key of the request, any governed global identifier, revision labelling, and the boundary between the request record, the change itself and the decision that resolves it.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003", "SRC-010" ], "questions": [ { "id": "q-identity-key", "text": "Which identifier is the authoritative key for this change request, and which system issues it?", "kind": "identity", "answer_data": [ "Issuing master system reference", "Authoritative identifier value", "Identifier scheme or format rule" ] }, { "id": "q-identity-definition", "text": "What distinguishes the change request record from the change itself and from the decision that dispositions it?", "kind": "definition", "answer_data": [ "Definition of the record boundary", "Named neighbouring concepts and their owning models" ] }, { "id": "q-identity-revision", "text": "How are successive revisions of the same request distinguished from a genuinely new request?", "kind": "provenance", "answer_data": [ "Revision label or sequence value", "Rule for when a revision becomes a new request", "Predecessor record reference" ] }, { "id": "q-identity-namespace", "text": "Under which namespace or IRI scheme is the request identifier resolvable outside the issuing system?", "kind": "interoperability", "answer_data": [ "Namespace or base IRI", "Resolution endpoint or catalogue reference", "Stability and reassignment policy" ] } ], "data_elements": [ { "id": "de-request-identifier", "name": "Request identifier", "description": "Authoritative master-system identifier of the change request.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-003" ] }, { "id": "de-request-iri", "name": "Request IRI", "description": "Governed global identifier or IRI under which the request is resolvable across systems.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001", "SRC-002" ] }, { "id": "de-request-revision-label", "name": "Revision label", "description": "Label distinguishing successive revisions of the same request.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003", "SRC-007" ] }, { "id": "de-issuing-system-ref", "name": "Issuing system reference", "description": "Reference to the system of record that minted the authoritative identifier.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-003", "SRC-010" ] } ], "artifacts": [], "inline_only_rationale": "Identity is pure inline reference data: identifier values, a namespace binding and a revision label. Materialising an identity document would create a second thing to keep synchronised with the record it names, and no cited source requires an identity artifact distinct from the request record itself." }, { "id": "origination-and-submission", "name": "Origination, submitter and intake", "description": "Who raised the request and under what mandate, what triggered it, when it was submitted, when the register observed it, and through which intake route.", "source_refs": [ "SRC-001", "SRC-009", "SRC-010", "SRC-012" ], "questions": [ { "id": "q-origin-submitter", "text": "Who submitted the request, and on whose behalf or under which mandate did they act?", "kind": "ownership", "answer_data": [ "Submitter party reference", "On-behalf-of party reference", "Mandate or role reference" ] }, { "id": "q-origin-trigger", "text": "What triggering event or observation caused the request to be raised?", "kind": "event", "answer_data": [ "Trigger classification code", "Reference to the originating event or record", "Trigger description" ] }, { "id": "q-origin-times", "text": "When was the request submitted, and when was that submission first recorded by the register?", "kind": "temporal", "answer_data": [ "Submission event timestamp", "Register ingestion timestamp", "Rule applied when the two differ" ] }, { "id": "q-origin-channel", "text": "Through which intake route did the request enter the register, and is that route trusted?", "kind": "provenance", "answer_data": [ "Intake channel code", "Channel trust level or authentication basis", "Automated or human origination flag" ] } ], "data_elements": [ { "id": "de-submitter-ref", "name": "Submitter reference", "description": "Reference to the party that raised the request, resolved in the party model.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-002", "SRC-010" ] }, { "id": "de-submitted-at", "name": "Submitted at", "description": "RFC 3339 event time at which the request was submitted.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-009" ] }, { "id": "de-recorded-at", "name": "Recorded at", "description": "RFC 3339 observation or ingestion time at which the register captured the submission.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-009", "SRC-010" ] }, { "id": "de-origination-trigger-ref", "name": "Origination trigger reference", "description": "Reference to the defect, incident, audit finding, obligation or observation that triggered the request.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-002" ] }, { "id": "de-intake-channel", "name": "Intake channel", "description": "Coded route through which the request entered the register.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] } ], "artifacts": [], "inline_only_rationale": "Origination is captured as attribution and timestamp fields aligned to PROV-O agent and time properties. There is no separately governed submission document; producing one would duplicate fields already carried on the request and would fork provenance across two objects." } ] }, { "id": "change-subject-and-delta", "name": "Change Subject and Proposed Delta", "description": "The controlled items and baseline targeted by the request and the substance of what would change.", "source_refs": [ "SRC-003", "SRC-007", "SRC-013" ], "findings": [ { "id": "affected-items-and-baseline-scope", "name": "Affected items, baseline and scope boundary", "description": "The configuration items, documents, interfaces and services the change would alter, the baseline the delta is expressed against, the sites or environments in scope, and explicit exclusions.", "source_refs": [ "SRC-003", "SRC-007", "SRC-013", "SRC-005" ], "questions": [ { "id": "q-scope-items", "text": "Which configuration items, documents, interfaces or services would the proposed change alter?", "kind": "composition", "answer_data": [ "Affected item references with versions", "Item category per reference", "Direct versus indirect impact flag" ] }, { "id": "q-scope-baseline", "text": "Against which baseline or approved configuration is the proposed delta expressed?", "kind": "relationship", "answer_data": [ "Baseline reference and version", "Baseline type", "Date or event at which the baseline was frozen" ] }, { "id": "q-scope-sites", "text": "Which sites, fleets, environments or organisational units fall inside the proposed scope?", "kind": "spatial", "answer_data": [ "Site, facility or environment references", "Jurisdiction codes where relevant", "Population or fleet selector" ] }, { "id": "q-scope-exclusions", "text": "What is explicitly excluded from the proposed scope, and why?", "kind": "constraint", "answer_data": [ "Exclusion statements", "Reason per exclusion", "Items deliberately left on the current baseline" ] } ], "data_elements": [ { "id": "de-affected-item-refs", "name": "Affected item references", "description": "References to configuration items, documents, interfaces or services in scope, each with a version binding.", "value_kind": "reference", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-003", "SRC-007" ] }, { "id": "de-baseline-ref", "name": "Baseline reference", "description": "Reference to the approved baseline against which the delta is stated.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-003", "SRC-007" ] }, { "id": "de-scope-site-refs", "name": "Scope site or environment references", "description": "Sites, environments, fleets or jurisdictions to which the proposal applies.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-013", "SRC-005" ] }, { "id": "de-scope-exclusion", "name": "Scope exclusion statement", "description": "Explicit statement of what the proposal does not cover.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003" ] } ], "artifacts": [], "inline_only_rationale": "Scope is a set of typed references plus short exclusion statements. Item structure, versions and baseline composition are owned by the configuration item and baseline model; copying them into a local artifact would create a stale duplicate of another model's authoritative content." }, { "id": "proposed-change-delta", "name": "Proposed change delta", "description": "The substance of the proposal expressed as a difference from the current approved state, its content classification, and the feasibility evidence submitted with it.", "source_refs": [ "SRC-003", "SRC-007", "SRC-001", "SRC-012" ], "questions": [ { "id": "q-delta-content", "text": "What exactly is proposed to change, expressed as a delta from the current approved state?", "kind": "definition", "answer_data": [ "As-is description", "To-be description", "Delta statement per affected item" ] }, { "id": "q-delta-kind", "text": "Which content classification applies to the delta: addition, modification, removal or reversion?", "kind": "classification", "answer_data": [ "Delta kind code", "Reversion target reference where applicable" ] }, { "id": "q-delta-representation", "text": "How is the delta represented so that it stays readable independently of any storage format?", "kind": "interoperability", "answer_data": [ "Representation convention for the delta", "Media type or notation used", "Rendering rules for non-text deltas" ] }, { "id": "q-delta-feasibility", "text": "What evidence accompanies the request that the described delta is technically achievable as stated?", "kind": "evidence", "answer_data": [ "Feasibility statement", "References to analyses, prototypes or prior art", "Stated assumptions and their confidence" ] } ], "data_elements": [ { "id": "de-as-is-description", "name": "As-is description", "description": "Description of the current approved state of the affected subject.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "de-to-be-description", "name": "To-be description", "description": "Description of the proposed state after the change.", "value_kind": "text", "cardinality": "1", "required": true, "source_refs": [ "SRC-003", "SRC-012" ] }, { "id": "de-delta-kind", "name": "Delta kind", "description": "Coded classification of the change content as addition, modification, removal or reversion.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-012", "SRC-013" ] }, { "id": "de-feasibility-note", "name": "Feasibility note", "description": "Statement and supporting references on the technical achievability of the delta.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007", "SRC-008" ] } ], "artifacts": [ { "id": "change-proposal-statement", "name": "Change proposal statement", "description": "The governed statement of the proposed change: as-is state, to-be state, per-item delta, content classification and stated assumptions. It is the object a change authority reads and the object a disposition attaches to.", "media_or_form": [ "structured record", "narrative text (Markdown, HTML or PDF rendering)", "tabular per-item delta list", "attached engineering representation (drawing, model or diff)" ], "serial": true, "identity_strategy": "Identified by the parent request identifier plus a monotonically increasing revision label; each revision is retained and never overwritten, so a disposition always names the exact revision it dispositioned.", "source_refs": [ "SRC-003", "SRC-007", "SRC-013" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "classification-and-justification", "name": "Classification and Justification", "description": "How the request is typed and prioritised, why it is being made, and what it traces back to.", "rationale": "Change type determines the route, the required content and the authority; justification and traceability are what allow the request to be judged and later audited. ITIL 4 distinguishes standard, normal and emergency changes; configuration management practice distinguishes configuration-changing proposals from deviations and waivers; OSLC provides the trace link vocabulary.", "source_refs": [ "SRC-002", "SRC-012", "SRC-013" ], "layers": [ { "id": "classification-and-typing", "name": "Classification and Typing", "description": "The type, instrument kind, governing change model and relative importance assigned to the request.", "source_refs": [ "SRC-012", "SRC-013", "SRC-004" ], "findings": [ { "id": "change-type-and-change-model", "name": "Change type, instrument kind and governing change model", "description": "Assignment of standard, normal or emergency type; discrimination between a permanent configuration change and a time- or quantity-limited deviation or waiver; the change model or template that governs handling; and any regulated category that forces a stricter route.", "source_refs": [ "SRC-012", "SRC-013", "SRC-004", "SRC-011" ], "questions": [ { "id": "q-type-assignment", "text": "Which change type applies to this request, and what evidence supports that assignment?", "kind": "classification", "answer_data": [ "Change type code", "Criteria values that produced the assignment", "Assigning party reference" ] }, { "id": "q-type-instrument", "text": "Is this a permanent configuration change, or a time- or quantity-limited departure that leaves the approved configuration documentation unchanged?", "kind": "exception", "answer_data": [ "Instrument kind code (change, deviation, waiver)", "Limit basis where the instrument is limited", "Reason the documentation is or is not altered" ] }, { "id": "q-type-model", "text": "Which change model, template or pre-authorised procedure governs the handling of this request?", "kind": "process", "answer_data": [ "Change model reference", "Pre-authorisation status", "Deviations from the model and their justification" ] }, { "id": "q-type-regulated", "text": "Which regulated, safety-related or contractual category does the change fall into, and does that category force a stricter route?", "kind": "requirement", "answer_data": [ "Regulated category codes", "Applicable regime reference", "Route escalation triggered by the category" ] } ], "data_elements": [ { "id": "de-change-type", "name": "Change type", "description": "Coded change type such as standard, normal or emergency.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-012", "SRC-004" ] }, { "id": "de-instrument-kind", "name": "Instrument kind", "description": "Whether the request is a configuration-changing proposal, a deviation or a waiver.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-013", "SRC-007" ] }, { "id": "de-change-model-ref", "name": "Change model reference", "description": "Reference to the change model, template or pre-authorised procedure applied.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "de-regulated-category", "name": "Regulated category", "description": "Coded regulatory, safety or contractual category attaching to the change.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-011", "SRC-005" ] } ], "artifacts": [], "inline_only_rationale": "Classification is a small set of coded values plus the criteria values that produced them. The code lists themselves are governed by external classifier registries of the adopting Dimension and are referenced, not reproduced here as an artifact." }, { "id": "priority-urgency-and-severity", "name": "Priority, urgency and claimed severity", "description": "The relative importance assigned to the request, the urgency imposed by a need date or exposure window, the severity of consequence claimed if the change is not made, and how these are recomputed as the request changes.", "source_refs": [ "SRC-002", "SRC-012", "SRC-004" ], "questions": [ { "id": "q-priority-value", "text": "What priority value is assigned to the request, on which defined scale, and by whom?", "kind": "measurement", "answer_data": [ "Priority value", "Scale definition reference", "Assigning party and timestamp" ] }, { "id": "q-priority-consequence", "text": "What consequence and severity are claimed if the request is not implemented?", "kind": "evidence", "answer_data": [ "Severity value and scale", "Consequence statement", "Supporting analysis reference" ] }, { "id": "q-priority-deadline", "text": "By which date or event must the request be dispositioned for it to remain useful?", "kind": "temporal", "answer_data": [ "Need-by timestamp or event reference", "Exposure or opportunity window", "Consequence of missing the window" ] }, { "id": "q-priority-recompute", "text": "How are priority and urgency recomputed when the request is superseded or its scope changes?", "kind": "state", "answer_data": [ "Recomputation trigger conditions", "Prior values with their validity intervals", "Party responsible for revaluation" ] } ], "data_elements": [ { "id": "de-priority", "name": "Priority", "description": "Assigned relative importance of the request on a declared scale.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002", "SRC-012" ] }, { "id": "de-severity", "name": "Severity", "description": "Claimed severity of consequence if the request is not implemented.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "de-needed-by", "name": "Needed-by instant", "description": "RFC 3339 instant or referenced event by which disposition is required.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009", "SRC-012" ] }, { "id": "de-priority-scale-ref", "name": "Priority scale reference", "description": "Reference to the scale definition that gives the priority and severity codes their meaning.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002", "SRC-004" ] } ], "artifacts": [], "inline_only_rationale": "Priority, urgency and severity are coded scalar values with a scale reference and a revaluation history. They are queried and sorted as fields; a document form would obstruct the population-level ranking these values exist to support." } ] }, { "id": "justification-and-traceability", "name": "Justification and Traceability", "description": "The stated reason for the change and the outgoing trace references that make it auditable.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003" ], "findings": [ { "id": "drivers-and-justification", "name": "Drivers, justification and claimed benefit", "description": "The business, technical, safety, security or regulatory driver behind the request, the consequence of inaction, any obligation that compels the change, and the benefit claimed with its measurement basis.", "source_refs": [ "SRC-003", "SRC-012", "SRC-011", "SRC-006" ], "questions": [ { "id": "q-driver-category", "text": "What driver justifies the request, and into which driver category does it fall?", "kind": "definition", "answer_data": [ "Driver category code", "Justification narrative", "Originating stakeholder reference" ] }, { "id": "q-driver-inaction", "text": "What would be the consequence of taking no action, and over what horizon?", "kind": "evidence", "answer_data": [ "Do-nothing consequence statement", "Time horizon", "Supporting analysis reference" ] }, { "id": "q-driver-obligation", "text": "Which obligation, audit observation or external mandate compels the change, if any?", "kind": "authority", "answer_data": [ "Obligation or mandate reference", "Issuing authority reference", "Compliance deadline" ] }, { "id": "q-driver-benefit", "text": "What benefit or objective is claimed, and how would it be measured after implementation?", "kind": "measurement", "answer_data": [ "Claimed benefit statement", "Measure and target value", "Measurement owner reference" ] } ], "data_elements": [ { "id": "de-driver-category", "name": "Driver category", "description": "Coded category of the driver, such as corrective, adaptive, regulatory, safety or security.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-003", "SRC-012" ] }, { "id": "de-justification-text", "name": "Justification narrative", "description": "Stated reason for the change in the submitter's own terms.", "value_kind": "text", "cardinality": "1", "required": true, "source_refs": [ "SRC-003", "SRC-007" ] }, { "id": "de-obligation-ref", "name": "Compelling obligation reference", "description": "Reference to a mandate, audit finding or regulatory obligation that compels the change.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-011", "SRC-005" ] }, { "id": "de-claimed-benefit", "name": "Claimed benefit measure", "description": "Benefit statement with an associated measure and target value.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004", "SRC-008" ] } ], "artifacts": [], "inline_only_rationale": "Justification is narrative and reference content that belongs on the request so that it travels with every projection of it. Benefit realisation tracking after implementation belongs to the executing and benefits models, so no local artifact is warranted here." }, { "id": "requirement-and-origin-traceability", "name": "Requirement and origin traceability links", "description": "Typed outgoing references from the request to requirements it affects, implements or tracks, and to the defect, nonconformance or finding that originated it, including version binding and behaviour when a target is withdrawn.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003", "SRC-010" ], "questions": [ { "id": "q-trace-requirements", "text": "Which requirements does the request affect, implement or track, and under which link type is each recorded?", "kind": "relationship", "answer_data": [ "Requirement references", "Link type per reference", "Direction and cardinality of each link" ] }, { "id": "q-trace-origin", "text": "Which originating defect, problem, nonconformance or audit finding does the request answer?", "kind": "provenance", "answer_data": [ "Originating record references", "Originating model identifier", "Assertion party and timestamp" ] }, { "id": "q-trace-pinning", "text": "How is each outgoing trace reference pinned to a specific version of the target record?", "kind": "interoperability", "answer_data": [ "Version pin value per reference", "Pinned versus floating reference flag", "Resolution rule when the pin is unavailable" ] }, { "id": "q-trace-withdrawal", "text": "What happens to the trace set when a referenced requirement is withdrawn or re-baselined by its owning model?", "kind": "exception", "answer_data": [ "Stale-link detection rule", "Local link state after target withdrawal", "Notification or review obligation raised locally" ] } ], "data_elements": [ { "id": "de-requirement-trace", "name": "Requirement trace link", "description": "Typed reference to a requirement record with link type (affects, implements, tracks) and version pin.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-002" ] }, { "id": "de-origin-record-trace", "name": "Origin record trace link", "description": "Typed reference to the defect, nonconformance or finding that originated the request.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002", "SRC-001" ] }, { "id": "de-link-state", "name": "Link resolution state", "description": "Local state of each outgoing link: resolved, stale, unresolved or withdrawn-target.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-010", "SRC-003" ] } ], "artifacts": [], "inline_only_rationale": "Traceability here is purely a set of typed, version-pinned references held on the request. A local traceability matrix artifact would duplicate content owned by WM-REC-006 and by the originating defect model, and would go stale the moment either target changed." } ] } ] }, { "id": "assessment-and-routing", "name": "Assessment and Authorization Routing", "description": "The assessment content produced for the request and the routing that places it in front of a competent change authority.", "rationale": "ISO 10007 and space and defence configuration management practice require impact evaluation before a change is approved; security-focused configuration management adds a security impact analysis. Routing selects who may decide but is not itself a decision — that separation is the central boundary of this model.", "source_refs": [ "SRC-003", "SRC-006", "SRC-007", "SRC-012" ], "layers": [ { "id": "impact-and-risk-assessment", "name": "Impact and Risk Assessment", "description": "Technical, schedule, cost, risk, safety, security, privacy and regulatory assessment content attached to the request.", "source_refs": [ "SRC-003", "SRC-006", "SRC-007", "SRC-008" ], "findings": [ { "id": "technical-and-interface-impact", "name": "Technical, interface and verification impact", "description": "Which interfaces, verification results and qualification statuses the change would invalidate, what re-verification it obliges, which dependent items inherit impact, and who produced the assessment and when.", "source_refs": [ "SRC-003", "SRC-007", "SRC-008", "SRC-005" ], "questions": [ { "id": "q-impact-interfaces", "text": "Which functional and physical interfaces, verification results or qualification statuses would be invalidated by the change?", "kind": "relationship", "answer_data": [ "Affected interface references", "Verification or qualification records invalidated", "Severity of invalidation per item" ] }, { "id": "q-impact-reverification", "text": "What re-verification, re-qualification or retesting would the change oblige?", "kind": "requirement", "answer_data": [ "Re-verification activity list", "Applicable acceptance criteria references", "Estimated verification effort" ] }, { "id": "q-impact-dependents", "text": "Which dependent items or downstream deliverables inherit the impact of the change?", "kind": "composition", "answer_data": [ "Dependent item references", "Propagation path per dependency", "Whether the dependent needs its own request" ] }, { "id": "q-impact-provenance", "text": "Who performed the technical impact assessment, on which revision of the proposal, and when?", "kind": "provenance", "answer_data": [ "Assessor party reference", "Assessed proposal revision label", "Assessment event and record timestamps" ] } ], "data_elements": [ { "id": "de-impacted-interface-refs", "name": "Impacted interface references", "description": "References to interfaces, verification records and qualification statuses affected by the change.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007", "SRC-003" ] }, { "id": "de-reverification-obligation", "name": "Re-verification obligation", "description": "Activity that must be repeated to restore verification standing after the change.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008", "SRC-007" ] }, { "id": "de-assessor-ref", "name": "Assessor reference", "description": "Party that produced the technical impact assessment.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008", "SRC-010" ] }, { "id": "de-assessed-revision", "name": "Assessed proposal revision", "description": "Revision label of the change proposal statement to which the assessment applies.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] } ], "artifacts": [ { "id": "impact-assessment-record", "name": "Impact assessment record", "description": "Governed record of the technical impact evaluation for one revision of the proposal: affected interfaces, invalidated verification, dependent items, re-verification obligations, assessor attribution and assessment timestamps.", "media_or_form": [ "structured record", "narrative assessment text", "impact matrix table" ], "serial": true, "identity_strategy": "Identified by the parent request identifier plus the assessed proposal revision label and an assessment sequence number, so a re-assessment after a proposal revision is a new record rather than an edit.", "source_refs": [ "SRC-003", "SRC-007", "SRC-008" ] } ], "inline_only_rationale": null }, { "id": "schedule-cost-and-resource-impact", "name": "Schedule, cost and resource impact", "description": "Effort, cost and schedule implications with stated confidence, the resources and long-lead items the change would consume, the commitments it would affect, and how estimate revisions are recorded.", "source_refs": [ "SRC-003", "SRC-007", "SRC-004", "SRC-008" ], "questions": [ { "id": "q-cost-estimate", "text": "What effort, cost and schedule change does the proposal imply, and at what stated confidence?", "kind": "measurement", "answer_data": [ "Effort, cost and duration estimates with units", "Confidence level or range", "Estimation basis and method" ] }, { "id": "q-cost-resources", "text": "Which resources, skills, facilities or long-lead items would the change consume?", "kind": "constraint", "answer_data": [ "Resource type references", "Quantity and availability window", "Long-lead procurement flag" ] }, { "id": "q-cost-commitments", "text": "Which delivery, funding or contractual commitments would be affected by the change?", "kind": "ownership", "answer_data": [ "Affected commitment references", "Commitment owner reference", "Nature of the effect" ] }, { "id": "q-cost-revision", "text": "How are estimate revisions recorded as the request is re-assessed?", "kind": "state", "answer_data": [ "Estimate version with validity interval", "Reason for revision", "Superseded estimate retained flag" ] } ], "data_elements": [ { "id": "de-effort-estimate", "name": "Effort estimate", "description": "Estimated implementation effort with unit and confidence.", "value_kind": "quantity", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003", "SRC-008" ] }, { "id": "de-cost-estimate", "name": "Cost estimate", "description": "Estimated cost impact with currency and confidence.", "value_kind": "quantity", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003", "SRC-007" ] }, { "id": "de-schedule-impact", "name": "Schedule impact", "description": "Estimated change in duration or milestone dates caused by the change.", "value_kind": "duration", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008", "SRC-004" ] }, { "id": "de-affected-commitment-ref", "name": "Affected commitment reference", "description": "Reference to a delivery, funding or contractual commitment affected by the change.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007", "SRC-004" ] } ], "artifacts": [], "inline_only_rationale": "Estimates are versioned quantitative fields with validity intervals; they are aggregated across the request population and compared against realised values. Holding them as a document would prevent that aggregation, and the authoritative cost and schedule baselines themselves live in the planning and finance models." }, { "id": "risk-safety-security-and-regulatory-impact", "name": "Risk, safety, security, privacy and regulatory impact", "description": "Assessed risk of implementing and of not implementing the change, the security impact analysis result, effects on safety functions and personal data processing, and whether external notification or prior approval is required.", "source_refs": [ "SRC-005", "SRC-006", "SRC-011", "SRC-012" ], "questions": [ { "id": "q-risk-both-ways", "text": "What is the assessed risk of implementing the change and, separately, of not implementing it?", "kind": "measurement", "answer_data": [ "Implementation risk rating and scale", "Non-implementation risk rating", "Assessment method reference" ] }, { "id": "q-risk-security", "text": "What security impact analysis result applies, including effects on controls and authorisation boundaries?", "kind": "security", "answer_data": [ "Security impact analysis outcome", "Affected control references", "Authorisation boundary effect statement" ] }, { "id": "q-risk-safety-privacy", "text": "Does the change affect safety functions, hazard controls or the processing of personal data?", "kind": "privacy", "answer_data": [ "Safety function or hazard control references", "Personal data categories affected", "Assessment obligation triggered" ] }, { "id": "q-risk-regulatory", "text": "Does the change require notification to, or prior approval from, an external regulator, customer or certification body?", "kind": "authority", "answer_data": [ "External body reference", "Notification or prior-approval obligation type", "Submission deadline and dependency on disposition" ] } ], "data_elements": [ { "id": "de-implementation-risk", "name": "Implementation risk rating", "description": "Assessed risk of carrying out the change, on a declared scale.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012", "SRC-006" ] }, { "id": "de-non-implementation-risk", "name": "Non-implementation risk rating", "description": "Assessed risk of leaving the change unmade, on a declared scale.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012", "SRC-005" ] }, { "id": "de-security-impact-outcome", "name": "Security impact analysis outcome", "description": "Result of the security impact analysis, including affected control references.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006", "SRC-005" ] }, { "id": "de-external-notification-obligation", "name": "External notification obligation", "description": "Obligation to notify or obtain prior approval from an external body before the change takes effect.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-011", "SRC-007" ] } ], "artifacts": [ { "id": "risk-and-security-impact-analysis", "name": "Risk and security impact analysis", "description": "Governed analysis attached to a proposal revision covering implementation and non-implementation risk, security impact on controls and authorisation boundaries, safety and privacy effects, and any external notification obligation identified.", "media_or_form": [ "structured record", "narrative analysis text", "risk register extract table" ], "serial": true, "identity_strategy": "Identified by the parent request identifier plus the assessed proposal revision label and an analysis sequence number; superseded analyses are retained so that a disposition can be traced to the analysis available at the time.", "source_refs": [ "SRC-006", "SRC-005", "SRC-011" ] } ], "inline_only_rationale": null } ] }, { "id": "authorization-routing", "name": "Authorization Routing", "description": "Selection of the competent change authority and confirmation that the request package is admissible for consideration.", "source_refs": [ "SRC-004", "SRC-012", "SRC-005" ], "findings": [ { "id": "authority-routing-and-readiness", "name": "Competent authority routing and package readiness", "description": "Which change authority the request was routed to, on which criteria values, whether the package is admissible for consideration, and what fallback applies when the authority is unavailable. Records routing facts only; the authority's mandate and the act of deciding belong to the decision model.", "source_refs": [ "SRC-004", "SRC-012", "SRC-005", "SRC-002" ], "questions": [ { "id": "q-route-authority", "text": "Which change authority was this request routed to as competent under the criteria applied?", "kind": "authority", "answer_data": [ "Change authority reference", "Authority scope statement as referenced", "Routing timestamp" ] }, { "id": "q-route-criteria", "text": "Which routing criteria were applied, and what were their values at the moment of routing?", "kind": "process", "answer_data": [ "Criteria names and values at routing time", "Routing rule or model reference", "Party or service that performed the routing" ] }, { "id": "q-route-admissible", "text": "Is the request package complete and admissible for consideration by that authority?", "kind": "validation", "answer_data": [ "Admissibility verdict", "Missing mandatory content list", "Verdict timestamp and evaluating party" ] }, { "id": "q-route-fallback", "text": "What escalation or fallback route applies when the routed authority is unavailable or declines competence?", "kind": "exception", "answer_data": [ "Fallback authority reference", "Trigger condition for escalation", "Time limit before escalation applies" ] } ], "data_elements": [ { "id": "de-routed-authority-ref", "name": "Routed authority reference", "description": "Reference to the change authority the request was placed before.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012", "SRC-002" ] }, { "id": "de-routing-criteria-snapshot", "name": "Routing criteria snapshot", "description": "Criteria names and values captured at the moment of routing.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004", "SRC-012" ] }, { "id": "de-admissibility-verdict", "name": "Admissibility verdict", "description": "Whether the package was judged complete enough for consideration, with the missing-content list.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004", "SRC-011" ] }, { "id": "de-routed-at", "name": "Routed at", "description": "RFC 3339 instant at which the request was routed to the authority.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009" ] } ], "artifacts": [], "inline_only_rationale": "Routing produces facts about the request — which authority, which criteria values, whether admissible — not a governed document. Deliberately no artifact is declared here: an approval or review package artifact would drift toward owning decision content, which the relation to WM-KNW-010 reserves to the decision model." } ] } ] }, { "id": "disposition-and-lifecycle", "name": "Disposition and Request Lifecycle", "description": "The outcome carried by the request, the conditions and effectivity attached to it, and the states the request itself moves through over time.", "rationale": "The registry purpose names disposition explicitly, and configuration management requires that an approved change carry an effectivity so that implementers know which units, versions and dates it applies to. The request-side lifecycle is distinct from both the decision that resolved it and the work that implements it.", "source_refs": [ "SRC-003", "SRC-007", "SRC-013", "SRC-002" ], "layers": [ { "id": "disposition-and-effectivity", "name": "Disposition and Effectivity", "description": "The recorded outcome, its binding to the authoritative decision, and the conditions and effectivity that scope an approval.", "source_refs": [ "SRC-002", "SRC-003", "SRC-013" ], "findings": [ { "id": "disposition-outcome-and-decision-binding", "name": "Disposition outcome and decision binding", "description": "The outcome value carried by the request, the reference and version binding to the decision record that resolved it, the times at which disposition occurred and was recorded, and how reversal or reopening is represented without rewriting history.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003", "SRC-009" ], "questions": [ { "id": "q-disposition-outcome", "text": "What disposition outcome does the request carry: approved, conditionally approved, rejected, deferred, withdrawn or superseded?", "kind": "state", "answer_data": [ "Outcome code", "Outcome scope where partial", "Outcome-setting party reference" ] }, { "id": "q-disposition-decision-link", "text": "Which decision record authoritatively resolved the request, and how is that reference bound and versioned?", "kind": "decision", "answer_data": [ "Decision record reference and version pin", "Owning model identifier", "Binding validation state" ] }, { "id": "q-disposition-times", "text": "When did the disposition occur, and when was it recorded against this request?", "kind": "temporal", "answer_data": [ "Disposition event timestamp", "Local recording timestamp", "Explanation where the interval is material" ] }, { "id": "q-disposition-reversal", "text": "How is a later reversal or reopening of a dispositioned request represented without rewriting the earlier outcome?", "kind": "lifecycle", "answer_data": [ "Successor outcome entry with its own decision reference", "Validity interval of the superseded outcome", "Reopening trigger and permitted states" ] } ], "data_elements": [ { "id": "de-disposition-outcome", "name": "Disposition outcome", "description": "Coded outcome recorded against the request.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002", "SRC-003" ] }, { "id": "de-decision-record-ref", "name": "Decision record reference", "description": "Version-pinned reference to the decision record in WM-KNW-010 that resolved the request.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001", "SRC-002" ] }, { "id": "de-dispositioned-at", "name": "Dispositioned at", "description": "RFC 3339 event time at which the disposition was made.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "de-disposition-recorded-at", "name": "Disposition recorded at", "description": "RFC 3339 observation time at which the outcome was written onto the request.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009", "SRC-010" ] } ], "artifacts": [], "inline_only_rationale": "Only the outcome value, the version-pinned decision reference and two timestamps are held locally. The governed document that carries rationale, options and the decider's mandate is the decision record owned by WM-KNW-010; declaring a local disposition artifact would reproduce that model's content and violate the reference boundary." }, { "id": "conditions-and-effectivity", "name": "Conditions, effectivity and limits", "description": "Provisos attached to an approval, the point from which the approved change becomes effective, the population and locations it applies to, and the expiry or quantity limit of a deviation or waiver.", "source_refs": [ "SRC-013", "SRC-007", "SRC-003", "SRC-011" ], "questions": [ { "id": "q-conditions-attached", "text": "Which conditions, limitations or provisos are attached to the disposition, and who verifies each?", "kind": "constraint", "answer_data": [ "Condition statements", "Verifier reference per condition", "Condition satisfaction state" ] }, { "id": "q-effectivity-point", "text": "From which unit, serial, lot, version, date or event does the approved change become effective?", "kind": "temporal", "answer_data": [ "Effectivity basis code", "Effectivity value or range", "Effective-from instant where date-based" ] }, { "id": "q-effectivity-population", "text": "To which sites, fleets, environments or jurisdictions does the effectivity apply?", "kind": "spatial", "answer_data": [ "Effectivity location or fleet references", "Jurisdiction codes", "Excluded populations" ] }, { "id": "q-effectivity-expiry", "text": "What is the expiry or quantity limit of a deviation or waiver, and what happens when it is reached?", "kind": "exception", "answer_data": [ "Expiry instant or quantity limit", "Consumed quantity to date", "Required action on expiry" ] } ], "data_elements": [ { "id": "de-disposition-condition", "name": "Disposition condition", "description": "Proviso attached to an approval, with its verifier and satisfaction state.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003", "SRC-007" ] }, { "id": "de-effectivity-basis", "name": "Effectivity basis", "description": "Basis on which effectivity is expressed: unit, serial, lot, version, date or event.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-013", "SRC-007" ] }, { "id": "de-effective-from", "name": "Effective from", "description": "RFC 3339 instant from which a date-based effectivity applies.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009", "SRC-011" ] }, { "id": "de-limit-quantity", "name": "Limit quantity", "description": "Quantity limit for a deviation or waiver, with the quantity consumed to date.", "value_kind": "quantity", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-013" ] } ], "artifacts": [], "inline_only_rationale": "Effectivity and conditions are structured field values that downstream execution and manufacturing systems must query mechanically (which serials, from which date, to which sites). Rendering them as a document would defeat that use, and enforcing them is the executing model's responsibility, not this model's." } ] }, { "id": "request-lifecycle-and-time", "name": "Request Lifecycle and Time", "description": "The state machine of the request itself and the temporal discipline applied to all its recorded times.", "source_refs": [ "SRC-002", "SRC-004", "SRC-009" ], "findings": [ { "id": "request-state-model", "name": "Request state model and transitions", "description": "The permitted states of a change request, the legal transitions between them, terminal states and reopening rules, entry preconditions, and control of concurrent editing.", "source_refs": [ "SRC-001", "SRC-002", "SRC-004", "SRC-012" ], "questions": [ { "id": "q-state-set", "text": "What is the permitted set of request states, and which transitions between them are legal?", "kind": "lifecycle", "answer_data": [ "State vocabulary with definitions", "Legal transition pairs", "Actor role permitted per transition" ] }, { "id": "q-state-terminal", "text": "Which states are terminal, and under what rules may a terminal request be reopened?", "kind": "state", "answer_data": [ "Terminal state list", "Reopening precondition set", "Reopened-request identity rule" ] }, { "id": "q-state-preconditions", "text": "Which preconditions must hold before a request may leave assessment and enter routing?", "kind": "constraint", "answer_data": [ "Precondition list per transition", "Evidence required for each precondition", "Party that confirms satisfaction" ] }, { "id": "q-state-concurrency", "text": "How is concurrent editing of a request in a non-terminal state detected and controlled?", "kind": "validation", "answer_data": [ "Concurrency control mechanism", "Conflict detection rule", "Resolution or rejection behaviour" ] } ], "data_elements": [ { "id": "de-request-state", "name": "Request state", "description": "Current state of the request in the declared state vocabulary.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-002", "SRC-001" ] }, { "id": "de-state-transition-event", "name": "State transition event", "description": "Record of one transition: from-state, to-state, actor, event time and record time.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004", "SRC-009" ] }, { "id": "de-record-version-token", "name": "Record version token", "description": "Token used for optimistic concurrency control on the request record.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] } ], "artifacts": [], "inline_only_rationale": "The state model is a vocabulary and a transition table expressed as configuration of the model, and the per-instance data is a current-state code plus a transition list. No governed document is produced, and the immutable event log that some adopters derive from transitions belongs to the audit store, not here." }, { "id": "temporal-and-event-record", "name": "Temporal discipline and derived durations", "description": "Which timestamps every request must carry and in which representation, how event time is distinguished from observation or ingestion time, which durations are derived rather than stored, and how target dates are kept distinguishable from commitments.", "source_refs": [ "SRC-009", "SRC-010", "SRC-003", "SRC-008" ], "questions": [ { "id": "q-time-required", "text": "Which timestamps must every change request carry, and in which time representation?", "kind": "temporal", "answer_data": [ "Mandatory timestamp field list", "Format rule applied to each", "Precision and offset requirements" ] }, { "id": "q-time-event-vs-observed", "text": "How are event time and observation or ingestion time distinguished when the two differ?", "kind": "provenance", "answer_data": [ "Paired field naming convention", "Rule for backdated or replayed submissions", "Handling of unknown local offset" ] }, { "id": "q-time-derived", "text": "Which ages and durations are derived at read time rather than stored, and from which base timestamps?", "kind": "measurement", "answer_data": [ "Derived duration definitions", "Base timestamp pair per derivation", "As-at instant used for the derivation" ] }, { "id": "q-time-proposal-vs-commitment", "text": "How are proposed target dates kept distinguishable from dates that have become commitments?", "kind": "definition", "answer_data": [ "Proposed versus committed field separation", "Model that owns the committed date", "Transition point between the two" ] } ], "data_elements": [ { "id": "de-event-time", "name": "Event time", "description": "RFC 3339 instant at which a modelled occurrence took place, with explicit seconds and offset.", "value_kind": "timestamp", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "de-observation-time", "name": "Observation or ingestion time", "description": "RFC 3339 instant at which the register observed or ingested the occurrence.", "value_kind": "timestamp", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009", "SRC-010" ] }, { "id": "de-derived-age", "name": "Derived age", "description": "Duration derived at read time from a declared timestamp pair and an as-at instant.", "value_kind": "duration", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009", "SRC-003" ] } ], "artifacts": [], "inline_only_rationale": "Temporal discipline is a set of field-level rules and stored instants, not a produced object. Externalising it as an artifact would separate the rule from the values it governs; the rules themselves are declared once in the model's service layers." } ] } ] }, { "id": "proposed-implementation-and-closure", "name": "Proposed Implementation Envelope and Closure", "description": "What the request proposes about how the change would be carried out, and what it records when the change has been realised.", "rationale": "ITIL 4 change enablement and common practice require an implementation approach, a backout intent and a proposed window before authorisation, while configuration management requires closure to be evidenced. Both are held here as proposal and closure facts, with execution owned by the implementing model.", "source_refs": [ "SRC-012", "SRC-004", "SRC-003", "SRC-007" ], "layers": [ { "id": "proposed-implementation-envelope", "name": "Proposed Implementation Envelope", "description": "Approach, backout intent, test intent, proposed window and constraints, all as proposal content.", "source_refs": [ "SRC-012", "SRC-004", "SRC-002" ], "findings": [ { "id": "proposed-approach-and-backout-intent", "name": "Proposed approach, backout intent and test intent", "description": "The implementation approach at the level of detail needed to judge the proposal, the backout or remediation intent with its trigger condition, the test or validation intent, and the explicit handover point to the executing model.", "source_refs": [ "SRC-012", "SRC-004", "SRC-002", "SRC-007" ], "questions": [ { "id": "q-approach-outline", "text": "What implementation approach does the request propose, at the level of detail needed to judge it?", "kind": "process", "answer_data": [ "Approach summary and major steps", "Assumptions and dependencies", "Skills or teams assumed" ] }, { "id": "q-approach-backout", "text": "What backout, remediation or rollback intent accompanies the proposal, and what condition triggers it?", "kind": "exception", "answer_data": [ "Backout intent statement", "Trigger condition or decision point", "Maximum time to restore the prior state" ] }, { "id": "q-approach-testing", "text": "What test or validation intent is proposed to demonstrate the change performs as claimed?", "kind": "validation", "answer_data": [ "Test intent statement", "Acceptance criteria references", "Environment or population for validation" ] }, { "id": "q-approach-handover", "text": "Where does the proposal end and the executing work order or release plan begin?", "kind": "composition", "answer_data": [ "Handover point definition", "Executing model identifier", "Fields carried across the handover" ] } ], "data_elements": [ { "id": "de-approach-outline", "name": "Implementation approach outline", "description": "Proposed approach and major steps as submitted for judgement.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012", "SRC-004" ] }, { "id": "de-backout-intent", "name": "Backout intent", "description": "Proposed means of reverting, with trigger condition and restoration time.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "de-test-intent", "name": "Test intent", "description": "Proposed validation activity and acceptance criteria references.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004", "SRC-007" ] }, { "id": "de-execution-record-ref", "name": "Execution record reference", "description": "Reference to the work order, change set or release record that executes the change.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] } ], "artifacts": [ { "id": "proposed-implementation-outline", "name": "Proposed implementation outline", "description": "The proposal-stage description of how the change would be carried out, sufficient for an authority to judge feasibility and risk. It is superseded by, and never substitutes for, the executing model's implementation plan.", "media_or_form": [ "structured record", "narrative text", "step list" ], "serial": true, "identity_strategy": "Identified by the parent request identifier plus the proposal revision label it accompanies; superseded outlines are retained so a disposition can be read against the outline that existed at the time.", "source_refs": [ "SRC-012", "SRC-004" ] }, { "id": "backout-and-remediation-outline", "name": "Backout and remediation outline", "description": "The proposal-stage statement of how the prior state would be restored, including the trigger condition or decision point at which backout is invoked and the tolerated restoration time.", "media_or_form": [ "structured record", "narrative text", "step list" ], "serial": true, "identity_strategy": "Identified by the parent request identifier plus the proposal revision label; retained alongside its outline so that the pair judged by the authority stays reconstructable.", "source_refs": [ "SRC-012", "SRC-004" ] } ], "inline_only_rationale": null }, { "id": "proposed-window-and-constraints", "name": "Proposed window, dependencies and disruption tolerance", "description": "The implementation window proposed against calendars and freeze periods, the dependencies and blackout constraints that bound it, the maximum tolerated disruption implied, and the notification expected before the window opens.", "source_refs": [ "SRC-012", "SRC-004", "SRC-009" ], "questions": [ { "id": "q-window-proposed", "text": "What implementation window is proposed, and against which calendar or freeze periods was it checked?", "kind": "temporal", "answer_data": [ "Proposed start and end instants", "Calendar or change-schedule reference", "Freeze period conflicts identified" ] }, { "id": "q-window-dependencies", "text": "Which dependencies, predecessor changes or blackout constraints bound the proposed window?", "kind": "relationship", "answer_data": [ "Predecessor request or work references", "Blackout constraint references", "Ordering requirement statement" ] }, { "id": "q-window-disruption", "text": "What is the maximum service disruption the proposal implies, and to whom?", "kind": "measurement", "answer_data": [ "Expected outage or degradation duration", "Affected service and consumer references", "Tolerance threshold reference" ] }, { "id": "q-window-notification", "text": "Which stakeholders are expected to be notified before the proposed window opens, and how far ahead?", "kind": "process", "answer_data": [ "Stakeholder group references", "Lead time requirement", "Notification owner reference" ] } ], "data_elements": [ { "id": "de-proposed-window", "name": "Proposed implementation window", "description": "Proposed start and end instants for carrying out the change, in RFC 3339 form.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009", "SRC-012" ] }, { "id": "de-window-dependency-ref", "name": "Window dependency reference", "description": "Reference to a predecessor change, blackout period or constraint bounding the window.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004", "SRC-012" ] }, { "id": "de-expected-disruption", "name": "Expected disruption", "description": "Expected outage or degradation duration implied by the proposal.", "value_kind": "duration", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012", "SRC-004" ] } ], "artifacts": [], "inline_only_rationale": "The proposed window is a pair of instants plus constraint references that must be machine-comparable against the change schedule owned by the executing model. The authoritative change schedule is not produced here, so no local artifact is justified." } ] }, { "id": "closure-and-evidence", "name": "Closure and Evidence", "description": "How a request is closed, what realisation and verification it references, and how supporting evidence is bound to it.", "source_refs": [ "SRC-003", "SRC-007", "SRC-002", "SRC-010" ], "findings": [ { "id": "closure-and-realized-outcome-reference", "name": "Closure and realised-outcome referencing", "description": "The basis and authority for closing a request, the implementation and release records it references as realisation evidence, the variance between proposed and realised change, and the referenced post-implementation review or verification result.", "source_refs": [ "SRC-003", "SRC-002", "SRC-004", "SRC-007" ], "questions": [ { "id": "q-closure-basis", "text": "On what basis is a change request considered closed, and who may close it?", "kind": "lifecycle", "answer_data": [ "Closure criteria set", "Closing party role reference", "Close code and closure note" ] }, { "id": "q-closure-realisation", "text": "Which implementation, release or work records does the closed request reference as realisation evidence?", "kind": "relationship", "answer_data": [ "Realisation record references", "Owning model per reference", "Realisation completion timestamp" ] }, { "id": "q-closure-variance", "text": "How is variance between the proposed change and the realised change recorded on the request?", "kind": "quality", "answer_data": [ "Variance statements per dimension", "Whether variance required a further request", "Variance acceptance reference" ] }, { "id": "q-closure-review", "text": "Which post-implementation review or verification result is referenced, and which model owns it?", "kind": "evidence", "answer_data": [ "Review or verification record reference", "Owning model identifier", "Result summary as referenced" ] } ], "data_elements": [ { "id": "de-close-code", "name": "Close code", "description": "Coded closure outcome such as successful, successful with issues, backed out or cancelled.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002", "SRC-004" ] }, { "id": "de-realisation-ref", "name": "Realisation reference", "description": "Reference to the implementation, change set or release record that realised the change.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002", "SRC-003" ] }, { "id": "de-variance-statement", "name": "Variance statement", "description": "Recorded difference between what was proposed and what was realised.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003", "SRC-007" ] }, { "id": "de-closed-at", "name": "Closed at", "description": "RFC 3339 instant at which the request reached a closed state.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009", "SRC-002" ] } ], "artifacts": [ { "id": "change-request-closure-record", "name": "Change request closure record", "description": "The record that terminates the request: closure criteria satisfied, close code, closing party, realisation references, variance statements and references to verification or post-implementation review owned elsewhere.", "media_or_form": [ "structured record", "narrative closure note" ], "serial": false, "identity_strategy": "Identified by the parent request identifier alone, because a request has at most one closure record; a reopening produces a new request state and, on subsequent closure, a successor closure record linked to the prior one.", "source_refs": [ "SRC-003", "SRC-004", "SRC-002" ] } ], "inline_only_rationale": null }, { "id": "supporting-evidence-references", "name": "Supporting evidence binding and integrity", "description": "The documents, models, analyses and datasets attached to or referenced by the request, how their integrity is asserted, how broken references are detected, and which evidence carries restricted or personal data.", "source_refs": [ "SRC-010", "SRC-005", "SRC-011", "SRC-007" ], "questions": [ { "id": "q-evidence-set", "text": "Which supporting documents, models, analyses or datasets are attached to or referenced by the request?", "kind": "evidence", "answer_data": [ "Evidence item references", "Evidence role per item", "Contributing party per item" ] }, { "id": "q-evidence-integrity", "text": "How is the integrity and immutability of each referenced evidence item asserted?", "kind": "security", "answer_data": [ "Digest algorithm and value", "Signature or seal reference", "Immutability claim and its basis" ] }, { "id": "q-evidence-external", "text": "Which evidence items are held externally, and how are broken or moved references detected?", "kind": "quality", "answer_data": [ "External location reference", "Last successful resolution timestamp", "Broken-reference detection rule" ] }, { "id": "q-evidence-restricted", "text": "Which evidence carries restricted, export-controlled or personal data requiring separate handling?", "kind": "privacy", "answer_data": [ "Restriction classification per item", "Handling requirement", "Redaction or separation rule" ] } ], "data_elements": [ { "id": "de-evidence-ref", "name": "Evidence reference", "description": "Reference to a supporting document, model, analysis or dataset, with its role in the request.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-010", "SRC-007" ] }, { "id": "de-evidence-digest", "name": "Evidence digest", "description": "Cryptographic digest asserting the integrity of a referenced evidence item.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005", "SRC-006" ] }, { "id": "de-evidence-restriction", "name": "Evidence restriction classification", "description": "Handling restriction applying to an evidence item, such as restricted, export-controlled or personal data.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-011", "SRC-005" ] } ], "artifacts": [ { "id": "evidence-manifest", "name": "Evidence manifest", "description": "The list binding a request to its supporting evidence: reference, role, contributing party, digest, last successful resolution and handling restriction per item.", "media_or_form": [ "structured record", "tabular manifest" ], "serial": true, "identity_strategy": "Identified by the parent request identifier plus a manifest sequence number; a new manifest version is issued whenever evidence is added, replaced or found unresolvable, and prior versions are retained.", "source_refs": [ "SRC-010", "SRC-005", "SRC-007" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "relationships-and-interoperability", "name": "Relationships and Interoperability", "description": "How requests relate to one another, how references to other models are bound, and how the model maps to external vocabularies without overclaiming conformance.", "rationale": "OSLC Change Management defines parent, related, supersession-adjacent and cross-domain link properties, and requires machine-readable representations. Alignment claims must be recorded as mappings, since ISO 10007 is guidance and ITIL is not openly published.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003", "SRC-012" ], "layers": [ { "id": "request-relationships", "name": "Request-to-Request and External Relationships", "description": "Links between change requests and the binding rules for references leaving the model.", "source_refs": [ "SRC-001", "SRC-002", "SRC-010" ], "findings": [ { "id": "inter-request-relationships", "name": "Relationships between change requests", "description": "Supersession, duplication, dependency and blocking links between requests, parent and child decomposition, detection of cycles and contradictions, and the effect of rejection or withdrawal on dependants.", "source_refs": [ "SRC-002", "SRC-001", "SRC-004" ], "questions": [ { "id": "q-rel-types", "text": "Which other change requests does this request supersede, duplicate, depend on or block?", "kind": "relationship", "answer_data": [ "Related request references", "Relationship type per reference", "Direction and assertion party" ] }, { "id": "q-rel-hierarchy", "text": "How are parent and child decomposition relationships between requests expressed and constrained?", "kind": "composition", "answer_data": [ "Parent reference", "Child references", "Depth and fan-out constraints" ] }, { "id": "q-rel-integrity", "text": "How are cycles, contradictory pairs and orphaned children detected and prevented?", "kind": "validation", "answer_data": [ "Graph integrity rules", "Detection point in the lifecycle", "Remediation behaviour on detection" ] }, { "id": "q-rel-cascade", "text": "What happens to dependent requests when this request is rejected or withdrawn?", "kind": "state", "answer_data": [ "Cascade rule per relationship type", "Dependant state after cascade", "Notification obligation raised" ] } ], "data_elements": [ { "id": "de-related-request-ref", "name": "Related request reference", "description": "Reference to another change request with a typed relationship.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002", "SRC-001" ] }, { "id": "de-parent-request-ref", "name": "Parent request reference", "description": "Reference to the parent request in a decomposition hierarchy.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "de-supersession-ref", "name": "Supersession reference", "description": "Reference to the request that supersedes, or is superseded by, this one.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002", "SRC-003" ] } ], "artifacts": [], "inline_only_rationale": "Inter-request relationships are typed edges on the request record, consistent with the registry's typed-edge link default. A relationship document would add nothing beyond the edges themselves and would need to be regenerated on every graph change." }, { "id": "external-reference-binding", "name": "External reference binding and resilience", "description": "How references to records in other models are expressed so they remain resolvable, whether they are version-pinned or floating, which model owns lifecycle for each referenced record, and what is recorded when a target cannot be resolved.", "source_refs": [ "SRC-001", "SRC-002", "SRC-010", "SRC-003" ], "questions": [ { "id": "q-extref-expression", "text": "How is a reference to a record in another model expressed so that it stays resolvable across systems and projections?", "kind": "interoperability", "answer_data": [ "Reference expression convention", "Target model identifier and record key", "Resolution endpoint or catalogue" ] }, { "id": "q-extref-pinning", "text": "Is a given reference pinned to a target version, or does it float to the target's current state?", "kind": "constraint", "answer_data": [ "Pinning mode per reference class", "Version pin value where pinned", "Rule for choosing the mode" ] }, { "id": "q-extref-ownership", "text": "Which referenced model owns lifecycle, evaluation and enforcement for each referenced record?", "kind": "ownership", "answer_data": [ "Owning model identifier per reference class", "Locally held attributes versus target-owned attributes", "Prohibited local operations on the target" ] }, { "id": "q-extref-unavailable", "text": "What is recorded locally when a target model or record is unavailable at reference time?", "kind": "exception", "answer_data": [ "Unresolved reference state", "Last successful resolution timestamp", "Effect on request admissibility" ] } ], "data_elements": [ { "id": "de-external-reference", "name": "External reference", "description": "Reference to a record in another model, carrying target model identifier, record key, pinning mode and link type.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-002" ] }, { "id": "de-reference-resolution-state", "name": "Reference resolution state", "description": "State of an external reference: resolved, unresolved, stale or target-withdrawn, with the last successful resolution instant.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-010", "SRC-009" ] } ], "artifacts": [], "inline_only_rationale": "Reference binding is a field-level convention plus per-reference metadata carried on the request. The registries that make targets resolvable are external, and reproducing them locally as an artifact would create a competing and quickly stale directory." } ] }, { "id": "interoperability-and-alignment", "name": "Interoperability and Standards Alignment", "description": "Declared mappings to external change-management vocabularies, their conflicts, and the projection-neutrality contract.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003", "SRC-013" ], "findings": [ { "id": "standards-alignment-and-projection", "name": "Standards alignment, conflicts and lossless projection", "description": "Which external vocabularies the model claims mapping to and at what level, where mapped terms genuinely conflict, how neutrality across serialisations is preserved, and what minimal profile a projection must preserve to count as lossless.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003", "SRC-012", "SRC-013" ], "questions": [ { "id": "q-align-targets", "text": "To which external change-management vocabularies does the model claim alignment, and at which level of strength?", "kind": "interoperability", "answer_data": [ "Alignment target with version", "Alignment strength: mapping, partial or conformance", "Evidence supporting the claim" ] }, { "id": "q-align-conflicts", "text": "Which mapped terms conflict in meaning across the aligned vocabularies, and how is each conflict resolved locally?", "kind": "definition", "answer_data": [ "Conflicting term pairs", "Nature of the semantic conflict", "Local resolution and the term left unmapped" ] }, { "id": "q-align-neutrality", "text": "How does the model stay neutral across JSON, RDF, Markdown, relational and document projections?", "kind": "constraint", "answer_data": [ "Neutrality rules", "Constructs forbidden because they are storage-specific", "Projection-specific encoding notes" ] }, { "id": "q-align-profile", "text": "What minimal interchange profile must a projection preserve for a round trip to be considered lossless?", "kind": "requirement", "answer_data": [ "Mandatory field set for the profile", "Round-trip test definition", "Reporting rule for dropped fields" ] } ], "data_elements": [ { "id": "de-alignment-claim", "name": "Alignment claim", "description": "Declared mapping to an external vocabulary with target version and claim strength.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-003" ] }, { "id": "de-term-mapping", "name": "Term mapping", "description": "Mapping between a local element and an external term, including unmapped and conflicting cases.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002", "SRC-013" ] }, { "id": "de-interchange-profile", "name": "Interchange profile", "description": "Named minimal field set that a projection must preserve for lossless exchange.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-004" ] } ], "artifacts": [ { "id": "alignment-mapping-table", "name": "Alignment mapping table", "description": "The governed table mapping this model's elements to external change-management vocabulary terms, recording claim strength, unmapped elements and known semantic conflicts. It is the evidence behind every alignment statement the model makes.", "media_or_form": [ "tabular mapping", "structured record", "machine-readable mapping file" ], "serial": true, "identity_strategy": "Identified by the model identifier plus the alignment target identifier and a mapping version number; a new version is issued whenever the model or the aligned vocabulary version changes.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "assurance-access-and-retention", "name": "Assurance, Access and Retention", "description": "Admissibility and quality control over the request population, status accounting, confidentiality classification, and retention and disposition of request records.", "rationale": "ISO 10007 makes configuration status accounting a first-class part of the configuration management process, and regulated regimes make records and their retention legally binding. Access classification and retention class are declared on the record; evaluation, enforcement and disposal execution sit with other models.", "source_refs": [ "SRC-003", "SRC-004", "SRC-005", "SRC-011" ], "layers": [ { "id": "validation-and-status-accounting", "name": "Validation and Status Accounting", "description": "Admissibility rules, duplicate and conflict detection, and reporting over the change request population.", "source_refs": [ "SRC-003", "SRC-004", "SRC-008" ], "findings": [ { "id": "submission-completeness-and-duplicate-detection", "name": "Admissibility, completeness and conflict detection", "description": "Content mandatory by change type, the checks run at submission and their failure handling, detection and merging of duplicates, and detection of open requests that would alter the same item in contradictory ways.", "source_refs": [ "SRC-004", "SRC-003", "SRC-011", "SRC-002" ], "questions": [ { "id": "q-valid-mandatory", "text": "Which content is mandatory for a request to be admissible, and how does that vary by change type?", "kind": "requirement", "answer_data": [ "Mandatory field set per change type", "Source of the obligation", "Waiver conditions for emergency requests" ] }, { "id": "q-valid-checks", "text": "Which automated checks run at submission, and what happens when one fails?", "kind": "validation", "answer_data": [ "Check identifiers and rules", "Blocking versus advisory classification", "Failure handling and return path" ] }, { "id": "q-valid-duplicates", "text": "How are duplicate or near-duplicate requests detected, and how are they merged or linked?", "kind": "quality", "answer_data": [ "Duplicate detection criteria", "Merge versus link decision rule", "Surviving-record identity rule" ] }, { "id": "q-valid-conflicts", "text": "How are two open requests that would alter the same item in contradictory ways detected?", "kind": "exception", "answer_data": [ "Overlap detection rule on affected items", "Contradiction criteria", "Escalation path once detected" ] } ], "data_elements": [ { "id": "de-mandatory-content-rule", "name": "Mandatory content rule", "description": "Rule declaring which content is mandatory for a given change type.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004", "SRC-011" ] }, { "id": "de-validation-result", "name": "Validation result", "description": "Outcome of a submission check, with check identifier, verdict and timestamp.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "de-duplicate-link", "name": "Duplicate link", "description": "Link asserting that this request duplicates or is duplicated by another, with the surviving record indicated.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002", "SRC-003" ] } ], "artifacts": [], "inline_only_rationale": "Validation produces verdicts and rule references attached to the request, and the rulesets themselves are model configuration rather than instance artifacts. Emitting a validation report artifact would duplicate the verdicts already carried and would tempt consumers to treat it as an audit record, which this model does not own." }, { "id": "status-accounting-and-change-measures", "name": "Status accounting and population measures", "description": "The status accounting views that must be producible over the request population, the measures that characterise its health, the authoritative source behind each reported figure, and the distinction between live snapshots and as-at reconstructions.", "source_refs": [ "SRC-003", "SRC-008", "SRC-009", "SRC-004" ], "questions": [ { "id": "q-status-views", "text": "Which status accounting views of the change request population must be producible on demand?", "kind": "process", "answer_data": [ "View definitions and filters", "Required grouping dimensions", "Requesting roles per view" ] }, { "id": "q-status-measures", "text": "Which measures characterise the health of the change request population, and how is each defined?", "kind": "measurement", "answer_data": [ "Measure definitions and units", "Base fields per measure", "Interpretation thresholds where declared" ] }, { "id": "q-status-source", "text": "What is the authoritative source for each reported figure, and how is double counting avoided?", "kind": "provenance", "answer_data": [ "Source field or record per figure", "Deduplication rule", "Exclusion rules for superseded or duplicate requests" ] }, { "id": "q-status-asat", "text": "Which reported figures are live snapshots and which are as-at reconstructions of a past instant?", "kind": "temporal", "answer_data": [ "As-at instant used", "Reconstruction method", "Restatement policy when late data arrives" ] } ], "data_elements": [ { "id": "de-status-view-definition", "name": "Status view definition", "description": "Definition of a status accounting view: filter, grouping and required fields.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003", "SRC-008" ] }, { "id": "de-population-measure", "name": "Population measure", "description": "Defined measure over the request population, such as cycle time, emergency share or rejection rate.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004", "SRC-003" ] }, { "id": "de-as-at-instant", "name": "As-at instant", "description": "RFC 3339 instant at which a reported figure is stated to hold.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009" ] } ], "artifacts": [ { "id": "status-accounting-extract", "name": "Status accounting extract", "description": "A read-only projection over change request records at a stated as-at instant, giving the configuration status accounting view of proposed and dispositioned changes. It reports; it is not an audit record and carries no tamper-evidence guarantee.", "media_or_form": [ "tabular extract", "structured record", "rendered report" ], "serial": true, "identity_strategy": "Identified by the view definition identifier plus the as-at instant and an issue sequence number, so that a restated extract for the same instant is distinguishable from the original.", "source_refs": [ "SRC-003", "SRC-008", "SRC-009" ] } ], "inline_only_rationale": null } ] }, { "id": "access-and-retention", "name": "Access Classification and Retention", "description": "Confidentiality classification declared on request records, and the retention class, holds and tombstone shape applied at end of life.", "source_refs": [ "SRC-005", "SRC-011", "SRC-003" ], "findings": [ { "id": "access-classification-and-confidentiality", "name": "Confidentiality classification and need-to-know", "description": "The handling classification carried by the request record, parts restricted below the record level, personal data present and its basis, and readability of rejected or withdrawn requests. Classification is declared here; evaluation and enforcement are external.", "source_refs": [ "SRC-005", "SRC-011", "SRC-006" ], "questions": [ { "id": "q-access-classification", "text": "What confidentiality or handling classification does the request record carry, and who assigned it?", "kind": "security", "answer_data": [ "Classification code and scheme reference", "Assigning party and timestamp", "Downgrade or declassification condition" ] }, { "id": "q-access-partial", "text": "Which parts of the request are restricted below the classification of the record as a whole?", "kind": "access", "answer_data": [ "Restricted element list", "Restriction basis per element", "Redacted projection definition" ] }, { "id": "q-access-personal-data", "text": "Which personal data appears in a request, and on what basis is it held?", "kind": "privacy", "answer_data": [ "Personal data categories present", "Lawful basis or policy reference", "Minimisation measures applied" ] }, { "id": "q-access-rejected", "text": "Who may read a request that has been rejected or withdrawn, and for how long?", "kind": "access", "answer_data": [ "Permitted reader roles after terminal disposition", "Time limit on access", "Model that evaluates the access decision" ] } ], "data_elements": [ { "id": "de-classification-code", "name": "Classification code", "description": "Confidentiality or handling classification declared on the request record.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005", "SRC-011" ] }, { "id": "de-restricted-element", "name": "Restricted element marker", "description": "Marker identifying an element restricted below the record-level classification.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005", "SRC-006" ] }, { "id": "de-personal-data-category", "name": "Personal data category", "description": "Category of personal data present in the request, with the basis for holding it.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-011" ] } ], "artifacts": [], "inline_only_rationale": "Only classification labels and restriction markers are held on the record. Access policies, the evaluating engine and the resulting access log belong to the adopting Dimension's access control and audit models; declaring an access artifact here would imply ownership of evaluation and audit semantics that the model explicitly disclaims." }, { "id": "retention-and-disposition-of-request-records", "name": "Retention, holds and disposition of request records", "description": "How long a request and its assessment content must be retained and under whose rule, what is deleted, redacted or preserved as a tombstone, which holds suspend disposal, and who executes disposal without this model owning the audit trail.", "source_refs": [ "SRC-011", "SRC-003", "SRC-007", "SRC-005" ], "questions": [ { "id": "q-retain-duration", "text": "How long must a change request and its assessment content be retained, and which rule sets that period?", "kind": "retention", "answer_data": [ "Retention class and period", "Rule or schedule reference", "Trigger event that starts the clock" ] }, { "id": "q-retain-shape", "text": "What is deleted, what is redacted and what is preserved as a tombstone at the end of retention?", "kind": "retention", "answer_data": [ "Tombstone field set retained", "Fields redacted versus destroyed", "Referential integrity guarantee for inbound links" ] }, { "id": "q-retain-hold", "text": "Which legal hold, investigation or dispute flag suspends disposal, and who may set or clear it?", "kind": "exception", "answer_data": [ "Hold flag and scope", "Party permitted to set and clear", "Effect on scheduled disposal" ] }, { "id": "q-retain-execution", "text": "Who executes disposal, and how is the disposal evidenced given that this model does not own the audit trail?", "kind": "ownership", "answer_data": [ "Executing model or policy owner", "Evidence reference produced by that owner", "Local record of the disposal outcome" ] } ], "data_elements": [ { "id": "de-retention-class", "name": "Retention class", "description": "Declared retention class assigning the request to a schedule owned by the adopting Dimension.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011", "SRC-003" ] }, { "id": "de-legal-hold-flag", "name": "Legal hold flag", "description": "Flag suspending disposal of the request pending legal, investigative or dispute action.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011" ] }, { "id": "de-tombstone-marker", "name": "Tombstone marker", "description": "Marker recording that the request has been disposed of, retaining identifier, terminal state and disposal reference only.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003", "SRC-005" ] } ], "artifacts": [], "inline_only_rationale": "Retention is expressed as a class code, a hold flag and a tombstone shape on the record. The schedule, the disposal action and the destruction certificate are produced and evidenced by the records management model of the adopting Dimension, so no artifact is created here." } ] } ] } ] }, "functions": [ { "id": "register-change-request", "name": "Register change request", "description": "Create a change request record with an authoritative identifier, capturing the proposed delta, affected items, baseline reference, submitter and origination times.", "inputs": [ "Proposed change delta", "Affected item references and baseline reference", "Submitter party reference", "Change type and instrument kind" ], "outputs": [ "Registered change request with authoritative identifier", "Submission event time and register ingestion time" ], "preconditions": [ "Submitter resolvable in the party model", "Baseline reference resolvable in the configuration item and baseline model", "Identifier minting rule available per the identity priority" ], "effects": [ "Request enters its initial state", "Identity is fixed and is never reassigned", "Origination provenance is attributed to the submitting agent" ], "source_refs": [ "SRC-001", "SRC-003", "SRC-007", "SRC-010" ] }, { "id": "validate-submission-admissibility", "name": "Validate submission admissibility", "description": "Evaluate a request against the mandatory content rules for its change type and report whether it is admissible for routing.", "inputs": [ "Change request record", "Change type", "Mandatory content ruleset reference" ], "outputs": [ "Admissibility verdict", "List of missing or malformed mandatory content" ], "preconditions": [ "Type-specific completeness ruleset resolvable", "Request in a pre-routing state" ], "effects": [ "Request marked admissible or returned to the originator", "No state is changed in any referenced model" ], "source_refs": [ "SRC-004", "SRC-011", "SRC-012" ] }, { "id": "assess-change-impact", "name": "Assess change impact", "description": "Produce impact, effort and risk assessment content for a specific revision of the proposal, including the security impact analysis where the change is security relevant.", "inputs": [ "Change request record and proposal revision", "Affected item and baseline references", "Assessor party reference" ], "outputs": [ "Impact assessment record", "Risk and security impact analysis" ], "preconditions": [ "Affected items resolvable", "Assessor assigned and competent per the adopting Dimension", "Proposal revision fixed for the duration of the assessment" ], "effects": [ "Assessment content attached with its own attribution and timestamps", "Superseded assessments retained rather than overwritten" ], "source_refs": [ "SRC-003", "SRC-006", "SRC-007", "SRC-008" ] }, { "id": "route-to-change-authority", "name": "Route to change authority", "description": "Select the competent change authority from routing criteria and place the admissible request before it, capturing the criteria values at routing time.", "inputs": [ "Admissible change request", "Routing criteria values", "Authority directory reference" ], "outputs": [ "Routed authority reference", "Routing criteria snapshot and routing timestamp" ], "preconditions": [ "Admissibility verdict is positive", "Authority directory resolvable", "Fallback route defined for unavailability" ], "effects": [ "Request moves to an awaiting-disposition state", "No evaluation, approval or rejection is performed by this function" ], "source_refs": [ "SRC-004", "SRC-005", "SRC-012" ] }, { "id": "record-disposition", "name": "Record disposition", "description": "Write the disposition outcome onto the request and bind it to the authoritative decision record that resolved it.", "inputs": [ "Decision record reference with version pin", "Outcome value", "Disposition event time" ], "outputs": [ "Dispositioned request carrying outcome and decision binding" ], "preconditions": [ "Decision record resolvable in the decision model", "Request in an awaiting-disposition state", "Outcome value in the permitted vocabulary" ], "effects": [ "Outcome state set with event and recording times", "Decision rationale, options and decider mandate remain wholly in the decision model" ], "source_refs": [ "SRC-001", "SRC-002", "SRC-003", "SRC-009" ] }, { "id": "record-conditions-and-effectivity", "name": "Record conditions and effectivity", "description": "Attach the provisos, effectivity basis and any expiry or quantity limit that scope an approval so downstream execution can determine applicability.", "inputs": [ "Conditions attached to the disposition", "Effectivity basis and value", "Expiry instant or quantity limit where the instrument is limited" ], "outputs": [ "Effectivity statement on the request", "Condition set with verifier references" ], "preconditions": [ "Outcome is approved or conditionally approved", "Effectivity basis is one of the permitted bases" ], "effects": [ "Applicability boundaries become machine-readable for executing models", "Condition satisfaction can be tracked without altering the disposition" ], "source_refs": [ "SRC-003", "SRC-007", "SRC-013", "SRC-011" ] }, { "id": "link-traceability", "name": "Link traceability references", "description": "Attach typed, version-pinned references from the request to requirements, defects, configuration items and other change requests.", "inputs": [ "Target model identifier and record key", "Link type", "Pinning mode and version pin" ], "outputs": [ "Validated trace link set with resolution state per link" ], "preconditions": [ "Link type is in the permitted vocabulary", "Target resolvable, or explicitly recorded as unresolved" ], "effects": [ "Reference stored locally with resolution metadata", "Target records are never modified by this function" ], "source_refs": [ "SRC-001", "SRC-002", "SRC-010" ] }, { "id": "transition-request-state", "name": "Transition request state", "description": "Move the request between states in accordance with the declared state model, recording the transition with event and observation times.", "inputs": [ "Current state", "Requested transition", "Acting party reference" ], "outputs": [ "New state", "Transition event record" ], "preconditions": [ "Transition is legal in the state model", "Entry preconditions of the target state are satisfied", "Acting party permitted for that transition" ], "effects": [ "State changed with paired event and record timestamps", "Prior state retained with its validity interval" ], "source_refs": [ "SRC-002", "SRC-004", "SRC-009", "SRC-012" ] }, { "id": "supersede-or-withdraw-request", "name": "Supersede or withdraw request", "description": "Terminate a request by withdrawal or by supersession, linking the successor and flagging dependants for re-evaluation.", "inputs": [ "Request reference", "Successor request reference or withdrawal reason", "Acting party reference" ], "outputs": [ "Terminal state with successor or withdrawal link", "Dependant re-evaluation flags" ], "preconditions": [ "Request not already closed", "Successor request exists where supersession is asserted" ], "effects": [ "History preserved; no prior content rewritten", "Dependent requests flagged, not automatically dispositioned" ], "source_refs": [ "SRC-002", "SRC-003", "SRC-004" ] }, { "id": "close-request-with-evidence", "name": "Close request with evidence", "description": "Close a dispositioned request, referencing the realisation records and verification results and recording variance between proposed and realised change.", "inputs": [ "Realisation record references", "Verification or post-implementation review reference", "Variance statements and close code" ], "outputs": [ "Change request closure record" ], "preconditions": [ "Disposition recorded", "Realisation references resolvable", "Closure criteria for the change type satisfied" ], "effects": [ "Request reaches a closed state", "Execution and verification remain owned by their models; only references are held here" ], "source_refs": [ "SRC-003", "SRC-004", "SRC-007", "SRC-002" ] }, { "id": "produce-status-accounting-extract", "name": "Produce status accounting extract", "description": "Generate a read-only configuration status accounting projection over change request records at a stated as-at instant.", "inputs": [ "View definition and population filter", "As-at instant", "Requesting role" ], "outputs": [ "Status accounting extract with source attribution per figure" ], "preconditions": [ "As-at instant expressed per RFC 3339 with seconds and offset", "Requesting role permitted for the view" ], "effects": [ "No records are mutated", "Extract is a report only and carries no audit-trail or tamper-evidence guarantee" ], "source_refs": [ "SRC-003", "SRC-008", "SRC-009" ] }, { "id": "export-interoperable-projection", "name": "Export interoperable projection", "description": "Serialise a set of change requests into a requested projection and report which fields fell outside the lossless interchange profile.", "inputs": [ "Change request record set", "Target projection and interchange profile", "Current alignment mapping table" ], "outputs": [ "Projection in the requested serialisation", "Mapping report listing unmapped and dropped fields" ], "preconditions": [ "Alignment mapping table current for the target vocabulary version", "Profile-mandatory fields present in the source records" ], "effects": [ "Profile fields preserved for round trip", "Alignment is reported as a mapping claim, never as certified conformance" ], "source_refs": [ "SRC-001", "SRC-002", "SRC-010", "SRC-003" ] } ], "composition": [ { "target": "WM-ACT-021", "relation": "CHILD", "purpose": "Registered parent entry in the ACT (controlled action) domain. Change Request specialises the parent's generic controlled-action framing; generic action identity scaffolding, actor attribution and scheduling semantics remain with the parent, and only change-control-specific structure is defined here.", "required": true, "source_refs": [ "SRC-003", "SRC-004" ] }, { "target": "WM-REC-006", "relation": "REFERENCE", "purpose": "Carries typed affects, implements and tracks references from the request to requirement records, with a version pin per link. Requirement text, versioning, baselining and requirement lifecycle stay wholly with WM-REC-006; this model stores only the reference, the link type and the local resolution state.", "required": false, "source_refs": [ "SRC-001", "SRC-002", "SRC-003" ] }, { "target": "WM-KNW-010", "relation": "REFERENCE", "purpose": "Binds the request's disposition to the authoritative decision record. Deliberation, alternatives, rationale, decider mandate and decision lifecycle are owned by WM-KNW-010; this model records only the outcome value, the version-pinned decision reference and the conditions transcribed onto the request for downstream applicability.", "required": true, "source_refs": [ "SRC-001", "SRC-002", "SRC-003" ] }, { "target": "Configuration item and baseline model of the adopting Dimension", "relation": "REFERENCE", "purpose": "Identifies the controlled items, documents and interfaces the proposal targets and the baseline the delta is expressed against. Item master data, baseline composition and baseline release are owned there and are read-only from here.", "required": true, "source_refs": [ "SRC-003", "SRC-007", "SRC-013" ] }, { "target": "Change implementation, work-order and release model of the adopting Dimension", "relation": "REFERENCE", "purpose": "Links an approved request to the records that execute it. Execution scheduling, task state, deployment, rollback execution and the authoritative change schedule are owned there; this model holds the proposed envelope before disposition and the realisation reference after it.", "required": false, "source_refs": [ "SRC-002", "SRC-004", "SRC-012" ] }, { "target": "Problem, defect, incident and nonconformance model of the adopting Dimension", "relation": "REFERENCE", "purpose": "Records the originating trigger for the request, mirroring the OSLC affectedByDefect relation. Triage, reproduction and closure of the originating record remain with that model; closing a request does not close its trigger.", "required": false, "source_refs": [ "SRC-001", "SRC-002" ] }, { "target": "Party, role and organisation model of the adopting Dimension", "relation": "REFERENCE", "purpose": "Resolves submitter, assessor, verifier and change-authority references. Identity proofing, organisational structure and delegation mandates are owned there; this model stores references and the routing facts only.", "required": true, "source_refs": [ "SRC-003", "SRC-010" ] }, { "target": "Access control and audit models of the adopting Dimension", "relation": "REFERENCE", "purpose": "Receives the classification labels and restriction markers declared on request records. Policy evaluation, enforcement and the resulting immutable access and change logs are owned there; referencing them grants this model no evaluation, enforcement or audit-trail semantics.", "required": true, "source_refs": [ "SRC-005", "SRC-006" ] }, { "target": "Records management and retention policy of the adopting Dimension", "relation": "REFERENCE", "purpose": "Owns retention schedules, legal hold administration and disposal execution for change request records. This model declares only the retention class, the hold flag and the tombstone shape that survives disposal.", "required": true, "source_refs": [ "SRC-011", "SRC-003" ] }, { "target": "OASIS OSLC Change Management Version 3.0 vocabulary (oslc_cm namespace)", "relation": "ALIGN", "purpose": "Field-level mapping target for change request interchange, covering state predicates, priority and severity, parent and related links, and requirement and defect trace links. The alignment is a recorded mapping claim; no conformance is asserted without a passing round-trip test.", "required": false, "source_refs": [ "SRC-001", "SRC-002" ] }, { "target": "ISO 10007:2017 configuration management process (change control and configuration status accounting)", "relation": "ALIGN", "purpose": "Positions the change request inside the configuration management process so that change control and status accounting activities can be located. ISO 10007 is guidance and explicitly not for certification, so this alignment can never be presented as a conformance claim.", "required": false, "source_refs": [ "SRC-003" ] }, { "target": "IETF RFC 3339 date and time on the Internet", "relation": "ALIGN", "purpose": "Normative representation for every time value in the model, requiring explicit seconds and an explicit offset or Z, with -00:00 reserved for a known UTC instant whose local offset is unknown.", "required": true, "source_refs": [ "SRC-009" ] }, { "target": "W3C PROV-O provenance ontology", "relation": "ALIGN", "purpose": "Mapping for record-level provenance of requests and assessments: request and assessment records as Entity, assessment and routing as Activity, submitter and assessor as Agent, with wasAttributedTo, wasAssociatedWith and generatedAtTime.", "required": false, "source_refs": [ "SRC-010" ] }, { "target": "NIST SP 800-53 Rev. 5 Configuration Management (CM) control family", "relation": "ALIGN", "purpose": "Alignment for security-relevant change control expectations, including documented change proposals and security impact analysis as assessment inputs. Control selection, implementation, assessment and audit evidence remain with the security control model of the adopting Dimension.", "required": false, "source_refs": [ "SRC-005", "SRC-006" ] }, { "target": "MIL-HDBK-61A(SE) engineering change proposal, deviation and waiver terminology", "relation": "ALIGN", "purpose": "Terminology alignment for discriminating a configuration-changing proposal from a pre-production deviation and a post-production waiver, and for unit, serial and lot effectivity concepts. Used for classification only; no DoD process obligation is imported.", "required": false, "source_refs": [ "SRC-013" ] } ], "serviceLayers": { "dimension": { "owner_package_requirements": [ "A named owner designated by the adopting Dimension is accountable for the change request register, the change type and instrument-kind code lists, and the mandatory content rules per change type.", "The owner package must name, for every outgoing reference class, the owning model and the operations this model is forbidden to perform on the target: requirement lifecycle (WM-REC-006), decision semantics (WM-KNW-010), execution, enforcement, access evaluation, audit logging and disposal execution.", "The owner package must declare the identifier minting authority and the namespace under which request identifiers resolve, together with the reassignment prohibition.", "The owner package must declare the retention class catalogue applicable to change requests and name the records management policy that executes disposal.", "The owner package must record which alignment claims are active, at which target version, and the date each mapping table was last revalidated." ], "namespace_guidance": "Local element and instance identifiers are lower-kebab-case and stable for the life of the model; they never encode a date, a status or an owning team. Instance identifiers resolve under a Dimension-governed base IRI of the form /change-request/. Where interchange with OSLC consumers is required, elements are additionally exposed under the oslc_cm namespace through the alignment mapping table rather than by renaming local elements.", "registry_links": [ "Registry entry vr.wm-act-032 in the world-model record plane, navigation path NAV.ACT.CHG, domain tag ACT.CHG", "Relation ledger planning/VERCY-MODEL-RELATIONS.csv, which is the authoritative source for the REFERENCE relations to WM-REC-006 and WM-KNW-010 and for the parent relation to WM-ACT-021", "Adopting-Dimension classifier registries for change type, instrument kind, priority and severity scales, driver categories, close codes and retention classes" ] }, "canon_and_patch": { "canonicalization_rules": [ "The canonical form is the format-neutral field set defined by this model; JSON, YAML, Turtle, Markdown, relational rows and document records are projections and never the definition.", "All time values are canonicalised to RFC 3339 with explicit seconds and an explicit offset before comparison or hashing; local-time strings without an offset are rejected at ingest rather than assumed to be UTC.", "Reference values are canonicalised as target-model identifier plus record key plus pinning mode; bare display labels are not references and must not be stored as such.", "Collections that carry no semantic order (affected items, evidence references, related requests) are canonically sorted by target identifier so that digests are reproducible.", "Narrative fields are canonicalised for whitespace only; no normalisation may alter wording that a change authority relied upon." ], "patch_rules": [ "Content already read by a change authority is never patched in place: a proposal revision, assessment or analysis is superseded by a new serial instance and the prior instance is retained.", "A recorded disposition is immutable. A reversal is expressed as a new outcome entry bound to a new decision reference, with the superseded outcome retaining its validity interval.", "Patches to reference sets must state, per affected link, whether the target changed or only the local resolution state changed, so that stale-link handling is distinguishable from a deliberate re-link.", "Every patch records the acting party, the event time and the register ingestion time; a patch that cannot be attributed is rejected.", "Correcting a value that was wrong at capture is recorded as a correction with a reason, not as a silent overwrite of the original." ], "compatibility_rules": [ "Adding an optional element or an enumerated value is backward compatible; removing an element, narrowing cardinality, or making an optional element required is a breaking change requiring a new model version.", "Changing the meaning of an existing code value is breaking even when the token is unchanged; a retired meaning requires a new code and a deprecation window for the old one.", "Alignment mapping tables are versioned independently of the model, so an external vocabulary revision does not force a model version bump unless local semantics change.", "Projections must preserve the declared lossless interchange profile; a projection that silently drops a profile field is non-conformant and must report the drop.", "Deprecated elements remain readable for at least one full retention cycle of the request records that used them." ] }, "artifact_rules": { "identity_priority": [ "Authoritative master-system identifier issued by the system of record that owns the change request register in the adopting Dimension", "Governed global identifier or IRI resolvable under the Dimension-governed namespace, used when the request must be addressable outside the issuing system", "UUID or ULID minted by the adopting Dimension, used only where no authoritative master-system identifier and no governed IRI exists", "Composite child key for serial artifacts: parent request identifier plus revision label or sequence number, never used as a standalone identity" ], "timestamp_rule": "All time values are recorded as RFC 3339 date-time strings with explicit seconds and an explicit numeric offset or Z; a date alone is never an identifier and never substitutes for an instant. Event time (when the submission, assessment, routing, disposition, transition or closure actually occurred) and observation or ingestion time (when the register recorded it) are stored as separate fields whenever they can differ, and derived durations name the timestamp pair and the as-at instant they were computed from. Where the instant is known in UTC but the originating local offset is unknown, -00:00 is used rather than Z, per RFC 3339.", "serial_naming_rule": "Serial artifacts are named as //, where the sequence is monotonically increasing within the parent and gaps are permitted but never reused. Proposal statements, impact assessments, risk and security analyses, implementation and backout outlines, evidence manifests, mapping tables and status accounting extracts are serial; the closure record is not, being at most one per request, with a reopened request producing a successor linked to its predecessor.", "integrity_rule": "Every artifact carries a digest over its canonical form, the acting party, the event time and the ingestion time. Artifacts referenced but stored elsewhere carry the digest and the last successful resolution instant, and a failed resolution sets an unresolved state rather than silently dropping the reference. Digests establish that content has not changed since capture; they are not an audit trail, and tamper-evident logging remains the responsibility of the adopting Dimension's audit store." }, "policies": [ "This model records the request-side view only. It must never assert a requirement's content or lifecycle, make or justify a decision, execute or schedule a change, evaluate an access policy, enforce a control, or write an audit record; where such a concept appears, it is held as a reference to the owning model.", "A disposition may only be recorded against a resolvable decision record reference. An outcome without a decision binding is inadmissible, because the authority to decide is not conferred by this model.", "Assessment content is bound to the specific proposal revision it evaluated. Revising the proposal invalidates dependent assessments rather than silently carrying them forward.", "Emergency changes may relax mandatory content at submission but never the obligation to record which content was relaxed, by whose authority and by when it must be completed.", "Alignment to any external standard is stated as a mapping with a version and a strength, never as conformance, unless a passing round-trip or assessment result is referenced as evidence.", "Personal data in a change request is minimised to what the assessment and routing genuinely require, and restricted elements are marked so that redacted projections can be produced without re-deriving the classification." ], "crud": { "read": [ "Any role holding read access to a request may read its identity, classification, state, disposition outcome and non-restricted content, subject to the classification labels declared on the record and evaluated by the external access model.", "Restricted elements are excluded from projections unless the reader satisfies the restriction; a redacted projection is a first-class output and must be marked as redacted rather than presented as complete.", "As-at reads reconstruct the request as it stood at a stated RFC 3339 instant using retained revisions, state validity intervals and superseded outcomes.", "Reads of referenced records resolve through the owning model at read time; this model returns the reference and its resolution state, never a cached copy presented as authoritative." ], "create": [ "A request is created with an authoritative identifier per the identity priority, a submitter reference, a submission event time and an ingestion time, a to-be description, at least one affected item reference and a baseline reference.", "Serial artifacts are created as new instances rather than by editing an existing instance; the parent request must exist and be in a state that permits the artifact kind.", "Creation captures the intake channel and whether the origination was human or automated, so that trust in the submission can be assessed later.", "Duplicate detection runs at creation; a suspected duplicate is created and linked rather than silently rejected, so the originator's submission is never lost." ], "update": [ "Updates before routing may revise proposal content freely, each revision producing a new serial proposal statement and invalidating dependent assessments.", "After routing, proposal content is frozen; changes require withdrawal and resubmission, or supersession by a new request, so that the authority's view of the package stays reconstructable.", "State transitions are updates constrained by the state model; illegal transitions are rejected rather than coerced.", "Adding, re-pinning or marking a reference stale is an update to local link metadata only and never propagates a write into the target model.", "Every update records the acting party, event time and ingestion time, and retains the superseded value with its validity interval." ], "delete": [ "Change request records are not hard-deleted while in an active or awaiting-disposition state; a request that should not proceed is withdrawn or rejected, preserving the record and its outcome.", "At the end of the declared retention period, the request is disposed of and reduced to a tombstone retaining the authoritative identifier, the terminal state, the disposition outcome code, the retention class and a reference to the disposal action; all other content is destroyed or redacted per the retention class, and inbound references resolve to the tombstone rather than breaking.", "A legal hold, investigation or dispute flag suspends all disposal until cleared by the party authorised in the records management policy; disposal attempted under hold is rejected.", "This model does not own deletion execution. The retention schedule, the disposal action and any destruction evidence are owned and executed by the records management and retention policy of the adopting Dimension; where a jurisdiction imposes statutory retention on quality records, that regime's period prevails over any local default. This model records only the retention class, the hold flag, the tombstone and a reference to the disposal record produced by the owning policy.", "Serial artifacts are disposed of with their parent request and are never disposed of independently while the parent remains, so that a retained disposition can always be read against the content it was made on." ] }, "roles": [ { "name": "Change request register owner", "responsibilities": [ "Owns the model instance, its code lists and its mandatory content rules", "Maintains the outgoing reference contract and the list of operations forbidden on target models", "Approves model version changes and deprecation windows" ] }, { "name": "Requester or originator", "responsibilities": [ "Submits the request with the proposed delta, affected items and baseline reference", "States the driver, justification and claimed benefit", "Responds to admissibility findings and revises the proposal before routing" ] }, { "name": "Assessor", "responsibilities": [ "Produces the impact assessment and the risk and security impact analysis against a fixed proposal revision", "Records assumptions, confidence and the assessment event and observation times", "Flags re-verification obligations and dependent items requiring their own requests" ] }, { "name": "Change coordinator", "responsibilities": [ "Runs admissibility validation and duplicate and conflict detection", "Applies the routing criteria and places the request before the competent authority, recording criteria values at routing time", "Records the disposition outcome and its decision binding once the decision model has resolved the request" ] }, { "name": "Closure verifier", "responsibilities": [ "Confirms closure criteria for the change type are satisfied", "Records realisation references, variance statements and the close code", "References the verification or post-implementation review owned by another model without restating its result as a local finding" ] }, { "name": "Records and access steward", "responsibilities": [ "Assigns the retention class and the confidentiality classification and maintains restriction markers", "Sets and clears legal holds under the records management policy", "Coordinates disposal with the owning policy and records the resulting tombstone" ] } ], "access": { "default_rule": "Deny by default. Read access to a change request is granted only to roles named in the adopting Dimension's access policy for the record's classification; write access is further restricted to the role that owns the specific lifecycle step. This model declares classification and restriction markers only; every access decision is evaluated and enforced by the external access control model.", "scopes": [ "bundle", "layer", "finding", "artifact" ], "exceptions": [ "Emergency changes may be readable by a broader on-call population for the duration of the emergency window, with the widened access recorded as an exception and reverted on closure.", "Regulator, customer, certification body or auditor access may be granted to a defined subset of requests and their evidence, produced as a marked redacted projection rather than by widening the underlying record's classification.", "Restricted elements marked as export-controlled or personal data remain excluded even from readers who satisfy the record-level classification, unless a separate basis is recorded.", "Rejected and withdrawn requests remain readable to the originator and the register owner for the retention period, since the reasoning that led to rejection has continuing value.", "A request under legal hold may have access narrowed below its normal classification at the direction of the party administering the hold." ], "audit_requirements": [ "Every access decision, grant, denial and exception must be logged by the external access control and audit models; this model neither writes nor owns those logs.", "Exception grants recorded here carry the granting party, the scope, the justification reference and an expiry instant in RFC 3339 form, so the exception itself is reviewable.", "Production of a redacted projection must be recorded by the producing service, including which elements were withheld and under which restriction.", "Disposal of a request must be traceable to a disposal record produced by the records management policy, referenced from the tombstone.", "Any claim that these audit requirements are met must cite the owning model's evidence; this model may not assert audit coverage on its own authority." ] }, "agents_bootstrap": { "filename": "AGENTS.md", "required_fields": [ "Name", "Type", "Specification URL", "Storage type URL", "Interface URL", "Processes URL", "Model ID", "Owner or maintainer", "Outgoing reference contract and forbidden operations", "Identity and timestamp rules" ], "read_order": [ "AGENTS.md — resolve Name, Type, Specification URL, Storage type URL, Interface URL and Processes URL before touching any record", "Specification URL — read the model scope, in-scope and out-of-scope statements and the boundary notes, so target-owned concepts are not written locally", "Outgoing reference contract — confirm which operations are forbidden against WM-REC-006, WM-KNW-010 and the execution, access, audit and retention models of the adopting Dimension", "Storage type URL — learn the projection in use (document store, relational, graph or file tree) and treat it strictly as a projection of the canonical field set", "Interface URL — learn the available read and write operations, their preconditions and the redaction behaviour of projections", "Processes URL — follow the registration, assessment, routing, disposition, closure and disposal procedures in order, and never substitute a local shortcut for a step owned by another model" ] } }, "coverage": { "claim": "Single-provider, owner-waived draft. The claude result gives a defensible, format-neutral structure for the change request as a proposal record and its disposition across 7 bundles, 14 layers, 27 findings, 108 questions, 9 artifacts and 12 functions, grounded in 11 tier-1 primary sources with no structural node resting solely on the two tier-3 sources. It is bounded by the frozen WM-REC-006 and WM-KNW-010 reference contract and is not a complete account of change management as a discipline; measurement semantics, register-level status accounting, retention of derived artifacts, three implied-but-undeclared functions and any second-provider corroboration remain open.", "confidence": "medium", "checklist": [ { "dimension": "identity", "status": "covered", "notes": "Authoritative master-system identifier first, then governed IRI, then UUID or ULID; composite child keys for serial artifacts; explicit prohibition on date-like identifiers and on reassignment. Grounded in OSLC resource identity and configuration identification practice." }, { "dimension": "lifecycle", "status": "covered", "notes": "Request-side state model, terminal states, reopening, supersession and withdrawal are modelled. The decision's own lifecycle and the executing work's lifecycle are explicitly excluded and referenced." }, { "dimension": "relationships", "status": "covered", "notes": "Inter-request links (parent, related, supersedes, duplicates, blocks) and cross-model links (requirement, defect, configuration item, execution record) with typed edges and version pinning, mapped to OSLC relationship properties." }, { "dimension": "temporal", "status": "covered", "notes": "RFC 3339 with seconds and explicit offset throughout; event time separated from observation or ingestion time; derived durations declared rather than stored; effectivity treated as a distinct temporal concept from record timestamps." }, { "dimension": "provenance", "status": "covered", "notes": "Submitter and assessor attribution, intake channel and trust, assessed proposal revision, and PROV-O alignment for Entity, Activity and Agent. Superseded content is retained rather than overwritten." }, { "dimension": "ownership", "status": "covered", "notes": "Register owner, requester, assessor, coordinator, closure verifier and records steward are defined, and every outgoing reference names the model that owns the target's lifecycle and forbidden local operations." }, { "dimension": "validation", "status": "covered", "notes": "Admissibility rules by change type, submission checks with blocking or advisory classification, duplicate detection, graph integrity checks and conflicting-concurrent-request detection." }, { "dimension": "access", "status": "covered", "notes": "Deny by default, classification and restriction markers declared locally, four access scopes, five named exception classes. Evaluation and enforcement are explicitly external, and audit requirements are stated as obligations on the owning models." }, { "dimension": "retention and deletion", "status": "covered", "notes": "Retention class, legal hold, tombstone shape retaining identifier, terminal state and outcome code, and explicit statement that the records management policy of the adopting Dimension owns schedule authorship and disposal execution, with statutory regimes prevailing." }, { "dimension": "interoperability", "status": "covered", "notes": "OSLC CM 3.0 mapping table as a governed artifact, ISO 10007 process alignment declared as non-certifiable guidance, lossless interchange profile with round-trip test, and projection neutrality across JSON, RDF, Markdown, relational and document stores." }, { "dimension": "classification", "status": "covered", "notes": "Change type, instrument kind (change, deviation, waiver), change model, regulated category, priority, severity and urgency, with code lists referenced from external classifier registries rather than fixed here." }, { "dimension": "impact and risk assessment", "status": "covered", "notes": "Technical and interface impact, schedule cost and resource impact, and risk, safety, security, privacy and regulatory impact, each bound to a specific proposal revision with its own provenance." }, { "dimension": "authority and disposition", "status": "covered", "notes": "Routing facts and admissibility are held locally; the disposition is an outcome value plus a version-pinned decision reference. Authority mandates, delegation limits and rationale are out of scope by the WM-KNW-010 relation." }, { "dimension": "measurement", "status": "covered", "notes": "Priority and severity scales, effort, cost and schedule estimates with confidence, expected disruption, claimed benefit measures, and population measures over the register with as-at reconstruction rules." }, { "dimension": "evidence and quality", "status": "covered", "notes": "Evidence manifest with digests, resolution state and restriction markers; variance between proposed and realised change; feasibility evidence; referenced verification and post-implementation review owned elsewhere." }, { "dimension": "spatial", "status": "covered", "notes": "Scope by site, facility, fleet, environment and jurisdiction, and effectivity applied to locations and populations. Geometry itself is not modelled; locations are references to the Dimension's location model." }, { "dimension": "execution and enforcement", "status": "not-applicable", "notes": "Deliberately excluded. Work orders, releases, deployment, rollback execution, policy evaluation, enforcement and audit logging belong to other models; this model carries references only and asserts no execution semantics." } ], "known_omissions": [ "No cost or currency model: monetary estimates are carried as quantities with a currency code resolved elsewhere, and no exchange-rate or accounting-period semantics are defined.", "No modelling of the change advisory or configuration control board as a standing body: membership, quorum, meeting cadence and voting are authority and decision concerns left to WM-KNW-010 and the party model.", "No negotiation or multi-party contractual workflow for customer-supplier change proposals, which ECSS and defence practice treat as a formal exchange with response deadlines; only the request-side record is modelled.", "No pre-approved standard-change catalogue structure: a change model is referenced but its authoring, review and expiry are not modelled here.", "No explicit modelling of change freezes and blackout calendars as first-class objects; they are referenced as constraints owned by the executing model's change schedule.", "No cost-of-delay or portfolio prioritisation semantics beyond a priority code and a needed-by instant.", "Emergency change retrospective authorisation is covered only as a state and a relaxation record, not as a distinct instrument." ], "conflicts": [ "Terminology conflict on the word 'change request'. OSLC CM 3.0 uses ChangeRequest as a broad supertype covering Defect, Enhancement, Task and ReviewTask, so an OSLC ChangeRequest may be a defect report that this model would treat as an originating trigger rather than as a change request. The mapping table must record this asymmetry, and a naive one-to-one mapping will overcount requests.", "Instrument conflict between configuration management and IT service management traditions. Defence and space practice distinguish an engineering change proposal from a deviation and a waiver, which do not alter approved configuration documentation, while ITIL-derived practice has no equivalent distinction and would classify all three as changes. The model keeps instrument kind separate from change type rather than collapsing them.", "Authority conflict on approval. OSLC carries approved, reviewed and authorizer directly on the ChangeRequest, whereas the relation ledger assigns decision semantics to WM-KNW-010. The model stores the outcome and a decision reference and treats the OSLC approval predicates as projections of that outcome, not as the seat of the approval.", "Standing conflict between guidance and requirement. ISO 10007 is guidance and explicitly not for certification, while ISO/IEC 20000-1 and incorporated regulatory regimes impose requirements. Structure grounded only in ISO 10007 is common practice, not a normative obligation, and is described as such.", "ITIL 4 is not openly published, so its change enablement definitions are cited through a secondary first-party restatement. Any structure resting only on that source is treated as common practice and is not presented as normative.", "Status accounting versus audit trail. ISO 10007 configuration status accounting and security-control audit expectations can both be read as requiring a change history. The model produces status accounting extracts as read projections and disclaims tamper-evident audit logging, which stays with the audit model." ], "regional_assumptions": [ "Retention periods are assumed to be set by the adopting Dimension's jurisdiction and sector. The FDA QMSR example (effective 2 February 2026, incorporating ISO 13485:2016 into 21 CFR part 820) applies only to regulated medical device manufacturers and is used as an illustration of statutory prevalence, not as a default.", "Personal data handling assumes a jurisdiction with data protection obligations requiring minimisation and a lawful basis; adopting Dimensions in other jurisdictions must substitute their own regime.", "Export-control and security classification markers assume a national scheme resolved outside this model; no specific scheme is embedded.", "NIST SP 800-53 and SP 800-128 are US federal guidance widely adopted commercially, but their use elsewhere is a Dimension choice, not an obligation.", "Change freeze calendars, working-day conventions and notification lead times are locale-dependent and are referenced rather than defined.", "The assumption that a change authority is distinct from the requester reflects segregation-of-duties practice in regulated and safety-critical settings; small organisations may legitimately combine the roles, which the model permits but does not silently assume." ], "adversarial_checks": [ "Boundary sweep against the relation ledger: every bundle, layer, finding and function was compared with the WM-REC-006 and WM-KNW-010 rationales. Two candidate findings were removed or rewritten as a result. A proposed 'approval and review record' finding was cut because collecting endorsements and rationale is decision-owned; what remains is routing facts, criteria values and admissibility. A proposed question on alternatives submitted for consideration was replaced with a representation question, because alternatives evaluation belongs to the decision model.", "Ownership-leakage test on every artifact: none of the nine artifacts reproduces target-model content. No approval package, no requirement snapshot, no execution plan, no access log and no disposal certificate is produced here. The status accounting extract explicitly disclaims audit-trail and tamper-evidence semantics, and the closure record holds references to verification results rather than restating them.", "Counterexample hunt for over-general structure: a pre-approved standard change with no assessment, an emergency change authorised retrospectively, a waiver that alters nothing in the configuration documentation, and a rejected request that must still be readable years later. Each is representable — through change model reference and relaxation recording, through outcome plus decision binding after the fact, through instrument kind with quantity and expiry limits, and through retention class with post-rejection read access — without adding a special case that would break the common path.", "Identity falsification test: a change request identified by 'CR-2026-08-14' would encode a date and would collide across systems, so date-like identifiers are prohibited and a submission date is never accepted as an identifier. Serial artifacts were checked to ensure their composite keys are never used standalone.", "Timestamp falsification test: a backdated emergency change submitted after the fact would be indistinguishable from a timely one if a single timestamp were kept, so event time and ingestion time are paired wherever they can differ, and RFC 3339 -00:00 is reserved for a known UTC instant with unknown local offset rather than being conflated with Z.", "Source-strength audit: each structural node was checked for primary support. Nodes resting only on the ITIL restatement or the mirrored DoD handbook are described as common practice or terminology alignment, and the conflicts list records that ISO 10007 is guidance rather than a certifiable requirement, so no conformance is claimed anywhere in the model." ] }, "researchAdjudication": { "providerMode": "single-provider-waiver", "activeProviders": [ "claude" ], "waivedProviders": [ "grok" ], "providerPolicy": { "contract_version": "1.0.0", "mode": "single-provider-waiver", "effective_at": "2026-08-29T09:06:27Z", "scope": "Queued subject-model research from WM-XCT-013 onward", "active_providers": [ "claude" ], "waived_providers": [ { "provider": "grok", "authorized_by": "repository owner", "authorized_at": "2026-08-29T09:06:27Z", "reason": "The repository owner explicitly instructed the research queue to continue without Grok after repeated structured-output failures." } ], "review_rule": "Claude-only results require a separate no-tools adversarial audit and remain reviewable drafts with a visible single-provider hold." }, "boundaryDecision": { "entry_kind": "entity", "status": "accepted", "rationale": "The subject is a persistent, addressable record with its own identity, revision labelling, state model, retention class and access classification, not an occurrence or a process step; 'entity' is correct on the subject plane even though NAV.ACT.CHG and the WM-ACT-021 parent place the model in the activity domain. The registry value 'standalone-mm' is a record-plane packaging kind on a different axis and must remain unchanged rather than be overwritten by 'entity'. The aggregate root stays the single request record, with proposal revisions carried as serial child artifacts and impact assessments bound to a named revision, so no split into a separate revision or register root is warranted." }, "decisions": [ { "concept": "Aggregate root is the change request record, with proposal revisions as serial children", "disposition": "accepted", "rationale": "Scope statement, state model, retention class, access classification and disposition binding all attach to one addressable record; revisions are carried by the serial change-proposal-statement artifact and by revision-pinned assessment provenance, so no second root is required." }, { "concept": "Entry kind 'entity' on the subject plane versus 'standalone-mm' on the frozen registry record", "disposition": "accepted as distinct planes; registry value must not be overwritten", "rationale": "These are different axes, not a contradiction: standalone-mm describes how the model is packaged in the registry, entity describes what the modelled subject is. The synthesizer must carry both and must not propagate 'entity' into the record-plane field." }, { "concept": "Ownership boundary to WM-KNW-010: the locally stored disposition outcome value", "disposition": "accepted with a required reconciliation rule before non-draft publication", "rationale": "The outcome is a local copy of decision-owned content. Reversal-as-new-state and version pinning are declared, but no rule says what happens when the referenced decision record is later amended and the cached outcome diverges; external-reference-binding covers unresolvable targets only, not stale-but-resolvable ones." }, { "concept": "Relationship contract declares only WM-REC-006 and WM-KNW-010 while nine boundary notes name further neighbours", "disposition": "accepted as under-declared, not contradictory; routed to the relation-ledger backlog", "rationale": "Configuration item/baseline, execution and release, audit store, records management, defect, location, party and external classifier registries all appear as boundary neighbours with no relation rows, and the WM-ACT-021 parent edge has no row either. All are declared read-only references, so a reviewable draft still stands under review_state boundary-review-required." }, { "concept": "Artifact cardinality of alignment-mapping-table and status-accounting-extract, both declared serial:true", "disposition": "rejected as declared; re-scope before publication", "rationale": "Neither is an instance child of one request. The mapping table is model configuration, exactly the treatment correctly applied to the state transition table, and the extract is a population projection keyed by an as-at instant. A per-request composite serial key misstates the identity of both." }, { "concept": "Register-level status accounting held inside an instance-scoped record model", "disposition": "accepted as a read-only projection; register split deferred", "rationale": "ISO 10007 status accounting is a register-level activity, and keeping it here is defensible only because the extract disclaims audit-trail and tamper-evidence semantics. No retention class, classification or hold rule is declared for the extract itself, which can carry restricted content." }, { "concept": "Function route-to-change-authority says 'select the competent change authority'", "disposition": "flagged for wording narrowed to evaluating declared criteria and recording the selection", "rationale": "This contradicts the authority-routing-and-readiness finding, which states it records routing facts only, and sits against the out_of_scope entry excluding authority mandates and decision rights. 'Select' reads as owning the competence determination." }, { "concept": "Function coverage asymmetry against declared questions", "disposition": "deferred; add_functions must stay empty under the single-provider waiver", "rationale": "q-retain-hold asks who may set or clear a legal hold, q-access-classification asks who assigns the handling classification and q-valid-duplicates asks how duplicates are merged. All three are local record operations, yet no function covers them and none may be added in this mode." }, { "concept": "Source-strength audit: no structural node rests solely on tier-3 support", "disposition": "accepted after checking all 27 findings and 12 functions", "rationale": "Every node citing SRC-012, the AWS restatement of ITIL 4, or SRC-013, the mirrored MIL-HDBK-61A copy, also cites at least one tier-1 primary source, and the conflicts list correctly describes both dependencies as common practice rather than normative obligation." }, { "concept": "ISO sources cited through paywalled catalogue landing pages", "disposition": "accepted for provenance, held for live verification", "rationale": "SRC-003, SRC-004 and ISO 13485 reached via SRC-011 resolve to abstract pages, so the normative text was never readable at the cited URL. Edition, confirmation date and incorporation-by-reference status must be re-checked before the draft is promoted." }, { "concept": "Retention class and legal hold do not propagate to derived artifacts or externally held evidence", "disposition": "accepted with the limitation stated explicitly in the publication", "rationale": "The evidence manifest points at items whose lifecycle is owned elsewhere, so a local hold flag cannot suspend their disposal. The tombstone shape covers the request record only and is silent on the eight serial artifacts and the closure record." }, { "concept": "Personal-data erasure against the no-overwrite provenance rule", "disposition": "accepted; redaction is the declared resolution but must be scoped", "rationale": "Submitter, assessor and closure-verifier identities persist under the rule that superseded content is retained rather than overwritten. The tombstone's redaction path resolves this in principle, but no rule names which fields are redactable while the provenance chain stays intact." }, { "concept": "Coverage checklist marks every applicable dimension 'covered' alongside seven declared omissions", "disposition": "rejected as stated; downgrade measurement to partial and re-examine classification", "rationale": "The omissions remove cost and currency semantics and cost-of-delay or portfolio prioritisation, which are measurement content, and remove the standard-change catalogue structure, which is classification content. An all-covered checklist overstates the draft's reach against its own omissions list." }, { "concept": "Bundle and layer naming 'Assessment and Authorization Routing' / 'Authorization Routing'", "disposition": "accepted with a non-blocking rename recommendation", "rationale": "The model records routing to an authority and package admissibility, not authorisation itself. The name invites a reading in which this model owns approval, which the WM-KNW-010 relation reserves elsewhere; the finding text disclaims it but the label does not." }, { "concept": "Inline-only rationales on the eighteen artifact-free findings", "disposition": "accepted", "rationale": "Each rationale gives a positive reason such as field-level queryability, external ownership or duplicate-staleness risk, rather than defaulting to silence. The deliberate no-artifact note under authority routing, refusing an approval or review package, is the strongest single piece of boundary discipline in the result." } ], "publicationHolds": [ "Live source and version verification hold: every cited URL, edition, effective date and namespace must be re-resolved at publication time. ISO 10007, ISO/IEC 20000-1 and ISO 13485 incorporated via the FDA QMSR were cited from paywalled catalogue pages, so their normative text was never read at the cited URL; NIST SP 800-53 Rev 5 update designation, NPR 7123.1D change status and the mirrored MIL-HDBK-61A(SE) currency also remain unverified.", "Single-provider hold: independent second-provider review is absent by explicit repository-owner waiver of Grok recorded at 2026-08-29T09:06:27Z after repeated structured-output failures. Every published artifact must carry that waiver, the named authorising party and the reviewable-draft status visibly, and must not present the result as cross-provider corroborated.", "Registry state hold: the frozen record must remain status=candidate and review_state=boundary-review-required, and entry_kind must stay 'standalone-mm' on the record plane. The subject-plane value 'entity' is published alongside it and must never overwrite it.", "Artifact-cardinality hold: alignment-mapping-table and status-accounting-extract must not be published as per-request serial children of the aggregate root until their scope is corrected to model-level and population-level respectively.", "Relation-ledger hold: publication must state that the frozen contract declares only two REFERENCE relations while nine boundary neighbours and the WM-ACT-021 parent edge carry no registry rows, so the declared edge set is knowingly incomplete.", "Coverage-checklist hold: the all-covered checklist must be reconciled against the seven declared omissions, with measurement downgraded to partial, before the coverage claim is published in its current wording.", "Independent second-provider review was explicitly waived by the repository owner; this Claude-only result remains a reviewable draft." ], "deferredResearch": [ "Reconciliation rule for a locally stored disposition outcome that diverges from an amended, reversed or re-versioned WM-KNW-010 decision record, covering detection, precedence and what the request shows while divergence is unresolved.", "Retention, classification and hold rules for the model's own derived artifacts, including the status accounting extract, the impact and risk analyses and the closure record, plus the limits of hold propagation to externally held evidence the model does not own.", "Registry relation rows for the unregistered neighbours named in the boundary notes: configuration item and baseline, execution and release, audit and status accounting store, records management, defect and nonconformance, location, party, and the external classifier registries, together with the WM-ACT-021 parent edge.", "Function definitions for classification assignment, legal-hold set and clear, and duplicate detection and merge, all implied by declared questions but absent from the twelve functions; blocked while add_functions must remain empty under the waiver.", "Field-level redaction rule that satisfies personal-data erasure obligations without breaking the no-overwrite provenance guarantee, naming which attributions are redactable and what provenance remnant survives.", "Whether register-level status accounting and population measures should be split into their own model rather than living inside an instance-scoped record model, and what that would mean for the extract's identity and retention.", "Independent second-provider or substitute review of the OSLC CM 3.0 mapping asymmetry and the lossless interchange profile, since the overcounting risk from the ChangeRequest supertype is currently asserted on a single provider's reading.", "Wording and scope correction for route-to-change-authority so that authority selection is expressed as evaluation of externally defined criteria and recording of the routed target, consistent with the finding text and the out_of_scope entry." ] }, "statistics": { "sources": 13, "bundles": 7, "layers": 14, "findings": 27, "questions": 108, "artifacts": 9, "functions": 12 } }