How AI Tracks NZS 3910 Obligations So Nothing Falls Through the Cracks

The Obligation Landscape: What NZS 3910 Actually Requires

NZS 3910 is not a long document, but it is a dense one. Within its standard conditions sit dozens of obligations that bind both the Principal and the Contractor, each triggered by specific events and governed by specific timeframes. Some are well understood. Others are routinely missed.

Take the basics. Under Clause 9.2.1, the Contractor must submit a construction programme within 10 working days of the contract being signed. That programme is not a formality. It establishes the baseline against which delay, disruption, and extensions of time are assessed for the entire project. Miss it, and the Contractor's position on any future time claim is weakened from the outset.

Clause 9.3 requires a performance bond, typically 10% of the contract value. The form, amount, and timing are specified in the special conditions. Late provision can technically put the Contractor in default before a single metre of concrete has been poured.

On the Engineer's side, Clause 9.8.3 requires a response to the Contractor's variation pricing within 10 working days. If the Engineer is silent, the Contractor's pricing does not automatically stand. But the ambiguity creates commercial tension that could have been avoided with a timely response.

Then there are the heavyweight clauses. Clause 10.3 sets out liquidated damages: the rate, the cap, and the trigger. Clause 11.3 governs practical completion certification, the single most consequential event in any NZS 3910 contract. Clause 12.4 controls retention release, both at practical completion and at the expiry of the defects liability period.

And then there are the claim and time clauses that trip up experienced teams every year.

Clause 13.3.1 requires the Contractor to give notice of a potential claim "as soon as practicable." That phrase sounds forgiving. It is not. In practice, it is almost always tightened by special conditions.

Clause 13.5 governs extensions of time: the notice, the substantiation, and the Engineer's assessment. Every step has a timeframe. Every step has a consequence if missed.

Here is what that landscape looks like in summary:

Clause	Obligation	Timeframe	Risk Level
9.2.1	Contractor submits construction programme	10 working days from contract	Medium
9.3	Performance bond provided	As specified in special conditions	Medium
9.8.3	Engineer responds to variation pricing	10 working days	Medium
10.3	Liquidated damages rate and cap applied	Triggered at due date for completion	High
11.3	Practical completion certification	On application by Contractor	High
12.4	Retention release (PC and DLP expiry)	At PC and at DLP expiry	Medium
13.3.1	Notice of potential claim	"As soon as practicable" (often 10 WD via SC)	High
13.5	Extension of time notice and substantiation	As soon as practicable + substantiation	High

Each of these obligations exists in the standard conditions. But on most NZ construction projects, the standard conditions are only the starting point.

Why Spreadsheets Fail

The typical approach to obligation tracking on an NZS 3910 project is a spreadsheet. Sometimes it is a well-structured register maintained by the contract administrator. More often, it is a patchwork of personal trackers, calendar reminders, and institutional memory.

This approach has three fundamental weaknesses.

1. Volume and Interconnection

A single NZS 3910 contract generates dozens of active obligations at any point during the project. On a multi-contract project, say a $120M development with a main contractor, a services contractor, and a separate early works contract, the number of concurrent obligations across all contracts can reach into the hundreds. Spreadsheets can list them. They cannot show you how they interact.

2. Time Sensitivity

Many NZS 3910 obligations are time-bound. The 10 working day window in Clause 9.8.3 for Engineer's response to variation pricing is straightforward to track in isolation. But when you have 15 open variations, each at a different stage of the pricing cycle, plus pending EOT notices under Clause 13.5, plus a claim notice deadline under Clause 13.3.1, that is when things fall through. Not because people are careless, but because the volume overwhelms manual tracking.

3. Special Conditions

This is where the real risk lives. Every NZS 3910 contract comes with special conditions that modify the standard clauses. A spreadsheet built from the standard conditions will track the wrong deadlines, the wrong thresholds, and the wrong consequences if the special conditions have changed them. And they almost always do.

The Special Conditions Problem

Special conditions are where NZS 3910 contracts become genuinely dangerous. The standard conditions provide a balanced framework. The special conditions can shift that balance dramatically, and the shift is often buried in pages of amendments that only a careful contract review will catch.

The problem is not that these amendments are hidden. They are right there in the contract. The problem is that tracking the modified obligations, as opposed to the standard obligations, requires someone to have read every special condition, understood which standard clauses they affect, and updated every tracker accordingly. On a project with 40 pages of special conditions across three contracts, that is a significant task. And it needs to happen before Day 1.

How AI-Powered Contract Tracking Works

AI-powered project intelligence does not replace the professionals who administer NZS 3910 contracts. It ensures they see everything they need to see, when they need to see it.

The process works in four stages:

1. Contract Ingestion

The full contract, including general conditions, special conditions, schedules, and appendices, is ingested and parsed. The system identifies every clause that creates an obligation, a right, a deadline, or a trigger condition. This is not keyword matching. The AI reads the contract the way an experienced contract administrator would, understanding that Clause 13.3.1 creates a notice obligation even when the special conditions have changed the timeframe.

2. Obligation Mapping

Every identified obligation is mapped with its trigger event, timeframe, responsible party, consequence of non-compliance, and any modification by special conditions. The result is a complete obligation register that reflects the actual contract, not the standard form.

3. Deadline Tracking and Alerts

As the project progresses, obligations become active. When a variation is issued, the system tracks the 10 working day response window under Clause 9.8.3, or whatever the special conditions have modified it to. When a potential claim arises, the system flags the notice deadline under Clause 13.3.1 and alerts the team before the window closes.

4. Cross-Project Intelligence

On multi-contract projects, the system tracks obligations across all contracts simultaneously. It identifies where obligations on one contract affect another. A delayed variation on the main contract triggers a potential claim under the services contract, or where practical completion on the early works contract triggers retention release obligations under Clause 12.4.

Beyond Tracking: Project Intelligence in Context

Obligation tracking is the foundation, but it is not the ceiling. AI-powered project intelligence connects obligation data to the wider project picture: programme status, payment history, variation trends, and correspondence patterns.

When the system flags a Clause 13.5 EOT notice deadline, it does not just tell you the date. It connects that deadline to the programme impact, the financial exposure if the extension is not granted, and the liquidated damages rate under Clause 10.3 that will apply if the claim fails. That is the difference between a deadline tracker and a project intelligence system.

The professionals on your project, your contract administrator, your project manager, your Engineer to the Contract, still make every decision. They still apply their judgement, their experience, and their knowledge of the project context. The AI system ensures they are making those decisions with the complete picture in front of them, not a partial one filtered through whatever the last person remembered to put in the spreadsheet.