Code changes cannot be marked complete until they have been proven
Automated tools often report “done.” Sometimes it is true; sometimes something has been quietly left broken. The completion loop refuses to take the report at face value. It verifies work against the actual change, runs the relevant test suite, scans for anything broken or half-finished, and only allows a task to be marked complete when there is evidence to back it up. The evidence is bound to the exact change, so “done” is an auditable record, not a claim.
The most expensive automation mistake is the one reported as finished.
Every other AI tool takes the model’s word that the job is done. On a quick draft that is fine. On software your business runs on, a confident “done” that is actually half-finished is how outages and breaches get shipped. The completion loop is the backstop. It demands proof tied to the real change before anything is allowed to count as complete, and it keeps the record. That is the difference between a demo and something you would trust near production, and it is what lets you safely let AI do more of the work on its own.
Four gates between a tool’s claim and a verified completion.
The tests actually pass.
The relevant test suite runs against the change and comes back green. A skipped or removed test does not count as passing.
Nothing in the diff is half-done.
The change is scanned for stubs, mocks, TODO markers, and silently-caught errors. Any unfinished work blocks the completion.
The scope was actually covered.
The original requirements are checked against the actual change. Any requirement raised but not addressed is reported, instead of slipping through.
The evidence is locked to the change.
The proof artifacts (test runs, scans, scope check) are bound to the exact files and lines that changed, so the audit trail cannot be edited away from what was really verified.
Trust “done” again, because it has to be proven
Automated work, accepted safely, with proof at the end of every job.