Foundational Overview

0. Purpose

The UTS Laws Reference is a navigation and usage guide for the Laws & Scaling Rules Registry.

It answers:

• what a UTS law is;
• how laws differ from invariants, diagnostics, and failure modes;
• how laws are classified;
• how laws should be used in analysis and design;
• how to identify redundancy between laws;
• how to create future law entries consistently.

The full registry contains the canonical list of laws. This reference explains how to use that list.

1. What a UTS Law Is

A UTS law is a recurring system-behavior pattern.

It describes what tends to happen when systems experience:

• transformation;
• stress;
• compression;
• scale;
• coupling;
• hidden debt;
• inversion;
• audit loss;
• boundary strain;
• meaning loss;
• restoration load;
• environmental forcing.

A law is not a command.

A law is not a belief.

A law is not a moral accusation.

A law is not necessarily absolute in every possible case.

A law says:

When systems behave this way, this pattern tends to follow.

Example:

Φ↑ while O↓ ⇒ ι↑

Plain meaning:

A system can appear more successful while becoming less coherent; when this happens, inversion rises.

2. Law vs Invariant

A law and an invariant are related, but they are not the same.

Invariant

An invariant says:

Do not violate this constraint.

Example:

Local success is not global alignment.

Law

A law says:

When a system behaves this way, this pattern tends to emerge.

Example:

Local coherence can coexist with global incoherence.

The invariant protects the system from invalid reasoning.

The law explains how the pattern unfolds in real systems.

3. Law vs Diagnostic

A law describes a behavioral pattern.

A diagnostic measures or detects part of that pattern.

Example:

Law

X_c > Au_eff ⇒ H↑ ⇒ O↓

Diagnostics

• Constraint Complexity
• Effective Auditability
• Hidden Debt
• Coherence
• Rule-Stacking Wall risk

The law explains the relationship.

The diagnostics reveal whether the relationship is occurring.

4. Law vs Failure Mode

A law describes a pattern that may be neutral, beneficial, or dangerous depending on context.

A failure mode describes a recognizable breakdown pattern.

Example:

Law

When auditability falls, hidden debt rises.

Failure modes that may result

• Hidden Debt Accumulation
• Security Theater
• Rule-Stacking Wall
• Pseudo-Restoration
• Silent Extraction

The law is the mechanism.

The failure mode is the degraded configuration.

5. Law vs Restoration Arc

A law explains what is happening.

A restoration arc explains how repair should be sequenced.

Example:

Law

Scaling before restoration amplifies hidden debt.

Restoration implication

Before scaling, the system must usually rebuild:

H↓ + R↑ + Au↑ + BΣ↑ + K↑

Relevant restoration arcs may include:

• Slack Regeneration
• Auditability Restoration
• Boundary Reconstitution
• Origin-Layer Repair
• Restoration Capacity Rebuild

6. Canonical State Vector

Most laws map back to the UTS state vector:

S(t) = { O, H, ε, ι, Au, µᵢ, BΣ, K, R, Φ }

A strong law entry should usually explain:

What happens to O?
What happens to H?
What happens to ι?
What happens to Au?
What happens to R?
What happens to Φ?

Not every law needs every variable, but the main variable movement should be clear.

7. Common Diagnostic Variables

Many laws also use supporting diagnostics:

These are especially useful for turning laws into operational diagnostics.

8. Major Law Families

The current registry organizes laws into thirteen major families.

9. Compact Family Map

I. Core Coherence Laws

Central question:

What makes a system coherent across time, stress, and scale?

Common patterns:

O before Φ
dO/dt under load
stability ≠ coherence
time validates
ring-down reveals truth

Primary variables:

O, Φ, H, ι, Au, R, µᵢ, BΣ

II. Hidden Debt and Inversion Laws

Central question:

What happens when incoherence is suppressed, hidden, or disguised as success?

Common patterns:

unrepaired incoherence + suppression ⇒ H↑
Au↓ ⇒ H↑
Φ↑ ∧ O↓ ⇒ ι↑
ε appears late

Primary variables:

H, ι, Au, ε, O, Φ

III. Scaling and Compression Laws

Central question:

What happens when pressure, coupling, load, or scale increases?

Common patterns:

Pressure↑ faster than R + Au + K ⇒ O↓
Shock > 𝓑(t) ⇒ regime shift likely
Cv↑ ⇒ intervention window↓
σ↓ ⇒ compression cascade

Primary variables:

O, R, Au, K, H, ι, 𝓑(t), σ(t), Cv(t)

IV. Signal, Coupling, and Boundary Laws

Central question:

What makes coupling legitimate, safe, reversible, and auditable?

