Every obligation, its evidence and the date it expires

Built for organisations carrying recurring duties, not a document library with reminders added on top. An obligation with an owner and a period, the artefact that closes it, the person who verified it and the date a certificate lapses are concepts the software already has.

Designation to certification mapping table listing the certifications each trade must hold, with credential type, validity in days, required flag and coverage across the workforce — The requirements register. Each trade carries the certifications it must hold and their validity period — 730 days for work at height, 365 for an operator's medical — and coverage shows how many people in that trade hold a current record.

The obligations register

Every recurring duty in one register, with the artefact that closes it named in advance.

An obligation is a recurring duty with a source, a period, an owner and a defined artefact that closes it. Each of those five words is a column.
It carries the instrument it comes from and the clause within it, so a finding can be argued back to the rule rather than to a policy document nobody has read.
Frequency is daily, weekly, monthly, quarterly, half-yearly, annual, event-driven or once, with an anchor saying which day of that period — plus a due offset, a reminder lead time, a grace period and a severity.
The owner is a role at a scope, not a named person. It resolves at generation time to whoever holds that role at that site today, so staff turnover does not orphan a duty.
Nobody creates the recurring items. A scheduler walks the active obligations, works out each period from its frequency and anchor, resolves the owner, and writes an instance with a period start, a period end and a due timestamp. A second pass marks the ones past due and grace as overdue.
Instances exist per scope, so thirty obligations across five sites is a hundred and fifty real items rather than thirty rows that quietly stand for them.
An event-driven obligation is generated by the thing that triggers it and records what that was, so an incident produces its statutory notification instead of relying on somebody remembering that it should.
What is due this week, what is overdue and what is unassigned is a query rather than a chase.

Credential record for a work-at-height competency awaiting verification, with a PDF competency card and a photographed assessment sheet as evidence, verify and reject controls, history, and the worker's other credentials — Verifying one record. The competency card and the photographed assessment sheet are stored with size and SHA-256 hash, the history shows who created and attached what, and a rejection carries a reason that the worker sees on their own record. The evidence tiles, the history panel, the other-credentials table and the verification checklist are additions; the real page is a single column of fields with Verify and Reject, and the repo has no upload flow.

Evidence and verification

An obligation closes against the thing that proves it. It cannot close against a tick.

A certificate, a photograph, a signed checklist or a test result is attached to the obligation it closes.
An instance can also close against a filed acknowledgement — the portal reference number and the date it was filed.
Every item records the person who verified it and the date they did so.
A record stays pending until somebody holding verify permission checks it, and a rejection carries a reason its owner sees on their own record.
Submissions are versioned rather than overwritten: an edit made after submission writes a new revision with the change recorded, so the register that was true in August is still legible in March.
Once an output has been produced from a submission — a register, a return, anything issued outside the organisation — the submission is locked by a database trigger, not by a convention.

September 2026 calendar showing training sessions and certificate end dates by day, with a searchable list of the month's events and a summary of the next seven days — Toolbox talks, assessments and certificate end dates on one calendar. An expiry appears on the day it falls, so the renewal can be booked before the date rather than found during an inspection.

Certification and expiry tracking

The lapse is found before the date, rather than during the inspection.

Licences, training records, insurance and equipment certificates each carry an expiry date and an owner.
Warnings are raised on a schedule you set per certificate type, ahead of the date.
An item past its date is flagged non-compliant until a replacement is in place.
A requirements register maps each trade to the certifications it must hold and their validity period — 730 days for work at height, 365 for an operator’s medical — with coverage across the workforce.
Toolbox talks, assessments and certificate end dates share one calendar, and an expiry appears on the day it falls.
Records from earlier cycles stay on the list after renewal, which is what an inspector asks for.
An action centre separates expired records, records ending soon, the gaps against the requirements register, and open escalations.

Organisation credentials list filtered to records pending verification, with worker name, certification title, end date, source, upload date and verification status — The verification queue. A competency card or medical certificate stays pending until someone with verify permission checks it, and the list filters by verification state, worker and expiry window.

Audits and inspections

One checklist engine, whatever the inspection is called this week.

The same engine runs a food safety audit, a site safety inspection and an internal review.
An inspection is completed against a checklist, with photographs attached to individual line items.
A failed item becomes a non-conformity with an owner and a due date.
It stays open until a corrective action with its own evidence closes it.
A finding’s state is the result of the events applied to it, so the history of a non-conformity is not reconstructed from a status column that was edited four times.

The inspection types it takes

Five kinds of inspection on one engine, rather than one product each.

Property inspection and collateral condition surveys — somebody attends the building and records its state for a reader who was not there and who reads it months later.
Safety and EHS inspections, on the same checklist and evidence rules as everything else.
Facility and building inspections, and equipment and asset inspections, likewise.
Food safety audits, whose findings carry an owner, a due date and a closing evidence item like any other.
An inspection type is a checklist, a cadence and the evidence that closes it, so adding a type is configuration rather than a new deployment.
The domain packs seeded so far cover construction and aviation training; the workforce path covers healthcare.

