Should a robot keep the near-miss, or only the event summary?

I’m deploying mobile robots around people, and I think deleting every near-miss buffer is the wrong default. A short, event-triggered raw window can show the failure an event summary hides: glare, an occluded person, lidar dropout, bad timing, or a mistaken classification. That matters for root-cause work and possibly improving the fleet.

But this should not become a surveillance archive. Process and mask locally where possible, provide clear notice and consent where feasible, encrypt the buffer, publish a short retention period, and delete automatically unless designated safety or engineering staff formally preserve it. Retrieval should be role-based, logged, and limited to a genuine investigation. The serious counterargument is that “anonymized” summaries can still carry re-identification risk, while raw footage creates a tempting archive.

Would you trust an anonymized incident log, or insist raw sensor data never leave the robot?

I’m broadly with the short buffer, but “anonymized” needs a lot of skepticism. A timestamp, route, clothing, and unusual movement can identify someone even after faces are blurred. The default should be local extraction, with raw export requiring a documented safety case—not merely an engineer wanting more training data.

The strongest practical argument is that near-misses are useful precisely because they expose hazards before injury. I’d separate safety investigation from model improvement: the former may justify preservation, while the latter should normally receive derived features or carefully reviewed samples.

Role-based access is necessary but not sufficient. I’d want tamper-evident access logs, a retention clock that cannot be casually reset, and a separate approval for exporting anything off the robot. Otherwise “temporary debugging data” has a predictable way of becoming permanent.

Consent gets messy in a warehouse or lobby. People may technically be notified but have no meaningful alternative. That argues for minimizing collection and making the robot’s behavior legible, not pretending a sign turns raw footage into harmless product telemetry.

The operational question is who responds at 2 a.m. If nobody owns the queue, buffers either vanish before review or get copied everywhere “just in case.” Define the trigger, reviewer, escalation path, and deletion job before deployment.

Local processing should be the architecture, not a policy aspiration. Keep the ring buffer on-device, produce a compact event record, and require an explicit signed action to release the raw window. If connectivity fails, safety evidence should not depend on cloud availability.

I’m less comfortable with automatic capture than the opening post. A near-miss threshold is itself a model, and a bad threshold can quietly collect ordinary pedestrian footage. I’d rather see a conservative summary by default, with raw retention enabled only for validated safety classes.

This will become a procurement issue, not just an engineering setting. Customers will ask where data is stored, who can retrieve it, and whether deletion is auditable. A documented short retention policy is easier to approve than a vague promise that footage is “only for debugging.”

Small wording point: privacy guidance supports minimization, local processing, access controls, selective disclosure, and destruction according to policy, but it does not settle the exact buffer length or consent model here. Those choices still need a documented risk assessment.

If the robot cannot explain why it nearly hit someone, keeping one brief forensic window seems sensible. Keeping everything forever because storage is cheap is not engineering; it is procrastination with a hard drive.

I’d retain synchronized sensor data, not just video. Many perception bugs are timing and fusion failures, so a pretty clip may prove nothing. Still: fixed TTL, encryption, audited retrieval, and no training reuse without a separate review.