COMPLIANCE

Obligations register & chase campaigns

The contract is a list of promises with deadlines. The obligations register extracts that list — one row per obligation, cited back to its clause — and keeps it in front of you with due dates and status. Chase campaigns then do the follow-up: one launch chases every subcontractor with a missing or expiring document, and each response closes its own chase.

Overview

Failure to understand or comply with contractual obligations has been the number-one cause of construction disputes for three years running (Arcadis Global Construction Disputes Report 2025). The obligations register exists so the contract’s promises are tracked as records rather than remembered: what must be done, by which party, triggered by what, due when, and where in the contract it says so.

You reach the register from the Registers band in the project sidebar, next to the claims register and the project’s other registers. You do not have to build it: contracts are read as they arrive, and every row keeps the citation it came from.

The obligations register for a project — rows of obligations with clause reference, party, type, due date tinted red for overdue and amber for due soon, severity and status columns, and a source chip on each row linking back to the contract clause.

Extraction is automatic — and re-runnable

The register is not something you have to go and generate. The picker states it in its own words: “Contracts are read automatically as they arrive — every deliverable, submittal and obligation becomes a register row, cited back to its clause. Use this to re-run a contract, or search to point the AI at a document it did not pick up.” Upload the contract and the rows appear behind it.

So the extraction picker exists for the two cases automatic reading does not cover:

Re-running a contract — the contract has been revised, or an earlier read was thin and you want the rows rebuilt.
Pointing the extractor at a document it did not read as a contract — a deed, a variation of contract, a special-conditions annexure or a scope document the classifier did not treat as contractual.

Using the picker

By default the picker lists only the project’s contracts, under a Contracts in this project heading — the short list is the common case. Searching widens the picker to every document in the project, which is how you reach a document that was never classified as a contract. A run is capped at 10 documents (Up to 10 documents per run.), each read as its own extraction job, and the register shows per-document progress while the runs are underway.

Documents that have already been read are skipped unless you tick Re-extract even if already extracted — that is the option to reach for after a contract revision.

The picker’s empty states tell you which situation you are in: “Nothing in this project reads as a contract yet — search above to pick any document.” means nothing was classified as contractual, while “No documents in this project yet — upload the contract first.” means there is nothing to read at all.

Grounded in the clause, not a summary of it

Every row keeps its source: the document, the clause reference, and the exact passage the obligation was extracted from. The source chip on a row opens the contract in the preview pane at that clause, so checking an obligation against the words that created it is one click.

What each row carries

Field	Meaning
Clause	The contract clause reference, for example cl 12.3(a).
Obligation	What must be done, in plain language.
Party	Who owes the obligation — Principal, Contractor, or both.
Trigger	The event or date that starts the obligation running.
Due	The due date where one can be resolved, or the contractual expression where it cannot — for example "30 days after practical completion". Days-to-due are calendar days.
Recurrence	One-off, recurring (for example monthly), or triggered by an event.
Type	Reporting, payment, notice, insurance, indemnity, milestone, or other.
Severity	Critical, high, medium or low — how much it matters if this one is missed.
Status	Active, fulfilled, overdue, waived or superseded.
Source	The document and clause the row was extracted from.

Due dates are tinted so the register reads at a glance: overdue rows in red, rows due within fourteen days in amber. Rows are ordered soonest-due first. Where a trigger was extracted, it is shown beneath the obligation text, so the row reads as the promise and the thing that starts it running.

Severity is deliberately quiet

Only Critical and High carry a coloured chip; Medium and Low render as plain text. Colour marks the exception, so on a register of two hundred rows the ones that will hurt you are the loudest thing on the page.

Every row drills into its clause

The source chip on a row opens the contract in a preview panel, jumped to the passage that produced the obligation. The jump is matched on the verbatim snippet the extraction kept, falling back to the clause reference when the snippet cannot be located — so a row is never an assertion you have to take on trust.

Corrections survive re-extraction

Extraction gets most rows right and some rows nearly right. When you correct a field on a row — the due date, the party, the trigger, the wording of the obligation — that field is recorded as confirmed, and the row carries a small green Confirmed badge. Hover it and you see the provenance of the fix: what the machine originally read, what you confirmed instead, and the date you did it.

A confirmed field is not overwritten when the contract is re-extracted. Re-running a revised contract refreshes the rows around your corrections rather than through them.

No, the AI will not clobber your fix

This is the first question a commercial manager asks of any extracted register, and the answer is the reason it is safe to correct rows as you go. Human judgement is treated as the higher-confidence source: once a field is confirmed, extraction defers to it and the original reading is kept alongside as history, not discarded.

Working the register

The register is a working list, not a one-off report. As obligations are met, mark them fulfilled — the record keeps who fulfilled it and when. An obligation that no longer applies can be waived, and one replaced by a revised contract is marked superseded, so the register stays honest without deleting history.

Status actions on a row

From the row itself you can Mark fulfilled, Mark waived, or Reopen one that was closed in error or has come back around. Fulfilled and waived rows render struck through and greyed rather than disappearing, so the history stays intact and an open register reads as the work that is left.

Back-to-back gaps

Above the register sits a panel showing time-bar exposure across the contract chain: where the window you have under the head contract is shorter than the window you have given a subcontractor. It reads the same obligations you are looking at and shows where the windows do not line up — the places where a claim can reach you after your own right to pass it on has closed. The assistant exposes the same view, so you can ask for it in chat rather than opening the page.

Ask about it in chat

The register is readable by the assistant, read-only and filtered to what you are permitted to see. So what’s due on Northgate in the next fortnight? — or what notices do we owe this month — is answered from these rows, not re-derived from the contract on the spot. Same rows you see on the page, same citations back to the clause.

Compliance-chase campaigns

Knowing what is owed is half the job; collecting it is the other half. A compliance-chase campaign follows up an entire list of subcontractors for a document you need from each of them — certificates of currency are the classic case — in one launch, instead of one email thread per sub.

Who gets chased

When you create a campaign, Alloovium builds the candidate list from the counterparties already known on the project and works out each one’s compliance state from the documents they have previously submitted through document requests: current when their best document is in date, expiring when it lapses within the window (30 days by default), and missing when no matching document exists — an expired document counts as missing. You review that preview and choose who to include before anything is sent.

What a launch does

You give the campaign a name, the document kinds you are asking for — certificate of currency, insurance certificate, SWMS, ITP, permit, licence, induction record or JSA — and an escalation ladder. Launching it creates, for each target, a document request (the ask) and an escalation case (the chase) that walks the ladder on its own clock.

One response never stops another chase

Every target runs as its own independent chase. When a subcontractor submits the requested document and it is accepted, their chase stops — everyone else’s keeps walking the ladder. That is what makes a 200-target campaign practical: you launch once and only the stragglers keep consuming attention.

Candidate states are computed from requested documents

A counterparty’s compliance state is derived from documents received through document requests on the project. A sub whose current certificate sits in your library but was never submitted through a request will read as missing — check the preview before launch and exclude anyone you know to be current.

Following a campaign

The campaign page is the rollup: how many targets are resolved, how many are still being chased, and where each one sits.

Target status	What it means
Pending	Queued — the campaign has not sent to this target yet.
Sent	The request has gone out.
Opened	The target has opened the request.
Responded	The target has submitted a document.
Resolved	The submission was accepted — this chase is closed.
Escalated	The chase has moved up the ladder without a response.
Failed	The chase could not proceed for this target.

The campaign itself moves from draft to active on launch, and can be paused, resumed, or completed. A target can also be resolved manually — for example when a certificate arrives by another channel.