A finished software change shows what is different now. It does not yet show whether the result actually matches what someone wanted to achieve.
A requirement is written, an AI agent implements it, and the checks pass. It looks like a closed process: request in, working software out.
But the agent made decisions along the way. It may have interpreted an unclear term, added an edge case, or understood an existing rule differently from the business. The result can work cleanly and still rest on an assumption nobody consciously approved.
The faster a request turns into finished software, the more important the connection between the two becomes.
Finished is not the same as traceable
This problem is not new. Requirements were always incomplete, and humans filled gaps with plausible assumptions too. What is new is the speed. Some of the friction that once exposed open questions is disappearing.
A successful test shows that the software does what was checked. It does not automatically prove that the right business expectation was checked. As long as the request, the result, and the evidence live in separate places, their connection exists mainly in the minds of the people involved.
Four answers that belong together
What was meant to be achieved? The actual intent, not just a short task description.
What was implemented? The real result and its effects on the existing system.
What was checked? The expectations supported by evidence as well as the questions that remain open.
Who approves it? An agent can propose solutions and produce software. Responsibility for the business decision stays with a human.
This is where Decision-Driven Delivery begins: before implementation, it clarifies what was decided, why, and by whom. The article “Decisions, Not Tickets.” explains this approach in more detail. Evidence then follows the other direction: what became of that decision inside the software?
Traceability starts before implementation
Much can be reconstructed afterwards. But the connection is stronger when the starting point is fixed before work begins: this is the goal, this is the known state of the system, and this is the person responsible. The result, the checks, and any open risks are then connected back to that starting point.
The strength of each statement also has to remain visible. “Test passed” is an observed result. “Requirement met” is already a judgment. “No risk” may be only an assumption. Good evidence does not turn uncertainty into certainty.
Traceability is not a report added at the end. It accompanies the entire path from request to approval.
Changeproof makes the connection visible
This idea became Changeproof in the Entwicklerherz Lab. The tool connects the original goal with the actual software change, the checks that ran, and the points that remain open. The result is a “Change Passport”: a compact view of the basis on which a change can be judged.
An interactive demo follows a real software change from its business goal to the supported results and the remaining gaps.
Changeproof is a working Lab prototype, not a finished product and not a truth machine. It cannot reliably detect whether something was created by AI, and it cannot guarantee a correct decision. Its value is giving people a better basis for review and approval – especially when more software is produced than a team can understand at the same pace.
Anyone who wants to inspect or try the technical implementation can find the local library and command-line tool in the public GitHub repository.
A human still makes the final decision. But that decision no longer has to rely on scattered tasks, green checkmarks, and memory.