A Practical Guide to Asset Design and As Constructed (ADAC) Standard🖺From the ADAC standard itself through to a working council rollout
- Jill Singleton
- 2 days ago
- 13 min read
I have been having quite a few conversations just lately about the complex processes and challenges councils face when managing asset data handover from consultants and developers. It is a conversation that feels very familiar to me, because I went through many of the same challenges myself when I was working at a council and I remember just how stressful the handover processes could be. Asset registers needed to be brought up to date, GIS had to accurately reflect what had actually been constructed on the ground, and Finance needed reliable information for capitalisation, valuation, depreciation and year-end financial reporting.
And if all of that wasn't challenging enough, there was often another layer of complexity to deal with which was trying to piece together asset information from a collection of as-constructed CAD drawings, completed capital projects, donated assets, spreadsheets and, inevitably, missing or inconsistent data. Information arrived in different formats, at different levels of detail and from multiple sources, leaving council staff (me) to work out what was actually constructed and how it should be represented in the GIS, asset register and financial systems. What should be a relatively straightforward asset handover process very quickly turned into a time-consuming and stressful exercise.
Unfortunately, from the conversations I have been having recently, it seems that many of the challenges I experienced when I was sitting in the council chair are still very much there today. Hearing those familiar frustrations again has really got me thinking about how councils might approach asset data handover differently.
And that is why in this month’s blog post, I have chosen to write about ADAC, and how it could help councils create a more consistent, reliable and manageable approach to asset data handover.
Welcome to the Iamdata Solutions Asset Management Newsletter – September 2026
Every council receives new infrastructure. The infrastructure could have been built by the council itself, but the council also receives assets it did not build, from subdivisions, estates, capital projects etc, and every one of those assets must be registered, valued, mapped, maintained, and eventually, renewed by the council.
For many, many years that handover process happened on paper, in drawings, and the data behind it had to be re-typed by hand into the council's systems. It was slow, it was error prone, and it quietly cost councils a great deal in lost data quality and staff time. I’m truly hoping that there is more automation nowadays and no one has to do work like that anymore, but it does sound as thought the processes still are not automated enough.
ADAC exists to fix your data hand-over problems
If your council is weighing up whether to adopt it or has adopted it on paper but never made it work in practice, I'm hoping that this post will help as we walk through what ADAC really is and what a sound implementation actually involves.
What is ADAC (Asset Design and As Constructed)?
ADAC began in the mid-1990s and is now a nationally recognised standard overseen by the IPWEA. ADAC stands for Asset Design and As Constructed. At its heart, it is a vendor independent XML standard for describing civil infrastructure assets, both as they are designed and as they are actually built. An ADAC file is a structured, machine readable record of new assets, carrying survey accurate geometry and levels, cadastral and boundary references, and the detailed attributes each asset type requires as determined by the council, all defined against a published schema.
What does IPWEA say about ADAC?
IPWEA describes ADAC really well. You can read more here: https://www.ipwea-qnt.com/Web/Web/Resources/Asset-Design-As-Constructed-ADAC.aspx
ADAC is not a software platform. It is a business process. There is no product called ADAC that you buy and switch on. It is a standard and a way of working, and the software you use to author, validate and ingest ADAC data is a separate choice.
This distinction matters enormously, because councils that treat ADAC as an IT purchase tend to freeze or fail, while councils that treat it as a process change tend to succeed.
Why ADAC matters for local government asset data
The gain from ADAC is that asset data can be checked for errors, transformed and transferred electronically into your corporate systems, then used to populate your asset register, your GIS and your financial system without manual re-entry. IPWEA frames the purpose of ADAC around four objectives, and they are a useful lens for any council building a business case.
The first is asset registration, meaning the clean onboarding of a new asset into the GIS, the asset management system and the financial register. The second is asset valuation, capturing the value of the asset at the point of creation so that corporate governance and financial reporting obligations are met from day one rather than reconstructed later. The third is risk management, capturing the information needed to drive inspections and interventions across the asset's life. The fourth is renewals, giving your long-term planning a first cut of the data it needs to forecast future works.
There is a quieter benefit as well. Because ADAC sets a single, consistent specification, property developers and consulting engineers face the same requirements from one council to the next, rather than a different handover format in every local government area. That consistency reduces friction on both sides of the fence.
ADAC and the asset lifecycle from design to as constructed
The core idea is that an asset goes through stages. It gets designed, then it gets built, then a surveyor measures what was actually built. At each of those stages there is information worth capturing. The question is at what point do you create the structured ADAC data, and how much of the original design information is still available when you do?
When an engineer designs a subdivision in software like 12d or Civil 3D, they aren't just drawing lines. They're working in a rich model where a sewer pipe ‘knows’ it is a sewer pipe, knows its diameter and material, knows which manhole it runs from and to, and knows its invert levels.
All of that structure and intelligence lives inside the design model. But when that model is exported to a plain CAD drawing for issuing, most of that intelligence is stripped away. The drawing that comes out the other side is essentially just lines and text on layers. A line that was a ‘225mm PVC sewer pipe from MH1 to MH2’ becomes, on the flattened drawing, just a line on a layer called something like SEWER, with the size and material sitting nearby as separate floating text. The drawing looks the same to a human, but the machine-readable relationships are gone. That is what ‘lost to a flattened drawing’ means. So now the two workflows:
The ideal flow (create ADAC at the source)
The designer generates the ADAC data straight out of the design model, using the model's built-in ADAC export. Because the model still holds all the structure, the export is easy and accurate: the software already knows every pipe's size, material and connections, so it writes them straight into the ADAC file. The same structured record then gets updated through construction and finalised when the as-constructed survey comes in, but it stays structured data the whole way through. Nothing has to be reconstructed, because the information was never lost in the first place.
The common flow (rebuild ADAC after the fact)
In reality, a lot of the time the ADAC is not created at the source. The project runs, the drawings get finalised, and only then does someone sit down to produce the ADAC file, working backwards from the completed as-constructed drawings.
Now they are trying to rebuild all that lost structure from the flattened drawing. They have to look at a line on the SEWER layer and work out that it is a pipe, find the nearby text to work out its size and material, figure out which manholes it connects to, and derive its levels. Every one of those steps is a reconstruction of something that used to exist in the design model and was thrown away on export. It can be done, and it is done all the time, but it depends entirely on the drawing being clean and consistent. If the layers are named oddly, if the size text is sitting in the wrong place, if a pipe does not quite meet its manhole, the reconstruction produces errors.
The closer to the source the ADAC is created, the cleaner it tends to be. Data quality decays every time information is thrown away and then guessed back. Creating ADAC at the design stage avoids the throwing-away step entirely, so the data arrives clean. Rebuilding it from finished drawings means reverse-engineering information that need never have been lost, and some of it will be reconstructed wrongly.
ADAC stands for Asset Design and As Constructed
'ADAC' stands for Asset Design and As Constructed. The standard was always meant to carry data from the design stage onward, not just capture a snapshot at the very end.
The ideal flow is really just using ADAC the way it was designed to be used, and the ‘common flow’ is a workaround for when that didn't happen.
How contractors submit ADAC files to council
Under an ADAC policy, the contractor does not simply submit the CAD drawing. The structured deliverable is the ADAC XML file, and the drawings accompany it as the human readable record.
A typical as constructed submission bundle
A typical as constructed submission is a bundle, and the ADAC XML is one item in it, sitting alongside the as constructed drawings, the surveyor and RPEQ certifications, test results such as pressure tests and CCTV, schedules, operating manuals and warranties.
Each submission is tied to a single development approval or operational works number, and the XML must be validated for compliance before it is lodged, not after. Validation is the contractor's responsibility, not something the council is expected to fix on receipt.
There is no single national portal. The mechanism is set council by council.
ADAC Submission Example 1 - Logan City Council
The most common for developer-contributed assets is a request a link then upload model rather than a self-service portal.
Logan City Council is a clear worked example:
When the consulting engineer is ready, they email the development inbox and the relevant technical officer to request an online submission link for the development, quoting the Operational Works number and address, then upload all required documentation to the online file-sharing folder using the link Council provides, keeping civil drawings, survey drawings, ADAC and pressure tests as appropriately separated, unlocked files, and finally email again to confirm lodgement. If there are issues, a Council officer contacts the consulting engineer.
ADAC Submission Example 2 - SEQ Water Services Urban Utilities
The second pattern applies to the SEQ water service providers, who run their own submission requirements.
Urban Utilities, for example, requires that the XML be validated for compliance before being submitted, and supplied in the format and by the means specified in the organisation’s as-constructed handover procedures. The SEQ Design and Construction Code sits over this.
ADAC Submission Example 3 - State Planning
The third is the state planning portal. This is for the development application itself, not the ADAC handover. In NSW the DA goes through the NSW Planning Portal, and the as-constructed submission is then a condition of that consent handled through the council's own process.
Smaller or less digitised councils may still take submissions by email or transfer to a nominated address.
Putting it end-to-end, the process a contractor actually follows looks like this:
The works are approved under an Operational Works or development approval, and each as-constructed submission ties back to exactly one approval number.
On completion, a registered surveyor captures the as-constructed survey to survey accuracy, typically off permanent survey marks. The ADAC XML is generated from that survey and design data, usually in the same tool that produces the drawings, either during capture or after the drawings are finalised. The contractor then validates the XML against the IPWEA validator and the council's capture guidelines and fixes errors, because that is their responsibility before lodging, not the council's after.
They assemble the handover bundle, which is the validated ADAC XML plus the as-constructed drawings and the supporting evidence: RPEQ certification, test results, schedules, manuals, warranties.
Rockhampton Regional Council, for one, is explicit that the as-constructed submission must include information in both ADAC XML and PDF format. The consultants lodge it by the council's specified means, with the prescribed subject-line or file-naming convention. A council officer assesses it, using the XML as a cross-check on the completeness and accuracy of the drawings, and comes back to the engineer if something fails. Once accepted, the assets go on maintenance and the council incorporates the XML into its corporate GIS, asset and financial systems.
Everything upstream determines the quality of the XML that lands on your desk, which is exactly why the generate-and-validate discipline at the contractor's end matters so much to your data pipeline. If a council you work with wants to tighten intake, the highest-leverage move is usually a clear capture guideline plus a mandated pre-submission validation, so bad XML never reaches the lodgement step.
Once a submission arrives, a council officer assesses it, using the XML as a cross check on the completeness and accuracy of the drawings, and returns it to the engineer if it fails.
When it is accepted the ADAC data can be incorporated into the corporate systems. That step is where the value is finally realised, and it depends entirely on the quality of everything upstream.
How to implement ADAC in your council
Adopting ADAC well is a staged piece of work, and the order matters. The following roadmap reflects what a sound implementation looks like in practice.
Here’s a simple ADAC roadmap to get you thinking
1. Build the ADAC business case and secure ownership.
Because ADAC is a process change that spans development services, asset management, GIS, finance and IT, it needs an owner with authority across those teams and a business case that speaks to data quality, staff time saved and governance obligations met. This is the step councils most often skip, and its absence is the most common reason implementations stall.
2. Adopt the ADAC standard and fix your versions.
Decide which ADAC version you will accept and set your coordinate datum. This is not a set and forget decision, because the standard evolves and councils are actively moving to version 6.00 right now, often with a transition window during which both the new and previous versions are accepted before the older one is retired. For example, publishes explicit cutover dates for its move to version 6.00. Publish your accepted version and datum clearly and plan the cutover deliberately.
3. Develop your ADAC capture guidelines and a council data standard.
The ADAC schema covers a wide range of asset types, but most councils hold asset types or attributes that sit outside it. A council as constructed data standard defines how ADAC applies locally, extends it where necessary, and sets out the capture guidelines that submitters must follow. This document is the contract between the council and the development community, and the quality of your incoming data will rarely exceed the clarity of this standard.
4. Define the ADAC corporate target and the mapping.
Be explicit about where the data has to land, whether that is your GIS, your asset management system, your financial register, or all three, and map each ADAC asset type and attribute to the corresponding field in those systems. This mapping is the specification your ingestion process will implement, and keeping it in a maintainable, auditable form pays dividends every time the schema or your systems change.
5. Build the ADAC data pipeline.
This is the technical core, and it is a validate, transform, load process. Incoming XML is validated against the schema and against your local business rules, reprojected to your datum, mapped to your corporate model, and loaded, ideally through a staging step so that nothing reaches production systems unreviewed. ETL tools handle this well, and building it in house gives you full control, while off the shelf ingestion products can shorten the path if their configurability suits your needs. Either way, the pipeline should produce a clear validation report, not simply succeed or fail silently.
NOTE: (I will cover more about this in next month's blog post).
6. Set up the ADAC submission and lodgement process.
Decide how submitters will lodge, whether through an upload link, a portal or another channel, and publish the naming conventions, the one approval per submission rule and the required contents of the bundle. Make pre-submission validation a firm requirement, because a validation gate before lodgement is the single most effective protection for everything downstream.
7. Engage and equip the development community for ADAC compliance.
None of this works without the surveyors, designers and developers who produce the data. Provide the capture guidelines, offer drawing templates where relevant, and run briefing sessions. A short investment in helping submitters get it right first time saves a great deal of rework on both sides.
8. Pilot, operationalise, then improve your ADAC process flow.
Prove the whole flow on a small number of real submissions before switching it on across the board, then move to routine operation, and treat version management and continuous refinement as ongoing work rather than a one-off project. The standard will keep evolving, and your process needs to keep pace.
Common ADAC implementation mistakes to avoid
A few failure patterns recur often enough to be worth naming. Treating ADAC as an IT project rather than a cross-team process change leaves it without the authority it needs to succeed. Skipping or weakening the pre-submission validation gate lets poor data flow straight into corporate systems, undoing the entire benefit.
Underinvesting in the capture guidelines produces inconsistent submissions that no amount of downstream cleverness can fully rescue. Ignoring version and datum management leaves councils accepting files they cannot properly ingest. And relying on downstream reconstruction from drawings, rather than encouraging ADAC generation at the source, builds fragility into the whole chain. The councils that avoid these traps are the ones that see ADAC deliver what it promises.
Getting ADAC implementation right
ADAC is one of those rare standards that genuinely repays the effort of adopting it well. Done properly, it turns the messy, manual business of asset handover into a clean, repeatable, auditable process, and it puts accurate asset data into your systems at the moment those assets are created rather than months or years later. Done poorly, it becomes another form to fill in that no one trusts. The difference is almost never the technology. It is the clarity of the standard you set, the discipline of the validation you require, and the care you take mapping incoming data into the systems that run your council.
Real-world ADAC examples and council guidelines
The following are current, publicly available references that show ADAC in practice, useful whether you are drafting your own standard or reviewing an existing one.
IPWEA-QNT, Asset Design As Constructed - The national standard, the XML schema and validation tool, and the route to recognised software vendors and implementation partners.
SEQ Design and Construction Code - The common standard for submitting design and as constructed information to Southeast Queensland water service providers.
Sunshine Coast Council, As Constructed Data Standards and Guidelines - A council data standard incorporating ADAC, with published version 6.00 transition dates and a GDA2020 datum requirement.
Rockhampton Regional Council, As Constructed Submissions - Submission requirements and lodgement conventions, including the rule that submissions carry both ADAC XML and PDF.
City of Moreton Bay, As Constructed Data Standards - A further council data standard example showing how ADAC feeds asset information into corporate systems.
Look out for next month's blog where I'll delve deeper into this subject, and I will have a go at answering the question I've been asked many times, ‘We understand why ADAC is important... but where do we actually begin?’
I have worked on many different projects with my Local Government clients, from designing and developing Power BI Reports, to building SQL Server databases for spatial data, to managing and maintaining GIS and the Asset Management systems. If you'd like to discuss how we might work together, then please email Jill at ➡️ jill.singleton@iamdata.solutions
If you would like to receive the latest Newsletter Blog straight to your inbox, please subscribe here: ➡️ https://www.iamdata.solutions/subscribe
You can read all our Newsletters and Blogs here:➡️ https://www.iamdata.solutions/blog
You may also be interested in our Projects Page:➡️ https://www.iamdata.solutions/past-projects
Check out what our clients say about us here:➡️ https://www.iamdata.solutions/reviews
If you would like to see a particular topic covered in these newsletters, then please let me know about it. The chances are other people will be interested and would like to hear about it too! Please email me at: ➡️ jill.singleton@iamdata.solutions with your suggestions.
Comments