Published

Change Request

vr.wm-act-032 · wm-act-032-change-request

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.

World Models Activities and processes ACT.CHG

Bundle → Layer → Finding → Questions Classifiers What it is Why it exists Distinguishing features What robots and AI may and may not do Moral aspects Owners Links to other meta-models Identity and identifiers Direct properties Recognition Capabilities and actions Hazards and failure modes Standards and interfaces Context of use Sources

Bundle → Layer → Finding → Questions Filled

7 bundles · 14 layers · 27 findings · 108 questions

Request Identity and Change Subject What a change request instance is, how it is identified and originated, and exactly which controlled subject, baseline and scope the proposal targets.

Identity and Origination

The identifiers that make a request addressable and the provenance of its raising.

Change request identity and addressability

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.

Which identifier is the authoritative key for this change request, and which system issues it? identity
What distinguishes the change request record from the change itself and from the decision that dispositions it? definition
How are successive revisions of the same request distinguished from a genuinely new request? provenance
Under which namespace or IRI scheme is the request identifier resolvable outside the issuing system? interoperability

Origination, submitter and intake

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.

Who submitted the request, and on whose behalf or under which mandate did they act? ownership
What triggering event or observation caused the request to be raised? event
When was the request submitted, and when was that submission first recorded by the register? temporal
Through which intake route did the request enter the register, and is that route trusted? provenance

Change Subject and Proposed Delta

The controlled items and baseline targeted by the request and the substance of what would change.

Affected items, baseline and scope boundary

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.

Which configuration items, documents, interfaces or services would the proposed change alter? composition
Against which baseline or approved configuration is the proposed delta expressed? relationship
Which sites, fleets, environments or organisational units fall inside the proposed scope? spatial
What is explicitly excluded from the proposed scope, and why? constraint

Proposed change delta

The substance of the proposal expressed as a difference from the current approved state, its content classification, and the feasibility evidence submitted with it.

What exactly is proposed to change, expressed as a delta from the current approved state? definition
Which content classification applies to the delta: addition, modification, removal or reversion? classification
How is the delta represented so that it stays readable independently of any storage format? interoperability
What evidence accompanies the request that the described delta is technically achievable as stated? evidence

Classification and Justification How the request is typed and prioritised, why it is being made, and what it traces back to.

Classification and Typing

The type, instrument kind, governing change model and relative importance assigned to the request.

Change type, instrument kind and governing change model

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.

Which change type applies to this request, and what evidence supports that assignment? classification
Is this a permanent configuration change, or a time- or quantity-limited departure that leaves the approved configuration documentation unchanged? exception
Which change model, template or pre-authorised procedure governs the handling of this request? process
Which regulated, safety-related or contractual category does the change fall into, and does that category force a stricter route? requirement

Priority, urgency and claimed severity

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.

What priority value is assigned to the request, on which defined scale, and by whom? measurement
What consequence and severity are claimed if the request is not implemented? evidence
By which date or event must the request be dispositioned for it to remain useful? temporal
How are priority and urgency recomputed when the request is superseded or its scope changes? state

Justification and Traceability

The stated reason for the change and the outgoing trace references that make it auditable.

Drivers, justification and claimed benefit

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.

What driver justifies the request, and into which driver category does it fall? definition
What would be the consequence of taking no action, and over what horizon? evidence
Which obligation, audit observation or external mandate compels the change, if any? authority
What benefit or objective is claimed, and how would it be measured after implementation? measurement

Requirement and origin traceability links

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.

Which requirements does the request affect, implement or track, and under which link type is each recorded? relationship
Which originating defect, problem, nonconformance or audit finding does the request answer? provenance
How is each outgoing trace reference pinned to a specific version of the target record? interoperability
What happens to the trace set when a referenced requirement is withdrawn or re-baselined by its owning model? exception

Assessment and Authorization Routing The assessment content produced for the request and the routing that places it in front of a competent change authority.

Impact and Risk Assessment

Technical, schedule, cost, risk, safety, security, privacy and regulatory assessment content attached to the request.

Technical, interface and verification impact

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.

Which functional and physical interfaces, verification results or qualification statuses would be invalidated by the change? relationship
What re-verification, re-qualification or retesting would the change oblige? requirement
Which dependent items or downstream deliverables inherit the impact of the change? composition
Who performed the technical impact assessment, on which revision of the proposal, and when? provenance

