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.