Safety and evidence in Diyar
Cogitave Diyar drives real industrial heat-treatment equipment without depending on a network connection, and this module explains the three mechanisms that let it do so safely and provably. First, a layered, hardware-first fail-safe design where every failure path — a wedged CPU, a blind sensor, a power cut, a lost serial cable — falls back to the heater being off, never the reverse. Second, a request model where the cloud and any remote client can only ask the edge to start a run; the edge alone verifies and can refuse, and there is no primitive anywhere in the system that lets a remote party force actuation. Third, an evidence pipeline that journals every reading locally before it is ever published, chains it so tampering becomes detectable, layers a Merkle history tree on top so completeness can be proven without shipping an entire run's history, and lets the cloud independently reconcile what it received rather than trusting the edge's word. Throughout, the module states plainly which parts of this are built and verified today versus named, not-yet-shipped follow-ups.
By the end of this module, you will be able to:
- Explain the de-energize-to-trip rule and identify which of Diyar's four safety layers are hardware-mandatory versus software defense-in-depth.
- Describe why a comms-loss watchdog is required before any heat output can be driven over a field bus such as Modbus.
- Explain why a remote start from the cloud is a signed, vetoable request rather than a command, and what "config-class only" means for a device shadow's desired state.
- Trace how a reading becomes tamper-evident evidence: journal-before-publish, the SHA-256 hash chain, the per-session Merkle history tree, and cloud-side reconciliation.
- State, in each case, what Diyar has actually built and verified today versus what is a named, not-yet-shipped follow-up.