{
  "uid": "cogitave.learn.diyar-safety-and-evidence.the-cloud-cannot-actuate",
  "kind": "moduleUnit",
  "href": "/modules/diyar-safety-and-evidence/the-cloud-cannot-actuate/",
  "title": "Why the cloud can request but never actuate",
  "summary": "",
  "type": null,
  "products": [],
  "roles": [],
  "levels": [],
  "subjects": [],
  "headings": [
    "Where a run can be started",
    "The signed, vetoable remote-start request",
    "Authority is one-directional",
    "The device shadow: desired state is config-class only",
    "Why the boundary is drawn here"
  ],
  "source": "Diyar's cloud and mobile clients can ask an edge device to start a run, but nothing in the protocol lets them force it. This unit covers the shape of a remote-start request, why the cloud holds no actuation primitive at all, and the one config-only exception carved out for the device shadow.\n\n## Where a run can be started\n\nAn operator starts a run at the kiosk on the LAN, or remotely from a web or mobile client. Both paths reach the same one door: the edge validates every request locally before anything is energized.\n\n## The signed, vetoable remote-start request\n\nA remote start is a **signed, device-bound, nonce- and TTL-limited request** that the edge independently validates and **may veto** — heater actuation is not something the cloud protocol can represent directly. Every route is authenticated and tenant-scoped, but authentication only gets a request to the edge's own door; it is the edge, not the cloud, that decides whether the door opens.\n\nThis holds for automated callers too: any tool that wraps the remote-start path is exactly that — a wrapper over the same signed contract the edge already verifies and can refuse. Adding a caller never adds a second way in.\n\n## Authority is one-directional\n\n- No cloud primitive energizes anything: the cloud can request, advise, and mirror state; by design, it holds no primitive that turns heat on.\n- There is deliberately no broadcast actuation primitive anywhere in the system — mass remote ignition is named as the top threat the architecture defends against, not a capability it offers.\n- Even a fully compromised cloud component still only reaches the edge's verify-and-veto gate; it cannot skip it.\n\n> [!IMPORTANT]\n> This is a design invariant, not a today's-implementation detail: the accepted architecture blueprint states that the signed, edge-verified, edge-vetoable session start is the *only* path to energy, \"for agents too\" — nothing added later is allowed to introduce a second one.\n\n## The device shadow: desired state is config-class only\n\nDiyar keeps a device shadow with a reported half and a desired half (plus a version, for optimistic concurrency). This is deliberately different from how some other IoT platforms use a device twin's desired state:\n\n- **Desired is config-class only** — things like the OTA update channel, the sampling interval, or log verbosity — drawn from an allow-list derived from the device's profile.\n- Writing a desired value is **never** actuation. The edge treats desired state purely as advisory configuration that it acknowledges back into reported state.\n- Actuation stays exclusively on the signed session-start path with edge veto, full stop.\n\nAs of the most recent delivery record, the cloud-to-device half of this is wired for on-prem deployments: a config-class desired value is published to the device over the local broker, and the edge **re-validates every delivered key, fail-closed, against the same config-class allow-list** before applying it — so even a broker an attacker fully controls cannot push anything past config-class.\n\n> [!NOTE]\n> A separate, write-only \"advisory commands\" path was considered and then removed from the contract rather than kept around unused — one fewer door is safer than a door nobody uses. Delivering desired state onto AWS IoT's shadow mechanism is a documented follow-up, not yet built; the edge side needs no change when it lands, because it already subscribes to that channel.\n\n## Why the boundary is drawn here\n\nThe recurring theme across the request path and the shadow is the same: every surface that reaches the cloud terminates in something the edge can refuse or ignore, never something the edge is compelled to obey. A signed request can be vetoed. A desired-state write can only ever mean configuration. Authority over energy stays local to the device that has to answer for what it did — which is also why the evidence it produces has to be trustworthy on its own, covered next.\n",
  "partOf": "cogitave.learn.diyar-safety-and-evidence",
  "durationInMinutes": 5,
  "quiz": null
}