An Edit Date Is Not a Verification Date

Most systems store two dates. Created. Updated.

Both of them tell you something about the database. Neither one tells you anything about the world.

I touched a record last Tuesday. Good. Did I check it against the source, or did I fix a typo in somebody name? The updated timestamp cannot tell the difference. And if that is the only date you keep, you will eventually hand a customer a stale fact with a fresh date stamped on it, and neither one of you will have any way to know.

That is not a data problem. That is a schema problem, and you create it on day one.

Add the third date

Add a field. Call it last_checked, or source_checked_at, or whatever fits how you name things. One rule on it.

It only moves when a person actually opened the original source and confirmed the record still matches.

Not when the row got imported. Not when the page got rebuilt. Not when somebody fixed a capital letter.

Only when a human went back and looked.

Now you can ask your own database a question you could not ask before. What is in here that nobody has laid eyes on in ninety days?

That question is the whole point of the field.

What it looks like in the open

RepWatchr is mine, so I will use my own work as the example. Its coverage page publishes that count instead of keeping it internal, and it says the quiet part in writing. A later import or edit date does not confirm that a person still holds office.

That one sentence is the entire schema lesson in plain English.

Somebody could re import the whole roster tonight. Every updated timestamp in the system would go green. Every fact in it would be exactly as old as it was this morning.

This is not just for directories

I keep hearing this only matters if you are running a database of officials. It does not.

Your pricing page. When did somebody last confirm those are the prices you actually charge?

Your staff page. When did somebody last confirm all those people still work there?

Your service area. Your hours. The phone number in the footer. The integration you say you support. The certification you say you hold.

Every one of those is a claim about the world sitting on a page, and every one of them goes stale on a schedule nobody ever wrote down. Your website will happily tell you the page was edited in March. It will not tell you the last time a human verified the thing the page says.

How to retrofit it

If you already shipped without it, you are not stuck.

Add the column. Backfill it null. Do not backfill it with the updated date, ever. A null is honest. A guess is not, and a guessed verification date is worse than no date at all, because a date gets believed.

Then build one view. Everything null or stale, oldest first. That view is your work queue from now on.

Then decide the interval out loud. Ninety days, six months, a year, whatever fits how fast your facts actually move. Write it down somewhere a customer can read it.

Why this one matters to me

Because I have been on the receiving end of a confident record that was wrong.

A stale fact with a fresh timestamp is not a neutral mistake. It is a fact wearing a badge it did not earn. Somebody reads it, believes it because it looks maintained, and then makes a decision on it.

Two columns instead of one. That is the entire fix.

Build it now, while the table is empty and it costs you five minutes. Build it in year three and it costs you a migration and an apology.