System Model

1. What Is a Material Program?

Let’s start simply. A material program is not “code that runs on a computer.”
It is a structured description of how a system should behave. Every material program answers five questions:

1. What goes in?
2. What state does the system keep?
3. How does that state change?
4. What rules must always hold?
5. What comes out? If you can answer those five questions clearly, you have something that can be compiled, verified, and executed. If you cannot, you do not. That’s the difference between intent and infrastructure.

2. A Simple Walkthrough

Imagine a small program with a simple goal:

If the input value stays within a safe range, emit a stable signal. Nothing fancy. Step 1 — You write that intent in .matr. You declare:

• the input
• the allowed range
• what “stable” means
• what signal should be emitted At this stage, you are not “running” anything.
  You are describing behavior. Step 2 — Forma compiles that description. The compiler checks:
• Are all inputs declared?
• Are ranges bounded?
• Are transitions finite?
• Are constraints complete? If something is vague, compilation fails. Step 3 — Forma produces a Molebyte. The Molebyte is an artifact. It is not source code.
  It is not editable.
  It is not ambiguous. It contains:
• the structure of the program
• the declared constraints
• the boundaries
• the output definitions
• a stable identity (hash + version) Once created, it does not change. Step 4 — The artifact is bound to a profile. A profile defines the execution envelope. It answers questions like:
• What range of inputs is considered valid?
• What tolerance is acceptable?
• How many iterations are allowed? Profiles make assumptions explicit. Step 5 — Forma runs a verification cycle. It evaluates:
• how the system transitions between states
• whether constraints remain true
• what signals are produced Step 6 — Signals are compared to expectations. If everything matches, the run passes. If something deviates, it is classified and recorded. Nothing is hidden.
  Nothing is implied. That is the control plane loop.

3. Why Artifacts Exist

You might ask: Why not just run the source code directly? Because source code can change. It can drift.
It can be modified.
It can depend on context. Infrastructure cannot. An artifact exists so that:

• The program has a stable identity.
• Two people running the same artifact get the same result.
• Results can be audited.
• Versions can be compared. In Matter/Forma, that artifact is called a Molebyte. A Molebyte is simply the compiled, frozen form of your intent. Once created, it is immutable. If you change anything, you create a new artifact. That rule prevents ambiguity.

4. What “Execution” Means Here

Execution in Forma does not mean “run arbitrary code.” It means:

• Bind artifact
• Bind profile
• Apply policy
• Evaluate state transitions
• Produce signals
• Compare outcomes
• Record judgment Execution is structured evaluation. It is controlled. It is deterministic within declared bounds.

5. Signals: Why They Matter

A signal is not a log. It is a declared observable. If your program promises to emit a stability signal, that signal must be:

• typed
• bounded
• timestamped
• comparable Signals allow the system to answer a simple question:

Did the program behave the way it said it would? If the answer is yes, that is recorded. If the answer is no, the deviation is classified. Signals are how behavior becomes measurable.

6. Diffing and Judgment

After execution, Forma compares expected signals with observed signals. This comparison is structured. It checks:

• value equivalence
• boundary adherence
• tolerance limits
• presence or absence of required outputs The result of that comparison is a diff. A diff is not emotional.
  It is not interpretive. It is a structured record of differences. Policy then evaluates the diff. Policy may say:
• Any deviation fails.
• Minor deviation within tolerance passes.
• Escalate for review. The outcome is a judgment. That judgment is recorded in provenance.

7. What Determinism Means (In Plain Terms)

Determinism means: If you run the same artifact under the same profile with the same inputs, you get the same result. Not “probably.”
Not “most of the time.”
The same. If the profile allows tolerance, that tolerance is declared explicitly. Determinism is not about perfection. It is about predictability within bounds. That is what makes infrastructure possible.

8. Boundaries Are Not Optional

Every material program declares boundaries. Boundaries define:

• allowed inputs
• valid state ranges
• acceptable outputs
• iteration limits Without boundaries, there is no guarantee. Without guarantees, there is no control plane. Boundaries are enforced at compile time and verified at run time.

9. Failure Is Structured

When something goes wrong, it does not fail silently. Failures are classified:

• compilation error
• profile mismatch
• constraint violation
• signal deviation
• policy rejection Each failure produces a structured record. That record includes:
• artifact identity
• profile reference
• time of occurrence
• type of violation Failures are part of the system, not an exception to it.

10. Lightweight Formal Summary

After clarity, we can summarize the model. A run can be described as: Artifact + Profile + Policy + Inputs → Signals → Diff → Judgment More formally:

• An artifact defines bounded state and transitions.
• A profile defines execution limits and tolerance.
• Execution evaluates transitions under constraints.
• Signals represent observable outcomes.
• Diff compares expected vs observed.
• Judgment applies policy to the diff result. That is the system. No hidden layers. No improvisation. No runtime guesswork.

11. Why This Matters

If you had to explain this to your mom, you would say:

We write down exactly how something should behave.
We freeze that description so it can’t quietly change.
We test it in a controlled way.
We compare what happened to what we expected.
And we keep a permanent record of the result. That’s it. Everything else is implementation detail.