ADAC software buyer's guide for councils.
Councils take asset data from developers, check it, and live with it for the next fifty years. This guide covers what to look for in the software that does the checking, what usually goes wrong without it, and how to write a tender that separates a real validation tool from a document store with a folder called ADAC.
What ADAC is, in one paragraph.
ADAC, short for Asset Design and As Constructed, is the IPWEA-QNT XML specification Australian councils and utilities use to receive as-constructed infrastructure asset data from developers. It covers the classes a council inherits from development works, including stormwater, sewer, water, roads, and open space. Adoption is strongest in Queensland and South Australia, and it is used elsewhere in Australia too.
A submission is an ADAC XML file describing the constructed assets, together with the as-constructed drawings of the same works. The council reviews both before the assets are accepted into the asset register and the GIS. Each asset class carries its own mandatory attributes and permitted values, and most councils amend the base specification with local additions. For the longer definition, see what ADAC is.
Where as-constructed programmes go wrong.
Six patterns turn up again and again, and none of them are caused by the council team being careless. They are what happens when a specification is enforced by people rather than by a system.
Version drift
The council's standard was written against one ADAC version, the developer's consultant exports another, and the reviewer discovers the mismatch part-way through the review. Local amendments make it worse: the version is right, the council's own additions are missing, and nobody can say which document is authoritative.
Reviews restart. Submissions are argued rather than assessed.
Invalid XML, accepted anyway
A file that fails schema validation still arrives at the council, because nothing between the contractor's export and the council's inbox checks it. By the time it is opened, the works are finished, the contractor has demobilised, and the pressure is to accept and move on.
Bad data enters the register at the one moment it is cheapest to fix.
Validation done by hand in spreadsheets
One officer checks attributes in Excel and eyeballs the drawing next to the data. It works, until they take leave. Two officers apply the standard differently, neither can prove what they checked, and the check itself is invisible to everyone else.
Inconsistent decisions, no evidence, and a single point of failure.
The drawing and the data are never compared
Attribute validation passes and the submission is accepted, but the drawn network and the XML were never reconciled. A pit drawn and not listed is never maintained. A stated pipe length that disagrees with the drawn length quietly becomes the valuation.
Errors that only surface years later, during works or renewal.
The as-constructed backlog
Submissions sit in a shared drive waiting for someone to load them. Assets are in the ground, in use, and not in the register. The backlog has no owner and no deadline, so it grows in every direction at once.
Assets operated without a record, and a number nobody wants reported.
Asset data quality under external scrutiny
Asset data completeness and accuracy is a recurring theme in Australian state audit office reviews of local government asset management. Councils are generally expected to show that the data behind their asset valuations and renewal plans is reliable, and that means showing a process, not an assurance.
A finding the council cannot answer without reconstructing its history.
What to ask a vendor.
Ask for the behaviour, not the claim. Most of these questions end in “show us”, and the ones that matter most should be answered on a submission your own council supplies.
- Which ADAC versions can we run at the same time, and how is a project bound to one?
- Can our own officers add a mandatory attribute or restrict a value list, without raising a change request with you?
- When we amend the standard, what happens to projects already validating against the previous revision?
- Where is the record of who changed the standard, when, and with whose approval?
- Do you read the DWG as geometry, or only display it? Show us coordinates read out of our own file.
- Show us an asset present in the drawing and missing from the XML being reported.
- How is positional tolerance set, and by whom?
- Which values do you recompute from the geometry rather than trust as submitted?
- Show us a rule over a value — a cover depth, a gradient — being changed and re-run in front of us.
- How does a finding get back to the contractor, and how do we see what is outstanding?
- On resubmission, what tells the reviewer which findings cleared, without re-reading the whole file?
- Can a submission with open blocking findings be accepted, and who is allowed to override that?
- Can the developer validate before lodging with us?
- Show us the full audit trail for one submission, and tell us what an administrator can edit.
- Can you re-run a validation from two years ago against the standard as it was then?
- What does the validation report look like as an exported document we retain ourselves?
- How does accepted data reach our asset management system and our GIS?
- Which councils run that integration today, against the same products we use?
- Can we load a backlog of past submissions in bulk?
- From an accepted asset record, how many steps to the source drawing?
- Where is our data hosted, including backups?
- What does the price cover — submissions, users, asset counts, storage — and what triggers an increase?
- Which of our requirements are met by a partner, a service engagement, or a future release rather than the product today?
- On exit, how do we get everything out, in what format, and at what cost?
Where a generalist document system stops.
A general-purpose EDMS or records system does the document half well: storage, permissions, retention, approvals. It does not read the ADAC file or the drawing, and that is the half the council is buying. Worth stating plainly in the tender so responses are comparable.
| What arrives | In a generalist EDMS | What ADAC review needs |
|---|---|---|
| ADAC XML | Stored as a file. Its contents are opaque to the system, which sees an attachment with a name. | Parsed and validated against a nominated version of the standard, with findings against individual assets. |
| The as-constructed drawing | Viewable, sometimes only as a rendered preview or a PDF conversion. | Read as geometry in real-world coordinates, so it can be compared with the data. |
| Drawing versus data | Not attempted. The two are unrelated files in a folder. | Reconciled asset by asset, reporting what is missing, misplaced, or inconsistent between them. |
| The council's standard | A document stored alongside everything else, and applied by whoever remembers it. | Configuration the system enforces, versioned, approved, and tied to the projects that use it. |
| A non-conformance | A comment, a markup, or an email. Countable only by reading them. | A discrete finding with a severity, an owner, a due date, and a state. |
| Acceptance | An approval step that anyone with the role can complete at any time. | Held until blocking findings clear, with any override recorded against a named officer. |
| Handover to the register | A file someone downloads and loads by hand. | An export and an integration into the asset system and the GIS, with the source document still linked. |
How to structure the tender.
Write the schedule so that a response is testable. The pattern below keeps the evaluation on the demonstration rather than on the quality of the supplier's writing.
State the standard
Name the ADAC version or versions in force across your live developments, and attach your local amendments. Say that the supplier must support them concurrently, and that amendments must be configurable by council staff.
Attach a real submission
Provide one genuine ADAC XML file and its as-constructed drawings, de-identified if needed, and require every shortlisted supplier to demonstrate on it. Prepared samples prove nothing about your data.
Use a numbered matrix
Give every requirement a reference, a priority, and a response column, so responses can be compared line by line and a gap is a gap rather than a paragraph.
Score the demonstration
Weight the live demonstration above the written response, and script it from the verification column of your matrix so each supplier is asked to show the same things.
Price the whole picture
Ask for a five-year cost including implementation, migration of any backlog, integrations, and support. Ask what triggers an increase — submissions, users, asset counts, storage.
Write the exit in
Require full export of submissions, findings, decisions, and audit trail in an open format at any time, at no additional charge. This is much cheaper to agree before award than after.
An evaluation scorecard to adapt.
A sketch, not a rule. The weightings below suit a council whose main problem is submission quality; shift them towards handover and integration if your main problem is the backlog. Price sits in your own commercial envelope, not in this table.
| Criterion | Weight | Evidence required |
|---|---|---|
| Validation depth: schema, attributes, values, and rules | 25% | Live demonstration on a council-supplied submission, including a rule changed and re-run. |
| Drawing versus data reconciliation | 20% | A missing asset and a positional discrepancy shown on the council's own DWG. |
| Findings workflow and contractor return loop | 15% | Findings issued, resubmission compared, acceptance blocked while findings remain open. |
| Handover into the asset register and GIS | 15% | Named integrations, a reference council running them, and a sample export. |
| Audit trail, evidence, and retention | 10% | One submission traced end to end, plus an exported validation report. |
| Security, hosting, and data residency | 10% | Hosting regions in writing, certification with its scope, single sign-on demonstrated. |
| Implementation, support, and total cost over five years | 5% | A written implementation plan, named support hours, and a five-year cost schedule. |
Score each criterion out of five against the evidence actually shown, and record a nil score where a capability was described but not demonstrated. Panels that allow “on the roadmap” to carry a partial score usually find the roadmap does not arrive.
Next steps.
The numbered requirements this guide refers to, ready to copy into a tender schedule.
How Lunr ADAC Check validates ADAC XML against a configured standard and cross-checks it against the drawing.
The specification itself: what it covers, what a submission contains, and how a council reviews one.
The asset record, the inherited archive, and contractor handover, for a small council team.
Put us through your own evaluation.
Send one real ADAC submission and your requirements matrix. We will demonstrate against your file, row by row, and tell you plainly which rows we do not meet.
10M+ documents under management · Hosted in Australia and the US · SAML · Full audit trail · Export anytime
- entity
- Lunr Labs Pty Ltd
- location
- Melbourne AU
- workspace
- documents.lunr.app
- rev
- 2026