Skip to main content
EnfinitOS is built around six layers, designed as one operating model rather than stitched together later. Each layer has a single responsibility, and the contracts between them are versioned and public.

​
The six layers

1

Control

Define who can run what, under which rules, and with which explicit rollout and promotion permissions. This is the policy plane — RBAC, rights, scopes, approvals.
2

Runtime

Operate execution across screen estates through a disciplined runtime instead of ad hoc orchestration. Handles resolve, pacing, delivery, failure modes, and observability.
3

Spatial

Substrate-agnostic by design — 23 substrates from DOOH to drones are first-class in the type system. Adding a new substrate is configuration, not a rewrite.
4

Proof

Every delivery, activity, and operating action is signed, hash-chained, and verifiable offline. This is where the open-source auditor draws its source material from.
5

Metering

Project from raw delivery events into the metered units that matter — impressions, dwell time, surface-hours, attention seconds — for accountable commercial decisions.
6

Settlement

A versioned path from verified activity into finance, invoicing, and settlement discipline. Designed in from the start; never bolted on.

​
Two views of the six layers

If you have read the platform’s architecture decision records or the spatial SDK surfaces, you will have met a second six-layer chain:
World Model → Resolve → Proof → Metering → Commerce → Settlement
These are not two competing architectures. The chain above is the spatial substrate’s internal layering (ADR-0001) — a self-similar expansion of the platform spine for digital objects placed into governed physical space. It maps onto the spine like this: In short: the spine’s single Spatial layer expands into World Model + Resolve when you zoom in, and the spine’s Settlement layer encompasses both Commerce and Settlement in the spatial chain. Proof and Metering mirror one-to-one.

​
How they interact at runtime

A delivery event walks the layers from bottom to top:
  1. The render SDK reports a delivery event to Runtime.
  2. Runtime asks Control whether the underlying rights basis still authorises this delivery.
  3. If yes, Runtime asks Spatial to confirm the substrate-specific constraints (geofence, altitude, audience, consent).
  4. If yes, Proof signs the event and folds it into the tenant’s hash chain.
  5. Metering projects the event into the metered units the contract is denominated in.
  6. Settlement reconciles metered units against the contract on a periodic batch.

​
What separates EnfinitOS from a CMS or analytics dashboard

A CMS stores files. An analytics dashboard visualises results after the fact. EnfinitOS does neither — it is the policy-driven runtime that owns execution posture, rollout discipline, proof, metering, and operating control. That posture is enforced by types, not docs. A substrate that is not first-class in the type system cannot be governed; conversely, once a substrate is added to the type system, every layer above respects it without further wiring.

​
Why “substrate” rather than “channel”

A channel is a marketing-side abstraction — “social”, “OOH”, “CTV”. A substrate is an engineering abstraction — the surface a piece of content is rendered on, with its physical and regulatory properties: a DOOH panel, a wrist-worn complication, a vehicle HUD, a Remote-ID-broadcasting drone. The substrate model captures what the engineering layer actually has to constrain. See /concepts/substrate-model for the full list.