One more identity stream. No lane rewrite.
Tollscopic DOT# emits commercial-vehicle carrier events that can be joined downstream to existing violation transactions by site, lane, time, and context. The lane controller, plate camera, transponder system, and back office stay in place.
Tollscopic DOT# events sit beside your tolling stack.
Two streams, one downstream correlation. The existing transaction stream is not touched. The DOT# event stream is additive. The join happens after both streams exist — read-only, downstream of the lane.
Tollscopic DOT# does not need to own the lane.
The lane controller, ANPR cameras, transponder readers, and back office continue unchanged. DOT# adds a parallel event stream and a downstream correlation step. Integration happens after the lane, not inside it.
Unchanged. Tollscopic DOT# does not write into the TCS database or compete with the lane logic.
Unchanged. Tollscopic DOT# is a parallel sensor focused on commercial-vehicle door panels.
Unchanged. AVI/RFID continues to handle the primary identity path.
Unchanged. Tollscopic DOT# adds a stream the back office (or a thin overlay) can consume.
How the two streams meet.
The correlation overlay joins existing violation transactions with Tollscopic DOT# identity events by structural attributes. Ambiguous multi-match cases are kept explicit; the overlay never silently picks one.
What the hydrated queue enables.
The output of the overlay is a stream of carrier-named violation records — and named refusals. From there, deployment policy decides what downstream systems are allowed to do.
Attach a carrier candidate to violation records that the existing path could not resolve. The default audit-friendly use.
Verified events can flow into a review queue with full evidence — frames, fields, scoring rationale, version tags.
Catalog-miss events surface unknown-carrier patterns that may indicate stale snapshots or out-of-region traffic.
A neutral audit of the commercial-vehicle residue, even before any downstream action is taken.
Events leave through the path that fits the operator.
Event delivery is implementation-specific. The design point is that events are emitted from an outbox and can be delivered to the customer's chosen downstream path. The patterns below are the common ones.
HTTPS endpoint receives events as they emit. Most familiar pattern for modern back offices.
Periodic batch of events to S3 or equivalent. Friendly to back offices with batch ingestion.
Kafka or similar. For operators with event-driven downstream systems.
Scheduled file drops over SFTP. The legacy-friendly pattern when needed.
An event stream beside your tolling stack.
No critical-path lane replacement. The Tollscopic DOT# event stream is additive; the correlation overlay is read-only. The question is which delivery pattern fits your back office.