From observation to evidence

Systems that connect physical events, local processing and records someone can inspect.

A record someone can inspect.

Retain the source context, the observation and the result together. The boundary between them is part of the system's design.

Measured Lanesplitter detector snapshot at source time 168 seconds
Measured snapshot · retained synthetic source at 168s

Fixed-mast observation

Recorded input
316 frames · 5 fps
Result
0 production events
What was missing
Early maneuver history; tracks appeared near re-entry.
Inspect the retained receipt
Source, time, track and decision travel together. An evidence packet preserves the context needed to inspect a result.
Inspect both retained runs

The important work happens outside the data center.

What the work produces

  • Observation and configuration contracts
  • Local processing and durable evidence paths
  • Review tools with explicit provenance
  • Controlled validation and an honest limits report

Respect the physical system

A sensor observes a limited part of the physical world through a particular position, calibration and sampling process. We begin by defining what can be observed and what the proposed decision requires. The architecture needs to preserve uncertainty instead of converting every missing measurement into an invented answer.

LaneSplitter investigates this boundary through controlled traffic scenes and an actual camera-to-evidence pipeline. Its simulation viewer and detector are separate paths. That distinction guides the service: visualization helps inspect a system, while measured sensor evidence evaluates what the system can actually detect.

Keep local work locally accountable

Where the workflow requires it, we design local processing and persistence so the first record does not depend on remote delivery. Storage, resource limits and retry behavior need explicit contracts. Connection loss, disk exhaustion and power loss are different cases that require their own verification.

Setup access and normal operation deserve separate treatment. LaneSplitter's normal operation is outbound-only; a temporary setup interface is deliberately enabled for configuration. The appropriate boundary depends on the device and operators, but it should be a decision rather than the accidental persistence of a development interface.

Preserve enough context to review

A useful event record includes the observations that support it and the configuration under which it was produced. We design review around source material, timeline, identities, measurements, limitations and delivery state. Evidence hashes support integrity checking; they do not establish a signed chain of custody by themselves.

Public demonstrations use reviewed and clearly attributed artifacts. Private operational records remain behind the appropriate access boundary. A sample can teach the shape of the system without exposing a live camera, private location history or confidential material.

Let the evidence choose the next step

Validation begins with controlled cases and useful negative controls. We separate model behavior, pixel inference, runtime performance and field validation. A successful policy case does not establish camera coverage; a passing build does not establish field accuracy. Reports need to make those differences easy to understand.

This is specialist systems design and implementation, not a claim that LaneSplitter is a ready national enforcement platform. Bring the observation problem, available sensors and review requirements. We can define a bounded experiment and the evidence needed to decide what follows.

Leave the system understandable.

Decisions

What was chosen, the alternatives, and the constraints behind it.

Operating knowledge

How normal work proceeds and where a person intervenes.

A next step

A bounded implementation or change plan agreed from the actual system.

Discuss your system