Schedule, cost and resource impact

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.

What effort, cost and schedule change does the proposal imply, and at what stated confidence? measurement
Which resources, skills, facilities or long-lead items would the change consume? constraint
Which delivery, funding or contractual commitments would be affected by the change? ownership
How are estimate revisions recorded as the request is re-assessed? state

Risk, safety, security, privacy and regulatory impact

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.

What is the assessed risk of implementing the change and, separately, of not implementing it? measurement
What security impact analysis result applies, including effects on controls and authorisation boundaries? security
Does the change affect safety functions, hazard controls or the processing of personal data? privacy
Does the change require notification to, or prior approval from, an external regulator, customer or certification body? authority

Authorization Routing

Selection of the competent change authority and confirmation that the request package is admissible for consideration.

Competent authority routing and package readiness

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.

Which change authority was this request routed to as competent under the criteria applied? authority
Which routing criteria were applied, and what were their values at the moment of routing? process
Is the request package complete and admissible for consideration by that authority? validation
What escalation or fallback route applies when the routed authority is unavailable or declines competence? exception

Disposition and Request Lifecycle The outcome carried by the request, the conditions and effectivity attached to it, and the states the request itself moves through over time.

Disposition and Effectivity

The recorded outcome, its binding to the authoritative decision, and the conditions and effectivity that scope an approval.

Disposition outcome and decision binding

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.

What disposition outcome does the request carry: approved, conditionally approved, rejected, deferred, withdrawn or superseded? state
Which decision record authoritatively resolved the request, and how is that reference bound and versioned? decision
When did the disposition occur, and when was it recorded against this request? temporal
How is a later reversal or reopening of a dispositioned request represented without rewriting the earlier outcome? lifecycle

Conditions, effectivity and limits

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.

Which conditions, limitations or provisos are attached to the disposition, and who verifies each? constraint
From which unit, serial, lot, version, date or event does the approved change become effective? temporal
To which sites, fleets, environments or jurisdictions does the effectivity apply? spatial
What is the expiry or quantity limit of a deviation or waiver, and what happens when it is reached? exception

Request Lifecycle and Time

The state machine of the request itself and the temporal discipline applied to all its recorded times.

Request state model and transitions

The permitted states of a change request, the legal transitions between them, terminal states and reopening rules, entry preconditions, and control of concurrent editing.

What is the permitted set of request states, and which transitions between them are legal? lifecycle
Which states are terminal, and under what rules may a terminal request be reopened? state
Which preconditions must hold before a request may leave assessment and enter routing? constraint
How is concurrent editing of a request in a non-terminal state detected and controlled? validation

Temporal discipline and derived durations

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.

Which timestamps must every change request carry, and in which time representation? temporal
How are event time and observation or ingestion time distinguished when the two differ? provenance
Which ages and durations are derived at read time rather than stored, and from which base timestamps? measurement
How are proposed target dates kept distinguishable from dates that have become commitments? definition

Proposed Implementation Envelope and Closure What the request proposes about how the change would be carried out, and what it records when the change has been realised.

Proposed Implementation Envelope

Approach, backout intent, test intent, proposed window and constraints, all as proposal content.

Proposed approach, backout intent and test intent

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.

What implementation approach does the request propose, at the level of detail needed to judge it? process
What backout, remediation or rollback intent accompanies the proposal, and what condition triggers it? exception
What test or validation intent is proposed to demonstrate the change performs as claimed? validation
Where does the proposal end and the executing work order or release plan begin? composition

Proposed window, dependencies and disruption tolerance

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.

What implementation window is proposed, and against which calendar or freeze periods was it checked? temporal
Which dependencies, predecessor changes or blackout constraints bound the proposed window? relationship
What is the maximum service disruption the proposal implies, and to whom? measurement
Which stakeholders are expected to be notified before the proposed window opens, and how far ahead? process

Closure and Evidence

How a request is closed, what realisation and verification it references, and how supporting evidence is bound to it.

Closure and realised-outcome referencing

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.

On what basis is a change request considered closed, and who may close it? lifecycle
Which implementation, release or work records does the closed request reference as realisation evidence? relationship
How is variance between the proposed change and the realised change recorded on the request? quality
Which post-implementation review or verification result is referenced, and which model owns it? evidence

