Policy you can replay: math, cutpoints, actions, timers, assumptions — all bound to an ID.
12.0 Overview
The manifest turns interpretation into policy. If value is what happened, align is how stable/risky it looked, band is what to do, and stamp is when/ordering proof — the manifest is the rulebook that says what “GREEN/AMBER/RED/A-” meant at that moment, with no room to rewrite later.
12.1 What a manifest is
A compact, published rulebook that declares the math, thresholds, action meanings, timers, constants, and assumptions — and receives an ID carried as manifest_id in every record. Anyone downstream can look up that ID and reconstruct the judgment exactly as it was.
12.2 What a manifest MUST declare
- Identity/scope.
manifest_id, label, optional domain tag. - Alignment math (ASCII). Clamp, transform, weight, fuse, and bound; plus declared constants and weight rule.
- Band thresholds. Numeric cutpoints from align → band.
- Band meaning. One or more actionable sentences per band.
- Escalation timing. Concrete timers where applicable.
- Environment/gating (if used). How gates are computed and applied.
- Validity assumptions. Where this policy applies (and where it does not).
Reference alignment math (required to declare):
a_c := clamp(a, -1+eps_a, +1-eps_a)
u := atanh(a_c)
U += w * u
W += w
align := tanh( U / max(W, eps_w) )
# Declare: eps_a, eps_w, and the weight rule w (e.g., w := 1 | w := |m|^gamma | w := criticality_score)
12.3 Example manifest (industrial / hardware safety)
manifest_id: "PLANT_A_BEARING_SAFETY_v7"
domain: "industrial_bearing_line3"
# Alignment math
eps_a: 1e-6
eps_w: 1e-6
weight_rule: "w := 1"
align_pipeline:
a_c := clamp(a, -1+eps_a, +1-eps_a)
u := atanh(a_c)
U += w * u
W += w
align := tanh( U / max(W, eps_w) )
# Band thresholds (align → band)
bands:
GREEN:
condition: "align >= +0.5"
action: "Continue normal operation."
AMBER:
condition: "-0.2 <= align < +0.5"
action: "Throttle load; schedule inspection within 30 minutes; notify supervisor."
RED:
condition: "align < -0.2"
action: "Shut down affected shaft immediately; lock out; alert safety officer."
# Escalation timing
timers:
AMBER_to_inspection: "30 minutes max"
RED_shutdown: "Immediate"
# Validity assumptions
assumptions:
- "Both vibration_rms and housing_temp_K sensors online."
- "Inspection authority physically present for AMBER resolution."
- "Only safety officer may clear RED for restart."
12.4 Why freezing band cutpoints matters
Publishing numeric cutpoints and action text prevents post-incident goalpost shifts. “RED” cannot be softened later; “AMBER” cannot be retroactively treated as “instant shutdown.” Operators who followed policy are protected by the written thresholds and timers.
12.5 How manifests travel across teams and vendors
Manifests are portable documents — not secrets or centralized dependencies. Finance, safety, AI risk, and chemistry teams can each publish their own manifests. manifest_id lets any recipient request and replay the exact policy offline — comparable across sites without pretending the sites are identical.
12.6 Manifest lifecycle and versioning
Policies evolve; history must not. Changes mint a new manifest with a new ID. Old records keep their original manifest_id. This creates a clean chronological story (“v7 before 15:00, v8 after 15:00”) that auditors and investigators can verify.
One-line takeaway
A manifest is the frozen rulebook for align→band: it declares the math, cutpoints, actions, timers, gates, and assumptions, receives an ID, and travels with every record so meaning can be proven later without debate.
Navigation
Previous — SSMDE — How align Is Actually Computed (11.0–11.5)
Next — SSMDE — The Stamp: Time, Order, Integrity, and Memory (13.0–13.8)
Directory of Pages
SSMDE – Table of Contents
SHUNYAYA 