Skip to content

CTM Process v1.1 — W3C Strict Specification Master

Table of Contents

SECTION 1 — Introduction (Normative)

1.1 Purpose

The CTM Process defines the operational procedure that transforms real-world events into formal Civic Stress Trajectories, enabling consistent evaluation of societal stress, threshold sensitivity, and governance-style response patterns. It is the procedural complement to the CTM Model v1.0 and integrates all governance-style mechanics defined in Governance Styles v1.0.


CTM Process v1.1 extends v1.0 with:
Load smoothing

Threshold drift

Oscillation

detection

Multi-event bundles

Enhanced classification

logic

Governance-style interaction updates

Stability

metrics

Clarifications from Round 1–2 Review AIs

The intent is to provide a
deterministic, complete, and implementable specification suitable for analytical
engines, including CT Monitor and Cortex.

1.2 Scope

The CTM Process v1.1 governs:
Event parsing

Domain identification

Stress vector

generation

Load updating

Shock memory

Threshold evaluation with

drift

Governance-style modifiers

Friction and composite metrics

Trajectory

classification

It does not govern:
Public narrative interpretation

Moral

judgments

Normative political analysis

Downstream visualization

Prediction

models (reserved for v1.2+)

1.3 Document Status

This document is a W3C-style
Editor’s Draft, normative except where explicitly marked as non-normative in
Appendices.
All MUST, MUST NOT, and SHOULD statements are binding for conformant
implementations.

1.4 Dependencies

CTM Process v1.1 depends on two frozen
documents:
CTM Model v1.0 (canonical architecture)

Governance Styles v1.0

(Universal Fields and interaction rules)

No other inputs are required.

1.5
Core Principles Determinism: Given the same inputs, the system must produce the
same outputs.

Sequential evaluation: Each step uses the updated state from all

prior steps.

Non-feedback in v1.1: Composite governance modifiers do not alter

Load in this version.

Traceability: All intermediate values must be

inspectable.

Domain specificity: Stress and load are maintained

per-domain.

Minimal assumptions: v1.1 does not require sociological or

narrative interpretation.

1.6 Normative Terminology

This document uses:
MUST
/ MUST NOT to indicate mandatory requirements

SHOULD / SHOULD NOT for

recommended but optional behavior

MAY for optional behavior

Non-normative

for informative material

1.7 Overview of Improvements in v1.1

CTM Process v1.1
introduces the following enhancements:
Exponential smoothing of
Load

Threshold drift mechanics with stability factors

Oscillation detection

and amplitude tracking

Full support for multi-event bundles

Extended

trajectory classification rules

Deterministic ordering of

computations

Clarified state update timing

Non-feedback architecture

explicitly defined

Composite governance modifiers smoothed and

displayed

Distinction between base Load and AdjustedLoad maintained

Gradient

safety clarifications

These improvements increase stability, interpretability,
and diagnostic precision without altering the CTM Model v1.0 architecture.

1.8 Implementation Requirements

A conformant implementation:
MUST follow all step
sequences in order

MUST compute all intermediate variables unless explicitly

noted as optional

MUST implement smoothing parameters (α, β, λ)

MUST

implement threshold drift parameters (γ1, γ2, γ3)

SHOULD log all state

transitions for auditability

MAY apply additional smoothing or reporting

layers if results remain unchanged

SECTION 2 — Normative References (Normative)

This section lists the documents that are required to correctly
interpret and implement CTM Process v1.1. All listed references are normative
unless explicitly marked otherwise.

2.1 CTM Model v1.0 (Normative)

The CTM Model
establishes the six-layer architecture underpinning the CTM Process:
Layer 1 —
Stress Vector Layer

Layer 2 — Load Accumulation Layer

Layer 3 — Threshold

Layer

Layer 4 — Governance-Style Layer

Layer 5 — Interaction/Friction

Layer

Layer 6 — Trajectory Layer

All variable definitions, polarity
structures, threshold concepts, and architectural sequencing originate from CTM
Model v1.0.
CTM Process v1.1 MUST be implemented in accordance with CTM Model
v1.0.

2.2 Governance Styles v1.0 (Normative)

Defines all Universal Fields used
throughout the CTM Process:
SUL — Stability Under Load

CD — Coordination

Difficulty

ShockFrequency

SignalCoherence

BandwidthConsumption

IA —

Institutional Authority

These fields directly affect:
Decay rate

Threshold

sensitivity

Composite governance modifiers

Oscillation detection

Friction

metrics

CTM Process v1.1 MUST use the Universal Field definitions exactly as
specified in Governance Styles v1.0.

2.3 CTM Process v1.0 (Historical Reference, Informative)

CTM Process v1.1 is structurally based on CTM Process
v1.0 but adds:
Smoothing

Drift

Oscillation

Multi-event

bundling

Clarifications from Review AI rounds

The original v1.0 remains
informative and SHOULD NOT be used for implementation when v1.1 is
available.

2.4 External Standards (Informative)

The following are informative
references for structure and formatting:
W3C Style Guidelines (structural
consistency)

IETF RFC 2119 (definition of normative terminology)

IEEE Style

Guides (general engineering specification formats)

These standards shape
formatting conventions but impose no mechanical rules on CTM.

SECTION 3 — Definitions and Symbols (Normative)

This section defines all variables, symbols,
and terminology used throughout CTM Process v1.1.
A conformant implementation
MUST interpret these terms exactly as defined here.

3.1 Core Terms

Event

A real-world occurrence that produces civic stress. Examples include political
actions, institutional failures, regulatory changes, violence, or major public
statements.

Event Bundle

A collection of multiple events occurring within a
defined temporal window that MUST be processed together in v1.1. Bundling
improves interpretability and prevents oscillatory artifacts caused by
sequential micro-processing.

Domain

One of the eight canonical CTM
domains:
Executive

Legislature

Judiciary

Norms

Security

Economy

Media/Information

Civic

Culture

Domains determine where stress vectors apply.
Stress Vector (SV)A
structured representation of an event’s effect on one domain.
LoadA per-domain
measure of accumulated stress.
ShockMemoryA time-decayed record of recent
high-intensity stress events that modifies threshold sensitivity.

3.2 Polarity Symbols

Each Stress Vector includes a PolarityType with corresponding numeric
weights.
Positive Polarity (+C)Constructive action that reduces
instability
Weight = -1.0
Negative Polarity (–S)Structural erosion
Weight =
+1.25
Negative Polarity (+S)Short-term stabilizing action with long-term
cost
Weight = -0.75
Positive Polarity (+D)Destabilizing innovation
Weight =
+0.75
Negative Polarity (–D)Destructive destabilization
Weight = +1.0
Polarity
weights MUST be applied exactly as listed.

3.3 Magnitude Scale

All events have a
Magnitude level from 1 to 5:
1 = negligible
2 = low
3 = moderate
4 =
significant
5 = severe
Magnitude determines the impact of Stress Vectors on Load
and ShockMemory.

