A post-prototype change record should compare the intended design, the prototype as actually built or configured, and the results observed during inspection or testing. It should distinguish confirmed changes from suspected causes and unresolved issues. NIST’s digital-thread work supports this approach: it identifies feedback from inspection back to design as part of the process and describes data connecting design, manufacturing, and inspection.
What the change record should contain
A useful record is structured evidence rather than a general account of what happened. The following fields provide a practical starting point:
| Field | Information to preserve |
|---|---|
| Design reference | The drawing, model, specification, or other material that defined the intended prototype at the time of the run |
| Prototype state | The actual build, configuration, material, process, or setting used, including departures from the design reference |
| Observed difference | What changed, where it was observed, and how it affected the prototype |
| Supporting evidence | Measurements, test output, inspection notes, images, or other records connected to the observation |
| Interpretation | The proposed explanation, clearly labelled as confirmed, provisional, or unverified |
| Decision | Whether the difference requires a design revision, another inspection, a comparison run, or further confirmation |
| Open items | Unanswered questions, missing evidence, and the next checking action |
| Trace information | Identifiers, versions, and timestamps that connect the record to the relevant design, manufacturing, and inspection documents |
The distinction between the design reference and the prototype state is essential. A change record cannot reliably explain a result if it does not show both what was intended and what was actually used.
Keep observations separate from conclusions
An observation reports what the available evidence shows. A conclusion assigns meaning or a cause.
For example, “The surface appearance differed from the reference sample” is an observation. “The finishing process caused the difference” is a conclusion requiring supporting evidence. Another prototype run, a process record, or further inspection may be needed before that explanation can be treated as confirmed.
A clear change record therefore labels:
- Observed: directly supported by the recorded evidence
- Inferred: a reasonable interpretation that still requires confirmation
- Confirmed: supported by evidence accepted for the relevant purpose
- Open: unresolved because evidence, comparison, or authorization is still needed
These labels are working documentation controls, not NIST-mandated categories.
How to check the record
A reviewer should be able to answer several questions directly from the record:
- Can the intended and actual states be reconstructed? The design reference and prototype state should be identifiable without relying on memory or an informal conversation.
- Does every important observation have linked evidence? Measurements, images, test results, and inspection notes should remain traceable to the relevant finding.
- Are observations and interpretations clearly separated? A suspected cause should not be written as an established fact.
- Do the records agree? The design, manufacturing, and inspection entries should not silently refer to different versions or configurations.
- Does the record produce feedback for design? It should state the resulting decision or identify what still needs to be checked.
- Are unresolved items visible? Missing evidence and inconclusive results should not disappear from the final narrative.
This creates the basic feedback loop described by NIST: information from inspection can return to design with its evidence, status, and unresolved questions intact.
What still requires confirmation
The record itself does not prove which design version controlled the run, whether the as-run description is complete, or whether an inspection or test method is suitable for the intended conclusion. Those points remain matters for the maker to verify.
The maker must also confirm whether a proposed cause is supported, whether a design change has received any required internal or other applicable approval, and whether further testing is needed. The cited NIST material does not prescribe a mandatory change-record format, retention period, approval chain, or acceptance threshold. No such requirement should be inferred from it.
Until those checks are complete, the document is best treated as a traceable working record rather than final proof of what caused the result.