TemplateForge is QA automation for Civil 3D. It audits a whole folder of drawings against your practice's CAD layer standard, reports what is wrong and why, and applies the corrections behind a verified backup — and it exposes the whole thing as an MCP server, so an AI agent can run it for you.
AutoCAD has audited drawings against a standards file for twenty-five years. What none of it reads is which layer a kerb line is sitting on, or the Civil 3D settings that decide where the next one lands.
Ships in the box and does check many drawings at once. It compares layer definitions — colour, linetype, lineweight, plot style — and reports violations. It does not tell you that 412 objects are on the wrong layer, and it cannot see Civil 3D object-layer settings at all.
New in 2027, and it does read a standards file. One drawing at a time, and Autodesk labels it Tech Preview — “results may not be accurate”. It cannot tell you which of the 150 drawings in an issue package are wrong.
Excellent at issues, versions and risk across a project. It does not score a DWG against a layer standard at all.
Mature tools exist for building models. Civil drawings — alignments, corridors, surfaces, parcels — are the underserved side.
TemplateForge reads the layer table, every layer property, the external reference graph and Civil 3D's object-layer settings from each drawing, and scores them against your standard. No GUI, no one sitting there.
Every finding states how many real objects it affects, the proposed fix, a confidence value, the reasoning, and sample entity handles so you can select the offending objects in the drawing itself.
Approve what you agree with. It backs up each file, verifies the backup by hash before touching anything, applies only what you approved, and reports what it refused to touch and why.
Preview is the default. Nothing is ever written without an explicit action and a matching token.
TemplateForge is a native plug-in, not a converter. It reads the real drawing database — so it sees colour, linetype, lineweight and object-layer settings, which an export-based check cannot.
SettingsObjectLayerType object-layer settings.accoreconsole.exe, so a folder runs headless with no user present.# score a whole issue package > .\Invoke-DatumBatch.ps1 -Path .\04-Drawings ` -StandardPath .\practice-standard.json ` -Civil3DVersion 2024 161 drawings · 4 parallel · 3m30s 0 failures · 0 drawings modified # worst first Align-1.dwg 2.1% 19 findings · 601 objects Corridor-1a.dwg 56.0% 9 findings · 143 objects Mass Haul-1.dwg 84.8% 1 finding · 145 objects
Your standard is read out of your own Civil 3D template — both the layer table and the object-layer settings, because a template states its standard in both places.
The audit and the standard extraction are exposed over the Model Context Protocol, read-only. Point an MCP client at it, with Civil 3D open and the bridge running, and the drawing on your screen becomes something an agent can reason about — “what is on the wrong layer here, and what would it take to fix?” is a question with a real answer. Whole folders are the headless runner's job, not the bridge's: the bridge talks to the drawing you have open. The fix planner is deliberately not on the bridge either: applying a change to a drawing needs a person who has read the preview, not an agent that can call a tool.
Where this one is up to: the bridge is built and working, and it is not in the installer yet — the plug-in and the batch runner are what install today. If the agent side is the part you care about, say so and it moves up the list.
Two processes on purpose: the protocol layer stays version-agnostic, so one server serves every Civil 3D build you have installed.
“Score this drawing against our standard and tell me what I cannot issue it with.”
Not a chat log — a typed report the agent can rank, filter and explain, with the object counts behind every claim.
The agent can audit freely. It cannot apply a fix without an explicit action and a matching token.
One command, over a coffee. Every drawing opened, scored and closed — none of them modified.
A portfolio view ranking every drawing by compliance, then per drawing a worklist ordered by how many objects each problem actually affects. Empty template layers are separated out as housekeeping instead of padding the count.
Thirty-seven parcels sitting on C-PROP — a layer that is in the standard, but is not the standard's layer for a parcel, which is C-PROP-LOTS. Every one of them scores as compliant on a layer-name audit, and no finding mentions them. That is Parcel-1E.dwg in the report bundled with this site; the number is not an illustration.
The object-layer setting that put them there is still wrong, so it will happen again on the next drawing. TemplateForge audits those settings too, and names which finding each one explains.
Hash-verified backup per file, only the approved findings applied, and a clear account of anything it refused. Drawings that were already compliant are never opened for writing.
A browser control panel that browses your Autodesk Construction Cloud hubs,
projects and folders directly over APS, picks the drawings, and submits the audit
to Design Automation — accoreconsole on Autodesk's own cloud
engine, carrying the Civil 3D vertical. Nothing is installed and no drawing
leaves ACC. Browsing works today; the run is written and has never
executed — step 02 says why.
Three-legged sign-in with your own Autodesk account, then the real folder tree and the current version of every drawing. Region is probed automatically across US, EMEA and Australia.
The same engine as the desktop plug-in, submitted as a Design Automation workitem against the AutoCAD engine. Written, not yet run — the AppBundle is not published to an APS app, so this path has never executed. Cost and duration would be in the order of a few seconds and a few pence a drawing, but that is an estimate from the desktop timings and Autodesk's published rates, not something measured.
Every drawing in the project ranked worst-first, each one opening into the same report the desktop tool produces.
Where this actually is: the browse half — sign-in, hubs, projects, folders,
versions — is built and works. The Design Automation half is written but has
never run: the AppBundle and Activity that carry the engine are not published
to an APS app yet, so a live run returns a plain "not configured" rather than a
result. The three-second-per-drawing and cost figures above are the desktop
engine's measured numbers and an estimate of what the cloud will charge, not a
measurement of it.
Two separate things stand between this and a live run: publishing the AppBundle,
and one step only an account administrator can take — adding the app's Client ID
as a Custom Integration in ACC Account Admin. Until that is done a three-legged
token sees zero hubs, which is a permissions boundary rather than a missing
feature. Both are the honest reason this is not yet a button on this page.
A cloud-only check would be strictly weaker: the published derivative exposes layer names alone, with no colour, lineweight or object-layer settings. Design Automation opens the real drawing database, which is why the audit is worth running there and not against a viewer.
TemplateForge is developed by a practising civil engineer who spends the working week in Civil 3D. It exists because checking a package of drawings against a practice standard is still a manual job done one file at a time, and the tooling that does exist was built for a different industry.
An independent, self-funded developer working on one thing: CAD standards quality assurance for civil infrastructure. TemplateForge is a commercial per-seat product, in development, with an early-access programme opening to a limited number of consultancies.
Developed natively against the AutoCAD and Civil 3D .NET APIs. TemplateForge is an independent developer and is not affiliated with Autodesk.
If you are responsible for CAD standards across a civil project and want TemplateForge run against a real package of drawings, say so.