Edge Devices on Deevnet IoTaaS

ADR-0038: Tenants Update Their Own Devices

Mon, 01 Jan 0001 00:00:00 +0000

ADR-0038: Tenants Update Their Own Devices, Through Services They Already Have #


Status	Accepted (2026-10-17): already how the platform works. `eds` updates its three devices over the air through the broker, under its own ADR-0035, with no platform service of its own
Date	2026-10-17
Scope	How new firmware reaches a tenant’s edge device once the device is in place, and where the image is kept. Not how the firmware is built or signed ( ADR-0011 §4, unchanged), and not how a device reaches a tenant’s service in general ( ADR-0020, unchanged).
Extends	ADR-0011: answers the hosting bullet of open question 6, “where OTA images are hosted so the IoT segment can reach them”. The question’s other bullets stay open.
Amends	ADR-0012 §3: “firmware release hosting” and “OTA” leave its list of later platform layers. “Jobs” stays.
Related	ADR-0032 (every device belongs to a tenant), ADR-0034 (the same rule for workloads)

Context #

Firmware is already the owner’s. ADR-0011 §4 has firmware built and released by its owner, from its owner’s repository, and keeps signing keys out of the substrate vault. ADR-0032 makes that owner always a tenant.

ADR-0035: A Fixed Address for a Tenant's Device

Mon, 01 Jan 0001 00:00:00 +0000

ADR-0035: A Fixed Address for a Tenant’s Device #


Status	Accepted (2026-10-07), at the close of CHG-0044, which built it.
Date	2026-10-06
Scope	How a tenant’s device gets the same address every time on the device network, and what its name is. Not what may reach the device ( ADR-0020, unchanged), and not its identity ( ADR-0031 §6).
Amends	ADR-0011 open question 2 and ADR-0012 §3 and open question 3: “leases from the IoT pool” becomes “leases from the pool unless its tenant reserves it an address”. “No substrate host record” stands.
Related	ADR-0032 (every device has a tenant), ADR-0004 (a tenant’s names are in its own zone), ADR-0009 (inventory owns the segment), ADR-0033 (a tenant’s code restores it)

Context #

A tenant’s device leases whatever address the pool gives it. ADR-0011 decided that on 2026-09-15: an application-owned device takes no substrate host record, leases from the IoT pool, and is named in its owner’s zone. The reasoning was that a device’s identity is its credential, not its address, and that device churn should never become a substrate commit.

ADR-0032: Every Edge Device Belongs to a Tenant

Mon, 01 Jan 0001 00:00:00 +0000

ADR-0032: Every Edge Device Belongs to a Tenant #


Status	Accepted (2026-10-03): already how the platform works. The Deevnet API registers devices only under a tenant, and mabell is a tenant with devices and no workload.
Date	2026-10-03
Scope	Who may own an edge device. Not where a device attaches, or how it reaches services ( ADR-0011 §1–§4, unchanged).
Amends	ADR-0011 §1, the Ownership row: “the application, which may or may not be a tenant” becomes “the application, through its tenant”
Related	ADR-0012 (devices registered through the API), ADR-0031 (tenant device identity)

Context #

ADR-0011 split a device’s concerns across four owners, and gave ownership to “the application, which may or may not be a tenant”. That left room for a device whose owner is something other than a tenant, without saying what that something would be.

ADR-0020: Direct Device Access to Tenant Services

Mon, 01 Jan 0001 00:00:00 +0000

ADR-0020: Direct Device Access to Tenant Services #


Status	Accepted
Accepted	2026-09-19. What is accepted is a contract, not a mechanism: the capability, where authorization lives, and what it must never become. The service that implements it is future work and needs no decision here.
Date	2026-09-18
Amended	2026-09-18 and 2026-09-19, both before acceptance. See What this record stopped saying.
Scope	How an application-owned device consumes a service belonging to its application when the broker’s publish/subscribe semantics do not fit, and where the authorization boundary sits
Extends	ADR-0011 — answers its open question 5, “How does a device reach a service a tenant exposes directly?”. ADR-0012 — which built the rendezvous shape for publish/subscribe and, until amended, read as though that were the only shape. Both stay `Accepted` and unchanged in substance.
Related	ADR-0013 §2, ADR-0019, CHG-0007, Network Segmentation §8–§9

Context #

ADR-0011 settled that an application owns its devices, the platform attaches them by trust class, and they reach their application through scoped platform services. It then opened a question it never numbered:

ADR-0011: Edge Devices Are Application-Owned and Platform-Attached

Mon, 01 Jan 0001 00:00:00 +0000

ADR-0011: Edge Devices Are Application-Owned and Platform-Attached #


Status	Accepted; §1’s Ownership row amended by ADR-0032: every edge device belongs to a tenant, which may have no workloads. Open question 2’s “leases from the IoT pool” amended by ADR-0035: a tenant may reserve its device a fixed address.
Accepted	2026-09-15, once its four open questions were answered. Questions 1–3 were settled by the operator on 2026-09-15 ( CHG-0008 Step 9’s controller work made the platform side real); question 4 was settled on 2026-09-14.
Date	2026-09-13
Amended	2026-09-19, reconciling against ADR-0019 and ADR-0020. An editing error had deleted the heading that numbered two further open questions, leaving them orphaned — they are now 5 (tenant ingress, answered by ADR-0020) and 6 (the firmware supply chain, still open). Five statements overtaken by CHG-0013 and by ADR-0012 §8 are corrected in place. The decision is unchanged.
Extended by	ADR-0019: Tenant Layer 2 at the Access Edge — why a device does not join its tenant’s network. ADR-0020: Direct Device Access to Tenant Services — how it reaches that tenant’s services instead, answering open question 5. Both leave this record `Accepted` and unchanged in substance. ADR-0038: Tenants Update Their Own Devices — a tenant updates its own devices through services it already has, and the platform hosts no images, answering open question 6’s hosting bullet.
Validated	2026-09-14, read-only, before acceptance. See Validation
Scope	Who owns a physical device an application uses, what the platform knows about it, which network it joins, and how it reaches the services it needs
Depends on	ADR-0010: Tenants Consume Platform Services
Related	ADR-0001: Tenant Network Fabric, ADR-0003: Tenant Egress on a Single-Member Fabric, ADR-0009: Network Device Configuration Is Inventory-Owned and Controller-Applied, ADR-0012: IoT Platform Services Through a Deevnet API and Terraform Provider

Context #

Physical microcontrollers have been treated as substrate IoT devices. The treatment conflated concerns that answer to different owners: