SSMT – Symbolic Excursions, Flicker, and Governance KPIs (6.4–6.7)

From “how hard did we push the system” to “can policy travel without drama.”

Purpose.
Sections 6.4–6.7 define four clusters of operational KPIs built on top of Shunyaya Symbolic Mathematical Temperature (SSMT): excursion budgets, regime/flicker behavior, fleet roll-up, and governance health. These are the dials executives ask for (“How bad was it?” “Did it chatter?” “Are sites consistent?” “Are we still aligned with policy?”) — expressed in symbol space, not raw °C/°F.

These metrics are portable, replayable, and can be audited by anyone holding the manifest.

6.4 Symbolic excursion budgets (degree-day analogs)

Goal.
Quantify accumulated stress over a period using only symbolic temperature contrast, not raw units. This is how you write “cooling burden” or “overheating exposure” in a way that can be compared across assets, locations, or even materials.

Cooling-like excursions above a symbolic threshold e*:

S-CDD(t1..t2) :=
  sum_{tau=t1..t2} max( e_T(tau) − e* , 0 )

Heating-like excursions below −e*:

S-HDD(t1..t2) :=
  sum_{tau=t1..t2} max( −e_T(tau) − e* , 0 )

How to read this:

  • e_T is your unitless contrast around T_ref.
  • e* is your chosen “too warm” (or “too cold”) symbolic boundary.
  • S-CDD (“symbolic cooling degree-day”) is how much time×intensity you spent above comfort/safe range.
  • S-HDD (“symbolic heating degree-day”) is the mirror on the cold side.

Why it matters:

  • You can write policy like “Reject if S-CDD > 1.5 over the last 24h” and that sentence works in any physical environment once you’ve published the manifest (lens, T_ref, etc.).
  • No one has to translate between °C and °F. The burden is captured directly in symbol space.

This is especially useful in compliance, energy planning, cold-chain integrity, structural fatigue assessment, or mission survival windows.

6.5 Regimes and flicker

Goal.
Stop arguing about “alert storms.” Measure them.

Define a simple symbolic regime tag:

Regime(t) :=
  "HOT"    if e_T(t) >= E_hot
  "COLD"   if e_T(t) <= -E_cold
  "NORMAL" otherwise

Then define flicker over a rolling window [t−L, t]:

Flicker :=
  number_of_changes_in(
    Regime(tau) for tau in [t−L, t]
  )

Two important points:

  • Regime is defined entirely in symbol space (e_T, E_hot, E_cold).
    That means you can apply the same HOT / COLD logic consistently across many assets.
  • Flicker counts how often you bounced between regimes.
    High Flicker means the system kept crossing thresholds and coming back. That’s where human operators get spammed.

What you want over time:

  • Flicker goes down,
  • True positive capture stays high.

When SSMT hysteresis (Q_phase, dwell rules, “stay in risk unless cleared for N minutes,” etc.) is active, Flicker should drop sharply even in edge conditions (for example, hovering near a freeze pivot). This is proof that soft hysteresis and dwell-based clears are working.

This is also usable as a contract metric: “We accept alerts if Flicker per site per day stays under X.”

6.6 Fleet KPIs (portable across sites)

Now that e_T, a_phase, and hysteresis are normalized and bounded, you can compute fairness-style KPIs across an entire fleet without rewriting thresholds per site.

Core fleet KPIs:

HotFraction :=
  P_t( e_T >= E_hot )

ColdFraction :=
  P_t( e_T <= -E_cold )

RiskPhaseFraction :=
  P_t( a_phase_star <= -Phi_freeze )

MaxPhaseIntrusion :=
  max_{tau in [t−L, t]}( -a_phase_star(tau) )

ClearLatency :=
  min { Δt >= 0 :
        a_phase_star(t+Δt) >= +Phi_clear }
  (measured after entering risk)

Definitions:

  • P_t(...) is “fraction of time in the last window [t−L, t] where condition holds.”
  • a_phase_star(t) is whichever phase dial you chose:
    • a_phase for a single pivot (like freezing),
    • a_phase_fused if you’re tracking multiple pivots (for example, multiple material limits).
  • Phi_freeze, Phi_clear, E_hot, E_cold are declared symbolic thresholds.
  • MaxPhaseIntrusion captures “how deep into the dangerous side did we go.”
  • ClearLatency measures “once we went unsafe, how long until we were confidently back in the safe band.”

Why this matters:

  • You can now benchmark different locations or subsystems using one shared language.
  • You can tell which sites are constantly flirting with unsafe states, even if their absolute raw temperatures are different.
  • You can report how quickly systems recover after hitting a risk band, in a way that is replayable from symbolic logs.

For downstream teams (operations, maintenance planning, risk review), these KPIs are the difference between “we think Site A is struggling” and “Site A spent 12% of the last 24h in cold-side risk, took 47 minutes on average to clear, and hit a maximum phase intrusion of 0.72.”

6.7 Stability and governance metrics

These final signals measure whether the SSMT fabric itself is behaving the way it promised — anchors stable, thresholds portable, health flags meaningful.

Anchor stability
DriftFlag :=
  1 if | median_{[t−L, t]}( e_T ) |
        > E_drift
  else 0
  • If DriftFlag is 1, it means your declared baseline (T_ref, seasonal/diurnal correction, etc.) might no longer represent “normal.”
  • This is not just physics — it’s governance. It tells you, “Our anchor is sliding. Are we still telling the truth about zero?”
Threshold portability across sites s
PortabilitySpread :=
  max_s( Precision_s )
  − min_s( Precision_s )
  • Imagine applying one global hot rule (E_hot) across many sites and measuring how well it identifies meaningful “hot” events at each site.
  • Precision_s is per-site precision of that event rule.
  • PortabilitySpread is the gap between best and worst sites.
  • A smaller spread means your symbolic rule generalizes cleanly. A big spread means one of your sites is being treated unfairly (too sensitive or too lenient) by a supposedly “global” policy.

This is how you prove whether a single symbolic policy can be shared without constant retuning.

Guard or quality monitors
GuardViolationRate :=
  P_t(
    (health.sensor_ok == false)
    OR
    (health.range_ok == false)
  )

OORFraction :=
  P_t( oor != false )

LensConsistency :=
  1 if count_unique(
        resolved_lens over [t−L, t]
      ) == 1
  else 0
  • GuardViolationRate: Are we repeatedly violating declared physical/operational ranges (range_ok == false) or marking sensors unhealthy (sensor_ok == false)? If this is high, something is wrong in the field.
  • OORFraction: How often are we outside the declared valid band (oor != false)? This is a straight “are we living in spec or outside spec?” number.
  • LensConsistency: Did somebody quietly switch the encoding lens mid-run?
    • 1 means no — good.
    • 0 means yes — that’s a violation of policy. You’re no longer comparing like with like across time.

Together, these governance KPIs prove that:

  • The baseline is still trustworthy (DriftFlag),
  • The shared thresholds are still fair (PortabilitySpread),
  • The fleet is staying inside declared physics and config bounds (GuardViolationRate, OORFraction),
  • And no one silently changed how e_T is computed mid-flight (LensConsistency).

This is how symbolic temperature becomes contract-grade.

Navigation
Previous: SSMT – Mini-Metrics Library: Anomaly, Stability, and Phase Dwell (6.1–6.3)
Next: SSMT – Deployment Patterns: Inputs, Emits, and Safe Rules in Symbol Space (7.1–7.4)

Directory of Pages
SSMT – Table of Contents