Checking the system you have today

Before telling someone that a fix is live, check the system they are about to use. If you’re responsible for delivering the work, a remembered successful deployment leaves a question unanswered: did that deployment include this fix?

A saved note can be accurate about an earlier state. An assistant can faithfully repeat that note and still give the wrong answer to a present-tense question.

A check that answers the question

Imagine an engineer correcting a search filter that excludes records on the last day of a selected date range. The change passes its local tests. A project note says the release is complete.

Before closing the issue, she checks which version is running, then exercises the affected search in the deployed application with suitable test records. She includes records on both sides of the boundary. The check connects the code change to the behavior people will encounter.

There are limits to what she has established. The observed case works in that deployment. She hasn’t proved that every search behaves correctly, or that the system will stay unchanged. Her report can say exactly what was checked and where.

The poor alternative is to treat the release note as sufficient evidence. Perhaps it describes an earlier release. Perhaps the new version is running, but a setting changes its behavior. Repeating “deployment complete” more confidently doesn’t resolve either possibility.

This is also why “check the source” needs an object. Which source, for which claim? The code says what was written. A release record says what was deployed. An observation of the application says what happened in the case observed. A customer’s report may reveal a condition the test didn’t cover. These sources answer different questions; choosing one without naming the question can leave the decisive gap intact.

Memory still has a job

I want working memory to make verification easier. Keep the location of the evidence, the version examined and the reason a check matters. That record gives the next person a useful place to start.

The literal rule would go too far if it required a fresh lookup for every familiar fact or repeated calculation. Suppose an analyst has already verified a fixed dataset and is comparing several ways to display it. Fetching a new dataset before every chart would change the experiment and add needless work. Keep using the verified input; check again when the input, the question or the intended use changes.

Exploration also needs room to proceed from experience. You can sketch a design or develop a hypothesis without sourcing every intermediate thought. Label the hypothesis when others might mistake it for a finding. Verify the consequential claims before someone relies on them.

When sources disagree

An official-looking source can be wrong. A search can miss a record because the filter excludes it. A status page can report success while a particular operation still fails. Verification involves examining what the evidence supports, including the possibility that the check itself is inadequate.

When you can’t make the decisive check, preserve that uncertainty in the claim. “The tests pass; I haven’t checked the deployed behavior” gives a colleague a clear next action. You can continue the work that doesn’t depend on deployment having succeeded. Closing the issue would require evidence you don’t yet have.