Identify what must survive

Separate recent measurements, configuration, event state and the operating system's own storage activity. Raspberry Pi's technical paper explains cached writes and orderly shutdown as examples of resilience concerns. That does not mean every interruption corrupts every computer. Obtain the supported behavior of the installed storage and application, including any documented power-loss protection rather than assuming it from a rugged enclosure.

Define the supported shutdown and restart boundary

Ask which warning or hold-up input the device supports, how shutdown completion is indicated and what initializes after power returns. A battery with enough nominal energy does not prove that these controls exist or are coordinated. This page does not prescribe filesystem changes, recovery commands or a universal shutdown time. Those belong to the device and application maintainers.

The owner's accepted recovery record should identify the last retained and first new valid record. A computer that boots normally can still leave uncertainty about the final transaction before power was lost.

Verify records as well as powered operation

Acceptance should use owner-approved events and check data continuity, retained configuration and application recovery against declared expectations. Keep failed writes or uncertain records visible instead of filling gaps as valid measurements. Include the shutdown/restart input profile and required duration in the wind-system enquiry. Wind generation may contribute energy, but it does not establish a reliable hold-up supply during a particular interruption. No MARSTON computer-management, storage-protection or data-integrity feature is confirmed by this general service requirement.