SpecificationThe Final Anchor

The substrate, formally defined.

The canonical graph model, semantic domains, execution semantics, lowering rules, and invariants of the HeteroIR substrate. Not the doctrine, and not its implications — the formal laws of the computational world itself, and the requirements every compatible architecture, compiler, and runtime must meet.

01

Scope & authority

This document is the authoritative definition of the HeteroIR substrate. The concept, motivation, and doctrine are set out elsewhere; here they are reduced to formal, testable rules.

For what the substrate is and why it must exist, seeWhat HeteroIR Is,The Substrate.

Everything below is normative. It governs conformance, not motivation.

This specification governs four things, and only these: what a HeteroIR graph is, what it means, how it executes, and how it lowers onto physical hardware — independent of any single vendor, device, or paradigm.

02

Canonical graph model

All computation in the substrate is expressed as a canonical graph. This section is its normative definition — node types, edge semantics, and the contracts a graph must satisfy to be valid.

Node types

A node declares a unit of computation in one of the recognized domains:

  • Logical — discrete operations
  • Photonic — optical transforms
  • Neuromorphic — spike dynamics
  • Quantum — operators and measurement
  • Continuous — analog fields
  • Probabilistic — stochastic processes
  • Temporal — event and timing nodes

Edge semantics

An edge carries a typed quantity between nodes:

  • Discrete values
  • Continuous fields
  • Probabilities and distributions
  • Spikes and events
  • Quantum amplitudes
  • Temporal markers

Graph contracts

Every well-formed graph must satisfy:

  • Type coherence
  • Semantic preservation
  • Temporal consistency
  • Multi-physics compatibility

A graph that satisfies these contracts is a valid substrate graph. A graph that violates them is not expressible in HeteroIR.

The canonical graph is the single structure into which every paradigm — present and future — is required to map.

03

Semantic domains

The substrate defines five semantic domains — discrete, continuous, probabilistic, temporal, and quantum. Each node and edge type declared in §02 binds to exactly one of them.

The meaning of each domain, with examples, is covered underCapabilities → Unified semantics.

Two rules make this section normative rather than descriptive. First, the domains are intrinsic: they are defined at the level of the substrate, not as adapters or emulations layered over a digital core. Second, they are closed under composition — a graph may mix all five, and no domain may be silently reduced to another.

One world holds all five, without translation between foreign models of meaning.

04

Execution semantics

Execution behaviors — multi-physics coordination, heterogeneous scheduling, and dynamic graph evolution — are described in Capabilities. This section states the one rule that binds them: execution is defined by the substrate, never by the hardware.

For the behaviors themselves, seeCapabilities.

The governing requirement is invariance across targets. The same graph must carry identical meaning whether it is simulated, compiled, or executed on physical devices; any target that cannot honor the declared semantics of a node must refuse it rather than approximate it.

Execution is a property of the world, not of the machine.

05

Lowering rules

Lowering translates a substrate graph into execution on concrete hardware — classical, photonic, neuromorphic, quantum, or hybrid. It is semantic-preserving by definition: every lowering must satisfy four contracts.

  • Completeness — every node and edge in the graph is accounted for by the target.
  • Fidelity — the declared semantics are honored, not approximated away.
  • Isolation — lowering one region does not corrupt the semantics of another.
  • Interoperability — regions lowered to different architectures continue to compose correctly.

Meaning survives the transition from representation to execution. Lowering is a projection, never a loss.

06

Substrate invariants

The invariants are the laws of the substrate. They hold for every valid graph, every execution, and every lowering, without exception.

  • Semantic integrity — declared meaning is never silently altered.
  • Physics coherence — each domain behaves according to its own physical model.
  • Temporal validity — causal and timing relationships are always preserved.
  • Graph consistency — the canonical structure and its contracts always hold.
  • Heterogeneous compatibility — architectures coexist and compose without conflict.

These are not guidelines. They are the constitution of the computational world.

07

Compliance requirements

To be considered HeteroIR-compatible, an implementation must conform to the substrate as defined here. Requirements differ by role.

Architectures

A hardware architecture must:

  • Expose a lowering target for its domain
  • Honor the semantics of nodes it accepts
  • Preserve temporal and causal guarantees
  • Compose with other architectures

Compilers

A compiler must:

  • Emit only valid canonical graphs
  • Preserve semantics through every transform
  • Satisfy the four lowering contracts
  • Reject graphs that violate contracts

Runtimes

A runtime must:

  • Uphold execution semantics
  • Coordinate heterogeneous scheduling
  • Support dynamic graph evolution
  • Maintain the substrate invariants

Conformance is defined against the invariants and contracts of this specification — not against any reference vendor or device.

Compatibility is not a claim. It is a demonstrable obligation to the laws of the substrate.

08

Role in the ecosystem

The Specification is the final anchor of the doctrine. Every other page describes, argues, or inspires; this one defines. When a claim made anywhere in the ecosystem needs a precise meaning, it resolves to the rules written here.

Every claim in the doctrine ultimately resolves here — to the laws written down in the Specification.

The Anchor

This is the definition every architecture answers to — the substrate, written into law.

The reference implementation and conformance suites are released against these definitions.