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.
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.
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.
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.
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.
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.
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.
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.
- 01The Missing Layeridentifies the fracture
- 02What HeteroIR Isnames the substrate
- 03Capabilitieswhat it can do
- 04The Substratehow it works
- 05Visionwhere it leads
- 06Humanity's Leapwhy it matters
- 07Build the Futurethe call to build
- 08Vision Paperthe doctrine, formalized
- 09Specificationthe substrate, definedYou are here
Every claim in the doctrine ultimately resolves here — to the laws written down in the Specification.