System Diagram

The Contract Obligation & Notice data model, mapped — 16 models, 53 relationships

🔍 Open the Interactive Diagram Viewer — pan, mouse-wheel zoom, fit-to-screen, full-screen, per-area tabs, the full ERD, and a focus mode that draws one model and its neighbours at a chosen depth. Contract, Person and Organisation are hub tables (almost everything carries contract_id), so their links can be hidden to declutter the overview.

Architecture overview

Everything is anchored on the Contract. From it hang the parties bound to it, its clause register, its obligations, and every event, notice, claim, variation, breach, piece of evidence, approval and task raised under it.

flowchart LR
    subgraph PARTIES["📄 Contracts & parties"]
        Contract
        ContractParty
        Clause
        Organisation
        Person
    end
    subgraph OBLIGATIONS["✅ Obligations"]
        Obligation
        ObligationOccurrence
    end
    subgraph NOTICES["📨 Notices & events"]
        Notice
        ContractEvent
    end
    subgraph CLAIMS["⚖️ Variations, claims & breaches"]
        Variation
        Claim
        Breach
    end
    subgraph GOVERNANCE["🗂️ Evidence & governance"]
        Evidence
        EvidenceLink
        Approval
        Task
    end

    Organisation --> Person
    Organisation --> Contract
    Contract --> ContractParty
    Contract --> Clause
    Contract --> Obligation
    Clause --> Obligation
    Obligation --> ObligationOccurrence
    Contract --> ContractEvent
    Contract --> Notice
    ContractEvent --> Notice
    Obligation --> Notice
    Contract --> Evidence
    Evidence --> EvidenceLink
    Contract --> Variation
    Notice --> Variation
    Contract --> Claim
    ContractEvent --> Claim
    Contract --> Breach
    Obligation --> Breach
    Contract --> Approval
    Contract --> Task

Contracts & parties

Organisation and Person are directories. Contract names a principal org, a contractor org, a contract manager and a legal owner. ContractParty records each organisation's role on the contract (principal/contractor/subcontractor/ …) and its notice address — obligations, notices, claims and breaches reference parties, not raw organisations, so the correspondence chain is role-aware. Clause is the clause register and can nest (parent_clause_id).

Obligations

Obligation captures a requirement against a clause, with a trigger, a due rule, optional recurrence, and a lifecycle status. Recurring obligations produce dated ObligationOccurrence rows, each with its own due date and outcome.

Notices & events

ContractEvent records something that happened and flags whether it could give rise to a notice, claim, variation or breach. Notice is a contractual notice in either direction, with sender/recipient parties, service and acknowledgement tracking, links to the triggering event/obligation, and self-supersession.

Variations, claims & breaches

Variation, Claim and Breach are the commercial consequences — each links back to the contract, the relevant clause, and (where applicable) the notice and event that drove it. Claim carries the time/cost entitlement and its deadlines; Breach runs identified → cure → remedied/escalated.

Evidence & governance

Evidence is the register (custody, verification, privilege); EvidenceLink attaches a piece of evidence to whatever it supports (obligation, event, claim, …) via a polymorphic target_type/target_id. Approval gates external issue; Task tracks follow-ups. Approval and Task also use a polymorphic target.

Regenerating this diagram

The interactive viewer is generated — after any DSL, menu_config.yaml or schema/diagram_config.yaml change, re-run:

python scripts/build_diagram_viewer.py contract