04·3D & Spatial
Spatial Asset Intelligence
A walkthrough scan of an office floor should do more than render a 3D model. It should say where every fire extinguisher, smoke detector and exit sign is, as a register somebody can check. The work was getting from a cloud of imagery to a list of real objects with trustworthy positions, and then deciding which of those objects were dependable enough to hand over.
ResultFour asset classes came out dependable enough to put in front of an operator, each entry positioned against the building's own geometry and paired with a crop so it can be checked by eye.
[ Ask about this build ]01Discover
Why it exists.
A walkthrough scan already carries the information. Every fire extinguisher, smoke detector and exit sign on the floor is sitting there in the captured imagery and geometry, and nothing about how the building is scanned needs to change. What is missing is the step that turns all of that into a list of real objects with positions, which is the difference between a 3D model somebody looks at and a register somebody can act on.
The tempting shortcut is to find each asset in an image and estimate how far away it looks. That puts assets near where they are, and near is not useful when the output is a safety document. Positioning each one against the building's own captured geometry costs more work and is the only version worth shipping.
02Define
The brief.
Read a fire-safety asset register off a handheld building scan, accurately enough that an operator can check it rather than redo it.
03Develop
What it took
Skills behind it.
Primary discipline plus the support stack.
Skills demonstrated
- ResearchPrimary
Rebuilt the register from scratch rather than patching the existing one, so the new result could be compared against the old. The two diverged, and that divergence was recorded as a finding instead of being reconciled away.
- 3D & SpatialPrimary
Positioned each asset against the building's own captured geometry rather than estimating its distance from a single image, which is the difference between roughly where a thing is and where it actually is. For a safety register, roughly is not useful.
- AI & Machine LearningSecondary
Open-vocabulary detection across the scanner's several camera streams, so new asset types could be asked for in plain language instead of requiring a labelled training set per class, with a second pass triaging candidates before an operator sees them.
- Data PipelinesSecondary
Consolidated repeated sightings into one entity per real object: the same extinguisher appears in many frames, so each detection is a vote on a position rather than a separate asset. How strict that consolidation is turned out to be the accuracy dial.
Develop · Build
How it came together.
- 01
Rebuild rather than patch, so the result can be checked
There was already a curated register to compare against, which made it tempting to correct the existing list. It was rebuilt from scratch instead, because a patched list cannot tell you whether the method works, only whether the corrections landed. The rebuild and the curated version disagreed. That disagreement was written down as a finding rather than quietly reconciled, since a register nobody can audit is worth very little in a safety context.
Research - 02
One object, not a dozen sightings of it
The same extinguisher shows up in frame after frame, so each detection is really a vote on a position rather than a separate asset. Consolidating those votes is what turns detections into entities, and how strict that consolidation is became the main accuracy control: loosen it and the register inflates with duplicates and ghosts, tighten it and the count converges on what had been verified by hand on the floor.
Data Pipelines - 03
The class that was tested and cut
Emergency lights never worked, and establishing why took longer than the four classes that did. Several ways of asking for them were compared, and the most promising one looked clearly better judged on its own: more confident, far less noise. Run end to end it turned out to be finding every round fixture on the ceiling, producing dozens of times more locations than the building actually has emergency lights. It had traded scattered mistakes for confident ones, which is worse, because confident mistakes survive review.
AI & Machine Learning - 04
Proving it was recognition, not positioning
Before blaming recognition, the positioning was tested as the alternative culprit, since a good detector fed by bad geometry fails the same way from the outside. It was not the geometry: filtering on how clean each position was never separated the bad results from the good ones, and pushing that filter harder destroyed the classes that already worked without recovering a single emergency light. The positions were sound and pointed at the wrong objects, which located the fault in recognition and meant no amount of refinement downstream would have rescued it.
3D & Spatial
04Deliver
What shipped.
Four asset classes came out dependable enough to put in front of an operator, each entry positioned against the building's own geometry and paired with a crop so it can be checked by eye. A fifth was tested and cut, which turned out to be the more useful result.
Four classes are dependable enough to hand to an operator, each paired with a crop so an entry can be checked by eye rather than trusted, and the office-wide pipeline now covers a much wider set of asset types. Emergency lights stay out. The honest version is that these detectors cannot separate an emergency light from an ordinary ceiling light because the two look the same, and no amount of rephrasing the request fixes a problem the pixels do not contain. Getting past it needs a human in the loop teaching the difference, not a cleverer prompt, and knowing which of those two you are facing is most of the value.
By the numbers
Classes trusted
operator-checkable
Class tested and cut
on evidence, not instinct
Classes, office-wide
register pipeline