3.4 Mathematical Symbols

Symbol
Meaning

i
domain

index

b
branch index

Load_i(t)
Load for domain i at time

t

ShockMemory_i(t)
shock memory for domain i at time t

α
Load smoothing

coefficient

β
ThresholdModifier smoothing coefficient

λ
Composite modifier

smoothing coefficient

γ1, γ2, γ3
drift coefficients

SV_j
j-th Stress

Vector

M_j
magnitude of SV_j

PolarityWeight_j
numeric weight based on

polarity

EffectiveThreshold_state
threshold adjusted for governance style and

drift

DriftRate
computed threshold drift for this

cycle

OscAmplitude_i
oscillation amplitude for domain i

ΔLoad_i
first

derivative of Load_i

Δ²Load_i
second derivative of

Load_i

ActorScale
event-scale multiplier (1.0–3.0)

3.5 Branch vs System Variables

Branch-Level Variables

SUL

CD

IA

Amplification_b

OscProb_b

Latency_b

These MUST
be computed per branch.
System-Level Variables

CompositeAmplification

CompositeOscProb

CompositeLatency

CompositeStability

Load_system

OscillationIndex

These
MUST be computed through IA-weighted aggregation.

3.6 Threshold States

CTM Process v1.1 defines five possible system
states:
Normal

Strained

Crisis

LBT — Legitimacy Breaking Threshold

CCT

— Civilizational Collapse Threshold

Threshold states are determined by
comparing Load_system to EffectiveThreshold values.

3.7 Reserved Terms for v1.2

The following terms appear only in preview contexts and MUST NOT be
implemented in v1.1:
MetaTrajectory

Drift Zones

Feedback Load

Amplifier

Parallel Event Interaction Matrix

3.8 Notes on Terminology

Load
always refers to base smoothed Load unless explicitly stated
otherwise.

AdjustedLoad includes friction effects and SHOULD NOT be used for

threshold comparisons.

Trajectory strictly refers to the 6A/6B/6C

classification.

Event Complexity refers to multi-domain or multi-polarity

properties of a single event.

SECTION 4 — Process Overview (Normative)

This
section provides a formal, high-level description of the CTM Process.
It defines
the required sequence, dependencies, and data transformations before the
detailed step-by-step procedures in Sections 5–12.
A conformant implementation
MUST execute all steps in the exact order described here.

4.1 Architectural Structure

CTM Process v1.1 follows the six-layer CTM architecture defined in CTM Model v1.0, operationalized through eight sequential steps:
CTM Layer
Process
Step
Description

Layer 1
Steps 1–3
Parse events → identify domains →

generate stress vectors

Layer 2
Step 4
Update Load, apply smoothing, update

ShockMemory

Layer 3
Step 5
Compute EffectiveThresholds, drift, and determine

threshold state

Layer 4
Step 6
Apply governance-style modifiers and compute

composite metrics

Layer 5
Step 7
Compute friction, stability, oscillation,

and AdjustedLoad

Layer 6
Step 8
Classify the resulting trajectory as 6A, 6B,

or 6C

This structure MUST NOT be altered.

4.2 Required Inputs

A conformant
implementation MUST accept the following inputs:

4.2.1 Event Input Raw text description

Timestamp

Actor identity (optional but recommended)

ActorScale

(1.0–3.0)

EventBundle grouping (if applicable)

Event parsing is defined in
Section 5.

4.2.2 Governance Inputs

From Governance Styles v1.0:
SUL per
branch

CD per branch

IA per branch

ShockFrequency per

branch

SignalCoherence per branch

BandwidthConsumption per branch

All
governance-style inputs MUST be loaded before executing Step 6.

4.2.3
Persistent System State Load_i(t) per domain

ShockMemory_i(t) per

domain

Previous cycle’s DriftRates

Previous cycle’s

OscAmplitude_i

Previous threshold states

This state MUST be preserved
between cycles.

4.3 Required Outputs

A conformant CTM implementation MUST
produce a CTM Result Packet, containing:
Trajectory classification (6A, 6B,
6C)

EffectiveThreshold values

Drift metrics

Governance-style modifiers

(per branch & composite)

Load values and derivatives

Friction

metrics

Oscillation metrics

The CTM Result Packet MAY contain additional
metadata but MUST contain the fields listed above.

4.4 Processing Sequence (Normative)

A conformant implementation MUST execute the following sequence:
Step
1: Parse event→ produce structured event representation
Step 2: Identify
domains→ produce domain activation vector
Step 3: Generate stress vectors→
produce SV list
Step 4: Update Load and ShockMemory→ compute Load_i(t+1), apply
smoothing
→ compute ShockMemory_i(t+1)
Step 5: Compute EffectiveThresholds→
apply drift
→ determine threshold state
Step 6: Apply governance-style
modifiers→ compute per-branch amplification, latency, oscillation probability
→
compute composite values
Step 7: Compute friction and stability metrics→
calculate volatility drag, friction index, OscAmplitude_i, ΔLoad_i, Δ²Load_i
→
compute AdjustedLoad
Step 8: Classify trajectory→ evaluate deterministic rules
→
output 6A, 6B, or 6C
No step MAY be reordered or skipped.

4.5 Determinism Requirements

CTM Process v1.1 MUST produce the same output given identical
inputs.
Determinism is enforced by:
Explicit ordering of computations

Fully

defined formulas

Non-feedback architecture in v1.1

Strict rule precedence in

Step 8

Prohibition on unspecified randomization

Implementations MAY add
noise or additional smoothing only if results remain identical to the
deterministic reference output.

4.6 Time Model

CTM v1.1 operates in discrete
timesteps:
Each full cycle processes all events in the timestep

Multi-event

bundles MUST be processed as a single timestep

State at timestep t+1 MUST

depend only on timestep t

Continuous-time approximations are out of scope for
v1.1.

4.7 Interpretation NotesBase Load vs AdjustedLoad Base Load determines
threshold crossings and trajectory.

AdjustedLoad is non-normative and purely

diagnostic.

Domain vs System Level All Load, ShockMemory, oscillation, and
drift metrics are maintained per-domain.

System-level metrics MUST be computed

through IA-weighted aggregation.

Non-Feedback ArchitectureGovernance-style
modifiers affect interpretation, NOT stress accumulation.
Feedback loops MAY be
introduced in v1.2 but MUST NOT appear in v1.1.

4.8 Failure Handling (Non-Normative)

Implementations SHOULD safely handle:
division by values near
zero (using epsilon clamps)

missing governance-style data (halt with

error)

malformed events (skip or return error)

out-of-range magnitudes (cap

at [1,5])

These are recommendations; they do not affect normative
behavior.

SECTION 5 — Step 1: Event Parsing (Normative)

Event Parsing is the
first operational step in the CTM Process.
Its purpose is to transform
unstructured real-world information into a structured representation suitable
for domain identification and stress vector generation.
A conformant
implementation MUST follow the requirements in this section.

