Compliance software that only tracks staff certificates

Your compliance tracker knows who holds which certificate and when it runs out. But most of what an inspector can ask you about is not a certificate. It is a filing that was due, a notice that had to be given, an inspection that had to happen, an insurance policy that had to be in force.

And the list of what applies to you changes without anyone touching it. Hire past a headcount threshold and a new obligation starts that week, with a deadline that may already be running. A tick-list of what applies to you is wrong within a month of your next hiring round, and nobody finds out until an inspection.

We found this out from the first version of our own platform. It modelled compliance as a person holding a credential that runs out: a member of staff, a job designation, the credentials that designation requires, an expiry date on each. That is correct, and it is a special case.

What was actually going on

We saw how special when we built a register for a different sector: 184 continuing obligations across 15 domains, compiled from the laws and approval regimes that apply to one kind of business in one region. Perhaps a dozen 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 an activity may begin.

Reading all 184 rows for what they share, five things survived: the obligation, the source that requires it (because the first question when an entry is challenged is where it came from), the trigger that makes it apply and fall due, the evidence that it was done, and the owner, of which there were six functions 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.

The frequencies needed eight values, and only five are calendar periods: daily, monthly, quarterly, half-yearly and annual. The others are once per project, event-driven (a worker joins, equipment is altered, an incident occurs), and periodic at an interval set by something other than the calendar. For example, medical examinations for some roles fall due every two years below a given age and every year above it. Five calendar values cover a bit under half of a real register.

Deadlines run in both directions too. Some notices are due within hours of an incident. A commencement notice must be given a month before work starts, so being late is discovered by the work beginning, not by a date passing.

What we changed

The register is now treated as a rule that produces a list, evaluated against the organisation’s current state, not as a list somebody ticks. Which obligations apply is worked out from data the system already holds, such as headcount, sites and activities. So it can tell you that something new applies the week it starts applying.

An obligation and an occurrence are kept apart. The obligation is the rule: this must happen, this often, evidenced this way, owned by this function. There are 184 of them and they change when the law changes. An occurrence is one instance: this obligation, this project, this period, this due date. 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. Occurrences outnumber rules by about three orders of magnitude, and they are the workload. A certificate expiry turns out to be one kind of occurrence among many.

Evidence is three facts, not one: somebody says it was done, there is a file or reference, and somebody with authority looked and agreed. Collapsing those into an upload is how a system ends up reporting compliance because a file exists. And where an obligation is a continuous state, such as facilities available or notices displayed, it becomes a scheduled check that produces a record, because a document cannot evidence it.

What it did not fix

A register compiled for one sector in one region is not a general model, and we would not claim the five things survive a third. What we do believe is that the two registers we have, a workforce credential model and a construction obligation model, differ in every detail and agree on the structure.

It also does not compile the law for you. The register’s contents still have to come from the statutes that apply to a particular business.

The pattern, for anyone who is inspected

Take your last inspection and list what you were asked about. Count how many were certificates. Then ask whether your tracker would have told you, in the week it began, that a new obligation applied after your headcount changed.

And for each item ask which event starts its clock, and how long before or after that event it is due. If the answer lives in somebody’s head, it will be missed.

Where this ends up

That structure is what Sazinga Comply is built on: obligations held as content, occurrences generated from them, and evidence that carries a verification state rather than a tick.