Add certification form on a phone with title, start and expiry dates, issuing training cell, an attached photograph of a signed assessment sheet and notes — Adding a record from the site: a catalog item or a free-text title, dates, issuer, and a photograph of the signed assessment taken on the phone. The photo field is an addition: the repo has no upload flow, and these phone screens are the portal's responsive layout below 900px rather than a native app.

Field capture and the supervisor’s view

What comes back has to be good enough for somebody who was never at the building.

The inspector works from a phone at the property.
Photographs are taken in the app rather than chosen from a gallery.
Each carries the coordinates and the time the shutter fired — not the time it reached the server, which is the field a dispute actually turns on when the site had no signal.
The back office sees each survey as it lands.
A supervisor role, built for Creative Lending Solutions, a US lender writing finance against commercial property, shows a manager what each member of staff has actually completed rather than what the schedule says they were sent to do.
The worker and inspector screens are the portal’s responsive layout below 900px, not a native app.

Audit log timeline grouped by day, listing a verification, a submitted daily site safety inspection, a credential upload, an automatic escalation, a rejection and a mapping change, each with time and actor — The audit log is read-only and grouped by day. Each entry records the entity, the action, the person or system behind it and the time — including the escalation the system raised when a crane operator's competency reached its end date with no renewal on file. The daily site safety inspection entry comes from the v2 obligations engine, which has a schema and seed data but no portal screen.

The audit trail

Two mechanisms, both in the database rather than in the application.

The audit log is append-only and hash-chained: each entry incorporates the one before it, so deleting or altering a past entry breaks the chain and the break is detectable.
Append-only enforcement is a trigger on the table, which means it applies to anything that writes — a script, a console, a future feature — and not only to the code that remembered to behave.
Each entry records the entity, the action, the person or system behind it, and the time.
Escalations the system raises itself sit in the same log as the actions people take.
The log is read-only and grouped by day, and a past verification stays visible after the obligation is re-evidenced in a later cycle.

Two organisations in one installation

Isolation the application cannot forget to apply.

Tenant isolation is enforced by Postgres row-level security, keyed on an organisation identifier set per transaction.
The application role cannot bypass it.
Without that value set, every tenant-scoped table returns zero rows — the failure mode is an empty screen, not another organisation’s staff list.
Access within a tenant is built from forty-five permissions and seven system roles, and a tenant can define roles of its own on top.
Sector content arrives as a domain pack cloned into the organisation — obligation templates, form definitions and lookups it then edits as its own rather than receiving as an untouchable default.

What it does not do

It does not file anything for you, and it does not interpret regulation. It is not a document management system, not a learning management system, and not a health and safety incident investigation tool. It knows a training event happened and that a certificate resulted; it does not deliver the training, which is what Sazinga Engage is for. If the problem is really traceability — which batch, which lot, which customer — that is Sazinga Factory rather than this.

One register, one engine, one trail

The inspection knows the checklist because the obligation named the evidence that closes it, and the audit log knows who verified it because the verification wrote itself there. That is the whole design, and it is why the modules above are one product rather than eight. Comply is in production at fourteen installations — six in the USA, five in the Gulf, two in the UK and one in Africa — and the white-label survey deployments run at two to three surveys a day in each installation (September 2026). The operating context sits on the construction, food safety and healthcare pages, and the product overview covers how an obligation reaches a filing.

Frequently asked questions

Is this a document library with reminders on top?

No. A document library holds files; this holds obligations. An obligation is a recurring duty with a source, a period, an owner and a defined artefact that closes it, and an instance of it closes against that artefact — a certificate, a photograph, a signed checklist, a test result or a filed acknowledgement with its reference number. It cannot close against a tick.

What kinds of inspection does it handle?

Property inspection and collateral condition surveys, safety and EHS inspections, facility and building inspections, equipment and asset inspections, and food safety audits. They are not separate products — an inspection type is a checklist, a cadence and the evidence that closes it, so the same engine runs all of them and a new type is configured rather than built. Findings become non-conformities with an owner, a due date and a corrective action that has to be evidenced before it closes.

How does it stop a certificate lapsing unnoticed?

Each certificate, licence and training record is stored with an expiry date and an owner. Warnings are raised on a schedule set per certificate type, ahead of the expiry date, and an item past its date is flagged as non-compliant until a replacement is in place. The requirements register carries the validity period for each trade — 730 days for work at height, 365 for an operator’s medical — so a missing record shows as a gap rather than as silence.

What stops the audit trail being tidied up afterwards?

The log is append-only and hash-chained: each entry incorporates the one before it, so altering or deleting a past entry breaks the chain and the break is detectable. Append-only enforcement is a trigger on the table rather than a rule in the application, so it holds for a script or a database console as well as for the product. Separately, a submission that has produced an output is locked by a database trigger.

Does it file anything with a regulator?

No, and that is worth being plain about. There is no integration that submits a return to a regulator’s portal. Comply records that the filing happened, by whom, and with which reference. It does not interpret regulation either — the obligation templates in a domain pack are a starting register built from published instruments, and a compliance officer still has to confirm which of them apply.

Ready to see Comply on your own numbers?

Know what is due, what is evidenced and what has expired. Tell us how it runs where you are — what is kept by hand, what arrives late, and what it costs when it goes wrong — and we will answer against your own figures rather than against the features page you have just read.

Would rather read than write? See the screens — real captured ones, no sign-in.