5.1 Inputs to Step 1

A raw event MAY come from:
news articles

government documents

legal

filings

executive actions

public statements

violence

incidents

institutional failures

social media posts (if

verified)

aggregated feeds (e.g., CT Monitor)

The required input fields
are:
RawText (MUST)

Timestamp (MUST)

ActorScale (MUST; default 1.0 if

unknown)

EventBundleID (OPTIONAL; v1.1 uses bundles when provided)

5.2 Output of Step 1

Step 1 MUST output a structured event object
containing:
Field
Description

EventID
unique

identifier

Timestamp
normalized to system clock

ActorScale
1.0–3.0,

multiplier for stress impact

ParsedDomains
empty list (populated in Step

2)

ParsedPolarities
empty list (populated in Step 3)

ParsedMagnitude
empty

list (populated in Step 3)

BundleID
grouping marker for multi-event

processing

This structured object serves as the canonical event
representation.

5.3 Parsing Requirements

Implementations MUST extract:
5.3.1Actor Identification

Determine whether the actor
is:
individual

institutional

systemic

This determines ActorScale:
Actor
Type
ActorScale

Individual
1.0

Institutional

actor
2.0

National/systemic actor
3.0

If ambiguous, ActorScale SHOULD be
1.0.

5.3.2 Action Identification

Extract the operative action(s) of the
event.
Examples:
“President vetoes funding bill”

“Court overturns regulatory

authority”

“Armed militants attack police station”

“Mass protest escalates

into violence”

“Regulator imposes new sanctions”

5.3.3 Affected Systems and
InstitutionsIdentify which systems might be impacted.
This information feeds
Step 2 (Domain Identification).

5.3.4 Polarity Clues (Preliminary)The system
MAY detect preliminary polarity cues from text, but final polarity assignment
MUST occur in Step 3.
Examples:
constructive intent → possible
+C

institutional degradation → possible –S

innovation or disruption →

possible +D

destabilizing harm → possible –D

The parser MUST NOT assign
polarity weights at this stage.

5.4 Normative Constraints Event parsing MUST
NOT assign domains.

Event parsing MUST NOT assign stress magnitudes.

Event

parsing MUST NOT compute polarities.

Event parsing MUST produce a

deterministic output given identical inputs.

Parsed fields MUST be stored

exactly once per event cycle.

If EventBundleID is present, events MUST be

treated as part of a single cycle.

5.5 Multi-Event Bundling RequirementsIf
multiple events share a BundleID, implementations MUST:
Process all events
together as a single timestep

Aggregate their stress vectors in Steps 3 and

4

Apply Load smoothing AFTER all events are processed

Apply ShockMemory

AFTER all events are processed

This avoids false oscillations caused by
sequential micro-events.

5.6 Examples (Non-Normative)Example 1Raw:
“Supreme
Court invalidates long-standing environmental regulation.”
Parsed
Event:
ActorScale = 3.0 (national institution)

Affected systems: Judiciary,

Norms, Environment (maps to Economy/Civic Culture)

Example 2Raw:
“Finance
Minister resigns amid corruption accusations.”
Parsed Event:
ActorScale =
2.0

Affected systems: Executive, Norms

SECTION 6 — Step 2: Domain Identification (Normative)

The purpose of Step 2 is to determine which of the
eight canonical CTM domains are impacted by the parsed event.
This step MUST
translate the event’s structured content into a deterministic Domain Activation
Vector.

6.1 Canonical Domains (From CTM Model v1.0)

A conformant implementation
MUST use exactly these eight
domains:
Executive

Legislature

Judiciary

Norms

Security

Economy

Media/Information

Civic

Culture

No additional domains MAY be added in v1.1.

6.2 Input to Step
2Inputs:
Parsed event object from Step 1

ActorScale

Extracted institutional

entities

Extracted functional descriptors (e.g., policing, legislation,

courts)

Domain identification MUST NOT use external sociological knowledge
beyond the information provided by the parsed event.

6.3 Output of Step 2Step 2
MUST output:
DomainActivationVector (DAV)A binary vector of length 8:
DAV = [d1,
d2, d3, d4, d5, d6, d7, d8]
where di = 1 if domain i is impacted, otherwise
0.
This vector is passed directly into Step 3 (Stress Vector Generation).

6.4
Domain Identification Rules6.4.1 Executive DomainTriggered when event
involves:
heads of state

cabinet officials

executive

orders

administrative agencies

6.4.2 Legislature DomainTriggered when event
involves:
bills

veto overrides

appropriations

legislative

investigations

6.4.3 Judiciary DomainTriggered when event
involves:
courts

rulings

judicial review

constitutional

interpretation

6.4.4 Norms DomainTriggered when event
involves:
corruption

abuse of power

legitimacy crises

political

violence

ethical violations

6.4.5 Security DomainTriggered when event
involves:
policing

military

paramilitary groups

terrorism

armed

conflict

6.4.6 Economy DomainTriggered when event involves:
financial
markets

taxation

regulatory enforcement

economic policy

6.4.7
Media/Information DomainTriggered when event
involves:
misinformation

censorship

media suppression

information

ecosystem shocks

6.4.8 Civic Culture DomainTriggered when event
involves:
mass protests

elections

public identity narratives

collective

behavior shifts

6.5 Multi-Domain AssignmentA single event MAY impact multiple
domains.
Implementation MUST produce activation for all relevant
domains.
Examples:
A Supreme Court decision impacting environmental regulation
→ Judiciary, Economy, Civic Culture

A government disinformation campaign →

Executive, Media/Information, Norms

Events MUST NOT be restricted to only one
domain.

6.6 Determinism RequirementsA conformant implementation MUST:
Use
keyword and structural cues only from the parsed event.

Produce identical DAV

outputs for identical inputs.

Avoid external political or sociological

inference.

Treat domain identification as purely functional, not

interpretive.

6.7 Domain Identification in Event BundlesFor Event
Bundles:
All events MUST be individually parsed.

Domains MUST be identified

per event.

DAV for the bundle MUST be computed as the bitwise OR of all event

DAVs in the bundle.

Example:
Event 1 DAV: [1 0 1 1 0 0 0 0]
Event 2 DAV: [0 1
0 1 0 1 0 0]
Bundle DAV: [1 1 1 1 0 1 0 0]

6.8 Examples (Non-Normative)Example
1“The President dissolves an oversight panel.”
Domains: Executive, Norms
Example
2“Armed militants seize a police station.”
Domains: Security, Norms, Civic
Culture
Example 3“A central bank abruptly raises interest rates.”
Domains:
Economy, Executive

SECTION 7 — Step 3: Stress Vector Generation (Normative)

Step
3 transforms the domain activation output from Step 2 into formal Stress Vectors
(SVs).
Each Stress Vector captures:
which domain is impacted

the polarity of

the impact

the magnitude of the impact

