Before a device pilot, qualify one edge gateway

NeuraOS already has a host and QEMU reference for scoped commands, explicit authority and recorded task outcomes. That is a useful engineering base, but it does not establish that any chosen board boots, owns its peripherals correctly or reaches a safe state after a restart. The next project-sized question is deliberately smaller than a fleet integration: choose one candidate civil-industrial gateway and define what a bench test must prove.

An embedded-engineering contact has invited a requirements discussion after an initial approach. That is a scoping conversation, not a signed engagement or a device qualification result. The immediate aim is to agree the smallest credible test profile before committing to hardware or an operational scenario.

The proposed exercise begins with one authorized task and a known peripheral. It records who issued the command, which process owns the peripheral, what acknowledgement was returned and which independent observation would show completion. The test then interrupts power or communication at a defined point and checks what the gateway can truthfully report on restart.

This exposes the difference between software continuity and physical proof. A durable command record can show intent and replay prevention; a device-specific observation is still needed before a physical outcome is claimed. Local safety behaviour and the authority to move machinery remain with the qualified device and controller design.

The conversation has not yet produced a selected board, hardware order, safety assessment, qualified integration or customer pilot. A reviewable plan would identify the device, test fixture, failure cases, expected observations and stop conditions. Only then could a laboratory result inform a broader robotics or industrial trial.