How a device becomes a Diyar solution

Diyar turns a physical device into a certified solution through layered signed documents and firmware-compiled registries, not through custom code written per customer. A signed device profile configures the edge's hardware at boot; a certified verdict engine - a frozen product engine or one of the generic function blocks - decides pass or fail; and a three-document app package computes, offline, exactly what a device is authorized to observe, operate, or actuate. The module walks each of these three layers as they exist in the Diyar edge platform today, closes with one worked solution (ISPM-15) built entirely on that machinery, and states plainly where a capability is proven only against internal example fixtures rather than a field deployment - because that distinction is part of what you need to evaluate the product honestly.

By the end of this module, you will be able to:

• Describe what a signed device profile configures at boot, and explain why the edge refuses to start on an invalid, unsigned, or mismatched profile.
• Explain how the HAL seam (TempSource / RelayBank / MonotonicClock) lets the same platform drive local hardware or a Modbus (TCP or RTU) field device without touching the safety-critical core.
• Explain why the CERTIFIED_ENGINES registry, not a valid signature alone, is what lets a new process rule run - and how the generic engines let a genuinely new product ship as pure signed data.
• Describe the three documents in a Diyar app package and how their offline intersection (A ∩ B ∩ C) computes a device's effective authority.
• Distinguish deploying an app (signing three documents) from certifying its ability to actuate hazardous output (a firmware release and certification event).

Prerequisites

• Comfort reading a Rust trait signature and a JSON object; no Rust programming experience is required.
• Familiarity with the general idea of signed/verified artifacts (code signing, detached signatures) is helpful but not assumed.
• No Diyar license, account, or deployment access is required - this module is architectural and conceptual.

Units

1. 01The signed device profile8 min
2. 02Verdict engines and the certified registry8 min
3. 03The app package and the permission model8 min
4. 04The ISPM-15 solution6 min
5. 05Knowledge check5 min
6. 06Summary3 min

Related

• 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. Module5 units26 min
• Understand Cogitave Diyar Cogitave Diyar is the platform layer of the Cogitave cloud: multi-tenant management for distributed field devices that have to keep working, and keep proving what they did, even when the network is unavailable. This module introduces the problem Diyar solves (a regulated, unattended field process — starting with ISPM-15 wood-packaging heat treatment — that must run and produce trustworthy evidence with no network), the edge-autonomous model that solves it (the device is the sole authority over safety and evidence and runs fully offline), the platform/solution split that lets a new regulated process plug in as a certified verdict engine plus a signed device profile rather than a fork, and a tour of the architecture from the edge binary through the cloud/on-prem control plane to the client surfaces — including an honest account of what is still early (the kiosk and portal UIs) and what is still gated pending hardware validation. Module5 units27 min
• Glossary The terms used across Cogitave documentation and training, defined once - agent kernel, capability grant, provider driver, sandbox, sovereign unikernel, MCP, evidence, and the words that are easy to assume. Documentation