SSMT – CI, Compliance, and Upgrade Safety (5.4–5.5)

If the math ever drifts, you should know instantly — before it reaches production.

Context.
Tier S1 gives you deterministic tests for Shunyaya Symbolic Mathematical Temperature (SSMT). Sections 5.4 and 5.5 describe how those tests are used in practice: continuous integration, compliance review, and controlled evolution. This is where temperature becomes part of a governed system, not just telemetry.

5.4 CI integration

Goal.
Make symbolic temperature auditable and stable across code changes, firmware updates, and policy revisions. The rule is simple: if the core math changes, the build fails.

Minimum enforcement.

  1. Run Tier S1 tests on every change.
    • Any change to firmware, analytics pipelines, alert logic, dashboards, or manifest-handling code must trigger the Tier S1 harness.
    • If any required property breaks (monotonicity, clamp bounds, valid lens config, pooling associativity, etc.), the release is blocked.
  2. Fail fast on domain-guard violations.
    • If a lens is misconfigured (alpha <= 0 for qlog, DeltaT <= 0 for linear, T_ref <= 0 where it must be > 0, etc.), CI must stop.
    • Silent “fallback math” is not allowed. The system must not auto-repair unsafe inputs and proceed as if nothing happened.
  3. Track “golden outputs.”
    • The canonical examples in the test vectors (unit invariance, phase dial symmetry, hysteresis shape, pooling associativity) each produce specific numeric outputs.
    • Those outputs (within tolerance) become golden baselines.
    • Any drift in those values forces review.
  4. Attach manifest expectations.
    • CI should check not just math but governance:
      • One declared lens.
      • Published T_ref.
      • Declared valid range T_valid_range_K.
      • Clamp floor eps_TK.
      • Flags for health.sensor_ok, health.range_ok, oor.
    • A build that removes or renames these required fields should fail.
  5. Enforce “no hidden renormalization.”
    • Policy must continue to be expressed in symbolic terms (e_T, a_phase, Q_phase, etc.), not quietly switch back to °C/°F in logic.
    • CI can assert this by scanning for direct comparisons against raw °C/°F in decision code and failing if found.

Why this matters.
This prevents an all-too-common failure mode: the symbolic layer is introduced, passes review, and then six months later somebody “quickly” patches in a raw °C cutoff for one corner case. CI makes that impossible to hide. The moment someone tries to bypass the symbolic standard, the build blocks.

This is what lets safety, compliance, data, and legal all agree on what “overheat,” “freeze risk,” or “operationally unsafe” actually means — and prove it.

5.5 Acceptance

Definition.
Acceptance means “this symbolic temperature representation is behaving exactly as declared, and any external party could replay it and get the same decisions.”

Acceptance happens when all of the following hold:

  1. All Tier S1 asserts pass under fixed tolerances.
    • Kelvin floor works.
    • Lenses are monotone and zero out at T_ref.
    • Alignment dials (a_T) stay bounded in (-1,+1).
    • Phase dials (a_phase, or a_phase_fused) show correct sign and magnitude relative to pivots.
    • Hysteresis (Q_phase) accumulates and clears gradually.
    • Pooling is both bounded and associative.
    • Out-of-range readings correctly set health.range_ok = false and record oor.
  2. No change in golden outputs without review.
    • If a change in implementation shifts any of the canonical values (example: the expected a_phase at 271.15 K no longer matches the recorded baseline within tolerance), that is not a minor refactor. That is a spec change and must be treated as such.
  3. Governance fields are still present and still meaningful.
    • The output still carries things like manifest_id, lens, T_ref, and range flags.
    • Human-readable policy remains bound to symbolic terms (e_T >= E_hot, a_phase <= -Phi_freeze for N minutes, etc.), not raw °C/°F cutoffs inside control code.
  4. No external data dependency required.
    • Tier S1 does not rely on production telemetry.
    • Everything can be tested offline.
    • This matters for compliance: you can prove the math is sane before first deployment, and you can prove that any code update hasn’t silently weakened safety logic.
  5. Sign-off is binary.
    • Either SSMT is accepted in that build, or the build is blocked.
    • There is no “partially passes, ship anyway.”
    • The entire point of SSMT is to remove ambiguity in safety review.

Practical outcome.
Once acceptance is achieved, SSMT is not just “a number that came from a sensor.” It is a governed signal with traceable math, declared guardrails, reproducible thresholds, and an audit story that survives personnel changes, system rewrites, and cross-team debate.

That is what elevates temperature from “telemetry” to “infrastructure.”

Navigation
Previous: SSMT – Tier S1 Validation: Proving the Math Holds Before Touching Real Data (5.0–5.3)
Next: SSMT – Mini-Metrics Library: Symbolic KPIs for Operations and Audit (6.1–6.3)

Directory of Pages
SSMT – Table of Contents