Notes from building ComplianceLink: modelling requirements as data, resolving many-to-many contractor and site relationships, and keeping two vendor systems in agreement without becoming a third source of truth.
The constraint that shapes everything
When the data you need is authoritative in someone else’s platform, the temptation is to copy it into your own database and work from there. That produces a third version of the truth, which diverges immediately and permanently.
The alternative is to treat those systems as the source, hold only the relationships and rules that neither of them models, and invest the engineering effort in keeping synchronisation honest.
Requirements are many-to-many
A contractor is not simply compliant or non-compliant. They are compliant for a specific site, doing specific work, at a specific time. A different site imposes a different document set; a different work type changes it again.
Modelling this as a resolved relationship — contractor, site, work type, resulting requirement set — rather than as a status flag on the contractor is what allows the question to be answered correctly for each assignment instead of approximately overall.
Rules as data, not conditionals
Requirement definitions change when a client updates their site rules or a regulation moves. If those rules live in application code, each change is a development task and a deployment.
Storing them as versioned data means the compliance team changes what a site demands directly, and historical evaluations remain interpretable because the version that applied at the time is still recorded.
Evaluate continuously, not on request
Checking compliance when someone opens a screen means gaps are discovered by whoever happens to look. Evaluating continuously — on document change, requirement change or new assignment — means the system finds the gap and raises it.
This turns compliance from a periodic audit activity into an exception-handling workflow, which is a considerably smaller amount of human work.
Synchronisation failure must be loud
The dangerous failure is not an integration that breaks visibly. It is one that stops quietly while the interface continues to display data that is now days old, with no indication that it is stale.
Dead letter queues with full context, replay tooling, and alerting on the absence of expected traffic are what make this class of failure detectable. They are not optional extras in a system whose entire purpose is to be correct about the current state.
Identity should come from the organisation
Building a separate user list means joiners and leavers are handled twice, and the second one is always forgotten. Deriving access from Entra ID group membership means the organisation’s existing identity processes govern the platform automatically.
For enterprise buyers this is also frequently a procurement requirement rather than a preference, which makes it worth building in from the start.
Written by the Webnatrix engineering team. This is evergreen technical writing, maintained as our practice changes rather than published to a date.