A final passing plot cannot explain earlier failures. If a parameter change leaves only the newest file, later participants cannot easily judge whether the change was necessary, whether the original problem was resolved or whether another normal behaviour was affected.
R&D software needs to preserve that process: when an anomaly appeared, which input was used, who changed what and which checks ran again. Those records give the next round a concrete starting point.
First save what happened
At failure, retain original inputs, settings, tool versions, logs and outputs where possible. Equipment tasks may also need sample batches, environmental conditions and instrument state. Screenshots aid reading but cannot replace raw data.
Record observations before causes. An abnormal weight curve may arise from weighing, feeding or data mapping; a failed import may involve units, format or missing fields. Before checking, software should allow “cause undetermined” rather than force a definite explanation.
In MOTRA local practice, insufficient sources or ambiguous attribution return to a person. Repair proceeds only with an evidenced scope, while engineering questions remain open. This avoids presenting a software repair as proof of an entire machine’s reliability.
Keep changes with their evidence
Each change needs a motive, scope and expected effect. Signal-mapping changes require input and state checks; dimensional changes also require rechecking dependent geometry and assembly. Keep the original version accessible for comparison and rollback.
PhysicsX’s glider-test article records problems introduced by the launcher and mounting and then explains the corresponding changes. Readers can follow a problem into the next attempt instead of seeing only the final flight.
For software, the same principle applies: trace a change to its failure and re-execution results to the change. A version with no error message is not enough to establish that the old problem is resolved.
Use regression to judge adoption
Regression should at least retrigger the original failure and cover normal behaviour affected by the change. Showing only the new version’s best run makes intermittent problems hard to see. Task requirements determine repeat conditions, count and anomalies; record results honestly.
Reproducibility under a fixed configuration means that software behaviour can be checked again. Different samples, environments or equipment require new tests. Reports should state condition changes rather than carry old results into a new scope.
Material experiments need the same context. Uncountable’s Mitra Chem case retains process information through linked samples. Tracing anomalous measurements to their sources and handling steps gives later teams a basis for deciding whether to remeasure or change the design.
Let the next participant continue
Compared with information management containing only attachments and current status, records with versions, reasons and regression results can explain a decision. Whether they save time or reduce omissions must be measured in actual use; benefits are not filled in beforehand.
GOPROMP’s approach to R&D management starts with these actions: retain evidence, mark open questions and hand over the next check. Materials research, mechanical design and experimental organisation can use different applications, each with task-specific failure handling. Explaining a failure gives the next round usable knowledge.