Overview

What this section is

The Learn section explains how to author, compile, verify, and manage deterministic material programs in the Forma control plane.

• Matter is the execution substrate abstraction: what a material program means.
• Forma is the control plane: where material programs are compiled, simulated, governed, and (eventually) routed to substrate execution.
• .matr is the authoring language: how intent is expressed as bounded, deterministic program artifacts.
• Molebyte is the compiled artifact format: the immutable, versioned unit Forma stores, verifies, and executes. If you are looking for empirical proof (simulation phases, validation narrative, constraints observed), go to Research. Learn defines the operational contract; Research documents the validation evidence.

The platform in one sentence

Matter/Forma is a deterministic control plane for material computation: .matr programs compile into immutable Molebyte artifacts that Forma verifies by simulation and governs as executable units. This statement is intentionally narrow:

• It describes what is true today (authoring → compilation → verification).
• It avoids claims that require substrate facilities (wet execution at scale).
• It is specific enough for engineers to reason about and critique.

Glossary of primary terms

This documentation uses the following terms with strict meanings.

Material program

A material program is a bounded description of:

1. inputs, 2) state, 3) transitions, 4) constraints, and 5) observable outputs
   such that execution can be simulated and verified under an explicit profile. A material program is not a “script” and not “AI behavior.” It is a deterministic state-transition specification compiled into an executable artifact.

Artifact

An artifact is the compiled, immutable unit that Forma can verify and run. In Matter/Forma, the artifact format is Molebyte. Artifacts are:

• immutable after compilation (no hidden mutation)
• addressable by identity (hash/version)
• governable by policy
• verifiable by simulation

Execution (in Forma)

In the current public platform model, execution means:

• binding an artifact to an execution profile and policy,
• running the verification/simulation pipeline,
• producing an observable signal trace and pass/fail judgment. Future substrate execution extends this definition to include physical routing, but the contract remains the same: artifact + profile + policy → run → signals → diff → judgment.

Profile

A profile is a declared execution envelope that makes assumptions explicit (allowed parameter ranges, tolerances, and constraints). Profiles are how Forma avoids ambiguous claims like “works in any environment.”

Signal

A signal is a typed, bounded observable produced by a run: values, events, or traces used to evaluate whether constraints were satisfied.

Diff

A diff is the structured comparison between expected and observed signals, computed under a profile and policy.

Judgment

A judgment is Forma’s final decision for a run: pass, fail, or escalate—derived from diff outputs and policy gates.

The Forma control-plane loop

Forma is organized around a deterministic control-plane loop:

1. Author intent in .matr
2. Compile to a Molebyte artifact
3. Attach a profile (execution envelope)
4. Gate with policy (safety, governance, integrity)
5. Run simulation/verification
6. Observe typed signals
7. Diff expected vs observed
8. Judge pass/fail/escalate
9. Promote artifact versions (optional) and record provenance In shorthand: Intent → Artifact → Profile/Policy → Run → Signals → Diff → Judgment → Provenance Two notes that matter:

• The loop is explicit. Nothing “just happens” off to the side.
• The output is not only a result—it is a record suitable for audit, regression, and version comparison.

Compile-Truth principle

Compile-Truth If it compiles, it is real. If it does not compile, it is not a valid .matr program.

Learn defines the mental model. The compiler is the source of truth.

This is intentional. Compilation errors are normal. They are part of system discipline, not a credibility problem.

What Learn documents (and what it doesn’t)

Learn does document

• the formal model (what an artifact is, what a run is, what a signal is)
• how .matr maps into Molebyte artifacts
• the compilation and validation pipeline as a deterministic transformation
• the artifact lifecycle and governance semantics (immutability, versioning, promotion)
• how profiles, policy, diffing, and judgment work conceptually and structurally
• representative examples that show end-to-end behavior without disclosing trade secrets

Learn does not document

• proprietary substrate implementation details (sequence designs, facility parameters)
• private runtime optimizations and internal heuristics
• the full quantitative simulation corpus (that belongs in Research)
• internal product UI workflows that are not stable yet (those can be gated)

Public vs Members Only documentation

Matter/Forma will publish two documentation layers:

Public Learn (this section)

Public Learn establishes legitimacy by providing:

• a precise model,
• a coherent artifact lifecycle,
• verifiable semantics,
• and examples that engineers can reason about.

Invite-only Docs

Gated documentation may include:

• full operational workflows,
• screenshots and UI walkthroughs,
• detailed artifact inspection procedures,
• simulation regression suites and logs,
• integration guidance and advanced governance models. The boundary is intentional: public docs describe the system contract; gated docs describe operational use at depth.

Design principles

These principles are enforced throughout the language and the control plane.

1) Determinism before execution

Forma privileges compile-time and preflight guarantees over runtime patching. If a behavior cannot be bounded and verified, Forma treats it as invalid.

2) Explicit boundaries

Artifacts declare their inputs, state, transitions, and outputs. Undeclared behavior is treated as non-existent.

3) Immutable, versioned artifacts

Once compiled, artifacts do not change. All changes create new versions with new identities and traceable diffs.

4) Profiles make assumptions first-class

Every run is executed under a profile that defines the envelope of validity.

5) Observable signals, structured diffs

Verification is based on typed observables and explicit diffing—not vibes and screenshots.

6) Governance is part of the runtime

Policy gates are not optional add-ons. They are part of the execution loop.

Claims and non-claims

To keep the Learn section technically credible, it is explicit about what is claimed.

Claims (what this documentation asserts)

• .matr is a bounded language: programs declare finite state, finite transitions, and finite observables.
• Compilation produces immutable Molebyte artifacts with stable identities (hash/version).
• Forma executes a deterministic control loop in simulation/verification mode: artifacts are evaluated against profiles and policy, producing signals, diffs, and judgments.
• Artifacts can be compared over time using structured diffs and provenance records.

Non-claims (what this documentation does not assert)

• It does not assert universal substrate compatibility. Profiles define validity envelopes.
• It does not assert that every artifact is physically realizable on every substrate. Physical mapping is constrained and versioned.
• It does not claim “AI decision-making.” Judgment is policy + diff evaluation, not opaque inference.
• It does not disclose substrate trade secrets (sequence-level designs, proprietary parameterizations). This separation is deliberate: engineers should be able to verify the contract without being asked to accept unspecified implementation claims.

Reading paths

If you are a developer

Start with:

1. Artifact Lifecycle → 2) .matr Specification → 3) Molebyte Format → 4) Simulation & Validation → 5) Examples

If you are an evaluator (due diligence)

Start with:

1. System Model → 2) Determinism Contract → 3) Governance & Versioning → 4) Research (simulation evidence)

If you are a researcher

Start with:

1. System Model → 2) Simulation & Validation → 3) Research (full ladder of phases)

Terminology quick-reference

Where to go next

• System Model: formal state model and determinism contract
• Artifact Lifecycle: how Molebytes are created, verified, promoted, and governed
• .matr Specification: language grammar, semantics, and constraints
• Molebyte Format: the artifact structure and integrity model
• Simulation & Validation: how runs produce signals, diffs, and judgments
• Examples: end-to-end programs and expected observables