Your Schema Is an Epistemology

I got a data model wrong recently in a way that turned out to be more interesting than the fix.

Our rules layer originally had one field: `effective_date`. If the date had passed, the system treated the rule as binding. Clean, obvious, and quietly incorrect.

Because "in effect" and "being enforced" are different questions with different answers. A rule can be validly in effect while its enforcement posture is genuinely unsettled — pending litigation, pending interpretation, pending an agency saying what it means in practice.

With one field, the system had no way to represent in effect, posture unclear. So it did what systems always do when the schema lacks a state: it picked the nearest available one and asserted it with total confidence.

That is bad anywhere. Where the output informs an operational decision, it is genuinely harmful — because the person downstream acts on the strength of your confidence, and your confidence was an artefact of a missing column.

The fix was structural rather than clever. Every rule record now carries `effective`, `enforcement` and `litigation` as separate fields, plus a `verification` field recording what our review has not confirmed. The honest answer became a first-class value instead of a null.

The part I keep thinking about is the generalisation.

Your schema is an epistemology whether you intended it to be or not. It encodes what kinds of knowledge your system is capable of holding. If there is no field for "we do not know yet", your product will not simply omit that state — it will convert it into something else, and everything downstream will consume the conversion as fact.

The absence of a column is not neutrality. It is an assertion that the state does not exist.