Why Engineering Decisions Need Evidence

Technical Perspective

Imagine returning to a system after a month away. A test is green. The change that introduced it is merged. The notes say that the chosen approach was the simplest reliable option.

Then a small question appears: simplest for which situation?

The answer may have been obvious. Perhaps the system was being reconstructed from incomplete material. Perhaps a dependency was temporarily unavailable. Perhaps a failed experiment had ruled out one path, or an assumption about the operating environment had not yet been tested. Without that context, the code and the green test remain, but the decision is difficult to interpret.

This hypothetical scenario illustrates a common engineering problem: a decision can survive in a repository after the reasoning that made it sensible has disappeared.

The part of engineering that code does not preserve by itself

Software and technical systems leave many kinds of evidence behind: source files, configuration, test output, diagrams, issues, and deployment records. Those artifacts matter, but they do not automatically explain the path that produced them.

An engineering decision usually depends on more than its visible result. It may depend on:

• the problem the decision was intended to solve;
• the alternatives that were considered;
• assumptions about users, data, dependencies, or the operating environment;
• constraints that made some options impractical;
• evidence that supported the choice;
• uncertainty that remained at the time; and
• changes that occurred afterward.

Together, these details form the decision’s provenance: the information needed to understand where it came from, what it was meant to accomplish, and how much confidence it deserves now.

Provenance is not paperwork added after the real work. It is part of the work’s continuity. When a later engineer can see not only what changed but why it changed, they can test whether the original reasoning still applies. When they cannot, they may preserve a decision that no longer fits, repeat an experiment that already happened, or remove a constraint that was carrying more weight than its name suggested.

Continuity across sessions

Engineering continuity becomes difficult whenever work crosses a boundary: a new development session, a handoff between people, a change in tools, or a transition between a person and an AI-assisted system.

The boundary itself is not the problem. A well-described handoff can be useful. The problem is that summaries tend to compress exactly the information that later judgment needs. “Use approach B; approach A was rejected” is shorter than “approach A was rejected because it depended on an unavailable component under the current reconstruction constraints, while approach B preserved the required behavior with a known limitation.” The shorter note is easier to write and much harder to trust.

AI-assisted engineering makes this tension more visible. An AI tool can help compare approaches, generate code, document changes, and identify questions. It can also make it easy to move quickly through a large amount of context without making the important assumptions explicit. A later agent or engineer may receive a polished result without receiving the boundary conditions that made the result acceptable.

The remedy is not to preserve every intermediate thought. That would create a different failure: an archive so large that the useful reasoning is hidden inside it. The goal is selective continuity. Preserve the question, the decision, the basis for the decision, the unresolved uncertainty, and the evidence that would cause someone to revisit it.

Saor’s public engineering philosophy describes this as human-directed, AI-assisted engineering: tools may expand the range and speed of investigation, while responsibility for decisions, acceptable risk, and final acceptance remains human. The principle is described in How We Work.

A handoff that carries evidence

Consider this explicitly hypothetical handoff:

Revision 7f3c2d1 passed the reconstruction test against the approved sample set. The decision was to keep approach B because approach A required a dependency that was unavailable in the target environment. After that revision, the source code changed in the input-normalization path. Before relying on the earlier result, compare the changes with 7f3c2d1, confirm whether the test still exercises the same path, and rerun or replace the evidence if its conditions no longer hold.

An inadequate note would say:

Tests pass at 7f3c2d1. Continue from here.

A useful handoff records the tested revision, the relevant inputs, the reason for the decision, the change that may affect applicability, and the reviewer’s next question. The difference is not the amount of prose. It is whether the next person can determine what the earlier test actually supports.

A test result is not a permanent fact

Running a test answers a narrower question than engineers sometimes assume. It tells us what happened when a particular test ran against a particular version, with particular inputs and conditions.

That result can still matter.

Consider a hypothetical reconstruction procedure that succeeds on a preserved sample under one dependency set. If the dependency later changes or the input is normalized differently, the earlier result still describes its original run but may no longer support the same decision.