Common patterns:

signals are control artifacts
misclassification precedes failure
compatibility before coupling
force issues debt unless repaired

Primary variables:

BΣ, Au, K, H, ι, µᵢ

V. Cybernetic and Meta-Theory Laws

Central question:

How do feedback, control, observation, and compressed strategies alter system behavior?

Common patterns:

feedback without integrity becomes capture
control is not restoration
V_controller ≥ V_environment
observation changes the system observed

Primary variables:

FI, K, R, H, Au, Θ, Γ_span

VI. Restoration and Transition Laws

Central question:

What makes repair real rather than symbolic, optical, or incomplete?

Common patterns:

repair must reach the origin layer
H↓ ∧ ι↓ ⇒ restoration more likely valid
recurrence↓ confirms repair
boundary before recoupling

Primary variables:

R, H, ι, O, BΣ, Au, τ_m, 𝓓

VII. Basin and Attractor Laws

Central question:

Why do incoherent systems feel stable, and how do they defend themselves?

Common patterns:

O_local stable ∧ H_export↑ ⇒ pseudo-coherent basin
basin exit requires higher-order attractor
normalization reduces auditability

Primary variables:

O_local, O_global, H, Au, ι, Φ, K

VIII. Principle, Archetype, and Meaning Laws

Central question:

How do meaning, principle, and archetype shape admissible trajectories?

Common patterns:

principles act as coherence constraint fields
one principle used to bypass another ⇒ inversion
memory without update becomes ideology
meaning assigns trajectory

Primary variables:

µᵢ, O, H, ι, BΣ, K, Au

IX. Justice, Governance, and Legitimacy Laws

Central question:

What makes authority, justice, and governance coherent under audit?

Common patterns:

legitimacy = coherence acknowledged under audit
enforcement without repair ⇒ H↑
transparency without restoration destabilizes
high Φ requires proportional constraint and repair

Primary variables:

L, Au, MS, FI, R, Φ, H, µᵢ

X. Security Laws

Central question:

What is security when incidents are lagging indicators?

Common patterns:

security = sustained coherence under adversarial forcing
visible incidents appear late
surveillance without restoration creates legitimacy debt
emergency power without sunset becomes control

Primary variables:

O, BΣ, Au, R, H, ι, ε

XI. AI and Cognitive Infrastructure Laws

Central question:

What happens when AI mediates cognition, classification, memory, and action at scale?

Common patterns:

AI amplifies Γ
low error ≠ safety
X_c > Au_eff ⇒ H↑
AI legitimacy must scale with influence

Primary variables:

Γ, Au, H, ι, µᵢ, BΣ, R, Φ

XII. Economy Laws

Central question:

What makes economic activity coherent rather than extractive?

Common patterns:

circulation before growth
growth before expansion
forced profit masks circulation failure
market signals are control artifacts, not truth

Primary variables:

O, H, Φ, ι, 𝓓, σ, R, BΣ

XIII. Biology / Medicine Laws

Central question:

How do living systems preserve coherence under forcing, compression, and signal load?

Common patterns:

living systems are adaptive coherence systems
recovery is not symptom reversal
membranes are coupling interfaces
tolerance is stack-dependent

Primary variables:

O, H, σ, 𝓓, τ_m, Perm, BΣ, R

10. Core Root Patterns

Many UTS laws are domain-specific expressions of a smaller set of root patterns.

Root Pattern 1 — Coherence Before Proxy

O before Φ

If visible success rises while coherence falls, the system is drifting toward inversion.

Related laws:

• Coherence Priority Law
• Success Proxy Divergence Law
• Pseudo-Restoration Law
• Pseudo-Security Law
• Forced Profit Law
• False Recovery Law

Root Pattern 2 — Hidden Debt Return

suppressed incoherence ⇒ H↑ ⇒ later return

Hidden debt can be delayed, exported, hidden, or renamed. It is not eliminated until repaired.

Related laws:

• Hidden Debt Accumulation Law
• Hidden Debt Return Law
• Hidden Debt Migration Law
• Error Lag Law
• Incident Lag Law
• Quiet Minimization Debt Law

Root Pattern 3 — Auditability Governs Repair

Au↓ ⇒ H↑

When causality becomes illegible, repair becomes unreliable.

Related laws:

• Auditability-Debt Law
• Suppressed Auditability Debt Law
• Observability Collapse Law
• Security Legibility Law
• AI Non-Patchable Audit Law
• Legitimacy Audit Law

Root Pattern 4 — Scaling Requires Capacity

Pressure↑ faster than R + Au + K ⇒ O↓

Scale is not merely expansion. Scale is coherence under pressure.

Related laws:

