SSMT – Governance, Compliance Levels, and Numeric Safety Rules (8.1–8.4.1)

How SSMT stays honest at scale: one lens, one manifest, explicit clamps, and published guard rails.

Why this layer matters.
Section 8 is where SSMT stops being just “a better temperature signal” and becomes an operational standard. The goal is not only to emit e_T, a_phase, Q_phase, etc., but to prove that those dials are disciplined, replayable, and safe for audit, safety policy, and downstream automation.

8.1 Principles (normative)
These are the non-negotiables. Terms “MUST,” “SHOULD,” and “MAY” are used in their standard normative sense.

Single lens per study.
A deployment MUST choose exactly one lens (for example "log", "linear", "beta", "kBT", "hybrid", "qlog") and keep it fixed for that run. Mid-run switching destroys comparability.

Symbol-only machine logic.
Machine logic MUST consume only symbolic channels:

{ e_T,
  a_phase or a_phase_fused (if defined),
  a_T?,
  Q_phase?,
  manifest_id,
  health flags }

It MAY also use g_t if an environment gate is declared elsewhere. Human-facing dashboards MAY display °C/°F for comfort, but those displays MUST NOT feed back into machine logic.

Publish anchors.
The manifest MUST publish the anchors that define how e_T is computed:

T_ref
DeltaT?      # if linear or hybrid local branch
E_unit?      # if kBT
tau?         # if hybrid
alpha?       # if qlog

If the pivot logic uses a_phase, it MUST publish each pivot (for example T_m, DeltaT_m, c_m, k_side, rho) and any tags like "water" or "skin_safety_band".

Validity first.
Every manifest MUST declare a numeric safety band:

T_valid_range_K = [T_min, T_max]

Out-of-range readings MUST set health.range_ok = false and MUST mark oor as "below_min" or "above_max". You cannot hide dangerous readings by silently clipping them without a flag.

Kelvin floor.
After converting raw units to Kelvin, firmware MUST apply:

T_K := max( T_K , eps_TK )

If eps_TK is not the default, that number MUST be published. This protects math near 0 K.

Clamps are explicit.
If emitting bounded dials like a_T or a_phase, you MUST clamp them:

|a_T|      <= 1 - eps_a
|a_phase|  <= 1 - eps_a

The manifest MUST publish eps_a. This prevents unbounded runaway values from destabilizing dashboards or ML.

Auditability.
Every record MUST carry a manifest_id that resolves to the full recipe (lens, pivots, guards, ranges, clamps). That is how a third party can reconstruct a decision path months later.

Simplicity first.
Teams SHOULD begin at S1 (symbolic contrast only) and upgrade only where survival, pooling, or automated gating justifies it. SSMT is intentionally layered so you do not have to jump to “full everything” on day one.

8.2 Compliance levels
Compliance levels define how much of SSMT you are emitting. They also define what downstream systems are allowed to assume.

S1 (Minimal).
What you emit:

e_T
manifest_id
health.range_ok (and related health flags)
oor?
timestamp_utc

What you do NOT emit:

  • No a_phase
  • No Q_phase
  • No a_T
  • No pooling
    Use S1 when you only need unitless temperature contrast (e_T) and basic auditability.

S2 (Phase-aware).
S1 plus:

a_phase          # or a_phase_fused if multiple pivots
Q_phase          # soft hysteresis memory
T_m_tag_list?    # pivot tags like "freeze band"

Use S2 when survivability bands, freezing/softening points, warp bands, fatigue bands, etc. matter. Alerts come from a_phase (which side of a pivot and how deep) and Q_phase (have we stayed there long enough to care).

S3 (Full).
S2 plus:

a_T              # bounded alignment dial from e_T
pooling rules    # rapidity pooling for fleet/state rollups
(optional) g_t   # environment gate defined in Section 3.1 logic

Use S3 when you need bounded fleet dashboards, pooled KPIs, environment-aware throttling, or direct symbolic gating of other scores.

Upgrade rule.
A higher level MUST NOT redefine the meaning of any field from a lower level. You only add more fields; you never silently change what e_T or a_phase meant.

8.3 Change control and versioning

Manifest version.
Your manifest MUST include something like:

version: "1.1"

It is a plain string. Changing version is how you declare that your recipe changed in a meaningful way.

No mid-run lens changes.
Switching lens or anchor policy mid-run is prohibited. If you must change lens, that is a new study with a new manifest_id. That forces traceability.

Backward compatibility.
When you add new output fields, they MUST be optional and MUST ship with published defaults. No consumer should break just because you added Q_phase or a_T.

Deprecations.
When you want to retire a field, you MUST give an advance window. During that window, you keep a shim and announce the retirement so downstream systems have time to update. (The exact number of months is a governance choice, but it needs to be documented in policy.)

8.3.1 Manifest integrity (normative, recommended)
The manifest is not just “nice documentation.” It is evidence. You should protect it like evidence.

Recommended pattern:

  • Emit both manifest_id and manifest_hash (for example, SHA-256 of the manifest file bytes).
  • Each consumer SHOULD log both, along with the incoming data.

