AEDEXA

Inspiration

Tell a crew of builders to just build a house, and they will — but without a clear plan, without real drawings, what they build is a mess. That's why architects and engineers exist: no project moves from idea to building without them. We started AEDEXA from one question — what if every fact about a site carried its source, the way a medical record does? Doctors change, the record stays. We're building for architects, civil and structural engineers, and site developers doing early-stage feasibility work in the CIS/Kazakhstan market — the decisions made before a design contract is signed, before a full survey is paid for, where a wrong assumption is most expensive to find out about late.

What it does

AEDEXA reads a real DWG or DXF site drawing — or a plan image, or a location traced on a satellite map — and turns it into a model you can check, not just look at:

Placement & setbacks — detects the site boundary, utility protection zones, and surroundings, then computes a buildable area net of setbacks, sanitary clearances, and earthworks. Every constraint is labeled with its building-code clause.
DWG topo survey — builds a 3D terrain model (TIN) from spot elevations and contour lines, classifies drawing objects, and exports DAE/DXF.
2D → 3D reconstruction — turns a full 2D drawing into a verifiable 3D model, with AI-completed geometry always labeled as an explicit "AI assumption," never silently passed off as a measured dimension.

Every result carries one honest status — PASS, FAIL, MISSING_DATA, or EXPERT_REVIEW — and a link to the rule it came from. If the drawing doesn't have the data, AEDEXA says so instead of filling in a typical value. Placement and topo survey run entirely in the browser; a drawing never has to leave the device for those two modes.

How we built it

Client: Vite-based React 19 (Server Components), deployed as a single Cloudflare Worker; Cloudflare D1 for accounts and project sync.
DWG/DXF reading: LibreDWG compiled to WebAssembly, running in a Web Worker so large files (tested up to 20 MB, 150+ utility lines) don't block the UI.
Geometry: Delaunator for terrain triangulation, polygon-clipping for setback and zone operations, three.js for the 3D scene, Leaflet for the map-based site source.
AI, in two bounded places:
1. CAD semantic analysis — a vision-capable model via the Featherless API reads drawing text labels and geometry groups to classify entities the rule-based parser leaves unclassified. It runs only when the user asks for it, never on the critical placement/terrain path.
2. 2D → 3D reconstruction — a multi-step agent: it audits the drawing against its own source views, produces a parametric "recipe" validated against a strict JSON schema, a deterministic solver builds the geometry from that recipe, and an independent AI visual-review pass checks the model against the source views before it's shown.
Building codes: a registry where every rule carries its source document and clause, so a value the app hasn't verified cannot return PASS.

Challenges we ran into

Real drawings from CIS practice use inconsistent, hand-written layer and block names for the same thing — a boundary, a contour, a utility line — so the classifier has to recognize intent without a fixed schema.
Keeping AI output honest: the reconstruction agent has to tell a measured CAD dimension apart from its own inferred guess, and never blend the two without a visible label.
Large real-world DWGs — tens of megabytes, thousands of entities — need to parse and triangulate in-browser without freezing the tab.

Accomplishments that we're proud of

275 automated checks run on every change; a pipeline run over 69 real third-party DWG files (63 parse cleanly) is compared byte-for-byte against a saved baseline before any change to the parsing code ships.
19 building-code rules in the registry, each traceable to a source clause.
The placement and topo-survey modes need zero server calls — the file never leaves the user's device.
Watching the reconstruction agent catch its own mistake on a real bridge drawing — flagging a missing stair detail instead of quietly shipping a confident-looking model — was the moment the "AI assumption, never a silent guess" design actually proved itself on data we hadn't hand-picked.

What we learned

Rule-based parsing and AI aren't competitors here — the rule-based path has to stay in charge, with AI called in only where the rules genuinely run out of information, and always labeled when it's guessing. We also learned that an AI feature earns more trust by visibly refusing to finish than by always producing a confident-looking result. And real-world CAD data is messier than any schema we designed on paper: the classifier had to be built around how people actually name layers, not how a spec says they should.

What's next for AEDEXA

Expanding the building-code registry's coverage and re-verifying sources against current editions.
A CIS-focused, opt-in dataset built from real, anonymized projects to train task-specific adapters instead of relying only on a general-purpose vision model.
Batch digitization of archived paper and scanned drawings into the same verifiable model.