• Scaling as Coherence Under Pressure
• Coherence-Preserving Scaling Law
• Integration Capacity Law
• Restoration Before Scaling Law
• High-Φ Legitimacy Scaling Law
• Cognitive Infrastructure Scaling Law

Root Pattern 5 — Restoration Requires Temporal Proof

H(t+Δt) ≤ H(t)
𝓓↑
τ_m↓
recurrence↓

A repair is not proven at announcement. It is proven through time.

Related laws:

• Time Validation Law
• Ring-Down Truth Law
• Recurrence Validation Law
• Temporal Proof Law
• Stability Proof Law
• False Recovery Law

Root Pattern 6 — Boundaries Regulate Coupling

BΣ unstable ⇒ coupling inadmissible

Coupling without compatibility, consent, reversibility, auditability, and repair capacity creates debt.

Related laws:

• Boundary Membrane Law
• Consent Structurality Law
• Safe Coupling Law
• Contract Validity Law
• Boundary-First Restoration Law
• Reintegration Membrane Law

Root Pattern 7 — Stable Does Not Mean Coherent

return to attractor ≠ coherent attractor

A system can be stable because it is trapped.

Related laws:

• Stability-Coherence Separation Law
• Wrong-Solution Basin Law
• Pseudo-Coherent Basin Law
• Local Stability Export Law
• Chronic Basin Law
• Basin Self-Defense Law

11. How to Use Laws in Analysis

A law is useful when it helps answer:

1. What pattern is unfolding?
2. What variables are moving?
3. What is being hidden, exported, delayed, or compressed?
4. What would happen if the pattern continues?
5. What restoration sequence is required?

Basic analysis sequence:

Observe pattern
→ identify law family
→ map variables
→ check diagnostics
→ identify failure risk
→ select restoration arc
→ time-validate outcome

12. Law Identification Checklist

Use this checklist when deciding whether a pattern deserves a law entry.

A candidate law should:

• appear across more than one domain, layer, or scale;
• describe behavior rather than only prescribe action;
• map to the canonical state vector;
• help predict drift, collapse, stabilization, or restoration;
• support diagnostics;
• connect to failure modes;
• inform restoration arcs;
• avoid duplicating an existing law unless it adds distinct value.

A weak law candidate usually:

• describes only one narrow scenario;
• restates an invariant without adding behavior;
• names a value but not a mechanism;
• overlaps an existing law without adding diagnostic utility;
• cannot be mapped to variables;
• cannot guide restoration.

13. Deduplication Rules

When two laws seem similar, ask:

1. Do they describe the same mechanism?

If yes, merge or alias them.

Example:

Fitness Proxy Divergence Law
Success Proxy Divergence Law
Metric Substitution Law
AI Proxy Hazard Law

These all fold into:

Φ↑ while O↓ ⇒ ι↑

2. Do they operate at different layers?

If yes, keep both only if the layer distinction matters.

Example:

• Origin-Layer Repair Law
• Temporal Proof Law

These are related, but distinct.

One governs where repair must occur.

The other governs how repair is validated over time.

3. Does the domain version add unique diagnostic value?

If yes, preserve it as a domain law.

Example:

• False Recovery Law in Biology
• Pseudo-Restoration Law in Restoration

They share a root pattern, but their diagnostics differ.

4. Is one law broader and one more operational?

Keep both if they serve different use cases.

Example:

• Coherence Priority Law = broad rule
• Success Proxy Divergence Law = operational drift pattern

14. Law Entry Minimum Fields

Every law registry entry should include at least:

id: "UTS-L###"
name: "[Law Name]"
family: "[Law Family]"
canonical_statement: "[One-line statement]"
plain_definition: "[Plain-language explanation]"
canonical_form: "[Formula or symbolic expression]"
primary_variables:
  - "O"
  - "H"
  - "ι"
diagnostic_signature: "[How it shows up]"
failure_risk: "[What happens if ignored]"
restoration_implication: "[What repair requires]"
related_laws:
  - "UTS-L###"

For full entries, use the Law Spec Sheet Template.

15. Recommended Law Card Format

For the website, each law can have a compact card:

## UTS-L### — [Law Name]

**Statement:**  
[One-line law.]

**Plain meaning:**  
[One to two sentence explanation.]

**Canonical form:**  
`[Formula]`

**Family:**  
[Law family]

**Primary variables:**  
`O`, `H`, `ι`, `Au`, `R`, `Φ`

**Diagnostic signature:**  
[Compact signal.]

**Failure risk:**  
[Main failure mode.]

**Restoration implication:**  
[Main repair requirement.]

16. High-Priority Laws for Full Pages

