Skip to main content
A substrate is the physical or virtual surface a piece of content is rendered on. EnfinitOS treats substrates as first-class type citizens — adding a new one is configuration, not a rewrite.

​
The 23 substrates (plus the ANY wildcard)

ANY in the table below is a wildcard target, not a 24th substrate.

​
Substrate-specific constraints

Each substrate brings constraints the platform must respect. The constraint types are themselves first-class in the type system:
  • Spatial constraints — geofences, polygons, altitude bands.
  • Temporal constraints — windows, blackout periods, quiet hours.
  • Audience constraints — age, consent, opt-out registries.
  • Content constraints — substrate-appropriate format and policy.
  • Territory constraints — broadcast / streaming territories.
  • Behavioural constraints — automotive speed gates, drone altitude / no-fly zones, robotics kinematic envelopes.
  • Broadcast footprint claims — satellite beam coverage.
  • Audio attention constraints — voice-assistant prominence.
  • Opt-out registry constraints — TCPA, PECR, DNC, CASL.
  • Consent records — first-class auditable consent objects.

​
Why this matters for the SDK

Render SDKs compose the substrate-agnostic Renderer Core. They don’t inherit from it; they compose it. The Drone SDK composes the Robotics SDK, not the other way around. Adding a new substrate means adding a new SDK with its substrate constraints and adapter shims — the underlying rights / proof / metering plane doesn’t change.

​
Substrate readiness

Per-substrate shipping readiness is tracked openly in the substrate readiness matrix on the public developer hub.