Inspiration

The idea started with a fact that bothered us: the most expensive mistakes in construction are the ones nobody catches until it's structurally too late. A rebar spacing error, a missed tie, a column poured slightly out of tolerance, none of it is visible until the site gets re-opened, and by then the concrete has already cured. Re-pouring a single column can run into millions in materials, labor, and schedule slippage, yet the actual verification step that would have caught it takes maybe two minutes of an engineer's time.

That gap isn't a technology problem. It's a coverage problem. Structural engineers can't physically be on every site, every hour, checking every pour before it goes ahead. So we asked a narrower question: what if the verification didn't need an engineer physically present, just a worker who was already there, mid-task, doing what they'd do anyway?

What it does

The Pre-Pour Sentinel is a hands-free structural QA pipeline designed to run on smart glasses workers already wear on site for safety compliance. For this round, the capture and voice-trigger flow is demonstrated on [phone camera / webcam, tell me which], standing in for the glasses' form factor, with native hardware integration planned for Round 2 once devices are available.

A worker finishes tying rebar, looks at it, and issues a single voice trigger: "Run structural audit." The capture device fires a high-resolution image with GPS metadata attached, no touchscreen, no companion app open, no hands off the material.

That frame gets pushed to a cloud inference pipeline, where a CV model measures rebar pitch directly from the image and checks it against the blueprint's tolerance band:

|d_measured − d_blueprint| ≤ ε

where ε is the tolerance specified on the structural drawing (for example ±3mm against a 150mm nominal spacing).

On a pass, the backend auto-computes the required concrete volume for that pour and clears it for logistics. On a fail, it fires an alert and opens a live audio channel so a remote structural engineer can walk the worker back to spec before the pour is scheduled.

No new hardware SKU planned, no change to the worker's existing routine. Just a trigger phrase standing between a multi-million-dollar rework and a two-minute correction.

How we built it

We didn't start here. Our first architecture was always-on AR: continuous video streaming with live tolerance overlays rendered in the worker's field of view. It looked strong in a deck and fell apart against actual constraints:

Continuous video encoding plus AR rendering would drain glasses-class battery in under an hour.
Holographic overlays assume stable sightlines and a steady mount point. A jobsite gives you neither.
Workers wear thick PPE gloves and have their hands occupied constantly. Any touchscreen-dependent UX was dead on arrival.

That realization forced a rewrite of the whole system, from always-on to trigger-based. The capture device stays idle until a wake phrase fires the routine, takes one high-res photo with GPS tagging, and goes back to sleep. Everything computationally heavy, the CV comparison, the volume calculator, the override channel, runs server-side, keeping the on-device footprint minimal enough for all-day use on constrained hardware.

The stack splits into four layers: hardware access (camera/audio capture layer, built against [phone/webcam] for Round 1, targeting the glasses' SDK for Round 2), a mobile bridging layer relaying captures over the network, a vision-language model handling the blueprint comparison, and a dashboard application giving the remote engineer visibility plus override authority.

Challenges we ran into

Killing our own first build. The always-on AR version was the flashier demo, and it took an honest teardown before we'd admit it would never survive real deployment conditions.

Tolerance isn't a single number. A ±3mm spec on primary structural rebar carries different risk than the same margin on secondary ties. We had to parameterize tolerance per element type from the blueprint metadata instead of hardcoding one global threshold.

Building for failure, not just success. A clean pass is easy to demo. The override path, where a human re-enters the loop mid-workflow on a fail case, needed far more iteration on latency and audio handoff than the happy path ever did.

Designing around hardware we don't have yet. Without physical access to the glasses this round, we had to build the entire capture and trigger layer against a stand-in device, while keeping the interface abstracted enough to swap in the real glasses SDK for Round 2 without rearchitecting the pipeline.

Accomplishments that we're proud of

We killed our own first idea before it could waste our build time. The always-on AR concept was the more impressive demo on paper, and walking away from it after stress-testing it against real jobsite conditions (battery, PPE, sightlines) was harder than building the pivot itself.

We built a full closed-loop system, not a single feature. Voice trigger, GPS-tagged capture, cloud-side CV comparison against blueprint tolerance, an automated material volume calculator, and a live remote-override channel, all working end to end on our current hardware stand-in, not as isolated demos stitched together for a pitch.

We designed the failure path with as much care as the success path. It's easy to show a clean pass. We made sure the fail case, where a remote engineer has to step back into the loop mid-workflow and guide a worker in real time, actually works under latency, not just in theory.

We architected for hardware we don't have yet. Building the capture layer as a swappable module, rather than hardcoding against our stand-in device, means Round 2's glasses integration is a substitution, not a rebuild.

We parameterized tolerance instead of hardcoding it. Recognizing that a ±3mm spec means something different on primary rebar versus secondary ties, and building that into the blueprint-comparison logic rather than shipping a single global threshold, is a small detail we think shows real engineering discipline under hackathon time pressure.

What we learned

The strongest industrial AI systems aren't the ones packing in the most intelligence, they're the ones that disappear into a workflow that already exists. Every hour we spent trying to make the capture layer do more (continuous streaming, live overlays) made the product worse. Every hour we spent making the interaction do less (one phrase, one photo, one decision) made it better. The constraints weren't the obstacle to the idea. They were what made it deployable.

What's next for Pre-Pour Sentinel

Native integration with Meta's smart glasses hardware. Round 1 runs the capture and trigger logic on a stand-in device. Once hardware is provided for Round 2, the next step is integrating directly with the glasses' on-device voice and camera pipeline, cutting latency and moving processing on-device instead of routing every frame through our own bridge.

On-device pre-filtering. Right now every captured frame goes to the cloud for comparison. We want to push a lightweight model onto the glasses' hardware to do a first-pass check (blur, framing, obvious misalignment) before the image ever leaves the device, cutting bandwidth use and giving faster feedback on bad captures.

Multi-site fleet dashboard. Right now the remote engineer view handles one worker, one site. Post-launch, we're building a fleet-level dashboard so a single engineer can monitor pass/fail rates and override requests across multiple active sites simultaneously, which is the actual scaling story for the product.

Pilot deployment with a real contractor. Once we have the actual glasses hardware, we want to run the system on an active, non-simulated pour cycle to get real tolerance-failure data instead of our current test-set scenarios, and to stress-test override latency under real network conditions on-site.

Expanding beyond rebar spacing. The current model checks one structural criterion. Post-launch, we want to extend the blueprint-comparison model to cover additional QA checks (formwork alignment, rebar cover depth, tie spacing) using the same trigger-and-capture pipeline, so the same hardware and workflow generalizes to more of the pre-pour checklist instead of staying single-purpose.

IP and commercialization path. We're working through retaining IP on the CV comparison pipeline while exploring a sales motion built around per-site or per-pour licensing, rather than a hardware sale, since the hardware would be something the customer already owns.