Skip to content
hstation
ServicesWorkAboutBlogMusic library

Engineering · 2 min read · 2026-08-31

Why I put legal rules in the database

A rule written in a document gets skipped in the busiest week. A CHECK constraint does not.

On a recent project I had a simple rule: do not publish a client's name on a case study page without written permission.

That rule lived in a process document, had a checkbox in the pre-publish checklist, and everyone on the team knew it.

It got skipped anyway.

Why checklists fail

Checklists work well when the person using one has time and is not under pressure. Those are also the moments when the risk is lowest.

The problem is the last week before a launch, when one person has to publish twelve pages in two days. That is when a checklist turns into a tick-through, and it is exactly when a mistake costs the most.

I do not think the answer is better discipline. Discipline is depletable. Systems are not.

Push the rule to the lowest layer

That rule is now a constraint in the database:

  • The published state can only be set when three fields are present: the clearance timestamp, who cleared it, and a link to the evidence.
  • The person clearing it cannot be the person who wrote the piece. Nobody clears the publication of a client name on their own work.

There is no way around it. There is no flag to switch it off. An update statement missing a condition is rejected by the database itself, whether it comes from the admin interface, a migration script, or somebody typing SQL at two in the morning.

Where this approach stops

Not every rule belongs here. I apply it when all three of these hold:

  • Breaking it has legal or financial consequences, not just inconvenience.
  • The rule can be stated as an expression over that row's own data.
  • The rule is stable, not something that changes per campaign or per client.

Rules about tone of voice, image dimensions, or menu ordering do not qualify. They change often, and putting them in the schema only creates friction.

What it costs

This approach has a real price. A rule in the database means every rule change is a schema migration. The error messages the database returns are also far less readable than ones the application writes itself, so the interface layer has to translate them into human language.

I accept both. Changing a legal rule should be rare and considered, and translating error messages is a one-time job.

Author
Quản trị viên
Published
2026-08-31
Updated
2026-09-06
Reading time
2 min read
All posts