the actor’s scale-adjusted

influence

A conformant implementation MUST follow the rules in this
section.

7.1 Inputs to Step 3Required inputs:
Parsed event
object

DomainActivationVector (DAV)

ActorScale (from Step 1)

Polarity cues

extracted in Step 1 (informative only)

Event magnitude (determined in this

step)

7.2 Output of Step 3Step 3 MUST output a StressVectorList, where each
Stress Vector SV_j contains:
Field
Description

Domain
one of the eight

canonical domains

PolarityType
+C, –S, +S, +D, –D

PolarityWeight
numeric

weight mapped from PolarityType

Magnitude
integer

1–5

AdjustedMagnitude
Magnitude ×

ActorScale

EffectiveImpact
AdjustedMagnitude × PolarityWeight

This list is
consumed directly by Step 4 (Load Update).

7.3 Magnitude Assignment
RulesMagnitude MUST be assigned according to textual and contextual indicators
in the event.
Magnitude Scale (Normative) Level
Interpretation

1
negligible

action or symbolic effect

2
localized or low-intensity action

3
moderate

institutional impact

4
significant systemic impact

5
severe or

destabilizing systemic impact

Magnitude MUST be assigned deterministically
based on explicit criteria (e.g., level of institution affected, scope of
impact, immediacy of consequence).

7.4 ActorScale AdjustmentAdjustedMagnitude =
Magnitude ×
ActorScale
Where:
ActorScale
Meaning

1.0
individual/local

2.0
institutional

3.0
national/systemic

ActorScale
MUST NOT change polarity type or magnitude level — only scale the effect.

7.5
Polarity Assignment RulesPolarityType MUST be assigned based on event meaning,
NOT sentiment.
7.5.1 +C (Constructive)Actions that strengthen institutions or
reduce instability.
Examples: anticorruption measures, legal compliance,
stabilization steps.
Weight: –1.0

7.5.2 –S (Structural Erosion)Actions that
degrade institutional integrity.
Examples: constitutional violations, corruption
exposure, systemic delegitimization.
Weight: +1.25

7.5.3 +S (Short-Term
Stabilizer)Actions that stabilize short-term conditions but impose long-term
stress.
Examples: emergency powers, temporary financial relief with long-term
cost.
Weight: –0.75

7.5.4 +D (Destabilizing Creative Disruption)Innovations or
changes that disrupt while also creating new equilibria.
Weight: +0.75

7.5.5 –D
(Destructive Destabilization)Actions that cause damage without offsetting
benefits.
Examples: violence, institutional sabotage, catastrophic
failures.
Weight: +1.0

7.6 Stress Vector ConstructionFor each domain di = 1 in
the DomainActivationVector:
Construct:
SV_j = {
Domain: domain_i,

PolarityType: selected polarity,
PolarityWeight: weight mapping,
Magnitude:
integer 1–5,
AdjustedMagnitude = Magnitude × ActorScale,
EffectiveImpact =
AdjustedMagnitude × PolarityWeight
}
StressVectorList = [SV_1, SV_2, …,
SV_k]
Implementations MUST compute one Stress Vector per activated domain.

7.7
Multi-Polarity EventsSome events contain multiple actions with conflicting
polarities.
Examples:
A government provides relief (+C) while suppressing
oversight (–S).

A ruling expands rights (+C) but invalidates long-standing

precedent (+D).

In such cases:
One Stress Vector MUST be generated per
polarity per domain.

Magnitude MUST be split or assigned

proportionally.

Example:
Event contains actions +C and –S in the same
domain:
DAV = [1 0 0 1 0 0 0 0]
PolarityTypes = [+C, –S]
Produces:
SV_1
(Domain=Executive, +C)
SV_2 (Domain=Executive, –S)
Implementations MUST NOT
collapse multi-polarity events into a single vector.

7.8 Multi-Event BundlesIf
events are bundled:
Stress vectors MUST be generated per event.

Bundles MUST

concatenate all SVs into a single StressVectorList.

No vector may overwrite

another.

Example:
Event A produces 3 SVs; Event B produces 2 SVs → bundle
produces 5 SVs.

7.9 Determinism RequirementsA conformant implementation
MUST:
Map polarity types directly to fixed numeric weights.

Use deterministic

magnitude rules.

Apply ActorScale uniformly.

Produce the same output given

identical parsed events.

Interpretation MUST NOT vary across
implementations.

7.10 Examples (Non-Normative)Example 1“President fires ethics
inspector after investigation.”
Domains: Executive, Norms
Polarity:
–S
Magnitude: 4
ActorScale: 3
EffectiveImpact: 4 × 3 × 1.25 = 15
Example
2“Supreme Court expands voting rights.”
Domains: Judiciary, Civic
Culture
Polarity: +C
Magnitude: 3
ActorScale: 3
EffectiveImpact: 3 × 3 × (–1.0)
= –9

SECTION 8 — Step 4: Load Update and Smoothing (Normative)

Step 4 computes
updated Load_i(t+1) and ShockMemory_i(t+1) for each domain i, applying:
raw
stress accumulation

exponential smoothing

decay rate adjustment based on

governance stability

deterministic update ordering

This step is a direct
operationalization of Layer 2 (Load Accumulation) in the CTM Model v1.0 and
introduces smoothing improvements in v1.1.
A conformant implementation MUST
follow the rules in this section.

8.1 Inputs to Step 4Required
inputs:
StressVectorList from Step 3

Load_i(t) for each

domain

ShockMemory_i(t)

SUL (per branch)

ThresholdState(t−1)

Smoothing

parameters α (Load) and β (ThresholdModifier)

8.2 Output of Step 4Step 4 MUST
output, for each domain i:
Load_i(t+1) (smoothed)

ΔLoad_i = Load_i(t+1) −

Load_i(t)

ShockMemory_i(t+1)

These values feed directly into Step 5
(Threshold Calculation).

8.3 Raw Load Update (Before Smoothing)For each domain
i, sum the EffectiveImpact of all Stress Vectors targeting domain
i:
RawLoad_i(t+1) = Load_i(t) * DecayRate_i(t) +
Σ(EffectiveImpact_j)
Where:
DecayRate_i(t) is defined in Section 8.4

Σ sums

only vectors where SV_j.Domain = i

Load MAY increase or decrease depending on
polarity mix.

8.4 Decay Rate CalculationDecayRate_i MUST be computed using the
previous timestep’s threshold state:
DecayRate_i(t) = (1 – SUL_i * 0.05) *
ThresholdStateMultiplier(t-1)
ThresholdStateMultipliers (Normative) Threshold
State
Multiplier

Normal
1.0

Strained
0.8

Crisis
0.6

LBT
0.3

CCT
0.3

(Load decay essentially halted)

Decay rate MUST use state(t−1).
This ensures
proper sequential dependency.

