1. Why Observability Is Non‑Negotiable
If a system can’t be measured, it can’t be governed. That’s true in software. It’s even more true in material computation. When you run a material program (even in simulation), you’re not just asking:
Did it “work”? You’re asking:
- Did it stay within declared boundaries?
- Did constraints hold at every step?
- Did outputs arrive in the expected window?
- Did the system behave consistently across runs? Forma is built around a simple idea:
If you want credibility, you need structured observables. So Forma treats observability as part of the execution contract.
2. Signals vs Logs
A log is useful for debugging. It is not a reliable basis for validation. Logs are:
- unbounded
- free-form
- often subjective
- hard to compare cleanly Signals are different. A signal is a declared observable that Forma can store, compare, and audit. If you want to validate behavior, you use signals. If you want to understand why behavior occurred, you may use logs in gated tooling. Publicly, what matters is:
- signals are typed
- signals are bounded
- signals are comparable
3. What a Signal Looks Like (Public Level)
You do not need internal schemas to understand the contract. A signal is a record with four core parts:
- Type — what kind of value it is
- Value — what was observed
- Bounds — what range is considered valid
- Time/ordering — when it occurred (or the sequence position) In addition, signals carry provenance metadata:
- artifact identity
- run identity
- profile reference
- policy reference If you had to explain this simply:
A signal is a measured output that has a known shape and a known range, so we can compare it reliably.
4. Where “Expected” Comes From
Diffing requires two things:
- what happened
- what should have happened In Forma, “expected” is not guesswork. Expectations come from declared structure:
- output declarations in
.matr - constraints compiled into the artifact
- boundaries declared in the artifact
- tolerances declared in the profile That’s why the platform is strict about declarations. If outputs and bounds aren’t declared, expectations can’t be defined. And if expectations can’t be defined, validation becomes opinion.
5. Diffing: Objective Comparison
A diff is Forma’s structured comparison between:
- expected signals
- observed signals Diffing is designed to be boring. It should feel like an accounting ledger:
- factual
- consistent
- repeatable A diff answers:
- what deviated
- by how much
- in what category That’s it.
5.1 Diff Classes
At the public level, Forma classifies diffs into a small set of useful categories.
Value mismatch
A signal has a value outside expected equivalence.
Boundary violation
A signal crossed a declared bound.
Tolerance breach
A signal stayed within bounds but exceeded allowed deviation.
Missing signal
A required signal did not appear.
Unexpected signal
A signal appeared that was not declared.
Timing deviation
A signal occurred outside the declared timing window. These categories are simple on purpose. They are easy to reason about. They also scale.
6. Drift: Small Deviations That Matter
Drift is not a single failure. Drift is gradual divergence over time. A system can “pass” today and still drift. For example:
- latency slowly increases
- outputs approach boundary edges
- tolerances get used more frequently Individually, those may still pass. Collectively, they can indicate loss of stability. Forma treats drift as a first-class observable. Not with dramatic language. With simple comparisons.
6.1 Drift Detection (Public Level)
At a public level, drift detection is:
- comparing run outputs over time under consistent profiles
- tracking which diff classes occur and how often
- monitoring distance-to-boundary trends If you had to explain it to your mom:
It’s like tracking your car over time.
Even if it still runs, you can see when it’s starting to run worse. Drift is a signal about reliability.
7. Regression: Comparing Artifacts Over Time
Once artifacts are immutable, you can compare them. Forma supports regression in two practical ways.
7.1 Structural Regression
This asks:
Did the artifact itself change? It compares:
- constraints
- boundaries
- transitions
- output declarations
- profile compatibility This is a “contract change” check.
7.2 Behavioral Regression
This asks:
Did behavior change under the same conditions? It compares:
- signal traces
- diff frequency
- drift indicators
- judgment outcomes This is a “reliability change” check. Together, these prevent a common failure mode:
We changed something and didn’t notice that behavior shifted.
8. How Judgment Uses Diffs (Without Becoming Subjective)
Policy turns diff records into decisions. The important point is that judgment does not reinterpret signals. It evaluates diff classes against rules. For example:
- Any boundary violation fails.
- A tolerance breach may pass if within acceptable limits.
- Repeated timing deviations may escalate. This is not “AI.” It is governance applied to measurement.
9. Public vs Gated Depth
Public Learn should make clear:
- what signals are
- how expectations are defined
- what diffing means
- what drift means
- how regression comparisons work conceptually Gated docs can include:
- full signal schema
- dashboards
- drift scoring models
- diff visualization tooling
- alerting and automation You can keep operational tooling private without making the public contract vague.
10. Summary
Observability is what turns execution into something measurable. Signals are structured observables. Diffs are structured comparisons. Drift is long-term divergence. Regression compares artifacts and behavior over time. Together, these are what make Forma a credible control plane.