forma

Execution model

FORMA treats control as a design-time discipline. Material execution proceeds within bounded constraints, with policy and validation resolved before execution starts. This page describes why, how, and what the execution model produces at each stage.

Design-Time Certainty vs Runtime Control

Why material computing inverts the assumptions of traditional systems — and why that inversion matters at scale.

Traditional computing systems prioritize control during execution. Processes can be interrupted, restarted, rolled back, or patched while running. This model evolved alongside silicon-based machines, where computation is abstracted from physics and errors are relatively cheap to correct.

Material computing operates under different physical laws. Once execution begins, matter behaves according to chemistry and physics, not software signals. This shifts the center of gravity from runtime control to design-time certainty — a change that unlocks massive parallelism, lower energy costs, and fundamentally different scaling properties.

Traditional ComputeMaterial Computing
Runtime FocusDesign-Time Focus
Interruptible executionNon-interruptible execution
Global clocks and instruction pointersContinuous time and physical state
Addressable memoryState encoded in matter
Preemption and kill signalsPreflight validation and constraints
Errors corrected during executionErrors prevented before execution
Cheap retries, expensive scaleCheap scale, expensive mistakes
Sequential optimizationMassive inherent parallelism
Control during runtimeCertainty before execution

Why This Is a Strength

Material computing does not remove control — it relocates it.

Instead of relying on runtime intervention, Matterforma enforces correctness before execution begins. Programs are compiled, simulated, constrained, and approved prior to material execution. Once started, execution proceeds deterministically within predefined boundaries.

This approach mirrors how high-stakes physical systems already operate: semiconductor fabrication, pharmaceutical manufacturing, chemical processing, and aerospace systems all rely on rigorous design-time validation because runtime interruption is either impossible or unsafe.

Matterforma brings this proven engineering discipline to computation itself.

Why Design-Time Certainty Wins at Scale

As AI workloads scale, the cost of mistakes grows non-linearly. A small error propagated across millions or billions of executions can consume enormous energy, infrastructure, and capital.

Traditional systems absorb this risk by allowing retries, rollbacks, and patches — but those mechanisms become increasingly expensive as scale increases.

Material computing flips the equation. By enforcing correctness before execution, Matterforma enables massive parallelism without proportional increases in risk. Billions of material executions can occur simultaneously because they do not compete for clocks, memory, or interrupts.

The result is a system optimized for:

  • • parallel execution at physical limits
  • • predictable energy consumption
  • • bounded failure modes
  • • reduced marginal cost per execution

This makes material computing especially well-suited for AI inference, simulation, optimization, and large-scale pattern evaluation — where scale is essential and runtime intervention is already impractical.

Control Moves Earlier in the Stack

Traditional compute stack

  • Runtime interrupts
  • Retries
  • Rollbacks
Control shifts from execution to design

Matterforma stack

  • Constraints
  • Simulation
  • Approval

Material computing does not trade safety for scale.

It achieves scale by making safety non-negotiable before execution.

Matterforma is built for a world where computation is no longer abstract — where logic runs in matter, and certainty matters more than interruption.

The artifact lifecycle

Execution in FORMA is not "run a program." It is: produce an artifact, validate it, govern it, and then execute it under constraints. Each stage creates durable records so the full chain from intent to outcome is reproducible and auditable.

01

Compile

.matr source compiles into a Molebyte — a versioned, content-addressed artifact carrying logic, metadata, and execution constraints.

02

Validate

Preflight checks verify structural correctness, constraint satisfaction, profile compatibility, and resource budgets before a run is submitted.

03

Govern

The governance engine evaluates consequence tier, compute tier, approval requirements, and cost ceilings. No execution proceeds without a policy decision.

04

Execute

MFCore schedules the approved run into a Material Cloud execution pool. The run proceeds under the profile constraints locked at approval time.

Execution profiles

Every run executes under an explicit profile. A profile is not a configuration file — it is a binding contract between the artifact and the runtime that defines what resources are available, what constraints apply, and what happens when boundaries are reached.

profile components

What a profile contains

  • Resource envelope — Compute, memory, and energy bounds for the run.
  • Cost ceiling — Maximum credit expenditure permitted for the execution.
  • Timing constraints — Maximum wall-clock duration and scheduling priority.
  • Isolation level — Whether the run shares a pool or requires dedicated capacity.
  • Observation contract — Which signals must be captured and at what granularity.

profile enforcement