8.5 Load Smoothing
(Exponential)SmoothedLoad_i(t+1) MUST be computed as:
Load_i(t+1) = α *
RawLoad_i(t+1) + (1 – α) * Load_i(t)
Where:
α (Load smoothing coefficient) MUST
be between 0.4 and 0.8

Recommended: α = 0.6

The smoothing MUST occur after
RawLoad_i is computed.

8.6 Shock Memory UpdateShockMemory tracks the
accumulated effect of significant stress events.
For each domain
i:
ShockMemory_i(t+1) = ShockMemory_i(t) * 0.5

  • Σ(M_j for all SV_j where
    Magnitude ≥ 4)
    Key rules:
    Only Magnitude 4 or 5 events contribute. ActorScale
    adjustments DO affect the impact, but NOT ShockMemory contribution. Decay
    factor MUST be exactly 0.5.

ShockMemory MUST update after Load but before
ThresholdModifier is used in Step 5.

8.7 Execution Order
(Normative)Implementations MUST update variables in the following
order:
Compute RawLoad_i(t+1)

Compute Smoothed Load_i(t+1)

Compute

ΔLoad_i

Update ShockMemory_i(t+1)

Store results for Step 5

A conformant
implementation MUST NOT deviate from this order.

8.8 Multi-Event BundlesFor
Event Bundles:
Sum EffectiveImpact across all vectors from all events in the
bundle.

Apply smoothing once per bundle, not per event.

ShockMemory MUST

apply the same rule: all qualifying magnitudes in bundle accumulate before decay
is applied.

This prevents artificial time fragmentation.

8.9 Determinism
RequirementsA conformant implementation MUST:
Use identical α for all domains
in v1.1

Apply decay BEFORE smoothing

Use ThresholdState(t−1) ONLY

Apply

ShockMemory updates after Load updates

Refrain from introducing

randomness

8.10 Examples (Non-Normative)Example 1 — High positive stress,
stable governanceLoad_i(t) = 10
SUL = 0.2 → (1 − SUL*0.05) =
0.99
ThresholdState(t−1) = Normal (1.0)
One stress vector: EffectiveImpact =
+8
RawLoad = 10 * 0.99 + 8 = 17.9
SmoothedLoad (α = 0.6) = 0.617.9 + 0.410 =
14.74

Example 2 — Crisis decay + ShockMemory accumulationLoad_i(t) = 40
SUL =
0.3 → (1 − 0.015) = 0.985
ThresholdState(t−1) = Crisis (0.6
multiplier)
EffectiveImpact (sum) = +12
ShockMemory(t) = 5
ShockMemory(t+1) = 5

  • 0.5 + 4 (Magnitude=4 event) = 6.5
    DecayRate = 0.985 * 0.6 = 0.591
    RawLoad ≈ 40
  • 0.591 + 12 ≈ 35.64
    SmoothedLoad (α = 0.6) ≈ 0.635.64 + 0.440 ≈ 37.38

SECTION 9 — Step 5: Threshold Calculation with Drift (Normative)

Step 5
determines:
EffectiveThreshold values for all threshold categories

DriftRate

and drift stability adjustments

Threshold state (Normal, Strained, Crisis,

LBT, CCT)

This is the operationalization of Layer 3 — Threshold Layer in CTM
Model v1.0, extended in v1.1 to include:
Threshold drift

Drift stability

factors

Smoothing of threshold modifiers

Governance-style influence through

StyleSensitivity and CFC

A conformant implementation MUST follow the rules in
this section.

9.1 Inputs to Step 5Required inputs:
Load_i(t+1) per
domain

ShockMemory_i(t+1)

SUL per branch

CFC (Composite Friction

Coefficient)

Drift parameters γ1, γ2, γ3

ThresholdModifier smoothing

β

9.2 System-Wide LoadCTM Process v1.1 operates on per-domain Loads, but
threshold comparisons require a system-level Load.
System Load MUST be computed
as:
Load_system(t+1) = Σ_i Load_i(t+1)
Weighted alternatives MAY be introduced
in v1.2, but v1.1 MUST use simple summation.

9.3 Base Threshold ValuesThe
following BASE thresholds MUST be used in v1.1:
ST (Strained Threshold) =
100

CST (Crisis Threshold) = 200

LBT (Legitimacy Breaking Threshold) =

400

CCT (Civilizational Collapse Threshold) = 800

Base thresholds MUST NOT
be altered unless specifically overridden by:
governance-style
modifiers

ShockMemory

drift

9.4 Style Sensitivity Calculation
(Branch-Level)StyleSensitivity reflects how sensitive a governance-style branch
is to Load.
Per-branch:
StyleSensitivity_b = 1.0 – (SUL_b * 0.1)
System-wide
sensitivity MUST be determined by:
StyleSensitivity_system =
WeightedAvg(StyleSensitivity_b, IA_b)
IA weighted averaging is normative.

9.5
Threshold Modifier (ShockMemory Influence)ShockMemory lowers thresholds, making
them easier to cross.
For each domain:
ThresholdModifier_i_raw = 1 / (1 +
ShockMemory_i * 0.1)
System threshold modifier MUST be
smoothed:
ThresholdModifier = β * ThresholdModifier_i_raw + (1 – β) *
ThresholdModifier_previous
Where β MUST be between 0.5 and 0.9.
Recommended β =
0.7.

9.6 Threshold DriftThreshold drift recognizes that sustained stress or
oscillation can weaken institutional resilience.
DriftRate MUST be calculated
as:
DriftRate = γ1 * SustainedLoadFactor

  • γ2 * OscillationFactor
  • γ3 *
    GovernanceStabilityFactor
    Where:
    9.6.1 Sustained Load FactorSustainedLoadFactor
    = Load_system(t+1) / CST
    9.6.2 Oscillation FactorOscillationFactor =
    OscillationIndex / EffectiveThreshold_Crisis_previous
    9.6.3 Governance Stability
    FactorGovernanceStabilityFactor = CompositeStability_previous
    All
    numerator/denominator divisions MUST clamp denominator to ≥ ε =
    0.0001.
    DriftRate MUST be clamped to the range:
    -0.25 ≤ DriftRate ≤ +0.25

9.7
Effective Threshold CalculationEffectiveThresholds MUST
incorporate:
BaseValue

StyleSensitivity

CFC

ShockMemory-factored

ThresholdModifier

DriftRate

Thus:
EffectiveThreshold_state =

BaseValue_state

  • StyleSensitivity_system
  • (1 + CFC)
  • ThresholdModifier
    *
    (1 + DriftRate)
    This formula MUST be applied for:
    ST CST LBT CCT

9.8
Determination of Threshold StateCompare Load_system(t+1) to EffectiveThreshold
values:
Condition
State

Load_system <

EffectiveThreshold_ST
Normal

EffectiveThreshold_ST ≤ Load <

EffectiveThreshold_CST
Strained

EffectiveThreshold_CST ≤ Load <

EffectiveThreshold_LBT
Crisis

EffectiveThreshold_LBT ≤ Load <