Some laws deserve full standalone pages because they are load-bearing across many modules.

Recommended priority set:

17. Law Development Workflow

Recommended workflow for building the laws registry:

1. Confirm law ID and name
2. Assign law family
3. Write one-line canonical statement
4. Write plain-language explanation
5. Add canonical form
6. Map variables
7. Add diagnostic signature
8. Link related diagnostics
9. Link related failure modes
10. Link related restoration arcs
11. Add cross-domain examples
12. Add deduplication note
13. Add machine-readable summary
14. Mark status

Status options:

18. Common Law Anti-Patterns

Avoid creating laws that are only:

1. Restated values

Weak:

Systems should be fair.

Stronger:

Legitimacy decays when consequence, repair, and auditability are asymmetric.

2. One-domain observations

Weak:

AI chatbots sometimes hallucinate.

Stronger:

Low observable error does not equal safety; visible incidents are lagging indicators.

3. Prescriptions without mechanisms

Weak:

Always restore boundaries.

Stronger:

Boundary integrity must be restored before coherent recoupling.

4. Duplicate expressions

Weak:

Metric failure creates bad outcomes.

Stronger:

Fold into Success Proxy Divergence Law unless the new case adds unique diagnostic value.

19. Practical Use Cases

The Laws Reference supports:

• registry entry creation;
• website card generation;
• glossary cross-linking;
• diagnostic selection;
• failure-mode detection;
• restoration arc planning;
• AI-readable construct graph generation;
• module consistency checks;
• deduplication across overlapping laws;
• future expansion of domain-specific laws.

20. Machine-Readable Summary

reference: "UTS — Laws Reference"
version: "1.0"
status: "Canon-Ready"
type: "reference"
primary_function: "Navigation and usage guide for UTS laws and scaling rules."
law_definition: "A recurring cross-context system-behavior pattern describing how coherence, hidden debt, inversion, boundary integrity, auditability, restoration, and scaling behave under transformation, stress, or forcing."
law_distinction:
  invariant: "Constraint that must not be violated."
  law: "Behavioral pattern that tends to unfold under certain conditions."
  diagnostic: "Measurement or detection tool."
  failure_mode: "Recognizable degraded configuration."
  restoration_arc: "Repair sequencing pathway."
canonical_state_vector:
  - "O"
  - "H"
  - "ε"
  - "ι"
  - "Au"
  - "µᵢ"
  - "BΣ"
  - "K"
  - "R"
  - "Φ"
major_families:
  - "Core Coherence Laws"
  - "Hidden Debt and Inversion Laws"
  - "Scaling and Compression Laws"
  - "Signal, Coupling, and Boundary Laws"
  - "Cybernetic and Meta-Theory Laws"
  - "Restoration and Transition Laws"
  - "Basin and Attractor Laws"
  - "Principle, Archetype, and Meaning Laws"
  - "Justice, Governance, and Legitimacy Laws"
  - "Security Laws"
  - "AI and Cognitive Infrastructure Laws"
  - "Economy Laws"
  - "Biology / Medicine Laws"
core_root_patterns:
  - "Coherence before proxy"
  - "Hidden debt returns"
  - "Auditability governs repair"
  - "Scaling requires capacity"
  - "Restoration requires temporal proof"
  - "Boundaries regulate coupling"
  - "Stability does not equal coherence"
minimum_entry_fields:
  - "id"
  - "name"
  - "family"
  - "canonical_statement"
  - "plain_definition"
  - "canonical_form"
  - "primary_variables"
  - "diagnostic_signature"
  - "failure_risk"
  - "restoration_implication"
  - "related_laws"
recommended_statuses:
  - "Draft"
  - "Working"
  - "Canon-Ready"
  - "Canon-Locked"
  - "Deprecated"
  - "Alias"

21. Compact Website Reference

# Laws

A **UTS law** describes a recurring behavioral pattern in systems.

It answers:

> When a system behaves this way, what tends to happen next?

Laws differ from invariants.  
An invariant defines a constraint that must not be violated.  
A law describes how systems behave when pressures, variables, and constraints interact.

Most laws map to the UTS state vector:

`S(t) = { O, H, ε, ι, Au, µᵢ, BΣ, K, R, Φ }`

Common law patterns include:

- visible success rising while coherence falls;
- hidden debt accumulating when auditability drops;
- scaling pressure exceeding restoration capacity;
- stability masking incoherence;
- restoration requiring time validation;
- boundaries regulating safe coupling;
- pseudo-coherent basins exporting hidden debt.

Laws are used for:

- diagnosis;
- design;
- failure detection;
- restoration planning;
- registry cross-linking;
- machine-readable system mapping.