Example fields to attach:

manifest_id:    "SSMT-CORE-001"
manifest_hash:  "sha256:...hex..."
schema_version: "1.1"
spec_version:   "vX.Y"

Why both schema_version and spec_version?

  • schema_version tells you which field layout the device is using.
  • spec_version tells you which edition of the public standard you believe you’re following.
    They can evolve at different speeds.

Practical effect:
If someone later disputes an alert, you can prove “These readings were generated under manifest hash H, which matches the schema we published, and the thresholds were exactly E_hot, E_cold, Phi_freeze that were in force that day.”

8.4 Domain guards and numeric safety (must)
The math itself has safety rails. These guards MUST be enforced before emitting symbols.

Lens domains.
Each lens only makes sense under certain physical/numeric conditions.

log, beta:
  require T_K > 0 and T_ref > 0

linear:
  require DeltaT > 0

kBT:
  require E_unit > 0

hybrid:
  require tau > 0
  linear branch inherits DeltaT > 0
  log branch inherits T_K > 0 and T_ref > 0

qlog:
  require T_ref > 0 and alpha > 0
  # "qlog" keeps e_T = 0 at T_ref and stays numerically sane near 0 K

If any of these guards fail, you MUST NOT silently emit “good-looking numbers.” You MUST either mark health.sensor_ok = false / health.range_ok = false (depending on cause), or refuse to emit that channel until the config is valid.

Clamps.
Bounded dials must stay bounded.

a_T      := tanh(c_T * e_T)
a_T      := clamp_a(a_T, eps_a)

a_phase  := tanh( c_m * ( (T_K - T_m) / DeltaT_m ) )
a_phase  := clamp_a(a_phase, eps_a)

|a_T|      <= 1 - eps_a
|a_phase|  <= 1 - eps_a

The manifest MUST publish eps_a, and eps_a MUST satisfy 0 < eps_a <= 1e-3. This protects downstream math from runaway magnitudes.

Saturation on out-of-range.
If the temperature is outside the declared safe numeric range:

T_K_eff := min( max( T_K , T_min ) , T_max )
oor     := "below_min" | "above_max"
health.range_ok := false

You MAY compute downstream dials (like e_T) using T_K_eff for numeric stability, but you MUST keep the flag. You are not allowed to pretend the reading was normal.

Kelvin floor.
Always apply:

T_K := max( T_K , eps_TK )

and publish eps_TK if non-default. This avoids undefined behavior near 0 K and protects log-style lenses.

Hysteresis stability.
For Q_phase and similar memory lanes:

rho     in (0,1)
k_side  > 0

This ensures soft memory is mathematically well-behaved and doesn’t oscillate wildly.

8.4.1 Extreme regimes (limits, normative)
Some environments push temperature handling into cryogenic, high-temperature, plasma, or radiation-driven extremes. In those regimes, numeric stability and honesty become even more important.

When to apply this block.
Declare an “extreme regime” policy when any of these are true:

  • Typical operating band is below 100 K.
  • Typical operating band exceeds 1000 K.
  • The medium is exotic (plasma, high vacuum, radiation-driven conduction/radiation balance).
  • Conventional assumptions about phase transitions do not hold cleanly.

Required declarations under extreme regime:

  1. Lens choice with justification.
    Teams SHOULD prefer beta or kBT when the cold-side or energy-per-mole story matters, and MAY use qlog very close to 0 K to maintain numeric sanity.
    If using hybrid or log in an extreme regime, you MUST publish why that is acceptable for the declared range.
  2. Explicit numeric band.
    You MUST declare:
T_valid_range_K = [T_min, T_max]
precision_K
precision_e_T

and you MUST document sensitivity limits for interpretation. If you provide quantized/bucketed versions of e_T, publish the bucket policy.

  1. Saturation with explicit flag.
    You MUST continue to compute using:
T_K_eff := min( max( T_K , T_min ) , T_max )

and you MUST mark oor so that downstream analysis knows the reading was outside validated range. Threshold logic MUST honor that flag in decisions.

  1. Phase pivots.
    Each pivot T_m MUST be physically justified. If phase behavior is uncertain or non-classical, you SHOULD omit a_phase for that pivot instead of faking precision.
  2. Validation surface.
    Your CI MUST include:
  • Lens monotonicity over [T_min, T_max].
  • Pivot symmetry at T_m (if using a_phase).
  • Failure injection for known issues such as sensor lag or self-heating.
  1. Manifest note.
    The manifest MUST clearly state:
"extreme_regime": true

and summarize why the chosen lens, pivots, and numeric ranges are considered valid.

The result is that even in edge physics, the symbolic dials stay replayable and bounded — not hand-waved.

Navigation
Previous: SSMT – Policy Snippets, Commissioning Discipline, and Rollout Strategy (7.9–7.12)
Next: SSMT – Conformance, Privacy, Accessibility, and Symbol-First Audit (8.5–8.7)

Directory of Pages
SSMT – Table of Contents