EffectiveThreshold_CCT
LBT

Load ≥ EffectiveThreshold_CCT
CCT

Threshold
state MUST be assigned deterministically using the first matching
condition.

9.9 Detected Drift StabilityCompute drift stability
as:
DriftStability = 1 – abs(DriftRate)
Higher DriftStability indicates stronger
institutional resilience.

9.10 Execution Order (Normative)Step 5 MUST execute
operations in this exact order:
Compute Load_system

Compute per-branch

StyleSensitivity

Compute ThresholdModifier_i_raw

Smooth

ThresholdModifier

Compute DriftRate

Compute EffectiveThresholds

Determine

threshold state

Compute DriftStability

Output results

A conformant
implementation MUST NOT reorder these operations.

9.11 Multi-Event
BundlesBundles MUST compute:
Load_system after all events

ShockMemory after

all qualifying magnitudes

Drift and thresholds once per bundle

Bundles MUST
NOT compute intermediate threshold states.

9.12 Examples (Non-Normative)Example
1 — Moderate Load, High ShockMemoryLoad_system = 180
ShockMemory =
8
ThresholdModifier = 1 / (1 + 0.8) = 0.555
EffectiveThreshold_CST = 200 ×
sensitivity × (1 + CFC) × 0.555 × (1 + drift)
If Load < EffectiveThreshold_CST →
Strained

Example 2 — Rapid oscillation, weak stabilityOscillationFactor ≈
0.3
CompositeStability ≈ 0.5
γ1 = γ2 = γ3 = 0.05
DriftRate ≈ (0.051.2) +
(0.050.3) – (0.05*0.5) = 0.05
Threshold drift increases thresholds
slightly.

SECTION 10 — Step 6: Governance-Style Modifiers (Normative)

Step 6
incorporates the governance-style mechanics defined in Governance Styles v1.0
and fully operationalizes Layer 4 — Governance-Style Layer of the CTM
architecture.
CTM Process v1.1 expands v1.0 by adding:
Smoothing of
governance-style modifiers

Explicit IA-weighted composite metrics

Clear

separation between interpretive modifiers and Load accumulation

Deterministic

sequencing

A conformant implementation MUST follow the rules in this
section.

10.1 Inputs to Step 6Required input fields (per branch b):
SUL_b —
Stability Under Load

CD_b — Coordination

Difficulty

ShockFrequency_b

SignalCoherence_b

BandwidthConsumption_b

IA_b

— Institutional Authority

System-level
inputs:
Load_i(t+1)

ΔLoad_i

DriftRate

prior cycle composite

metrics

10.2 Output of Step 6Step 6 MUST output:
Branch-Level OutputsPer
branch b:
Amplification_b

OscProb_b

Latency_b

Composite
OutputsSystem-level:
CompositeAmplification

CompositeOscProb

CompositeLatency

These
MUST be computed using IA-weighted averages.

10.3 Branch-Level Modifier
Equations10.3.1 Amplification_bAmplification represents how strongly branch b
amplifies or dampens civic stress.
Amplification_b =
(CD_b * 0.3)
+
(ShockFrequency_b * 0.4)

  • (SignalCoherence_b * 0.3)
    Interpretation:
    High CD →
    harder coordination → more amplification High ShockFrequency → more reactive
    system → more amplification High SignalCoherence → stabilizing → reduces
    amplification

Amplification_b MUST be calculated exactly using this
formula.

10.3.2 OscProb_bOscillation probability depends on:
volatility of
recent Load

branch stability

signal alignment

OscProb_b =

(abs(ΔLoad_system) / EffectiveThreshold_Crisis)

  • (1 – SUL_b)
  • (1 –
    SignalCoherence_b)
    Where:
    ΔLoad_system = Σ_i
    ΔLoad_i EffectiveThreshold_Crisis is from Step 5 OscProb_b MUST be clamped
    to [0, 1]

10.3.3 Latency_bLatency describes how quickly branch b reacts to
stress.
Latency_b =
(1 – SignalCoherence_b)

  • (BandwidthConsumption_b *
    0.5)
    Interpretation:
    Low signal coherence → delayed response High bandwidth
    consumption → slower adaptation

Latency_b SHOULD be clamped to a minimum of
0.0.

10.4 Composite Governance MetricsComposite metrics MUST be computed using
IA-weighted averaging.
Let w_b = IA_b / Σ(IA_b)
Then:
CompositeAmplification =
Σ_b (Amplification_b * w_b)
CompositeOscProb = Σ_b (OscProb_b *
w_b)
CompositeLatency = Σ_b (Latency_b * w_b)
These values MUST be used in Step
7 (Friction & Interaction Layer).

10.5 Smoothing Composite ValuesComposite
metrics MUST be smoothed using λ:
CompositeAmplification(t) =
λ *
CompositeAmplification_raw

  • (1 – λ) * CompositeAmplification(t-1)
    Similarly
    for:
    CompositeOscProb CompositeLatency

λ MUST be between 0.3 and
0.7.
Recommended: λ = 0.5.

10.6 Non-Feedback Requirement (Normative)In
v1.1:
Composite governance metrics MUST NOT feed back into Load
accumulation.
They MAY influence interpretive metrics (Step 7) and trajectory
classification (Step 8).
Any implementation that uses CompositeAmplification or
CompositeLatency to directly modify Load is NON-CONFORMANT with v1.1.
These
feedback loops are reserved for v1.2.

10.7 Execution OrderA conformant
implementation MUST compute variables in this exact sequence:
Compute
Amplification_b for all branches

Compute OscProb_b for all branches

Compute

Latency_b for all branches

Compute IA-weighted composite metrics

Smooth

composite metrics using λ

Output results

10.8 Interpretation Notes
(Non-Normative) High CompositeAmplification → the system tends to magnify stress
effects

High CompositeLatency → governance responses are slow

High

CompositeOscProb → system is vulnerable to oscillatory instability

Composite

metrics assist analysts but are NOT used in Load computation

SECTION 11 — Step 7: Friction & Composite Metrics (Normative)

Step 7 operationalizes Layer 5 —
Interaction/Friction Layer of the CTM Model.
This step computes:
friction
metrics

oscillation metrics

stability indicators

adjusted loads for

interpretive use

These metrics do not influence system Load in v1.1 but are
required for diagnostics and classification.

11.1 Inputs to Step 7Required
inputs:
Load_i(t+1)
(smoothed)

ΔLoad_i

CompositeAmplification

CompositeOscProb

CompositeLatency

DriftStability

EffectiveThresholds

Parameters:

W (oscillation window), ε (division clamp)

11.2 Outputs of Step 7A conformant
implementation MUST output:
OscAmplitude_i (per-domain)

OscillationIndex

(system-level)

VolatilityDrag_i (per-domain)

FrictionIndex

(system-level)

AdjustedLoad_i (per-domain)

ΔLoad_i and Δ²Load_i

derivatives