How profiles are enforced

  • Profiles are locked at governance approval time — they cannot be modified mid-execution.
  • MFCore validates pool compatibility before scheduling.
  • If a run exceeds its resource envelope, the pool enforces the boundary — the run does not get more.
  • Cost overruns trigger escalation, not silent continuation.
  • Profile metadata is stored in the Audit Ledger alongside execution results.

Two-axis governance

FORMA governs execution along two independent axes: consequence (what could go wrong) and compute (what resources are needed). These axes are orthogonal — a low-consequence workload can require high compute, and a high-consequence workload can be computationally trivial.

Consequence tiers (T0 -- T4)

Determine the depth of verification, approval requirements, and audit obligations for a workload.

  • T0 — Exploratory. Material Twin only. No physical consequence. Minimal review.
  • T1 — Validated. Requires Material Twin evidence and baseline comparison.
  • T2 — Verified. Requires policy approval and profile lock.
  • T3 — Audited. Multi-party review, full provenance chain, locked audit trail.
  • T4 — Irreversible. Maximum verification. Physical consequence. Cannot be undone.

Compute tiers (C0 -- C4)

Control resource allocation, scheduling priority, and pool access independently of consequence.

  • C0 — Material Twin only. No physical execution. Local compute.
  • C1 — Limited. Shared pool access. Cost-capped per run.
  • C2 — Standard. Standard pool access. Profile-bound scheduling.
  • C3 — Priority. Dedicated capacity. Priority scheduling queue.
  • C4 — Full. Reserved infrastructure. Maximum resource allocation.

example

A researcher running exploratory Material Twin models of a new molecular logic gate operates at T0/C0 — no physical consequence, Material Twin-only compute. When the same logic gate is approved for physical fabrication at scale, the workload moves to T4/C3 — irreversible consequence with priority scheduling and dedicated capacity. The governance requirements change dramatically even though the underlying artifact may be identical.

Material Twin: evidence, not demonstration

In FORMA, Material Twin simulation is not a preview. It is a required evidence step that produces verifiable outputs used downstream by governance, comparison, and audit systems. Material Twin models Matter inside Material constraints -- substrate classes, environmental conditions, thermodynamic limits, and failure modes. Results are stored as part of the artifact lineage and serve as baselines for evaluating real execution outcomes.

Baseline generation

Material Twin produces expected outcome distributions, timing profiles, and resource estimates that become the reference point for all subsequent runs.

Constraint verification

Preflight validation uses Material Twin to verify that declared constraints are satisfiable and that the artifact behaves within its Material profile boundaries.

Governance input

The governance engine requires Material Twin evidence for T1+ workloads. Without it, the policy gate denies the run request.

Signals and outcome comparison

Material execution does not produce logs. It produces structured signals: outcome distributions, confidence bounds, state deltas, energy accounting, and provenance metadata. Signals are the unit of decision-making in the FORMA execution model.

signal structure

What every signal contains

  • Outcome distributions across the execution population
  • Confidence bounds for each measured result
  • State deltas between input and output
  • Energy and resource consumption accounting
  • Cost attribution linked to the artifact and profile
  • Provenance chain connecting the signal to its source

comparison and judgment

How signals drive decisions

  • Signals are compared against Material Twin baselines and previous run outcomes
  • Drift beyond threshold triggers escalation, not silent continuation
  • BERNIE can propose next actions based on signal interpretation
  • High-consequence judgment always routes to human review
  • Every comparison produces an immutable record in the Audit Ledger

Agent-native execution

FORMA is designed for agent-driven workflows where BERNIE and other AI agents generate artifacts, submit runs, and interpret results. The execution model treats agents as first-class participants subject to the same governance boundaries as human operators.

What agents can do

  • Generate and refine .matr source programs
  • Compile artifacts and trigger preflight validation
  • Submit run requests within their permitted policy bounds
  • Interpret signals and propose next actions
  • Route workloads and escalate when thresholds are exceeded

What agents cannot do

  • Bypass governance policy gates
  • Execute T3+ workloads without human approval
  • Modify profiles or cost ceilings after governance lock
  • Delete or alter provenance records
  • Self-approve escalation decisions

This is the core principle: automation operates within boundaries, not around them. BERNIE's deterministic Governor ensures that AI-generated actions are always policy-compliant, even when the underlying intelligence layers propose novel approaches.

Certainty before execution. Provenance after.

The FORMA execution model ensures that every Material computation is validated, governed, observed, and recorded. Start with artifacts today and turn on physical execution when Material Cloud pools open.