SSMT – Pooling Sensors, Declaring Valid Ranges, and Staying Honest (1.6.x–1.8)

Multiple sensors. Multiple pivots. One clean story the whole fleet can trust.

We’re now in “fleet reality”:

  • You have more than one sensor.
  • You care about more than one survival limit.
  • You need to tell the truth even when a sensor misbehaves.

This page covers three things:

  1. Fusing multiple danger pivots into one safety dial (multi-pivot fusion).
  2. Declaring validity ranges and marking out-of-range honestly.
  3. Pooling multiple sensors without losing physics or lying to yourself.

1.6.x Multi-pivot fusion — normalized form
Sometimes you have several critical boundaries at once:

  • “Don’t freeze” and “don’t boil.”
  • “Don’t gel” and “don’t warp.”
  • “Safe for skin” and “unsafe for skin.”

Instead of raising five separate alarms, SSMT lets you fuse them into one bounded survival dial.

We first normalize each pivot the same way we did for a_phase, then blend them in a controlled, scale-stable way:

# Per pivot i:
z_i := c_m_i * (T_K - T_m_i) / DeltaT_m_i

# Weighted, scale-stable aggregator
W     := max( sum_i w_i , eps_w )
z_bar := (1 / W) * sum_i( w_i * z_i )

# Bounded fused dial
a_phase_fused := tanh(z_bar)
a_phase_fused := clamp_a(a_phase_fused, eps_a)

Where:

  • Each pivot i has:
    • T_m_i : its critical pivot (K)
    • DeltaT_m_i > 0 : softness width for that pivot
    • c_m_i > 0 : sharpness/importance of that pivot
    • optional label/tag like "freeze", "warp", "human_hot"
  • w_i > 0 are weights you choose to emphasize some pivots more than others (default w_i = 1).
  • eps_w > 0 guards against divide-by-zero in z_bar.
  • eps_a keeps the bounded dial inside (-1,+1).

What this gives you:

  • One scalar a_phase_fused in (-1,+1) that says “overall thermal survivability posture.”
  • Comparable meaning even if different assets track a different number of pivots, because the weighted average normalizes by total weight W.

Usage guidance:

  • Emit either a_phase for a single dominant pivot, or a_phase_fused for multi-pivot safety. You usually don’t need both.
  • You can still carry along T_m_tag_list (list of pivot tags) for audit trails and post-incident review.

This is ideal for:

  • life support envelopes,
  • structural integrity envelopes,
  • high-value cargo with multiple thermal failure modes,
  • crew safety dashboards where a single dial must be read in a hurry.

1.7 Validity and out-of-range handling (normative)
Honesty is part of the standard.
If your reading is outside the published valid range, you must say so.

Declare the expected safe physical range in Kelvin for this deployment:

T_valid_range_K := [T_min, T_max]

If a reading goes outside the range:

  1. Mark health.
  2. Still produce a stable symbolic number so dashboards don’t explode.

Process:

# 1. Flag the record
if (T_K < T_min) or (T_K > T_max):
    health.range_ok := false
    oor := "below_min" | "above_max"  # pick which one
else:
    health.range_ok := true
    oor := false

# 2. Stabilize for math (optional)
T_K_eff := min( max(T_K, T_min), T_max )

# 3. Derive symbolic forms from T_K_eff
e_T_eff  := encode_eT(T_K_eff, ...)
a_T_eff  := tanh(c_T * e_T_eff)          # only if you emit a_T

Key rules:

  • You do not lie about the physical reading. You keep the real T_K attached.
  • You do provide a “stability version” (T_K_eff) so pooled math and dashboards don’t blow up.
  • You must expose that this was out of declared bounds via health.range_ok := false and the oor flag.

Also:

  • If your chosen lens mathematically requires T_K > 0 (for example log or beta) and you would violate that, you must also set health.sensor_ok := false. That’s how the fleet later knows “this spike was nonsense, not physics.”

Why this matters:

  • Regulators and insurers can audit your honesty.
  • Engineers don’t have to reverse-engineer 15 alert emails to figure out whether a sensor went insane or a freezer actually failed.
  • You can prove, later, that you weren’t silently clipping safety data to look good.

1.8 Fleet or array pooling (safe, associative)
Now assume you don’t just have one sensor. You might have:

  • six probes on a cooling loop,
  • a ring of suit thermistors around a crew member,
  • thermal monitors at different points in a habitat wall,
  • three redundant sensors on a battery module.

How do you merge them without cheating physics or letting one noisy sensor dominate?

SSMT uses “rapidity pooling,” which is order-invariant and bounded.

pool_alignments(a_list, w_list=None, eps_a=1e-6, eps_w=1e-12):
    if w_list is None:
        w_list = [1 for _ in a_list]

    U = 0.0
    W = 0.0
    for a_i, w_i in zip(a_list, w_list):
        # clamp to keep |a_i| < 1
        a_i_clamped = clamp_a(a_i, eps_a)
        U += w_i * atanh(a_i_clamped)
        W += w_i

    W = max(W, eps_w)
    return tanh(U / W)

What this does:

  • Converts each bounded dial (for example a_T, or a_phase, or a_phase_fused) into its “rapidity space” using atanh.
  • Averages in that space using weights w_i.
  • Maps back into (-1,+1) using tanh.

Why it’s special:

  • It is associative and order-invariant.
    Pool [A,B,C] in any order → same result.
  • It is stable under shuffling and streaming.
    You can pool live or in batch: same outcome within epsilon.
  • No single extreme sensor can “run away” to infinite importance because all inputs are bounded and clamped.

This is critical for:

  • control loops that need one “fleet thermal stress” dial,
  • dashboards that summarize “module survivability posture,”
  • ML features that describe “panel health” instead of just a single point reading.

And because it’s deterministic, you can replay it in audits.

Bringing it together
At this point the stack looks like this:

  • T_K → (Kelvin, floored by eps_TK)
  • e_T → (unitless contrast vs published baseline)
  • optional a_T → (bounded stress dial, safe to pool)
  • optional a_phase / a_phase_fused → (safety/survival dial around one or many pivots)
  • Q_phase → (memory dial that encodes how long you’ve effectively lived in danger)
  • pooling via rapidity → (fleet-level truth, not a noisy snapshot)
  • T_valid_range_K, health.range_ok, oor → (honesty and traceability)

This is no longer “temperature in °C.”
This is “thermal truth, in a form that a fleet, a regulator, a habitat commander, and a risk model can all read the same way.”

Navigation
Previous: SSMT – Memory, Stability, and Flicker Control (1.5.x–1.6)
Next: SSMT – The Record You Emit and the Rules You Must Publish (1.9–1.11)

Directory of Pages
SSMT – Table of Contents