SSMT – What Goes on the Wire (0E)

What you actually emit: the portable, auditable thermal record

Once you’ve done the Kelvin conversion, chosen your lens, and declared your pivots, what do you actually send forward?
Answer: not raw °C or °F. You send a self-describing symbolic record.

This page shows what an SSMT-enabled system streams or logs in practice.
This is the point where temperature becomes portable across vendors, cities, data centers — and even habitats — without giving up accountability.


1. The minimal (“Lite”) record

For many deployments, you don’t need every dial. You just need a stable, unitless contrast and enough context to audit later.

A “Lite” SSMT record looks like this:

{
  "timestamp_utc": "...",
  "e_T": <number>,
  "manifest_id": "<string>",
  "health": {
    "range_ok": true/false,
    "sensor_ok": true/false,
    "drift": true/false
  }
}

Why this matters:

  • e_T is unitless and zero-centered (e_T = 0 at T_ref).
  • The consumer doesn’t need to know if the original sensor was logging °C or °F. That drama is gone.
  • manifest_id lets any reviewer go back and see which lens, which pivots, which guards you promised to use.
  • health is honesty. If the sensor was out of declared range or looked physically impossible, you admit it.

This “Lite” surface alone is already enough for:

  • dashboards,
  • fleet monitoring,
  • ML features,
  • long-term trend/stability scoring,
  • insurance/certification trail.

You are sending “how far from nominal are we?” not “local engineer’s custom °F offset.”


2. The full SSMT record (richer survivability info)

When survivability, material integrity, or human safety matters, you usually want more than just e_T.
You want to know which side of danger you’re on and how long you’ve lived there.

The full record looks like this:

{
  "timestamp_utc": "...",
  "e_T": <number>,
  "a_T": <number, optional>,
  "a_phase": <number, optional>,
  "Q_phase": <number, optional>,
  "T_m_tag_list": ["<string>", ... , optional],
  "manifest_id": "<string>",
  "health": {
    "range_ok": true/false,
    "sensor_ok": true/false,
    "drift": true/false
  },
  "oor": false | "below_min" | "above_max"
}

What each piece is for:

  • e_T
    Your declared contrast. The canonical “how far from baseline” signal.
  • a_T (optional)
    A bounded dial in (-1,+1) from a_T := tanh(c_T * e_T) then clamped.
    This is ideal for dashboards, pooled scoring across arrays, or ML priors where you don’t want one outlier to dominate.
  • a_phase (optional)
    Your live survivability dial around a specific pivot, from
    a_phase := tanh( c_m * (T_K - T_m) / DeltaT_m ).
    Tells you “which side of the line are we on, and how deep?”
  • Q_phase (optional)
    The smoothed memory channel that prevents alert flicker and encodes dwell time in danger.
    This is what you escalate on.
  • T_m_tag_list
    Human-readable tags for the pivots you’re publishing ("freeze", "warp", "human_hot", "boil", etc.).
    This lets downstream consumers interpret a_phase without reverse-engineering your materials science.
  • manifest_id
    Cryptic but critical. It’s how anyone in the future can replay your numbers and confirm you didn’t quietly change policy mid-stream.
  • health
    Live integrity flags:
    • range_ok: was T_K inside the declared T_valid_range_K?
    • sensor_ok: does the reading satisfy the basic sanity of the chosen lens? (for example, T_K > 0 for the log lens)
    • drift: are we marking long-term sensor drift?
  • oor
    A simple label for out-of-range: "below_min", "above_max", or false.

Combined, this becomes a self-contained audit object.
You can hand this record to a third party and let them judge safety without giving them your internal SCADA wiring, your raw °F, or your control loop.


3. Why we always include manifest_id

Without manifest_id, someone can always claim after an incident:
“We used a tighter safety band; the system just didn’t trigger.”

With manifest_id, you can look at the manifest that was actually in force at that timestamp:

  • Which lens did you say you were using: "log", "linear", "qlog"?
  • What was T_ref?
  • What pivot did you call “unsafe for skin” or “warp risk,” and what was its DeltaT_m?
  • What hysteresis rho did you claim would prevent flicker?

The record plus the manifest is proof of intent.
It is verifiable.
It is portable.
It is defensible.

That combination is what allows:

  • cities to publish thermal risk feeds without politics over units,
  • insurers to underwrite based on auditable rules,
  • mission control to compare different habitats or suits or coolant loops without renegotiating units on every call.

4. Human display vs machine logic

SSMT is very explicit about this separation:

  • Human dashboards and regulatory printouts are allowed to show °C / °F for comfort, legal compliance, or readability.
  • Machine logic (alert routing, gating, triage, ML features, roll-up KPIs, compliance scoring) should consume only the symbolic channels:
    • e_T
    • a_phase or a_phase_fused
    • Q_phase
    • and optional a_T

This stops a quiet UI tweak (“show °F here instead of °C”) from accidentally changing alert behavior.

You get cleaner safety, cleaner audits, and fewer embarrassing “we thought that was Fahrenheit” failures.


5. Practical tiers of rollout

Think of SSMT adoption in tiers:

Tier S1 (Lite)
Emit e_T, manifest_id, and health.
No survivability dial, no hysteresis memory.
Minimal friction. Ideal for analytics and reporting.

Tier S2 (Phase-aware)
Add a_phase (or a_phase_fused) and optionally Q_phase.
Now you see survivability and dwell time near critical pivots.
Ideal for infrastructure, life support, cold chain, or battery safety.

Tier S3 (Fleet governance / ML)
Add a_T, the bounded dial derived from e_T.
Now you can pool across arrays, rank assets by stress, or feed ML models stable features in (-1,+1).

You can start at S1 and upgrade later.
The manifest tells everyone which tier you’re emitting at any moment.


6. This is not vendor lock-in

Notice what’s missing:

  • There is no central server you’re forced to call.
  • There is no secret key handshake required to interpret e_T.
  • There is no proprietary unit.

After you declare your manifest, anyone — including an auditor, a regulator, another vendor, or even a future you — can replay your numbers and get the same result.

That is deliberate.


Navigation
Previous: SSMT – Phase Dials, Hysteresis, and Survival Bands (0D)
Next: SSMT – Encoding SSMT: Kelvin, Lens, and Contrast (1.1–1.3)


Directory of Pages
SSMT – Table of Contents