Date: 2026-06-22 Status: research-backed implementation brief for CSM app, fixed 12d macro, and ADAC proof gates Purpose: keep the ADAC/12d data-prep assumptions visible as commentable planning content.

ADAC delivery is an asset-data preparation and validation workflow, not a final XML button.

For CSM this means the app and fixed 12d macro must prove the chain from source survey data to grouped assets, writable attributes, validation evidence, and later ADAC XML/read-back. A schema-valid empty or shell XML is not production acceptance.

The 12d-specific lesson is important: 12d already has an ADAC lane, but it only works when the model has been prepared correctly. The CSM macro should therefore act as the missing preparation and enrichment layer: select real source data, resolve the client's codes to ADAC/client asset groups, populate the required attributes, preserve unique field values, and leave evidence that 12d's native ADAC validation/export tools can trust.

• 12d's public ADAC page says ADAC data is represented in 12d through parametric objects and hierarchical attributes; 12d can write and read ADAC XML, and its ADAC editors/validators are driven by ADAC XSDs.
• The 12d ADAC manual shows the practical workflow: create header, create asset, edit header/asset, validate, report, write ADAC XML, import/read back ADAC XML, and use utilities such as XSD-to-model to understand the asset schema.
• The 12d ADAC manual also states that the user must know the receiving authority's required ADAC assets, required Types/Uses, required elements, defaults for compulsory elements the authority does not want supplied, and the exact geometry/coordinate meaning before setting up map-file or attribute creation rules.
• Mackay Regional Council's 12d quick guide reinforces that the 12d ADAC process assumes survey/as-constructed data is coded using the authority's naming conventions and supplied setup files/toolbars.
• Unitywater guidance treats ADAC XML as the machine-readable asset data that accompanies signed as-constructed drawings/redlines and says generated XML must conform to the current ADAC schema plus Unitywater-specific requirements.
• City of Gold Coast guidance shows that a receiving authority can combine the ADAC data dictionary with local non-ADAC asset dictionaries and enforce version windows by project approval/contract dates.

Reference URLs:

• https://www.12d.com/product/adac.html
• https://downloads.12dmodel.com/v11/Documentation/12d_ADAC.pdf
• https://www.ipweaq.com/adac
• https://www.ipwea-qnt.com/Web/Web/Resources/Asset-Design-As-Constructed-ADAC.aspx
• https://www.mackay.qld.gov.au/__data/assets/pdf_file/0007/247246/ADAC_5.0.1_-_Creation_of_ADAC_XML_using_12d_Model.pdf
• https://www.unitywater.com/-/media/unitywater/pdf-accreditation-certification-documents/adac-xml-data-capture-guidelines-version-3-2.pdf
• https://www.goldcoast.qld.gov.au/Planning-building/Development-applications/Post-development-approvals-appeals/As-constructed-data-standards-and-guidelines

CSM must treat 12d as the execution and proof environment for prepared asset data, not merely as a file exporter. The receiving authority's requirements have to be resolved before 12d export:

• Which ADAC/client assets are required.
• Which Type/Use/subtype values are required for each asset.
• Which attributes/elements are mandatory, optional, conditional, or locally extended.
• Which values are field-captured, copied from source attributes, selected as project values, fixed/defaulted, calculated, spatially looked up, or blocked pending a human decision.
• Which geometry family is valid for that asset: point, line, polygon, surface, or authority-specific reference geometry.
• Which 12d storage bucket is required for the macro write: string, vertex, segment, super-vertex, or project/header-level attribute.

The CSM macro does not need to clone 12d's ADAC editor. It needs to prepare the same underlying kind of structured attribute data in a controlled CSM way, then produce evidence that 12d's native validators/export/read-back path has real asset content to work with.

CSM must store and validate these facts before treating an ADAC client as production-ready:

• client/council capture guideline source
• accepted ADAC schema/version for the project date or authority
• source model or selected source elements
• resolved client feature/code to Veris/field-code bridge
• ADAC asset path or equivalent client asset class
• geometry family: point, line, polygon, or surface/terrain where applicable
• 12d attribute storage bucket: string, vertex, segment, super-vertex, or header
• required/conditional attributes and their source kinds
• choice dictionaries and allowed values
• runtime profile values and 12d reference model names
• macro write evidence
• independent 12d attribute inspection evidence
• ADAC validation/report/XML/read-back evidence

The macro cannot be a fake shell. The panel must scan real source data and group elements by resolved schema identity and writable attribute signature.

The minimum useful 12d workflow is:

select source model/elements
  -> scan real elements
  -> resolve feature/code/group
  -> show grouped rows in GridCtrl_Box tables
  -> show selected group attributes and element rows
  -> allow controlled bulk value entry for group-safe attributes
  -> write through the vertex Attributes bag
  -> record affected element/vertex counts
  -> allow Go to element using stored model UID + element UID
  -> produce output-window and evidence files
  -> verify with an independent inspector

The macro must preserve unique field-captured values unless the operator uses an explicit override path.

For a bulk edit such as "add this comment to all UG Gas points", the valid CSM behaviour is:

select UG Gas group
  -> select a writable group-safe attribute such as Comment
  -> enter the bulk value
  -> show the affected elements before writing
  -> write only that attribute to only those selected group elements
  -> re-read the written attribute from 12d storage
  -> record changed/skipped/blocked counts

It must not infer that every attribute in the group should be overwritten.

Static checks that are useful but not final acceptance:

• macro compiles cleanly
• call audit reports no unknown/policy calls
• generated package files exist
• XSD shell validates
• static matrix says all rows have a strategy

Production acceptance requires current evidence from real or controlled 12d data:

• source model loaded or selected
• scanned element count and grouped count
• attribute write count and vertex count
• independent read-back from 12d attribute storage
• ADAC validate/report/XML/read-back where the client is an ADAC XML delivery client

Vida remains valid for macro workflow proof using Output\Vida\Vida_simulated_survey.12da, but Vida is not the ADAC XML production proof client because its confirmed scope rows are client-specific rather than ADAC XML delivery.

MRBC remains the best ADAC proof target because Output\MRBC contains the richest ADAC 4.2 style local fixture set. It is still blocked by real project/runtime evidence and duplicate Veris-code qualifier decisions.

WAADAC remains a strong real-profile ADAC client, but the pending ASLID -> SWLID bridge and capture-action review mean it must not be marked ready by guessing mappings.

When building or testing CSM ADAC work, treat this as the required sequence:

• Confirm the client standard version and capture guideline source.
• Confirm the project runtime profile values needed by the macro.
• Confirm code/feature bridges are approved and unambiguous.
• Generate or load real 12d fixture data.
• Run the fixed macro against that data.
• Inspect 12d attributes independently.
• Only then run/claim ADAC validation or XML acceptance.

Do not close ADAC macro gaps with placeholder rows, fake shell screenshots, empty XML validation, or compile-only evidence.