matter

The .matr language

.matr is a declarative language for expressing matter programs. It encodes executable intent: what materials to use, what protocols to follow, what constraints must hold, and what governance applies. Source is structured for compilation into Molebytes, simulation in the Material Twin, and governed execution through Material Cloud.

The language is intentionally constrained. It does not support arbitrary computation, side effects, or runtime branching. Programs describe a deterministic path from inputs to expected outcomes. This restriction is what makes every .matr program simulatable, auditable, and governable.

design principles

Language design rationale

  • Declarative over imperative. Programs express intent and constraints, not step-by-step substrate manipulation.
  • Deterministic execution. Given the same inputs and substrate model, a program always produces the same Protocol Execution Plan.
  • Governance is syntax. Consequence tiers and approval requirements are first-class language constructs, not external annotations.
  • Simulation-first. Every valid program can be simulated before execution. If it cannot be simulated, it cannot compile.
  • Composition over inheritance. Programs compose through explicit imports and bindings, not through object hierarchies.
  • Auditability by default. Source, compilation output, and execution provenance are linked at every stage.

Core constructs

Every .matr program is composed of a small set of top-level constructs. These are the building blocks of matter programs.

construct

material

A material block defines a physical or simulated substance and its properties. Materials are the inputs to protocols. Each material declaration includes a substrate binding (which physical or simulated environment it targets), concentration or quantity parameters, and optional metadata.

material GoldNanoparticle {
  substrate: "colloidal-au"
  diameter: 15 nm ± 2 nm
  concentration: 0.5 mM
  surface_charge: -35 mV
}

construct

protocol

A protocol block defines an ordered sequence of steps that operate on materials. Each step specifies inputs, duration, environmental conditions (temperature, pressure, pH), and expected intermediate outcomes. Steps execute sequentially within a protocol. Parallelism is expressed by composing multiple protocols, not by branching within one.

protocol Functionalize {
  step reduce {
    input: GoldNanoparticle
    reagent: "sodium-citrate"
    temperature: 100°C
    duration: 15 min
    stir_rate: 400 rpm
  }

  step conjugate {
    input: step.reduce.output
    ligand: "PEG-5000"
    duration: 2 hr
    temperature: 25°C
  }
}

construct

constraints

Constraints define the success criteria for a program. They are checked at simulation time and again after execution. A constraint violation during simulation prevents the artifact from being submitted. A constraint violation during execution triggers the signal and escalation pathway defined by the program's governance tier.

constraints {
  yield >= 0.80
  purity >= 0.95
  particle_diameter: 15 nm ± 3 nm
  endotoxin < 0.25 EU/mL
  batch_variance < 0.05
}

construct

governance

Governance annotations are required on every .matr program. They declare the consequence tier (T0 through T4), required approvals, escalation behavior, and any domain-specific compliance labels. The compiler enforces that governance is present and consistent with the program's constraint profile. Higher-tier programs automatically require more rigorous simulation and approval chains.

governance {
  tier: T2
  consequence: "physical-reversible"
  approvals: ["domain-lead", "safety-review"]
  escalation: "halt-and-notify"
  compliance: ["GLP", "ISO-13485"]
}

construct

simulation

Simulation parameters define how the program should be validated in the Material Twin before execution. They include the number of simulation runs, confidence thresholds, substrate model version, and comparison baselines. The Material Twin is not a test suite. It is a first-principles evaluation of the Protocol Execution Plan against a digital twin of the target substrate.

simulation {
  runs: 1000
  confidence: 0.95
  substrate_model: "colloidal-au-v3"
  baseline: "run_previous_batch"
  timeout: 300s
}

Compilation model

input

.matr source

Human-readable and agent-readable source files. Parsed into an AST, validated for structural correctness, checked for governance completeness, and resolved against substrate registries.

output

Molebyte artifact

A versioned, immutable binary artifact containing the Protocol Execution Plan, all metadata, constraint thresholds, governance annotations, and simulation parameters. This is what Material Cloud executes.

intermediate

Protocol Execution Plan (PEP)

The compiled representation of a .matr program's protocols. PEPs are deterministic operation sequences that Material Cloud can schedule against physical substrates, or that the Material Twin can evaluate in simulation. They are the core content of a Molebyte.

validation

Compile-time checks

The compiler validates syntax, substrate compatibility, constraint satisfiability, governance completeness, and simulation parameter ranges. Programs with errors produce actionable diagnostics, not silent failures.