The grandfathered label: when honesty is cheaper than backfill

mCORE is a mobile-first carrier tool. One of its features is a Route Forward Manager: carriers scan forwarding stickers, the tool stores them, and they can report on them later. Until recently, the tool showed you what you had. It did not show you what had changed.

Phase A of the roadmap added an event log. Every create, update, delete, and archive now writes a row to an append-only log. The edit form grows a History tab. You can see when a forward was scanned, when the name was corrected, when it was marked inactive. That feature shipped cleanly.

The day after, a carrier asked a reasonable question: why does my old forward from three months ago show only one event in its history, and why is that event dated yesterday?

Because I turned the feature on yesterday. The old forwards predate the log. They have no history in the log because no history was ever recorded for them. I had three options and I had to pick one.

Option 1: backfill fake dates

The forwards table has a created_at on each row. I could walk the table, synthesize a single "created" event per forward using that timestamp, and pretend the log had been running all along. The display would be clean. Every forward would show a history. Nobody would ask the question again.

This is the option a lot of apps take. It is wrong. The created_at on the row tells you when the row was inserted. It does not tell you when the sticker was scanned, when it was corrected, when it was edited, or when the carrier first looked at it. A backfilled event says "I know this" when actually I do not. The display would look right and would be lying.

For a consumer app, maybe that is acceptable. For a tool carriers use to track mail that has legal consequences when routed incorrectly, it is not. The whole point of the event log is to be audit-grade.

Option 2: hide the old ones

I could filter the history view to only show events from after the log was enabled. Old forwards would have a blank history tab. Technically correct, cleanly implemented, user-confusing. The carrier who asked would still be asking, he would just not be able to see why.

Option 3: the grandfathered badge

Every forward that existed before the log was enabled now shows a visible grandfathered tag in its history tab, with a one-line explanation: This forward predates the event log. No edit history is available before 2026-04-11.

No fake events. No hidden context. The user sees that the feature started on a particular date and that the data before that date is what the database has and no more. It took an hour to implement and it tells the truth.

Why this is the whole framework in miniature

Auditable tools have to be honest about what they know and what they do not. The moment you start synthesizing history to make the UI look complete, the audit loses value. If I had backfilled, a carrier who later used mCORE's history as the basis of a grievance or a dispute would have been citing data I had made up. That is how audit tools fail, and they fail quietly.

The grandfathered tag is ugly. It is also true. In a tool whose value proposition is that the data is real, true beats pretty every time.

mCORE is at mailman-sam.github.io/mcore. The Route Forward Manager event log is in v2.0.15 and up.