Case studies structured around the engineering problem

Published as clients release them. Until then, the documentation structure every entry will follow is set out in full below — including the parts most case studies omit.

Published: None yet
Structure: Fixed, five parts
Numbers: Verified or absent
Failures: Published too

Project evidence

Nothing here is invented

It is common in this sector to show unattributed renders, borrowed imagery and round numbers with no method behind them. This page does none of that. Three positions are held open, and they stay empty until a client releases the work.

Case study anatomy

Every published case study will answer these six questions, in this order.

Structure fixed

01 Project

Building type and size
Location and jurisdiction
Stage at appointment
Project team

02 Challenge

The problem in the client's terms — what was slow, repetitive, unreliable or unresolvable at the scale of the project.

03 Our scope

Disciplines engineered
Modelling and coordination scope
Level of information need
What stayed with others

04 Approach

How the systems were designed
How the model was structured
What was automated, and what was not
Where the engineer reviewed

05 Deliverables

Drawings and schedules issued
Models and formats handed over
Reports and issue records
Dates and revisions

06 Outcome

Measured against a stated baseline, with the measurement method named. Where a number cannot be verified, the case study will say so rather than estimate one.

Failures and dead ends will be published alongside successes. A case study library with no failures in it is a brochure.

Position 01 — reserved

MEP coordination case study

A coordination appointment documented against the five-part structure above, with the automated checking workload separated from the manual review workload.

Position 02 — reserved

Automation engagement

A workflow automated for a client team, with the baseline it was measured against stated and the parts that stayed manual explained.

Position 03 — reserved

Model data and QA

An information-first modelling appointment, showing what became queryable as a result and what checking that enabled.

Measurement

How impact will be stated

The rules we are committing to in advance, so that when numbers do appear here they mean something.

Rule 01Every number names its baseline

"40% faster" is meaningless without saying faster than what, measured how, over what scope. Any figure published here will carry all three.

Rule 02Automated and manual effort separated

If a routine did the checking and an engineer did the review, the case study says how much of each. Blending them inflates the automation claim.

Rule 03False positives reported

Automated checking produces findings that turn out to be wrong. The rate is a property of the rule set and will be stated, because a checker with an unstated false-positive rate cannot be evaluated.

Rule 04What did not work is included

Approaches that were abandoned, rules that had to be rewritten and checks that could not be automated will appear in the case study. A library with no failures in it is a brochure.

Rule 05Client release in writing

Nothing is published without written permission, including anonymised work. If a client prefers anonymity, the sector and scale are described and the name is not.

If you are evaluating us right now and want evidence rather than a structure, ask at enquiry stage. We will walk through the internal tooling, the rule sets and the QA output on a live workflow directly — under NDA, on a call, with the actual screens. That is a better test than a case study we wrote about ourselves.