Why this exists
Construction information is fragmented across BIM models, drawings, schedules and visual project context. A fluent chat response can hide where a fact came from or silently join the wrong sources. This workbench keeps natural language as the interaction layer while controlled domain execution remains the factual layer.
System architecture
The same codebase runs a fully local profile and a deployed Azure profile. A shared QueryPlan/MultiQueryPlan contract keeps heuristic and semantic planning inside bounded capabilities. Deterministic IFC and drawing tools produce the engineering facts; a vision model is a constrained fallback for visual context, not a replacement for structured BIM computation.
What the workbench can inspect
Counts, grouping and bounded quantity/height queries are computed from IFC data rather than guessed by the model.
PDF schedules and source regions remain attached to the result, with honest clarification or refusal when a field is ambiguous.
A deliberately narrow capability compares door and window quantities and dimensions by shared tags, reporting matched, mismatched and missing records.
BIM models, engineering drawings and viewer snapshots are explicit source modes, not an undifferentiated prompt.
A tool-calling path can investigate a flagged discrepancy through a fixed read-only toolbox and return its own evidence-backed basis.
Findings move through reviewable states; approval or rejection is explicit and the agent never edits the model or drawing.
On the Azure slice, project/source-set context and a request's trace remain available alongside the answer.
Planning, execution, evidence, verification and final disposition are rendered as a Decision Trace rather than hidden behind a chat bubble.
Finding resolution is a controlled loop
When reconciliation identifies a non-match, the system can persist it as an EngineeringFinding. A V2 investigation may gather more evidence, but the consequential step remains a human decision and a fresh re-check of the underlying sources.
Public data, not private project material
The public demo combines synthetic fixtures with two unmodified, openly licensed building models. Their attribution records remain in the source repository; the schedules used for reconciliation are ARMIE-generated from each building's own IFC values and include deliberately planted discrepancies for evaluation.
Controlled models and documents used for repeatable walkthroughs, capability gates and regression tests.
buildingSMART Community Sample Test Files, CC BY 4.0; approximately 38 real door/window openings.
RWTH Aachen E3D Institute, MIT; a larger institutional model with 111 real openings.
Implementation evidence
The screenshots below are the public repository's current visual evidence. The first group comes from synthetic fixtures; the final two were captured from the deployed Azure profile against the openly licensed RWTH DigitalHub model. They show the inspectable reference surface, not a hosted enterprise-product promise.
Engineering progression
Current scope and maturity
This is a public ARMIE AI reference implementation with local and live Azure profiles, bounded multimodal workflows, openly licensed demonstration data and an inspectable human-review loop. The latest mainline has been exercised against the two real building models in the public dataset pack, not only the smallest synthetic fixture.
It is not production SaaS, a compliance engine, an unrestricted BIM reasoning system, a multi-tenant platform or a guarantee of arbitrary document-layout or visual-model correctness. Cross-source reconciliation remains intentionally narrow to door/window quantities and dimensions; unsupported operations are declined by design. The live Azure slice is evidence of an engineering reference path, not a claim of enterprise production readiness.