ADAC - Where Do We Even Start with Implementing Asset Design As Constructed (ADAC) in Council?
Last month's blog post introduced the ADAC concept, what Asset Design and As Constructed is and why it could be useful to councils ➡️ https://www.iamdata.solutions/post/a-practical-guide-to-asset-design-and-as-constructed-adac-standard
This month I have gone a step further and provide a practical detailed roadmap for how to actually implement it at your council, twelve stages in four phases.
I hope you find this helpful.
Many councils are struggling with their current data handover processes and understand that implementing a policy like ADAC (Asset Design As Constructed) will help them enormously. I've found that the concept of an ADAC type policy is appearing in more and more conversations with councils. One of the questions I'm often asked whenever I mention ADAC is, ‘We understand why ADAC is important... but where do we actually begin?’
It is a reasonable question. When people first hear about ADAC, it does sound a bit overwhelming and can sound like another large technology project that will require new software, major system upgrades and months of implementation. In reality, I think that is one of the biggest misconceptions. From what I have seen, implementing ADAC is not primarily a technology project. It is a data and business process project.
Welcome to the Iamdata Solutions Asset Management Newsletter – October 2026
Most councils already own much of the technology they need. They have a GIS, an Asset Management system, SQL servers and databases, document management software and often some form of ETL or integration capability. The challenge is not usually the software. It is deciding how information should flow into the organisation, the various processing steps, and who is responsible.
Here are some are tips to help get you started on your ADAC journey.
Start by Understanding Your Current Process
It is important to have a very good understanding of what your current processes are. This in itself can be quite difficult to ascertain, and often this very first step is overlooked because people think that it's all going to change anyway and it isn't worth the effort. But, it really is worth getting a complete and thorough understanding of your current purposes. Once you have this information, document the processes, procedures and workflows to ensure everyone understands how things work today. I promise you this will also help you to determine how things could work with the implementation of ADAC.
Things to take into consideration and document in the process flowchart:
When a developer finishes constructing a new subdivision, what actually happens next?
Who receives the as-constructed drawings?
Who updates the GIS?
Who enters the assets into the asset register?
Who checks that the information follows the 3 C's (Current, Complete, Correct)?
Who confirms that the data is accurate before it becomes part of the council's corporate systems?
These questions often uncover something interesting. Many councils don't have one clearly defined process. Instead, the information moves between engineering, GIS, asset management and sometimes finance, with each team doing the best they can using the information they've been given. That is why documenting each stage of the process is so important and helpful.
Mapping the process is the first step before even thinking about the ADAC implementation.
You Probably Already Have the Technology
Another misconception I hear is that councils need to buy a special ADAC system. In most cases, they don't.
FME
One tool I would recommend, if you don't already have technology that can read and convert CAD files is FME.
I have been doing quite a bit of work with CAD files and I have had success using FME to read DWG files and extract the CAD geometry, layers, blocks, text and block attributes.
FME can then convert that geometry into GIS feature classes and write it to formats such as GeoPackage or directly into a SQL or Oracle spatial database. FME already has everything you need to do this work. If you set up a workspace, you can potentially use it over and over again. All you would have to do is point it to the next CAD file you want to process and FME can do all the work for you, it has native DWG readers and spatial transformation capabilities.
Other Tools Council will already have
The GIS already stores spatial assets. The asset management system already stores maintenance and lifecycle information. SQL Server or PostgreSQL already stores corporate data. Power BI is excellent for building reports on that information.
ADAC doesn't replace any of these systems. Instead, it becomes the standard way that newly constructed assets are delivered into them.
Rather than receiving PDFs, CAD files and spreadsheets that someone has to manually interpret, the council receives structured digital information that can be validated before it ever reaches production systems.
Start Small
If I were implementing ADAC, I certainly wouldn't try to cover every asset class on day one. I would begin with something familiar. Roads are often a good candidate because they involve several different asset types working together.
A single road project might include the road pavement, asphalt surface, kerb and channel, footpaths, stormwater pipes, pits, signs, and street lighting, water and waste assets. Each of those assets has different maintenance requirements, different replacement costs and different expected lives.
Capturing that information consistently from the beginning creates enormous value later.
Once the process is working well, it's much easier to expand into parks, irrigation, bridges, CWMS assets or other infrastructure.
Think About the Journey the Data Takes
One thing I have learned is that data rarely arrives exactly the way we need it. An ADAC file might be perfectly valid against the standard and still be missing something my council cares about, or carry a value that does not match how we classify things, or describe an asset we already hold in our records. So rather than treat every submission as ready to use the moment it lands, I like to give the data somewhere to arrive before it goes live. That somewhere is a staging area in the SQL server database.
The simplest way I can describe a staging area is that it is a holding space between the front door and the shelves. When a delivery arrives at a warehouse it does not go straight onto the shop floor. It comes into goods inwards first, where someone checks it against the order, opens the boxes, sets aside anything damaged, and only then moves the good stock through.
A SQL database staging table does exactly that job for asset data. Instead of importing an ADAC file directly into the GIS or the asset management system, I would first load it into a SQL staging database table, a working copy that sits to one side of the systems everyone relies on, where the data can be examined safely before it goes anywhere near production.
The reason this matters is that your GIS and your asset register are the source of truth. People make real decisions from them, works are planned against them, and assets are valued and reported from them. The last thing you want is unverified data from an outside submission flowing straight into those systems, because once it is in there it is mixed with everything else and far harder to pull back out. A staging area keeps that risk outside the door. Nothing reaches production until it has earned its place.
Once the data is in staging, it becomes something you can interrogate. This is where I would check that the mandatory attributes are actually populated, so a pipe is not arriving without its material or its diameter. It is where I would check that the geometry is valid and sitting in the right place, in the right coordinate system and inside the council boundary. It is where I would verify that the relationships between assets hold together, so a pipe genuinely connects to the manholes at each end rather than floating near them. And it is where I would apply our own business rules, confirming that values sit within the lists we accept and that everything is named and classified our way.
Staging also gives me room to enhance the data, not just judge it. An ADAC file describes the asset as it was built, but it will not know our internal asset numbering, our ownership and hierarchy fields, or how a new asset links back to the development it came from. Staging is where that local context gets added, and where a re-submission can be matched against an asset we already hold so that it updates the existing record rather than creating a duplicate.
By the time the data moves out of staging and into the asset management system and the GIS, it has been checked, corrected, enriched and matched, and everyone can have real confidence that what they are looking at is complete and reliable. Just as importantly, because all of this happened in one controlled place, you have a record of what was checked and what was changed, which is what makes the whole process defensible.
If this sounds familiar, that is because it is. It is the same shape as the ETL processes, extract, transform and load, that many councils already run to move data between their corporate systems. You extract the data from the source, you transform and check it in the middle, and you load it into the destination once it is clean. Seen that way, ADAC is not a special case at all. It simply becomes another trusted source feeding into a pipeline your council already understands.
Decide Who Owns Each Step
One of the biggest lessons I've learnt from working with councils is that good data doesn't happen by accident.
It happens because somebody owns each part of the process.
Engineering might receive the submission.
GIS might validate the spatial data.
Asset Management might review the asset attributes.
IT may oversee the integration.
Finance may rely on the data for valuation and depreciation.
When those responsibilities are clearly defined, the entire process becomes much smoother. Everyone knows what they're responsible for and where the data should go next.
Don't Forget the People
As much as we enjoy talking about technology, successful ADAC implementation is really about people.
Surveyors need to understand what's required.
Consultants need to know the submission standards.
Developers need to provide complete information.
Council staff need confidence that the data can be trusted.
The more everyone understands the purpose behind ADAC, the easier the implementation becomes.
Think Beyond Construction
One of the things I like most about ADAC is that it isn't really about construction at all. It's about the next thirty, fifty or even one hundred years. The construction is the easy part to picture, the pipe goes in the ground, the road gets built, the park gets handed over. But the moment of handover is not the end of that asset's story. It's the very beginning of a working life that will outlast the developer, the contractor, and quite possibly everyone involved in approving it.
That is why the as-constructed record matters so much. It is, in a real sense, the asset's birth certificate. And handover is the one moment in the asset's entire life when the information about it is complete, accurate and sitting right in front of us. The people who built it know exactly what it is, what it's made of, where it runs and how deep it sits. Every year that passes after that, some of that knowledge fades, until eventually the only way to recover it is to send someone out to dig, survey or guess. Capturing it properly on day one is the cheapest and most accurate it will ever be.
And almost everything a council does with an asset after that draws on this same information. When it comes time to inspect and maintain it, the schedule and the condition assessment start from knowing what the asset is and where it is. When it comes time to plan renewals and replacement, the forecast depends on knowing the material and the age, because those are what tell you how long it should last. When Finance reports on the value of the network and meets its governance obligations, it relies on the asset's value and attributes being captured at creation rather than reconstructed years later. Long-term asset plans, capital works programs and the dashboards executives use to make decisions are all, underneath, just this data being read again and again for different purposes.
So, the same record, captured once and captured well, quietly feeds decision after decision for years. Get it right at handover and every one of those future decisions becomes easier, faster and better founded. Get it wrong, or never capture it at all, and each of those decisions inherits the gap, usually at a point when fixing it is far harder and far more expensive than it would have been on the day the asset went in.
That is why I see ADAC as much more than a digital handover standard. It is the first chapter in an asset's lifecycle, and it's written for readers who aren't even in the room yet, the people who will inspect, value and renew that asset long after the ribbon is cut.
Is Your Council Thinking About Implementing ADAC or something similar?
If your council is starting to explore ADAC or a similar policy, my advice would be:
Not to over complicate it. Start by understanding your current process. Identify where information is duplicated or lost.
Decide how you would like asset information to move through the organisation. Then build a simple, repeatable workflow that validates and enriches the data before it reaches your GIS and asset management systems.
You don't need to solve everything in the first project. Like most improvements in asset management, it is about taking steady, practical steps that build confidence over time.
The councils that do this well won't just have better digital handovers. They'll have better data, better reporting and, ultimately, better decisions for many years to come.
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