Application Overview

What this app is for

The Legal Obligation Register converts legal and regulatory sources into governed operational obligations and then proves they are met. It answers, for any obligation, the questions an auditor or regulator asks: what law requires this, who owns it, how often is it due, what control manages it, what evidence proves it, who verified the control works, and what happened when it didn't?

It is the register at the centre of a compliance-management system — deliberately domain-agnostic (environmental, safety, financial, licensing) — and keeps itself current as sources change and obligations are reviewed.

The operating chain

SOURCE                    OBLIGE                    CONTROL & PROVE           ASSURE & REMEDIATE
instruments + provisions -> obligations +          controls + evidence  ->   verification +
+ business units            applicability +         requirements +            assessments ->
                            occurrences             evidence items            exceptions -> actions
                                                                              |
                                                                    reviews · instrument changes · comms

Read left to right, that is the sidebar: Instruments & Sources → Obligations → Controls & Evidence → Verification & Assurance → Exceptions & Actions.

The five functional areas

1. Instruments & Sources — where the obligation comes from

LegalInstrument (the source — type, jurisdiction, authority, status, review cycle), InstrumentProvision (the specific clause/section), InstrumentChange (a detected amendment with impact assessment) and BusinessUnit (the org structure that owns obligations and controls).

2. Obligations — the governed requirement

LegalObligation (typed, risk-rated, owned, with frequency and due rule), ObligationApplicability (which entities/sites it applies to and why), ObligationOccurrence (each dated instance of a recurring obligation) and ObligationReview (the periodic review that keeps interpretation current).

3. Controls & Evidence — how it is managed and proven

Control (preventive/detective/corrective/directive, key-control flag), ObligationControl (the mapping), EvidenceRequirement (what must be kept, with retention) and EvidenceItem (the actual records, with hash and acceptance).

4. Verification & Assurance — is it working

VerificationPlan and Verification (independent tests of control effectiveness) and ComplianceAssessment (the recorded assurance status — compliant / at-risk / non-compliant).

5. Exceptions & Actions — when it fails

Exception (a breach or control failure, with regulator-notification flag), CorrectiveAction (the remediation, tracked to verification) and Communication (related correspondence).

Two ideas that make it trustworthy

  • Every obligation is traceable to its source and provable by evidence. From a LegalObligation you can reach the instrument/provision that created it, the controls that manage it, the evidence that proves each occurrence, and the verification that confirms the control works.
  • Assurance is explicit and challenged. ComplianceAssessment records a status with a stated basis, Verification independently tests the control, and any gap becomes an Exception with owned corrective actions — so "we comply" is always backed by something.

Build status

Phase 1 (this build): the full schema (18 models), navigation, dashboards and a coherent seeded demo are complete and browsable as AI-Safe CRUD.

Phase 2 (documented, not built): the compliance engine — the dashboard metrics/sections, due-date and frequency computation, assurance rollups by business unit, overdue/verification-due detection, and rules.yaml / workflows.yaml. Today those outcomes are modelled statically in the seed.