CompositeStability

These feed directly into Step 8 (Trajectory
Classification).

11.3 Load Derivatives (Normative)11.3.1 First derivative:
ΔLoad_iAlready computed in Step 4:
ΔLoad_i = Load_i(t+1) − Load_i(t)
11.3.2
Second derivative: Δ²Load_iΔ²Load_i = ΔLoad_i(t+1) − ΔLoad_i(t)
Implementations
MUST store ΔLoad_i(t) from previous cycle.

11.4 Oscillation
AmplitudeOscillation is measured per-domain:
OscAmplitude_i = abs(ΔLoad_i) +
abs(Δ²Load_i)
OscAmplitude_i MUST be aggregated into a system-level
index:
OscillationIndex = Σ_i OscAmplitude_i
OscillationIndex feeds:
drift
(Section 9)

trajectory determination (Section 12)

11.5 Volatility
DragVolatility drag captures how instability inhibits governance efficiency.
For
each domain i:
VolatilityDrag_i = CompositeOscProb *
OscAmplitude_i
System-level:
FrictionIndex = Σ_i VolatilityDrag_i
A high
FrictionIndex indicates the system is “burning energy” inefficiently.

11.6
AdjustedLoad (Interpretive Only)AdjustedLoad_i reflects friction
effects:
AdjustedLoad_i = Load_i(t+1) * (1 + CFC)
AdjustedLoad MUST NOT be used
to determine threshold state or trajectory.
It is for analyst interpretation
only.

11.7 Composite StabilityComposite stability is determined
by:
CompositeStability =
(1 – CompositeAmplification)

  • (1 –
    CompositeOscProb)
  • DriftStability
    CompositeStability MUST be clamped to:
    0.0 ≤
    CompositeStability ≤ 1.0
    Interpretation:
    Near 1.0 → system stability is
    high Near 0.0 → system is fragile, volatile, or
    drift-prone

CompositeStability becomes a key input to Step 12.

11.8 Execution
OrderA conformant implementation MUST compute metrics in this exact
order:
Compute ΔLoad_i

Compute Δ²Load_i

Compute OscAmplitude_i

Compute

OscillationIndex

Compute VolatilityDrag_i

Compute FrictionIndex

Compute

AdjustedLoad_i

Compute CompositeStability

Output results

No variations or
reordering are permitted.

11.9 Multi-Event BundlesFor bundles:
Derivatives
MUST be computed only once per bundle

OscillationIndex MUST reflect the entire

combined Load change

DriftStability and composite metrics MUST be based on

bundle-aggregated results

Bundles MUST NOT compute oscillation per
event.

11.10 Examples (Non-Normative)Example 1 — High oscillation
environmentΔLoad_i = +6
Δ²Load_i = −4
OscAmplitude = |6| + |−4| = 10
If
CompositeOscProb = 0.3:
VolatilityDrag = 3.0

Example 2 — Strong friction
environmentOscillationIndex = 45
CompositeOscProb = 0.5
FrictionIndex = Σ_i
VolatilityDrag_i = 22
CompositeStability = (1 – CAmp) × (1 – COsc) ×
DriftStability
If CAmp=0.4, COsc=0.5, DriftStability=0.6:
CompositeStability =
0.6 × 0.5 × 0.6 = 0.18
System is fragile.

SECTION 12 — Step 8: Trajectory Classification (Normative)

Step 8 assigns the final Civic Stress Trajectory for
the current timestep.
This operationalizes Layer 6 — Trajectory Layer of the CTM
Model v1.0.
CTM Process v1.1 expands the v1.0 classification rules to
incorporate:
oscillation-driven patterns

slow-burn instability

detection

drift-adjusted thresholds

composite governance-style

effects

deterministic sequential rule precedence

A conformant implementation
MUST follow all rules in this section.

12.1 Inputs to Step 8Required
inputs:
Load_system(t+1)

ΔLoad_system

OscillationIndex

CompositeAmplification

CompositeOscProb

CompositeLatency

CompositeStability

EffectiveThresholds

Current

threshold state (Normal / Strained / Crisis / LBT / CCT)

Historical Load

values (minimum 3 cycles)

12.2 Outputs of Step 8A conformant implementation
MUST output:
TrajectoryClassificationOne of:
6A — Stabilizing Arc

6B —

Paralyzing Arc

6C — Escalatory Arc

Confidence ScoreA value between 0 and 1
based on:
threshold proximity

oscillation strength

governance-style

modifiers

stability metrics

Confidence is non-normative and MAY be
implementation-specific.

12.3 Deterministic Rule PrecedenceRules MUST be
applied in strict written order.
The first matching rule determines the
trajectory.
No rules MAY be reordered, removed, or modified.

12.4
Classification Rules (Normative)Below are the five classification rules of v1.1,
in exact execution order.

Rule 1 — Stabilizing Trajectory (6A)Assign 6A —
Stabilizing Arc if ALL of the following are true:
Load_system <
EffectiveThreshold_Crisis

ΔLoad_system ≤ 0 or OscillationIndex

decreasing

CompositeStability ≥ 0.5

Interpretation:
Stress remains below
crisis levels, stabilizing forces are dominant, and oscillation is low.

Rule 2
— Paralyzing Oscillation (6B)Assign 6B — Paralyzing Arc if ALL of the following
are true:
Load_system < EffectiveThreshold_LBT

OscillationIndex ≥

OscillationThreshold

CompositeOscProb ≥ 0.15

CompositeStability <

0.5

Interpretation:
Load is not catastrophically high, but oscillations
paralyze system function.
OscillationThreshold MUST be:
OscillationThreshold =
0.15 × EffectiveThreshold_Crisis

Rule 3 — Slow-Burn Deterioration (6B
Variant)Assign 6B — Paralyzing Arc if:
ΔLoad_system > 0 for three consecutive
cycles, AND

Load_system remains within ±10% of EffectiveThreshold_Crisis,

AND

CompositeStability < 0.4

Interpretation:
System is “stuck” in a
deteriorating state that never triggers a full crisis but steadily erodes
resilience.
This distinguishes chronic deterioration from acute
escalation.

Rule 4 — Escalatory Trajectory (6C)Assign 6C — Escalatory Arc if
ANY of the following are true:
Load_system ≥
EffectiveThreshold_LBT

ΔLoad_system > 0.15 ×

Load_system

CompositeAmplification > 0.4

CompositeLatency >

0.5

CompositeOscProb > 0.3 AND OscillationIndex

increasing

Interpretation:
Strong upward momentum, governance dysfunction, or
oscillatory instability is pushing the system toward crisis or collapse.

Rule 5
— Collapse-Level Trajectory (6C Severe Subclass)This is not a separate
trajectory class in v1.1, but MUST modify the confidence score.
If:
Load_system
≥ EffectiveThreshold_CCT
Trajectory MUST be 6C, with confidence ≥ 0.9.

