Engineering Test Evidence After Rework: Keep the Failure and Repair History Attached to the Same Unit
After rework, verify the functions the repair could affect and attach the new evidence to the same unit’s unchanged failure history. Repeating only the original failed test can miss a disturbed connector, invalid calibration or a changed configuration introduced during repair.
This article defines an original per-unit rework evidence method informed by NASA SP-2016-6105 Rev2. A small dependency and record-association model ran on CPython 3.12.14. No product was repaired, calibrated or released, and the example dependency map is hypothetical.
Preserve the failed configuration before repair
Record the physical unit identity, hardware and firmware configuration, failed requirement, raw observations and conditions that exposed the defect. Preserve the first result even if later testing cannot reproduce it.
Separate the observed symptom from the diagnosed cause. “Sensor reading invalid” is an observation; “connector contact failure” is a hypothesis until supported. A repair record should identify what was changed and why without silently converting the hypothesis into a proven root cause.
Keep original photographs, logs or measurements in their approved evidence store with appropriate access. Avoid including unnecessary customer data or credentials in a repair package. The technical link needs the unit and configuration context, not unrelated personal information.
Create a physical and software change record
Describe replaced parts, reworked connections, harness movement, mechanical changes and software or persistent-data changes made during diagnosis. Include the actual resulting revision and any controlled component identity needed for traceability.
A repair can leave the marketing model unchanged while materially changing the test configuration. Replacing a sensor may alter calibration applicability; replacing a storage device may alter provisioned data; a diagnostic firmware flash may leave a different boot or application state.
The NASA handbook’s configuration-management guidance supports identifying controlled configurations and managing changes. Apply that principle at the unit level: the post-rework article must have an identifiable state, not merely a note saying “fixed.”
Map the repair to dependent functions
| Hypothetical intervention | Functions or assumptions to review | Evidence to define |
|---|---|---|
| Replace a sensor. | Acquisition, calibration association and alarms derived from the reading. | Correct data path, applicable coefficients and dependent behavior. |
| Rework a connector. | Signal continuity, power path and communication through affected pins. | Relevant physical inspection and functional checks. |
| Replace storage. | Boot content, persistent identity and retained configuration. | Approved restoration and final configuration verification. |
| Move an antenna or shield. | Mechanical state and radio behavior affected by the change. | Product-specific inspection and required radio requalification. |
| Change firmware during diagnosis. | Released image, persistent-data compatibility and enabled test hooks. | Verified final handover to the intended shipping state. |
This table supplies questions, not a universal repair checklist. Use the actual schematic, assembly process and requirement dependencies. Do not prescribe an arbitrary RF test or calibration operation solely because a component name appears in the record.
Include adjacent disturbed paths, not only the part believed faulty. A connector repair may disturb a shared supply or return even when the original symptom involved one signal. A documented exclusion needs a reason showing that the function’s relevant dependencies were unaffected.
Decide what earlier evidence can still be reused
For each prior result, ask whether its article configuration, stimulus, measurement path and acceptance assumptions remain applicable after the repair. Retain an older result when the reuse argument is justified; do not repeat everything automatically without considering risk and coverage.
Keep calibration validity separate from numeric plausibility. A coefficient that produces an in-range reading may still belong to a removed component or an obsolete method. Verify its association and applicability through the approved process rather than copying it forward silently.
When the repair changes a requirement or design baseline, route that change through the responsible engineering process. Rework verification should not become an informal way to approve a different product specification.
Write the post-rework verification plan
List the checks required by the repair-impact map, their current configuration, observable criteria and evidence to retain. Include the original failing condition where it can be safely reproduced and any dependent or adjacent functions identified by the review.
Distinguish physical inspection, calibration, configuration checks and functional tests. A successful visual inspection does not automatically establish communication behavior, and a passing functional check does not prove every workmanship requirement.
Use the intended final firmware and supported operating path where the claim requires them. If diagnostic firmware supplies useful intermediate evidence, document which final checks remain after it is removed. Record incomplete checks explicitly instead of filling them from the unit’s earlier pass history.
Executed dependency and association controls
The host model supplied two hypothetical repair actions. Sensor replacement required sensor_read, calibration and alarm checks. Connector rework required sensor_read, power and link checks. Their union contained five distinct required checks.
The model rejected a closure containing only sensor_read. It also rejected a complete set attached to the wrong unit and a complete set attached to the old configuration. A complete set for unit U1 under the new C2 configuration was eligible for the model’s next review step.
A new R2 record linked to the original R1 without changing R1’s canonical serialized contents. These assertions test supplied dependency selection and record association only. They do not establish that the dependency map is complete or that any physical check actually passed.
Append outcomes without rewriting history
Give each inspection, retest and final disposition a new identity linked to the unit, repair record and resulting configuration. Preserve the original failure as a historical observation while recording its diagnosed cause, corrective action and later verification separately.
If a new check fails, retain it and reopen the repair scope. Do not overwrite the first result with the latest pass or merge multiple attempts into a fictional single successful run.
The final package should show the original condition, actual intervention, affected-function map, reused evidence rationale, new verification and remaining restrictions. This closes a specific unit’s repair with traceable evidence; it does not determine the population affected by a factory fixture change or authorize release merely because the original symptom disappeared.
