Define the unit of change
The fictional anchor is CR-17: move a customer data-export cutoff from 18:00 UTC to 17:00 UTC, with a requested 15 September 2026 release. The request itself says cost has not been assessed and approval has not been recorded. Every matrix row must remain tied to that one anchor.
Then freeze the related source set: scheduler work T-10, runbook task T-11, customer notice T-12, regression test T-13, warehouse dependency DEP-04, completeness control CTRL-06, missing security analysis SEC-02, and missing training assessment TRAIN-01.
Use standards with their real scope intact
NIST SP 800-171 Rev. 3 addresses protection of Controlled Unclassified Information in nonfederal systems and organizations. For systems in that scope, its configuration-management requirements include analyzing the security impact of changes before implementation and verifying controls after change. This article does not treat that sector-specific requirement as a universal mandate; SEC-02 exists to demonstrate how a missing applicable assessment should remain visible.
The UK Government's GovS 002 Project Delivery functional standard provides broader project-delivery context for governance, roles, planning, and control. In practice, use the authority, regulatory framework, and internal change policy that govern your organization.
Build the coverage gate before drafting
The seven domains are a fixture-specific completeness rubric:
| Domain | Fixture evidence | Question that must survive |
|---|---|---|
| System | T-10, T-13, SEC-02 | Did the code, test, and security assessment reach an acceptable state? |
| Process | T-11 | Is the operating procedure updated and reviewed? |
| People | T-12, TRAIN-01 | Who owns communication, and is training required? |
| Schedule | T-10–T-13 | Can incomplete work support the requested date? |
| Customer | CR-17, T-12 | What notice is required, by whom, and when? |
| Control | CTRL-06 | How will the documented 18:00 control expectation change? |
| Dependency | DEP-04 | Has the 17:15 consumer been tested against the new cutoff? |
The downloadable change impact matrix CSV contains the corrected seven-row version with source IDs, observed facts, unknowns, review actions, and empty approval fields.
The first response failed despite following the tone
The blind prompt named the possible domains but instructed the model to include one only when records supported an impact or unresolved assessment. It did not provide the expected output rows or final gate. The response produced system, process, schedule, customer, control, and dependency entries. It mentioned security and training in its final questions, yet no impact row cited SEC-02 or TRAIN-01, and there was no people row.
The local validator rejected that output for incomplete domain coverage. This is not a cosmetic disagreement: a change authority reading only the matrix could miss ownership and training work that the source packet explicitly contains.
Targeted correction after the failed gate
The first-pass output failed the fixture gate:
the people domain was omitted, and SEC-02 and TRAIN-01
were not cited in any impact row.
Re-audit only the supplied records.
Add source-bounded impacts without inventing conclusions.
Return corrected JSON only.Validate structure and meaning separately
The corrected output passed four fixture checks: the full domain set was present; every supplied source ID appeared in at least one impact; cost, approval, security, and training remained explicit questions; and the decision stayed REVIEW_REQUIRED. Three altered versions were then rejected when the people row was removed, SEC-02 was erased, or the gate claimed readiness.
Those mutations prove that the checker notices selected defects. They do not prove that seven domains are complete for a real change or that the proposed reviews are adequate. The full failure-and-correction pack includes both retained responses, the exact initial and correction prompts, the CSV, screenshots, validator, results, and hashes.
Tailor the matrix to the decision, not the template
Seven domains are appropriate for this cutoff change because the source set contains code, operating procedure, staff ownership, timing, customer communication, a control, and a downstream system. A facilities move, payroll rule, regulated product, or database migration will need different domains. Before using AI, ask the change authority what evidence must be visible for its decision.
Minimum row contract
- Source IDs: exact references to the change request and supporting record.
- Observed change: what the record actually says will differ.
- Known effect: only a consequence directly supported by the packet.
- Unknowns: absent owner, cost, date, result, assessment, or approval.
- Required review: the accountable function and the evidence it must produce.
Human review questions for CR-17
- Does the scheduler change behave correctly at the earlier cutoff?
- Is the 17:15 warehouse snapshot compatible with the new export timing?
- Who owns the customer notice, and what lead time is required?
- Does the completeness control need design, documentation, or evidence changes?
- What is the security impact conclusion under the applicable policy?
- Does the operating change require training or staffing adjustments?
- What cost and schedule effects have been assessed?
- Which authority can approve the change, and where will that decision be recorded?
Move each downstream artifact deliberately
New uncertainty belongs in the project risk register, but the risk register does not replace this source-to-domain map. Observable software behavior belongs in the acceptance-test workflow. When there is a real release candidate and current evidence, assemble the separate release readiness gate record.
Exit criterion
The matrix is ready for a change-authority meeting when the applicable domain rubric is defined, the frozen source set is covered, every row links facts and unknowns to evidence IDs, and accountable reviewers have been assigned. It remains analysis—not authorization—until the governing authority records its decision.
