Save the record before sending it

An edge system can observe something important while the network is unavailable. If remote delivery is the only moment at which that observation becomes a durable record, the system's ability to remember depends on a service it does not control. LaneSplitter makes a different boundary explicit: evidence is created and stored locally before the outbound delivery step. The roadside node owns the first record. Delivery copies an existing record rather than inventing the only one.

That ordering has a consequence people often miss. If the local write fails, simply sending the record anyway would create a remote-only outcome that breaks the chosen model. The current runtime skips that send. This does not make the failure harmless. It makes the failure mode explicit and keeps the system from quietly switching its source of authority at the worst possible moment. Local storage health therefore belongs in the operational story, not just the database code.

Capturing observations and waiting for an HTTP response have different timing requirements. The runtime separates the synchronous detection path from asynchronous outbound delivery. Its local store records send status, attempt history and outcomes. A fast notification path can tell the uploader about new evidence, but that notification is not the evidence itself. If the notification channel fills, a periodic scan can still find records that were already persisted.

The distinction is useful in many operational systems. A queue message can be a pointer to durable work rather than the sole copy of the work. But it is not enough to draw two boxes and call them independent. The shared storage, transaction boundaries, retry selection and lifecycle all need to be understood. A delivery worker that blocks the same critical resource as capture can still damage continuity even when it runs in a different task.

The words 'automatic retry' can hide an unbounded promise. A real system needs a retry policy, an attempt limit, a way to see the backlog and a decision about exhausted records. The current LaneSplitter configuration has bounded attempts. The website model uses an explicit small limit so a visitor can inspect the transition into an exhausted state. It does not animate an endless stream and imply that every record will eventually arrive regardless of conditions.

A reconnect is also not a proof of exactly-once delivery. An acknowledgement can be lost after a receiver accepts a record, leading a sender to try again. Event identity and the receiver's handling of duplicates matter. Claims about delivery semantics should describe both sides of that exchange and the actual failure tests. Local persistence is a valuable boundary, but it is not a substitute for an end-to-end protocol.

A disconnected node still consumes disk, memory and processing time. Evidence images, clips, databases and logs compete for finite resources. A model that keeps accepting records forever is teaching the wrong lesson. Our interactive explanation has a visible capacity and rejects additional records when it is reached. That is a declared model boundary. It is not a claim that the production node already implements that exact capacity policy.

Connection loss, disk failure and power loss are distinct experiments. A successful replay of one does not validate the others. Before describing a system as resilient, specify what keeps working, for how long, under which resource limits and with what recovery procedure. For LaneSplitter, global disk quota behavior and runtime throughput under evidence bursts remain work that needs its own measurements. The architecture is the beginning of that investigation, not its result.

Operators need to distinguish waiting, retrying, delivered and exhausted. They need a record identity and enough history to understand why a state changed. A total labelled 'success' loses the detail needed when a particular event matters. A useful system can answer what was stored, what was attempted, what the receiver reported and what remains unresolved. The first version of that view can be modest if those distinctions are already reliable.

This is the engineering value behind the website's sculpture opening and reconnecting. The visual sequence is an explanation of separated responsibilities. It is not a benchmark, a production health dashboard or a demonstration against live infrastructure. The useful question is what contract each piece carries, and which evidence would be needed to prove that the real implementation honors it under failure.