Transportation systems that understand what they see.
Tollscopic builds AI-native transportation systems for toll collection, traffic-camera safety, and commercial-carrier identification. From the roadside to the back office, we observe the physical event, preserve the evidence, learn from it offline, and emit structured records your existing systems can act on, audit, and replay.
One pattern under every product: evidence first, outcome second.
Tollscopic products start by preserving the physical observation. The product output is never just a string or a score. It is a structured event with evidence references, provenance, confidence, and downstream usage semantics.
Inference is the visible part. Learning is the system.
Traditional tolling and ITS systems treat AI as a new detector bolted onto an old pipeline. Tollscopic is built around the loop after the pass: production evidence becomes labels, replay material, offline evaluation, and the basis for controlled model and scorer promotion.
Reviewed and labelled examples improve models, prompts, thresholds, and scorers.
High-confidence production evidence and reviewer feedback expand useful training and evaluation sets.
Changes are tested against stored evidence before they affect production behavior.
Model, scorer, and config changes move forward only when offline evaluation supports them.
Trajectory correlation and classification improve from replayed edge cases, disputes, and audit outcomes.
Incident strategies improve from operator adjudication, hard negatives, coverage states, and camera drift.
Carrier scoring improves from labelled difficult reads, catalog misses, ambiguous candidates, and OCR-confusion patterns.
Confidence comes from the system around the model.
AI-native infrastructure only matters if the production system around it is rigorous. Tollscopic products are designed to expose the health of the evidence chain, not just the final output.
Device health, feed quality, event flow, queue depth, confidence distributions, refusal states, and downstream delivery surface as product signals, not just devops metrics.
Roadside systems need buffering, idempotent publishing, replayable evidence, and clear degraded states rather than silent failure.
Model, scorer, catalog, prompt, schema, and configuration changes are versioned, replay-tested, and promoted only after evaluation.
Reviews, disputes, adjudications, catalog misses, coverage gaps, and hard cases feed the learning and QA loop.
Roadside tolling built around trajectories, not lane assumptions.
Gantry-mounted sensing, edge compute that tracks each physical vehicle through the toll zone, sensor evidence bound to that trajectory, classification, audit, and transactions delivered to the back office already in place.
Gantry-mounted sensing and edge compute reduce dependence on pavement cuts and device-specific lane chains.
The vehicle path becomes the key that binds plate, tag, axle, class, and video evidence.
Every transaction points back to the evidence and versions that produced it.
Three products. One operating model.
Tollscopic applies the same evidence discipline to three adjacent roadside problems: collecting tolls, understanding camera scenes, and identifying commercial carriers when the usual billing signals fail.
Toll transactions from physical vehicle trajectories.
Tollscopic Tolling turns gantry-mounted sensor evidence into auditable toll transactions. It tracks each vehicle through the toll zone, attaches plate, RFID, axle/classification, and video evidence to that trajectory, and emits structured records to the back office already in place.
Explore Tolling →Existing camera feeds, coverage-honest incidents.
VESU watches existing traffic cameras, learns what each camera sees, detects safety-relevant roadway conditions, and reports both incidents and coverage gaps. The output is an evidence-backed incident package that lands in the TMC workflow operators already use.
Explore VESU →Carrier identity when plate and transponder paths fail.
DOT# reads USDOT and carrier markings from side-fire video, resolves the carrier against FMCSA records, and emits confidence-scored identity events with explicit refusal classes. Built for the commercial-vehicle residue a toll authority can see but cannot invoice through the usual path.
Explore DOT# →The proof is how the system behaves when evidence is messy.
Roadside systems fail in the long tail: dense traffic, occluded plates, missed tag reads, frozen camera feeds, glare, rain, damaged carrier markings, ambiguous classes, and incomplete catalog evidence. Tollscopic is designed around those cases.
Transactions, incidents, and identity events point back to the frames, sensor inputs, versions, and decision path that produced them.
When evidence is not strong enough, the system preserves the event and says why it did not act. Silence is a defect.
Production evidence feeds offline evaluation, labelled review, hard-case discovery, and controlled model and scorer promotion.
The operational systems already in place receive structured events. Tollscopic does not arrive demanding a new portal by default.
Start with the problem in front of you.
Different visitors arrive with different pain. Three columns. One click to the right page.
One evidence architecture, deployed three ways.
At the edge, systems capture the evidence that must stay close to the road. In the cloud, heavier reasoning, catalog lookup, scoring, event storage, replay, and integration happen in a controlled service. The result is not one monolithic product. It is one evidence architecture applied three ways.
Uncertainty is not an exception. It is part of the event.
Tollscopic does not claim that hard cases disappear. The system carries uncertainty forward as structured state, so it can explain, abstain, replay, train, and improve.
Bring us the roadside problem.
Whether you are modernizing toll collection, exploring traffic-camera safety automation, or trying to recover commercial-vehicle violations the plate path cannot close, the useful first conversation is the same: what evidence do you have, what decisions depend on it, and where does the event need to land?