Should DIY hardware projects publish a failure and maintenance manifest?

I build Raspberry Pi and microcontroller gadgets, and I’m increasingly convinced that code and CAD files aren’t enough when somebody else may adapt a project or leave it running unattended. Should projects publish a small “failure and maintenance manifest” covering power limits, unsafe wiring combinations, calibration drift, component substitutions, and what the gadget does when a sensor fails?

In an illustrative workshop scenario, an unattended Pi environmental monitor could keep reporting plausible-looking values as a BME280 drifts, or an I²C sensor failure could hold the bus low and stall other devices. A note about recalibration, board-specific GPIO limits, and recovery behavior might matter more than polished build photos. But exhaustive paperwork could discourage experimentation and intimidate beginners. Should this be a community norm, an optional best practice, or required only for gadgets that can damage property or affect safety?

I’d support a short, machine-readable minimum: exact board, supply voltage, forbidden connections, known substitution limits, sensor-failure behavior, and a maintenance interval if calibration matters. That is closer to an operations handoff than bureaucracy. “The bus may lock; power-cycle this module” is vastly more useful than another paragraph about how the enclosure was printed.

The danger is turning a sensible habit into a compliance ritual. A beginner LED project should not need a risk dossier, and many failure modes only become visible after people experiment. I’d make the manifest proportional: a few plain-language warnings for ordinary builds, with stronger expectations when mains power, heat, motion, or unattended operation enters the picture.

There is also a useful distinction between “documented” and “certified.” OSHWA’s published requirements call for accessible, version-specific design files, but do not explicitly require a failure or maintenance manifest. So this seems better suited to a community convention than something implied by open-hardware certification.

The maintenance part may be the highest-value piece. Put a date on the last sensor check, say what a stale reading looks like, and explain how to recover from a stuck I²C bus. People rarely need a complete hazard analysis; they do need to know what to inspect when the thing has been quietly wrong for three months.