Five layers between an engineering question and an engineering answer. Three are delivered today, one is in development, and this page publishes the difference along with the legend we use to describe it.
Capability status
Every capability claim on this website carries one of these four states. They appear beside individual line items, not only beside sections, because a section-level badge is how vague claims hide.
Delivered on client appointments today. If you appoint us this week, this is what arrives.
Being built now and used internally on our own delivery. Not a released product, not licensable, and no date is committed.
Intended direction. Not built. Published so the architecture is legible, not so it can be sold.
Simulated content shown on this website for illustration. Not a client project, not a real measurement.
What this rules out. No feature on this site is offered for licence. No date is committed for anything marked in development or roadmap. Nothing described as an agent operates without engineering review. If a page ever contradicts this paragraph, this paragraph is correct and the page is a defect.
The stack
Read bottom-up as data and top-down as accountability: model data feeds the layers above it, and the engineer at the top is answerable for everything below.
Models authored so their data is queryable from the outset — parameters populated during authoring rather than retro-fitted before handover. This layer is a service you can appoint today, and it is the precondition for every layer above it.
Live
DATA FLOWS UP · ACCOUNTABILITY FLOWS DOWN
What a competent engineer checks, written down as rule sets a machine can apply — clearances, sizing bands, system logic, access requirements, standards. This is the layer most BIM providers do not have, because it needs engineers rather than modellers.
Live
DATA FLOWS UP · ACCOUNTABILITY FLOWS DOWN
Extraction of elements, parameters, systems and relationships as structured data, then pattern and anomaly detection over it. In development and used internally on our own delivery. It proposes; it does not decide.
In development
DATA FLOWS UP · ACCOUNTABILITY FLOWS DOWN
The repetitive production and checking work, run as scripted and parametric routines. This has been live in our delivery since before we called it a platform — Dynamo, custom checking tools and data routines are how the work already gets done.
Live
DATA FLOWS UP · ACCOUNTABILITY FLOWS DOWN
Coordinated models, drawings, schedules, quantities and reports — issued through a common data environment with the correct status codes, signed by a named engineer who is accountable for them.
Live
Product architecture
The architecture we are building toward. Components are marked with their real state below the diagram — several of them are ordinary engineering practice rather than software, and that is deliberate.
Maturity model
A five-level model of AEC engineering maturity, with our honest position marked. We deliver at levels one and two, and are working inside three and four. Level five is a direction, not a position we hold.
LEVEL 01
Structured models replace drawings as the source of truth.
Standard practice
LEVEL 02
Rules and scripts take over repetitive production and checking.
Where we deliver
LEVEL 03
Model data is read and reasoned over to support engineering decisions.
In development
LEVEL 04
Defined workflows run end to end, drafting output for engineering approval.
Partially, internally
LEVEL 05
BIM, AI, automation and project data connected as one system across a portfolio.
Direction, not a claim
On level claims. Every vendor in this sector places itself at the top of whichever maturity model it publishes. Ours puts us in the middle, because that is where we are. Ask us to demonstrate a level-three or level-four workflow at enquiry stage — that is a reasonable request and we will show you the internal tooling rather than a slide.
Accountability
This is not a disclaimer bolted to the bottom of the page. It is a structural constraint that shapes what we build and what we refuse to build.
A routine that silently edits a live model removes the one thing that makes an engineering deliverable worth anything: a person who is answerable for it. So our automation drafts, proposes and reports. It does not commit.
The practical consequence is that our workflows are slower than a fully autonomous system would be, and defensible in a way that one would not be. That is the trade we have chosen deliberately.
A scope, a question or a rule set. The engineering judgement about what matters happens here, before any automation runs.
Model data is resolved, rules applied, anomalies detected and findings classified by cause rather than counted.
A report, a schedule, a quantity export or proposed model content — in a reviewable state, never written directly to the live model.
Accepts, amends or rejects. Rejections are fed back into the rule set, which is how the system gets better rather than more confident.
Through the CDE with the correct status code, under a named person's accountability.
Engineering enquiry
Send a scope, a drawing set, an information requirement or a workflow you are tired of doing by hand. You will get a technical response on approach, disciplines, deliverables and what is realistically automatable — from an engineer, not a sales desk.