A compliance register is not a list of obligations, it is a rule that produces a list
The first version of this platform modelled compliance as a person holding a credential that runs out. A member of staff, a job designation, a set of credentials that designation requires, an expiry date on each one. Compute who is missing something and who is about to be, and show it on a dashboard.
That model is correct and it is a special case. I found out how special when I built a register for a different sector: 184 continuing obligations across 15 domains, compiled from the statutes and approval regimes that apply to a single kind of business in a single region.
Perhaps a dozen of them are a person holding a certificate. The rest are filings, returns, notices, inspections, physical facilities, retention periods, payments, insurance policies and permissions that must exist before a particular activity may begin.
What the rows actually had in common
Reading 184 rows looking for the shape they share, five fields survived.
The obligation — what must be true or done. The source — which instrument requires it, because when somebody challenges an entry the first question is where it came from. The trigger — what causes it to apply and what causes it to fall due. The artefact — what constitutes evidence that it was done. The owner — which function is accountable, of which there were six across the register: head office, compliance, safety, site, finance and legal.
Nothing else generalised. Not the frequency, not the deadline arithmetic, not the shape of the evidence. Those three are where the variety lives, and they are where the modelling effort goes.
Frequency is not a calendar field
The vocabulary needed eight values, and only five of them are calendar periods: daily, monthly, quarterly, half-yearly, annual. The other three are the difficult ones.
Once per project. The obligation arises when a project starts and is discharged once. It is not recurring, but it is also not a single global task, because there are many projects.
Event-driven. The obligation arises when something happens — a worker joins, a piece of equipment is altered, an incident occurs, a particular is changed. There is no schedule. The occurrence is created by an event elsewhere in the business, which means the compliance system has to be told about events it does not own.
Periodic at a rule-defined interval. The interval is a function of something other than the calendar. One example from this register: medical examinations for certain roles fall due every two years below a given age and every year above it. The interval depends on an attribute of the subject and changes as the subject ages.
A frequency enumeration with five calendar values covers a bit under half of a real register. If your model treats frequency as a period, everything else becomes a special case, and special cases in a compliance product are the items that get missed.
Applicability is a predicate, not a flag
Many obligations only apply above a threshold. Several are headcount-based, at a range of different thresholds depending on the obligation. Others depend on the size of a site, the presence of a particular process, or the height of a structure.
This is the part that changes the design most, because it means an organisation’s obligation list is not stored. It is computed.
Hire past a threshold and a set of new obligations begins to apply, immediately, with deadlines that may already have started running. Drop below it and they stop — although the retention obligations attached to them do not. The register is a rule that produces a list, evaluated against the organisation’s current state.
A product that lets a customer tick which obligations apply to them will be wrong within a month of their next hiring round, and nobody will know it is wrong until an inspection. A product that evaluates applicability from data it already holds — headcount, sites, activities — can tell a customer that something new applies to them the week it starts applying, which is the single most valuable thing this category of software does.
Deadlines run in both directions and in different units
The arithmetic in this register spans four orders of magnitude and two directions.
There are notices measured in hours from an incident. There are notices measured in days from a change of particulars. There is a commencement notice that must be given a month before work starts — a deadline that runs backwards from an event, so being late is discovered by the event happening, not by a date passing.
There are quarterly filings due a fixed number of days after a period ends. There are half-yearly certificates due in named months. There are cyclical facility obligations at different intervals for different parts of the same facility.
A due date is a function of an anchor event, an offset, a direction and a unit, and all four vary. Model it that way and the odd ones fall out naturally. Model it as a date column populated by whoever creates the record, and every one of those rules lives in somebody’s head.
The obligation and the occurrence are different tables
This is the conclusion that mattered most, and it took the register to see it.
An obligation is a rule: this must happen, on this cadence, evidenced this way, owned by this function, applicable under these conditions. There are 184 of them and the list changes when the law changes.
An occurrence is one instance: this obligation, this project, this period, this due date, this evidence, this state. The register’s own summary works out that a single project generates on the order of hundreds of daily checks, a dozen monthly filings and a handful of quarterly and half-yearly submissions in a year. The occurrence count dwarfs the rule count by three orders of magnitude and it is what the software actually manages.
Certification expiry, seen from here, is one occurrence generator among many: an obligation whose anchor is a credential’s issue date and whose interval is its validity period. That is why the original model felt complete — it is a complete implementation of one generator.
Evidence is three facts, and sometimes it is not a file
The credential model had already separated these and I did not appreciate why until the register.
Evidence is a claim — somebody asserts the thing was done. It is an artefact — a file, a reference number, a receipt. And it is a verification — somebody with authority looked and agreed. Three facts with three different owners and three different timestamps, and collapsing them into an upload is how a system ends up reporting compliance because a file exists.
The register also contains obligations that have no artefact at all, because they are continuous states: facilities available, notices displayed and legible, registers kept at the site and up to date. Those cannot be evidenced by a document. They are evidenced by an inspection, which means the model has to turn a continuous obligation into a periodic check that produces a record — and the record’s value is the date and the inspector, not the content.
A continuous obligation becomes a scheduled check. If your model has no way to express that, half a real register has nowhere to live.
The rules
Model the trigger, not the rule. A rule is prose in a document. A trigger is an anchor, an offset, a direction and a unit, and it is the only part software can act on.
Applicability is evaluated, never stored. The list of obligations that apply to a customer is a query against their current state, and it changes without anybody editing anything.
Separate the obligation from the occurrence. The first is your content and it changes rarely; the second is your workload and it changes constantly. Products that conflate them cannot update a rule without rewriting history.
Evidence has a verification state or it is not evidence.
The limit worth stating: a register compiled for one sector in one region is not a general model, and I would not claim the five fields survive contact with a third one. What I do believe is that the two registers I have — a workforce credential model and a construction obligation model — differ in every detail and agree on the structure, and that agreement is the part worth building on.