> ## Documentation Index
> Fetch the complete documentation index at: https://docs.enfinitos.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Architecture

> Six layers — Control, Runtime, Spatial, Proof, Metering, Settlement — designed as one operating model rather than stitched together later.

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

<Steps>
  <Step title="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.
  </Step>

  <Step title="Runtime">
    Operate execution across screen estates through a disciplined
    runtime instead of ad hoc orchestration. Handles resolve, pacing,
    delivery, failure modes, and observability.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="Metering">
    Project from raw delivery events into the metered units that
    matter — impressions, dwell time, surface-hours, attention
    seconds — for accountable commercial decisions.
  </Step>

  <Step title="Settlement">
    A versioned path from verified activity into finance, invoicing,
    and settlement discipline. Designed in from the start; never
    bolted on.
  </Step>
</Steps>

## 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:

| Spatial chain layer | Where it sits on the platform spine                                                                                                |
| ------------------- | ---------------------------------------------------------------------------------------------------------------------------------- |
| World Model         | **Spatial** — the declarative world-state half (venues, zones, surfaces, safety envelopes). Mutations are governed by **Control**. |
| Resolve             | **Spatial** — the intent-resolution half; it mirrors the resolve discipline **Runtime** applies on the hot path.                   |
| Proof               | **Proof** — same envelope, same signing, spatial-native receipts.                                                                  |
| Metering            | **Metering** — dwell, occupancy-weighted exposure, attention-eligible seconds as pure projections over proof.                      |
| Commerce            | **Settlement** — pricing, packaging, caps, and revenue-share semantics live in the spine's settlement layer.                       |
| Settlement          | **Settlement** — always a projection of core settlement, never a parallel ledger.                                                  |

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](/concepts/substrate-model) for the
full list.