Catalog Source of Truth: Choosing Ownership and Update Rules
How to decide which copy of a catalog record is allowed to win, who may change it, and how an update is recorded.
- 01 Name the record
- 02 Name the owner
- 03 Write update rules
- 04 Log the change
A source of truth is a rule about copies
Most catalogs have more than one copy of a fact. A supplier file, an internal editing tool, a search index, and a storefront can all hold a title. They will drift. “Source of truth” is the rule that says which copy is allowed to win for a given field, and how the other copies are refreshed.
It is not a slogan for a particular database. Calling a system the source of truth without saying which fields it owns just moves the argument into that system. Two editors inside the winning system can still overwrite each other.
Write the rule per field group, not only per record. The public name, the price, the availability flag, and the classification may have different owners. A single “master record” that pretends otherwise will be edited by whoever has the password.
This choice sits inside the operations workflow. The workflow needs an owner. This page is how that owner is specified. It does not replace the stage order.
Name the record before you name the system
You cannot assign a winning copy until you can say what the record is. Use a stable identifier and a record type. If two files use the same code for different things, you do not have one record with two copies. You have a collision. Stop and separate them before writing an update rule. Conflicting values describes that separation. An update rule that “lets the latest file win” will silently destroy one of the two things.
For a real record with several copies, list the copies. Include the ones people forget: the export a partner still receives, the cache, the spreadsheet someone maintains because the tool is slow. A copy you do not list will keep winning in practice.
Write update rights as permissions, not as trust
An update rule answers:
- Who may change this field group on the winning copy?
- Which incoming sources may propose a change, and which are ignored?
- What happens when a proposal disagrees with the current value?
- How quickly must the other copies refresh, or are they allowed to lag?
“The content team owns it” fails the first question if several people can edit and no permission distinguishes a proposal from a commit. Name the permission. A proposal can be broader than a commit. The winning copy changes only on commit.
Disagreement needs a default that was chosen in advance. Common defaults are: reject the proposal and keep the current value, accept the proposal and log the previous value, or hold both and require a person. Pick one per field group. “We will decide” is not a default. It is how the incident becomes the policy.
Lag should be explicit. A search index that refreshes hourly is not a second source of truth. It is a copy with a delay. Say the delay. If a customer can see the index, the delay is part of what you publish, even if you never print the number of minutes on the site.
This table scrolls sideways on a narrow screen.
| Decision | Question to answer | What to record |
|---|---|---|
| Winning copy | Which system is allowed to commit this field group? | System, field group, and record type |
| Proposal path | Which sources may suggest a new value? | Source list, or none |
| Disagreement | What happens when the proposal differs? | Reject, accept, or hold for a person |
| Other copies | What must refresh, and may it lag? | Copy name and allowed lag, or forbidden lag |
| Retirement | Who may remove the record from publication? | A separate permission from ordinary edits |
Change the rule in the open
An update rule is itself a catalog fact. When you change which system wins, that change needs a date and a reason. Records edited under the old rule stay as they were unless you run a migration. Do not reinterpret yesterday’s commits as if the new system had always won.
Release management is where a batch of catalog changes is named, validated, and logged. A change to the update rule belongs in that log as well. It is not a background configuration tweak. People will debug the wrong copy if they do not know the rule moved.
Keep the previous rule readable for as long as you keep the change log that cites it. A log line that says “updated under the ownership rule” is useless once the rule text is gone.
Do not confuse a public identifier with the winning database
If a catalog record is published on the web at a stable URL, removing the record without a trace breaks that URL. W3C Best Practice 27, in the Data on the Web Best Practices recommendation of 31 January 2017, says that when removing data from the web, preserve the identifier and provide information about the archived resource. The recommendation is about data on the web, and about dereferencing a URI, not about internal primary keys.
The operational reading for a public catalog is limited and still useful. If you have given people a public identifier, retirement should leave that identifier pointing at an explanation or at the replacement, not at an empty error with no context. That requirement does not decide which internal database wins day to day. It decides what the public identifier must do after you stop publishing the record.
Internal identifiers can be retired on a different rule. Write both. A public URL and a primary key are not the same object, even when one is derived from the other.
What this page will not settle for you
It will not tell you to centralize everything. Some field groups should stay with the supplier until intake accepts them, and only then move to your winning copy. It will not tell you to distribute everything either. Both patterns fail when the winning copy is unnamed.
It will not estimate how many systems are too many. That number is local. It will not name a vendor. The artifact this method asks for is the table above, filled with your systems and your permissions, not a diagram of someone else’s stack.
When ownership has to be explicit
When can a copy lag behind the winning record?
When you have written the allowed lag and the readers of that copy can tolerate it. A customer-facing copy with an unstated lag is a second, accidental source of truth.
When needed: As soon as a cache, index, or export exists.
When should a proposal be rejected automatically?
When the field group says so, for example a classification that only the vocabulary owner may commit. The rejection should be visible to the sender of the proposal.
When needed: In the update rule, before the first conflicting file arrives.
When do you rewrite history?
You do not. A new winning copy applies to later commits. Earlier values stay attributed to the rule that was in force, unless a separate migration says otherwise.
When needed: Any time the owning system changes.