Trust and accountability

Trust and Accountability

Flashing microcontroller firmware changes persistent device software. The project therefore treats documentation, evidence, review, and recovery as part of the product—not as optional release notes.

What a trustworthy release shows

flowchart LR
  A[Public source and build instructions] --> B[Reproducible build]
  B --> C[Image checksum and size]
  C --> D[Physical-board test evidence]
  D --> E[Recovery and rollback evidence]
  E --> F[Reviewed release manifest]
  F --> G[Owner-authorized flash]

Loading

Before using a release, a reader should be able to answer:

• Which exact board and revision does this image target?
• Which source revision and pinned toolchain produced it?
• What image checksum identifies the artifact?
• What was tested on physical hardware, and what was not?
• How can the device be recovered if the normal image fails to start?
• Which capabilities, radios, sensors, transports, and data flows are enabled?
• Where are the known limitations and compatibility boundaries recorded?

Evidence without exposing users

Release evidence should be useful without disclosing credentials, network topology, private device identifiers, personal location, or raw sensor data. Use redacted logs, reproducible commands, checksums, board revision details, and clear pass/fail observations. Never add secrets to wiki pages, issues, pull requests, firmware defaults, or release artifacts.

Accountability after release

If a defect is found, document the affected board profiles and releases, describe the safe mitigation or recovery path, and publish a corrected release with a new manifest and evidence trail. Do not silently replace an image at an existing release reference.