1. The Unit of Reality in Forma
In Forma, the unit of reality is not source code. It is an artifact. Source code is something humans write. Artifacts are what systems can trust. That distinction matters because Forma is a control plane. A control plane needs stable objects:
- stable identity
- stable structure
- stable audit trails If you try to run “whatever the source code is today,” you get drift. If you run artifacts, you get reproducibility. So Forma works like this:
- Humans write
.matr - Forma compiles it into a Molebyte artifact
- Forma verifies and governs the artifact
- Forma runs the artifact under a declared profile and policy From that point forward, the artifact—not the source—is what the platform executes.
2. What a Molebyte Is
A Molebyte is the compiled artifact format used by Matter/Forma. At a practical level, a Molebyte is a structured package containing:
- the program’s declared inputs and outputs
- the program’s state and transitions
- the constraints that must hold
- the profile compatibility declaration
- an identity (hash) and version metadata It is not the substrate. It is not a DNA sequence. It is not a wetlab protocol. It is a deterministic execution artifact. If you had to explain it to your mom:
A Molebyte is the frozen, verified version of the program—so it can’t quietly change and so results can be trusted.
3. The Molebyte “Shape” (Public Level)
You do not need the private internal schema to understand the contract. Publicly, it is enough to know that every Molebyte carries the same categories of information:
3.1 Header
A short block that identifies:
- artifact name
- artifact version
- artifact hash (identity)
- compile timestamp
- toolchain signature
3.2 Program Structure
A structured representation of:
- inputs
- state variables
- transitions
- outputs
3.3 Constraint Table
A list of constraints with:
- what each constraint checks
- which variables it applies to
- what constitutes violation
3.4 Boundaries
An explicit boundary set:
- allowable input ranges
- allowable state ranges
- allowable output ranges
- iteration limits
3.5 Profile Compatibility
A declaration of which execution profiles the artifact can be run under.
3.6 Integrity
A deterministic identity hash derived from canonical serialization. That is the artifact contract. The exact internal representation can evolve. The contract must not.
4. The Artifact Contract
Artifacts are governed by three simple rules.
4.1 Immutability
Once compiled, a Molebyte does not change. No hidden edits. No “patching the artifact.” No runtime mutation. If you change logic, constraints, boundaries, or profile declarations, you produce a new artifact. Immutability prevents the most common source of mistrust in complex systems:
“Are we even running the same thing?”
4.2 Identity
Every artifact has a stable identity. Identity is derived from the artifact’s contents. This is typically implemented via a deterministic hash over canonical serialization. The practical implication:
- If two artifacts are identical, they share the same identity.
- If anything meaningfully changes, identity changes.
4.3 Reproducibility
Given:
- the same artifact
- the same profile
- the same policy
- the same declared inputs Forma expects the same results within profile tolerance. That is the reproducibility contract.
5. The Artifact Lifecycle
Forma treats artifacts as moving through explicit lifecycle states. This matters because it turns “software” into “infrastructure.” Below is the public lifecycle model. Deeper operational states can be gated later.
5.1 Draft
What it is: .matr source still being authored.
What can happen here:
- syntax checking
- linting
- local validation What cannot happen here:
- execution
- promotion Drafts are not artifacts.
5.2 Compiled
What it is: source has been compiled into a Molebyte. What Forma validates:
- bounded inputs, state, outputs
- complete transition definitions
- constraint consistency
- boundary closure What is produced:
- Molebyte artifact with identity + version metadata Compilation converts intent into an immutable unit.
5.3 Profile-Bound
What it is: artifact has been bound to an execution profile. What Forma validates:
- profile compatibility
- tolerance definitions
- iteration limits This step answers:
“Under what assumptions is this artifact valid?”
5.4 Verified
What it is: artifact has passed simulation/verification runs. What Forma validates:
- constraints hold across declared test conditions
- signals remain within bounds
- termination behavior matches profile What is produced:
- run records
- signal traces
- diffs
- judgments Verified means:
“We have evidence, under declared conditions, that this behaves as specified.”
5.5 Versioned
What it is: artifact is stored with stable identity and belongs to a version lineage. Versioning allows:
- regression testing
- artifact comparison
- controlled upgrades Versioning is how the system prevents silent drift.
5.6 Promoted
What it is: artifact has been approved for a higher trust tier. Promotion is policy-driven. In public terms:
- promoted artifacts are preferred execution candidates
- promotion records are permanent Internally, promotion tiers can be expanded later.
5.7 Executable
What it is: artifact is eligible for execution in a run environment. Today that environment is simulation/verification. In the future, execution may include substrate routing, but the lifecycle contract does not change.
6. Versioning and Diffs
Once artifacts are immutable, versioning becomes meaningful. Forma can answer:
- What changed between version 1.1 and 1.2?
- Did constraints become tighter?
- Did output bounds change?
- Did behavior shift under the same profile? There are two kinds of diffs.
6.1 Structural Diff
Compares the artifact structure:
- transitions
- constraints
- boundaries
- profile declarations This is a “what changed in the program” diff.
6.2 Behavioral Diff
Compares run outputs under the same conditions:
- signal traces
- pass/fail outcomes
- deviation classifications This is a “what changed in behavior” diff. A serious control plane needs both.
7. Provenance
Provenance is the permanent record that makes the system trustworthy. Every verified run produces a provenance record linking:
- artifact identity
- artifact version lineage
- profile used
- policy gate applied
- run configuration
- resulting signals
- resulting diff
- final judgment Provenance is append-only. If you want to trust the system, provenance is where you look.
8. What Can Be Public vs Gated
Public documentation should fully explain:
- why artifacts exist
- what they contain at a category level
- what lifecycle states mean
- how versioning and provenance work Gated documentation can include:
- internal schema details
- artifact inspection tooling
- UI workflows
- raw run logs and regression suite mechanics The public contract stays intact either way.
9. Summary
Forma treats Molebytes as the unit of execution because artifacts are stable. A Molebyte is:
- compiled from
.matr - immutable
- identity-addressable
- profile-bound
- verifiable
- versioned
- promotable The artifact lifecycle turns programs into infrastructure.