12.5
Determining Trajectory Confidence (Non-Normative)A recommended confidence score
formula:
confidence =
0.4 × ThresholdProximityScore

  • 0.3 ×
    OscillationSeverityScore
  • 0.2 × GovernanceDysfunctionScore
  • 0.1 ×
    DriftSeverityScore
    Implementers MAY choose alternate scoring methods provided
    trajectory class remains identical.

12.6 Execution Order (Normative)Step 8 MUST
execute operations in this exact order:
Evaluate Rule 1

If not matched,

evaluate Rule 2

If not matched, evaluate Rule 3

If not matched, evaluate

Rule 4

Apply Rule 5 modifier

Output trajectory class and confidence

If
multiple rules match:
The earliest rule in the list takes
precedence.
Implementations MUST NOT perform backtracking or weighting-based
arbitration.

12.7 Special Handling for Multi-Event BundlesFor
bundles:
ΔLoad_system MUST reference aggregated Load(t+1) minus
Load(t)

Historical Load MUST NOT include intra-bundle

values

OscillationIndex MUST reflect post-bundle computation

Rules MUST NOT
evaluate bundle sub-events individually.

12.8 Examples (Non-Normative)Example 1
— Stabilizing ArcLoad_system = 150
EffectiveThreshold_Crisis = 200
ΔLoad_system
= −10
CompositeStability = 0.6
→ 6A

Example 2 — Oscillation
ParalyzingOscillationIndex = 40
OscThreshold = 30
CompositeOscProb =
0.25
CompositeStability = 0.3
→ 6B

Example 3 — EscalatoryLoad_system =
420
EffectiveThreshold_LBT = 400
→ 6C

SECTION 13 — Appendices (Non-Normative)

These appendices provide supporting detail, worked examples,
reference formulas, and implementation notes.
They do not modify the normative
requirements of Sections 1–12.

13.1 Appendix A — Complete Variable Reference Table

A consolidated list of all variables used in CTM Process
v1.1.
Variable
Meaning
Source

D[domain]
Binary domain activation

vector
Step 2

StressVectorList
List of all stress vectors generated by

event
Step 3

M_j
Magnitude of jth stress vector (1–5)
Step

3

PolWeight_j
Polarity weight applied to stress vector
Step

3

Load_i(t)
Per-domain Load at time t
Step 4

Load_system(t)
Aggregated

Load across domains
Step 5

ShockMemory
Running stress memory

accumulation
Step 4

EffectiveThresholds
Adjusted threshold values per

branch
Step 5

ThresholdState
Normal / Strained / Crisis / LBT / CCT
Step

5

SUL
Stability-Under-Load (0–1)
Governance Styles v1.0

CD
Contradiction

Density
Governance Styles v1.0

SignalCoherence
Branch coherence

measure
Governance Styles v1.0

ShockFrequency
Rolling average shock

rate
Governance Styles v1.0

BandwidthConsumption
Resource saturation

metric
Governance Styles v1.0

IA
Institutional Alignment weight
Governance

Styles v1.0

CompositeAmplification
Weighted amplification measure
Step

6

CompositeOscProb
Weighted oscillation probability
Step

6

CompositeLatency
Weighted latency measure
Step

6

CompositeStability
Weighted SUL metric
Step 7

OscillationIndex
Derived

oscillatory volatility metric
Step 7

ΔLoad_system
Load change between time

steps
Step 7

TrajectoryClass
6A / 6B / 6C
Step 8

Confidence
Confidence

score in trajectory classification
Step 8

13.2 Appendix B — Stress Vector Examples

Example 1 — Single-Domain Negative ShockEvent: Court blocks statewide
election reforms
Domain: Judiciary
Magnitude: 4
Polarity: −S
Stress vector:
SV =
{domain=Judiciary, magnitude=4, polarity=−S, weight=−10}
Contribution to
Load:
ΔLoad_jud = magnitude × weight = 4 × (−10) = −40

Example 2 — Multi-Domain
Political CrisisEvent: President declares unilateral domestic
emergency.
Domains: Executive, Norms, Media/Information, Legislature
Magnitude:
5
Polarities: +C (Executive), −S (Legislature), −S (Norms), +D (Media)
Generates
four
vectors:
Domain
Magnitude
Polarity
Weight
Contribution

Exec
5
+C
+10
+50

Legislature
5
−S
−10
−50

Norms
5
−S
−10
−50

Media
5
+D
+6
+30

Sum:
−20 Load_system

13.3 Appendix C — Load & ShockMemory Worked Example

Initial
Conditions: Load_jud(t) = 100

ShockMemory = 5

SUL =

0.6

ThresholdState(t−1) = Strained

DecayRate:
DecayRate = (1 − SUL × 0.05) ×
Multiplier(Strained)
= (1 − 0.6 × 0.05) × 0.8
= (1 − 0.03) × 0.8
= 0.97 × 0.8 =
0.776
New Load (before stress):
Load_jud’ = 100 × 0.776 = 77.6
Add stress:
+
40
→ Load_jud(t+1) = 117.6
ShockMemory:
ShockMemory(t+1) = 5 × 0.5 +
shocks_above_4
If magnitude=5 → shocks_above_4=1
→ 2.5 + 1 =
3.5
ThresholdModifier:
1 / (1 + 0.1 × 3.5) = 1 / 1.35 ≈ 0.74

13.4 Appendix D — Governance Modifier Examples

Example 1 — High Institutional AlignmentIf IA
weights:
Exec = 1.0

Legislature = 0.9

Judiciary = 0.8

CompositeOscProb
example:
(0.3×1.0 + 0.2×0.9 + 0.1×0.8) / (1.0+0.9+0.8)
= (0.3 + 0.18 + 0.08) /
2.7
= 0.56 / 2.7 ≈ 0.207

13.5 Appendix E — Oscillation Index Examples

Example:
Load_system history: 180, 220, 210, 235, 225

Δ = [+40, -10,
+25, -10]
AbsΔ = [40, 10, 25, 10]

OscillationIndex = mean(AbsΔ) = 21.25

13.6 Appendix F — Sample Trajectory Classifications

Scenario A — Stabilizing Arc
(6A) Load = 155

EffectiveThreshold_Crisis = 210

ΔLoad_system =

−8

CompositeStability = 0.55

→ 6A

Scenario B — Paralyzing Arc
(6B) OscillationIndex = 35

OscThreshold = 30

CompositeOscProb =

0.21

CompositeStability = 0.30

→ 6B

Scenario C — Escalatory Arc
(6C) Load_system = 422

EffectiveThreshold_LBT = 400

→ 6C

13.7 Appendix G — v1.1→v1.2 Forward Notes (Non-Normative)

The following topics are expected to be
addressed in v1.2:
formal JSON schema for CTM Result Packet

UI-ready

interpretation layer

severity bands and color-coded narrative

output

performance optimizations for multi-event batch

processing

context-aware stress parsing (semantic roles, actor hierarchy,

triggers)