Execution, Simulation & Validation

1. What “Execution” Means Right Now

Forma is a control plane. A control plane does not need to pretend execution is magical. In the public platform model today, execution means:

• the artifact is evaluated under a declared profile,
• under a declared policy,
• using a simulation/verification pipeline,
• producing observable signals and a recorded judgment. This is already meaningful. It turns intent into something testable. When substrate facilities exist, the execution target can expand. The control plane contract does not change.

2. What a Run Is

A run is a single, bounded evaluation of an artifact. A run always binds four things:

1. Artifact (the Molebyte)
2. Profile (the execution envelope)
3. Policy (what counts as acceptable)
4. Inputs (values within declared bounds) If any of those are missing, there is no run. This is deliberate. It prevents ambiguity like:

“We ran it… somehow… with some settings… and it looked fine.” A run is explicit. It has an identity. It produces outputs that can be compared later.

3. Simulation Modes (Public Level)

Forma supports multiple verification modes. You do not need internal details to understand what these modes mean.

3.1 Unit Runs

A unit run evaluates a single artifact in isolation. Use unit runs when you want to validate:

• a primitive gate
• a memory element
• a small transition system Unit runs are where most correctness proofs begin.

3.2 Integration Runs

An integration run evaluates a composed system:

• multiple intents
• chained transitions
• shared constraints Integration runs answer a different question:

Does this still behave correctly when composed?

3.3 Parameter Sweeps

A sweep evaluates the same artifact across a range of inputs and parameters. Sweeps are how you learn scaling boundaries. They answer:

• where does behavior stay stable?
• where does it degrade?
• what tolerances are required? Sweeps are what separate “it worked once” from “it behaves under a declared envelope.”

4. Signals

A signal is how Forma makes behavior measurable. Signals are not logs. A log is unbounded text. A signal is a declared observable. A signal has three practical properties:

1. Type (what kind of thing it is)
2. Bounds (what range is valid)
3. Time/ordering (when it occurred) Signals can represent:

• boolean outcomes
• numeric values
• state transitions
• latency measurements
• event markers Signals are declared in the program. If you want to validate something, you make it observable.

5. Expected vs Observed

Every verified run produces observed signals. But verification requires a baseline. So Forma also maintains expectations. Expectations come from:

• declared output bounds
• declared constraints
• profile tolerances
• known invariants That baseline is what makes diffing objective.

6. Diffs

A diff is the structured comparison of:

• what should have happened
• vs what actually happened Forma diffing is designed to be boring. That’s a compliment. It avoids interpretation. It classifies differences. Common diff classes include:
• Value mismatch: a signal has the wrong value
• Boundary violation: a value exceeded declared bounds
• Tolerance breach: deviation exceeded profile tolerance
• Missing output: expected signal did not appear
• Unexpected output: a signal appeared that was not declared
• Timing deviation: an output arrived outside declared latency range The important part: Diffs are structured records. They can be stored, compared, and audited.

7. Judgments

A judgment is Forma’s decision about a run. Judgment is not “AI.” It is policy applied to a diff. At a public level, the judgment space is simple:

• PASS
• FAIL
• ESCALATE Policy decides what triggers each. For example:
• A strict policy may fail on any mismatch.
• A tolerant policy may allow small deviations.
• A safety policy may escalate when certain boundaries are approached. Judgments are recorded with provenance.

8. What Gets Stored

The point of a control plane is not only to run things. It is to remember what happened. A verified run produces and stores:

1. Run identity and configuration
2. Artifact identity and version lineage
3. Profile reference
4. Policy reference
5. Observed signals (trace)
6. Diff record
7. Judgment outcome This is how you get:

• regression testing
• artifact promotion decisions
• reproducible validation
• credible audit trails

9. Reproducibility Over Time

A single run can be interesting. A system becomes credible when runs are comparable. Because artifacts are immutable and profiles are explicit, Forma can answer:

• Did behavior change between v1.0 and v1.1?
• Did a constraint become tighter?
• Did a tolerance requirement shift?
• Did an integration chain introduce drift? This is not a marketing claim. It’s a direct consequence of:
• immutable artifacts
• explicit profiles
• structured signals
• stored diffs
• recorded judgments

10. Summary

Forma execution today is verification execution. A run is: Artifact + Profile + Policy + Inputs → Signals → Diff → Judgment Signals make outcomes measurable. Diffs make comparison objective. Judgments make governance explicit. And the stored record makes the system trustworthy.