On September 15 we told the database to refuse a new person whose name is a near-match for one we already have. Then we replayed every person created since May, 1,046 of them, against the rule. Eleven would have been refused. Ten of those were real duplicates that had actually been created and had to be cleaned up by hand. One was a pair of different people with similar names, which is what the override is for.
That rule has a name in our system and a dozen siblings. This is the piece about the rules a database enforces on its own, and why a newsroom needs them more than a style guide.
Prose does not fire
Here is the pattern that produced every one of these rules. A mistake happens. We write down the rule that would have prevented it, in a document that every session is supposed to read. The rule is correct. Months later the same mistake happens again, because the rule lived in prose and prose does not fire. It is read on the calm day and skipped on the busy one.
So the rules moved into the database, where they fire on every write, from every tool, by every person, including me. A rule in the database cannot be forgotten. It can only be deliberately overridden, and the override leaves a record with a name on it.
Some of the rules
A person cannot be created twice. Same first name and a surname within a couple of letters, or the same surname and a first name that is a nickname of the other: refused, with the existing record named in the error so the writer reuses it. Persons only, on purpose. Places and organizations are watched but not blocked, because "District 5" and "District 6" are legitimately different and a rule that cries wolf gets switched off.
A category belongs to one publication. A Farmington story cannot carry a Charlotte category, even one with the same name. Before the rule, 98 stories had drifted onto another publication's category, invisibly, because same-named categories render fine.
A person's public profile cannot carry their home address or date of birth. The rule fires on the specific shape those details take in an arrest log, and deliberately not on an arrest date, an arrest location, or a business address, because the first version caught 28 ordinary entries and a rule that fires on everything protects nothing.
A transcript cannot be marked processed until the work exists: its people linked, its facts written into the relevant beat, a marker pointing at the write it produced. Not a checkbox. The artifacts.
A published show episode closes its own planning row, so the calendar cannot say "overdue" about something that shipped last Wednesday.
A sync from a beat file cannot overwrite a roster entry a human edited in the newsroom desk, our internal tool. It stops and says so.
What they have in common
Each one reads an artifact, never a report. Each one was written the day a failure earned it, and tested against the real failure, re-created, before it went live. Each one has a watchdog beside it on the nightly checks board, in case a path bypasses it. And each one was tuned against live data to fire rarely and correctly, because the alternative to a precise rule is not a loose rule; it is no rule, once someone turns it off.
Why this is a publishing decision
Very little of this is available on a rented content system, and none of it in the form we need, because the rules are ours. They encode how we publish: that a person has one page, that a category belongs to a paper, that private details stay out of public profiles, that "done" means the work exists. A vendor cannot know those things. We do, and we put them where they cannot be forgotten.
A newsroom's standards are only as real as the thing that enforces them. Ours are enforced by the database. That is not a technical choice. It is an editorial one.
This is No. 12 in We Built Our Own. Previous: Backups we can prove. Next: One database is the whole company.