Where a fact comes from and when it was true

Most business databases keep one value per field. When the value changes, the old one is overwritten. That works until someone asks about the past. What did we know about this supplier when we signed the contract? Who entered this figure, and where did it come from? Was the address wrong back then, or did the company move later?

The problem grows when sources disagree. A company register lists a supplier under one legal form, the supplier’s own website names another, and a year later the register corrects its entry. A database with one field for the legal form can hold only one of these answers. It cannot say which source claimed what, or since when. The same happens with prices, product weights, contacts and owners. Now that more and more sources contain AI-generated text, a fact of unknown origin is worth even less.

The second part of my research question is how knowledge about an object can be kept together with its time and its source.

Keep every claim, overwrite nothing

My approach is to store each fact as a separate claim that is never overwritten. A claim records the value, who entered it, which source it cites and how far that source can be trusted. A correction adds a new claim and hides the old one without deleting it. The database can still show what it said before, and who said it. Removing a value needs a written reason.

The cost is volume, because the store grows with every claim and every correction. I accept that cost. An overwritten value is gone for good, and a hidden one can be restored.

Two dates for every fact

Each claim carries two dates. The first says when the fact was true, for example the day a contract began. Sources often know only the year, so this date may be incomplete. The second says when the database learned the fact. A register entry read today may describe a change that took effect years ago. With both dates the store answers two different questions: what was true on a given day, and what did we believe on that day. The technical term is bitemporal modeling.

Trust in sources

Sources differ in how reliable they are. An official register counts for more than a forum post, and an experienced editor for more than a new account. Each claim stores a trust rank, the lower of the rank of its source and the rank of its author. The rank is evidence for a later review. Which value appears is decided by the latest editorial change. Otherwise an old, highly ranked claim that nobody sees anymore would block every correction. A careless edit can then push aside a well-sourced value, but the old claim stays, and the edit can be reversed.

Fast copies stay copies

Applications read from simplified copies because they are fast: one flat column per value, or a search index. Such a copy drops detail. A shop page may show a product’s gross weight where the net weight belongs, and the column does not say which one it holds. In my approach the claims are the only source of truth. Every copy can be rebuilt from them and never writes back. A gap among the claims can be deliberate, because an editor may have removed a wrong value, and refilling it from an old copy would overrule that decision.

What is in use and what is open

The claims, the two dates and the trust rank are in production use on a client’s information platform. Grouping the changes of one edit into a version is a design I am still developing.

Two questions are open. Which value should a reader see when the latest edit and the trust rank point to different claims? And how do claims follow an object when two records turn out to describe the same thing, or one record turns out to describe two? The second question is part of my work on object identity.

I use W3C PROV-O and the ISO standard on data provenance as references and do not call the store compliant with either.