Supporting evidence binding and integrity

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.

Which supporting documents, models, analyses or datasets are attached to or referenced by the request? evidence
How is the integrity and immutability of each referenced evidence item asserted? security
Which evidence items are held externally, and how are broken or moved references detected? quality
Which evidence carries restricted, export-controlled or personal data requiring separate handling? privacy

Relationships and Interoperability How requests relate to one another, how references to other models are bound, and how the model maps to external vocabularies without overclaiming conformance.

Request-to-Request and External Relationships

Links between change requests and the binding rules for references leaving the model.

Relationships between change requests

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.

Which other change requests does this request supersede, duplicate, depend on or block? relationship
How are parent and child decomposition relationships between requests expressed and constrained? composition
How are cycles, contradictory pairs and orphaned children detected and prevented? validation
What happens to dependent requests when this request is rejected or withdrawn? state

External reference binding and resilience

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.

How is a reference to a record in another model expressed so that it stays resolvable across systems and projections? interoperability
Is a given reference pinned to a target version, or does it float to the target's current state? constraint
Which referenced model owns lifecycle, evaluation and enforcement for each referenced record? ownership
What is recorded locally when a target model or record is unavailable at reference time? exception

Interoperability and Standards Alignment

Declared mappings to external change-management vocabularies, their conflicts, and the projection-neutrality contract.

Standards alignment, conflicts and lossless projection

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.

To which external change-management vocabularies does the model claim alignment, and at which level of strength? interoperability
Which mapped terms conflict in meaning across the aligned vocabularies, and how is each conflict resolved locally? definition
How does the model stay neutral across JSON, RDF, Markdown, relational and document projections? constraint
What minimal interchange profile must a projection preserve for a round trip to be considered lossless? requirement

Assurance, Access and Retention Admissibility and quality control over the request population, status accounting, confidentiality classification, and retention and disposition of request records.

Validation and Status Accounting

Admissibility rules, duplicate and conflict detection, and reporting over the change request population.

Admissibility, completeness and conflict detection

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.

Which content is mandatory for a request to be admissible, and how does that vary by change type? requirement
Which automated checks run at submission, and what happens when one fails? validation
How are duplicate or near-duplicate requests detected, and how are they merged or linked? quality
How are two open requests that would alter the same item in contradictory ways detected? exception

Status accounting and population measures

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.

Which status accounting views of the change request population must be producible on demand? process
Which measures characterise the health of the change request population, and how is each defined? measurement
What is the authoritative source for each reported figure, and how is double counting avoided? provenance
Which reported figures are live snapshots and which are as-at reconstructions of a past instant? temporal

Access Classification and Retention

Confidentiality classification declared on request records, and the retention class, holds and tombstone shape applied at end of life.

Confidentiality classification and need-to-know

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.

What confidentiality or handling classification does the request record carry, and who assigned it? security
Which parts of the request are restricted below the classification of the record as a whole? access
Which personal data appears in a request, and on what basis is it held? privacy
Who may read a request that has been rejected or withdrawn, and for how long? access

Retention, holds and disposition of request records

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.

How long must a change request and its assessment content be retained, and which rule sets that period? retention
What is deleted, what is redacted and what is preserved as a tombstone at the end of retention? retention
Which legal hold, investigation or dispute flag suspends disposal, and who may set or clear it? exception
Who executes disposal, and how is the disposal evidenced given that this model does not own the audit trail? ownership

Classifiers Filled

Family: World Models
Category: Activities and processes
Entry kind: entity
Navigation path: NAV.ACT.CHG
Domain: ACT.CHG
Industry: Cross-industry
Tags: changerequestact.chg

What it is Filled

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

Why it exists Filled

Distinguishing features Filled

A change request is the request-side record of a proposed change; the decision (WM-KNW-010) and the implementation are separate records.
It differs from a deviation or waiver, which accepts a nonconformance without changing the baseline.
It differs from a problem or defect record, which may trigger it but describes a fault.
Assessments bind to the proposal revision they evaluated and lapse when the proposal changes.

What robots and AI may and may not do Filled

Must not

