Industrial operations software · 2026

PipeTrace

PipeTrace has grown from a station queue into a broader shop-floor system: receiving a load, checking the quantity, moving it between racks, recording repair work, and giving supervisors a traceable record. I’m also building a separate vision-learning workflow to help with counting. It does not replace the person confirming what arrived.

Visit PipeTrace

PipeTrace mobile station queue showing prioritized work orders — The station-first queue in an earlier interface capture.Existing browser verification image; not a capture of the newer vision-learning work.

My role: Product engineering
Status: Pilot preparation + vision R&D
Contribution: Station workflows, receiving and movement records, supervisor controls, and the newer vision-learning pipeline.

JavaScript
PWA
Supabase
Postgres
Python / ONNX

Here’s the problem

The work has to make sense before the interface can.

The data has to remain useful while the work moves between operators, stations, racks, and occasionally unreliable connections.

What made this difficult

The environment is part of the product.

Station workflows need visible offline and pending states. The newer camera-learning uploads require a connection.
Shared tablets still need clear operator attribution.
Counts, corrections, and movement require an auditable history. A suggested camera count cannot silently change a receiving record.

Decisions that shaped it

I made the hard boundaries visible.

Start at the station

The primary path is organized around the job an operator can work next, not an office-style dashboard.

Treat sync as interface

Pending, synced, failed, and retrying events are product states instead of hidden infrastructure.

Separate fast work from control

Operators get a short station path while supervisors retain reconciliation and configuration tools.

Keep the count accountable

Receiving quantities stay employee-confirmed. The experimental vision path can propose a count or decline to answer; manual marking and review remain available.

PipeTrace administrator screen for machine capabilities — Machine configuration sits outside the operator’s working path.Earlier interface capture, retained for workflow context.

What I built

Enough of the system to test the real seam.

An installable web app with station queues, receiving, repair steps, reconciliation, reporting, and offline-aware event handling.
Supabase and Postgres controls for attributed work, quantity-aware movement, private evidence, and supervisor review.
Separate development work adds authorized photo collection, dataset review, training jobs, model evaluation, and private inference.
A local training and ONNX inference smoke test has run on synthetic input. That proves the pipeline executes—not that it counts real pipe accurately.

What is true now · September 5, 2026

Receiving, movement, and review now form a much more complete workflow. The newer camera and model pipeline exists in local development branches and still needs integration and field validation before release.

What still needs proving

The newer vision and movement work is on development branches, not a verified production rollout.
There is no field-accuracy claim or verified active field model. Real, authorized images and independently checked counts are still required.
Hosted release checks and physical tablet, scanner, and camera acceptance remain open.

Reconcile the release branches, validate the hosted pilot, and test receiving and camera counts against independent ground truth in the approved field scope.