To decide whether evidence still applies, someone needs enough context to compare the earlier conditions with the current ones. That usually includes the version under test, the relevant inputs, the environment, the intended scope of the result, and the changes made since the evidence was collected.

This is why “the test passed” and “the test is still evidence for this decision” are different statements. The first describes an observation. The second is an interpretation that depends on provenance and change.

The distinction also protects against a subtler mistake: treating a successful prototype as proof that a production system is ready. A prototype can answer an important question while leaving reliability, security, operational cost, or maintainability unresolved. Good engineering keeps those boundaries visible instead of allowing one positive result to carry more meaning than it earned.

Different kinds of review provide different assurance

The person or process that builds a system is often well placed to understand its intent. That same familiarity can make it harder to notice an assumption that has quietly become part of the implementation.

Self-review is the first level: the builder checks the work against the intended question and looks for obvious mistakes. Even when it happens later, self-review remains the builder’s own evaluation; time and distance do not make it independent. A separately performed evaluation goes further by having another person or process execute checks or examine the result, but it may still share the builder’s assumptions, context, or definition of success.

Independent verification adds a different kind of assurance. The evaluator has enough separation to challenge the claim, the test conditions, the limits of the result, and the possibility that the implementation has been evaluated against an easier question than the real one. These forms of review are valuable at different levels of risk; they should not be treated as interchangeable.

Independence does not mean that every change requires a separate organization or a ceremonial review. The appropriate level depends on risk. It does mean that building and judging are different responsibilities: when one person performs both, the later judgment is still self-review, not independent verification.

This separation is especially important when work is handed between sessions or tools. A clear record allows another person—or a later human-led review—to challenge the reasoning rather than merely inspect the final artifact. It turns verification from a search for reassuring output into an examination of whether the output answers the intended question.

Where TPMS fits

TPMS — Engineering Continuity & Verification is publicly described as a developmental system exploring how engineering context, decisions, uncertainty, and supporting evidence can remain useful as work moves between people, agents, and working sessions.

This article connects to that public research direction at the level of the problem, not by claiming a finished system or validated result. The same continuity problem appears whenever engineering decisions need to remain understandable after their original session has ended.

The interesting question is not whether every project should produce a large record. It is how a project can preserve the smallest useful account of its reasoning while keeping uncertainty and change visible. That question touches documentation, experiment design, review, reconstruction, and the boundaries between human judgment and tool assistance.

A practical standard for future decisions

For a decision that may matter later, a compact record can begin with five questions:

1. What question or requirement prompted the decision?
2. Which alternatives were considered, and why were they not chosen?
3. What assumptions and constraints shaped the choice?
4. What evidence supports it, and what does that evidence not establish?
5. What change would make the decision worth revisiting?

These questions are not a rigid template. A small implementation choice may need only a sentence. A high-risk reconstruction or architectural decision may need experiments, comparisons, and independent review. The useful measure is not the volume of documentation, but whether a future reader can recover the decision’s meaning without guessing.

That fits Saor’s broader principle of preferring the simplest reliable solution that meets the actual requirements, while introducing complexity when evidence demonstrates that it is needed. The public Research Library overview places TPMS alongside other questions about understandable, user-controlled, and evidence-aware systems.

Questions worth exploring next

Several subjects would make valuable companion articles when there is approved material to support them:

• Decision provenance in practice: what information makes a technical decision recoverable without turning a project into an archive of every thought?
• Evidence applicability: how should engineers compare a prior result with a changed system, input, dependency, or operating context?
• Agent handoffs: which context must remain explicit when work moves between people, sessions, and AI tools?
• Independent verification: how can review be proportionate to risk while still challenging the assumptions behind a result?

These topics would extend the argument when approved material exists. They lead back to the same central question: when someone inherits an engineering decision, what would allow them to understand it, test it, and responsibly decide whether to keep it?

When the next engineer finds a green test, a merged change, and a note calling an approach “the simplest reliable option,” the evidence should help answer the question that follows: simplest for which situation? It does not make the decision permanent or certain. It preserves enough context for the next engineer to judge whether the reasoning still holds.

That is the practical value of engineering evidence: not certainty, but continuity that survives the person and session that created it.