Record a disposition without a resolvable decision record.
Implement or release a change that is not approved.
Reuse an assessment for a revised proposal.
Hide which content was relaxed for an emergency change.
Restate requirement content inside the request.

Only with a human decision

Approving, rejecting or deferring a change.
Authorising an emergency change.
Accepting residual safety or security risk of a change.

May

Register a change request with its reason, scope and affected items.
Assess impact on requirements, configuration items, cost and schedule.
Route a request to the change authority defined for the affected baseline.
Close a request with links to the decision and implementation evidence.

Moral aspects Filled

Changes to safety-related systems can harm people; impact assessment must cover safety, not only cost.
Requests from different stakeholders deserve fair and transparent handling.

Who is affected

Requesters
Users affected by the changed system
Change authority members

Owners Filled

Steward

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.

Roles

Change request register owner: 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
Requester or originator: 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
Assessor: 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
Change coordinator: 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
Closure verifier: 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
Records and access steward: 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

Links to other meta-models Filled

child

WM-ACT-021 - 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.

references

WM-REC-006 - 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.
WM-KNW-010 - 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.
Configuration item and baseline model of the adopting Dimension - 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.
Change implementation, work-order and release model of the adopting Dimension - 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.
Problem, defect, incident and nonconformance model of the adopting Dimension - 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.
Party, role and organisation model of the adopting Dimension - 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.
Access control and audit models of the adopting Dimension - 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.
Records management and retention policy of the adopting Dimension - 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.

aligned

OASIS OSLC Change Management Version 3.0 vocabulary (oslc_cm namespace) - 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.
ISO 10007:2017 configuration management process (change control and configuration status accounting) - 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.
IETF RFC 3339 date and time on the Internet - 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.
W3C PROV-O provenance ontology - 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.
NIST SP 800-53 Rev. 5 Configuration Management (CM) control family - 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.
MIL-HDBK-61A(SE) engineering change proposal, deviation and waiver terminology - 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.

neighbor

WM-REC-006 Requirement - 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.
WM-KNW-010 Decision - 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.
Change implementation, work-order and release model - 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.
Configuration item and baseline model - 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.
Deviation and waiver (concession) requests - 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.
Problem, defect and nonconformance records - 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.
Audit trail and status accounting store - 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.
Records management and retention policy - 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.
Service request / standard pre-approved request - 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.

parent

WM-ACT-021

What else AI and robots need to interact with it Filled

Sources Filled

OSLC Change Management Version 3.0. Part 1: Specification - OASIS Open Projects (OSLC Open Project)
OSLC Change Management Version 3.0. Part 2: Vocabulary - OASIS Open Projects (OSLC Open Project)
ISO 10007:2017 Quality management — Guidelines for configuration management - International Organization for Standardization (ISO)
ISO/IEC 20000-1:2018 Information technology — Service management — Part 1: Service management system requirements - ISO/IEC JTC 1
NIST Special Publication 800-53 Revision 5, Update 1: Security and Privacy Controls for Information Systems and Organizations - National Institute of Standards and Technology (NIST)
NIST Special Publication 800-128: Guide for Security-Focused Configuration Management of Information Systems - National Institute of Standards and Technology (NIST)
ECSS-M-ST-40C Rev.1 — Configuration and information management - European Cooperation for Space Standardization (ECSS) / European Space Agency
NPR 7123.1D — NASA Systems Engineering Processes and Requirements (Updated w/ Change 2) - National Aeronautics and Space Administration (NASA)
RFC 3339 — Date and Time on the Internet: Timestamps - Internet Engineering Task Force (IETF)
PROV-O: The PROV Ontology - World Wide Web Consortium (W3C)
Quality Management System Regulation (QMSR) - U.S. Food and Drug Administration (FDA)
Change enablement in ITIL 4 — Change Enablement in the Cloud (AWS Well-Architected) - Amazon Web Services
MIL-HDBK-61A(SE) Configuration Management Guidance - U.S. Department of Defense (Office of the Under Secretary of Defense, Systems Engineering); copy hosted by AcqNotes

Open questions

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.
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.

Machine files

Card as JSON Specification AGENTS.md Source Card backlog vercy.card/1

Provenance

world-models research · reviewable-draft

Built from: models/wm-act-032-change-request/spec.yaml, ver-cy/world-models/card-supplements/wm-act-032-change-request.json