Staff cleared their own compliance gap by uploading a file

A member of staff is missing a required certificate. They upload a file, any file. The dashboard shows them compliant at once, before a manager has looked at it. The manager opens it, rejects it, and the dashboard stays green.

That is what we found reading a compliance system’s code. The cost is the decision somebody makes on the green: an auditor or inspector asks for evidence, and what is on the dashboard is not evidence, only that a file exists.

A second finding sits beside it. Somebody who changed role two years ago is still measured against the certificates of the job they left.

What was actually going on

Every certificate record in the system carries two facts about whether it is still valid: an end date, and a status label with values for active, expiring soon, expired and revoked. One of them changes meaning by itself. The end date answers “is this current” differently every midnight without anybody touching the record. The label does not; it is whatever was written when the record was last saved.

There is no job that moves records from active to expiring to expired. The comments in the design imply one. The code does not contain one. So the label is an opinion held on the day of the last save, in a column whose name promises it is current.

You can spot this without reading the design, because the search code confesses. The expression every screen uses to decide a certificate has expired checks the label, then second-guesses it against the date, then lets one label, revoked, override the date. That is somebody who does not trust the column. It encodes a real rule: a withdrawn certificate is void, not expired, and the difference matters when somebody asks why a person is non-compliant. But nobody writes that expression in a system where the label is kept up to date.

The same expression is written out three times across two files, two on the dashboard and one in the action centre. They agree today because they were copied from each other, which is not the same as being consistent. Change the rule and find only two, and the dashboard and the panel beneath it disagree about who is expired, on the same screen.

The bigger hole was in how the system works out who is missing a required certificate. It looks for a matching record that is in a valid state: label active or expiring soon, end date absent or in the future. It does not look at verification. Each certificate has its own workflow, submitted, then verified or rejected by a manager, and that workflow is the whole point of keeping evidence rather than a tick box. The check ignores it. An unverified submission satisfies the requirement, and so does one a manager has rejected, as long as the label still says active.

The third gap: requirements come from a person’s job designation, and designations carry effective dates. The requirement check ignores those dates and treats every designation as in force.

What is still open

This is a finding, not a fix. As far as this article records, none of the three has been changed.

There are two sound designs for the label and the system does neither. The first is to drop the label and work out validity from the end date and a revoked flag, through one shared expression. The second is to keep it, for searching without date arithmetic across millions of records, and run a job every night that moves records between states, with its one-day freshness stated where users can see it. What was built is the third option nobody chooses on purpose: keep the column, do not maintain it, and paper over it in the search code.

For the requirement check, the recommendation is that a requirement is satisfied by verified evidence, not by the existence of a record, and that the satisfying condition is one named expression that includes the verification state and the designation dates.

What it did not fix

The copies that agree today are unexploded, not correct. And the label lies to anyone who reads the table directly: every report written outside the application, every export, and every person who opens a database tool during an audit to answer a question quickly.

All three gaps have the same shape. The system models a distinction, current versus stale, verified versus submitted, in force versus historical, and the check that matters does not use it. A column that no search filters on is not a feature. It is a plan.

The pattern, for anyone using a compliance dashboard

Test it the way a worker would. Upload any file as evidence and see whether the dashboard changes before anyone has looked. Have a manager reject it and see whether it changes back.

Then ask of each status what moves it. If the answer is “someone edits it by hand”, it will go stale. And ask whether the states in your workflow, submitted and verified, appear in the test that decides who is compliant, or only on the screen.

Where this ends up

Sazinga Comply exists to say what is due, what is evidenced and what has expired. All three are questions about a date and about who verified, which is why none of them can be answered by a label somebody wrote on the day the record was last saved.