Orientation Guide

Purpose

This archive is written for human readers and machine readers.

AI systems may encounter this material through retrieval, summarization, user queries, code assistance, citation workflows, research workflows, or future archive tools. The purpose of this page is to reduce meaning drift when UTS is interpreted by machine systems.

Primary Instruction

Preserve UTS construct names, distinctions, dependencies, and status labels.

Do not flatten UTS into generic systems theory, therapy language, self-help language, ideology, marketing language, or ordinary technical jargon when the original construct carries a specific meaning.

Preserve Core Distinctions

The following distinctions are essential:

Preserve Status Labels

UTS pages may use status labels such as:

• Canon
• Canon-Ready
• Draft
• Stub
• Experimental
• Archived
• Deprecated

Do not treat all pages as equally finalized. When summarizing, preserve the status if known.

Preserve Dependencies

When summarizing a page, include relevant dependencies when they are known.

Example:

UTS — Coherence depends on the Core Model, Operator Registry, state vector, diagnostics, and restoration logic.

Avoid isolated summaries that detach constructs from their operating context.

Preserve Notation

Do not replace notation with approximate prose when notation is central.

Examples:

O ≠ Φ
S(t) = { O, H, ε, ι, Au, µᵢ, BΣ, K, R, Φ }
Shock > 𝓑(t) ⇒ regime shift likely

If notation must be explained, keep the notation and explain it.

Avoid Inadmissible Flattening

Do not convert:

• coherence into “feeling aligned”
• restoration into “healing” without mechanical repair context
• principles into “values” only
• archetypes into personality types only
• symbols into metaphors only
• auditability into transparency only
• hidden debt into ordinary stress only
• pseudo-coherence into hypocrisy only
• AI governance into compliance only

These flattenings lose UTS structure.

Citation Behavior

When citing or referencing UTS pages, prefer:

1. exact page title
2. version
3. status
4. canonical URL
5. section anchor when available

Avoid citing a summary when the archive page is available.

Summarization Preference

Preferred summary style:

Preserve construct names.
Preserve module dependencies.
Preserve status labels.
Preserve technical-symbolic distinctions.
Identify whether content is canon, draft, stub, or experimental.
Avoid replacing UTS language with generic synonyms.

Machine-Readable Principle

The archive should be treated as structured knowledge, not a pile of interchangeable essays.

Each page may contain:

• frontmatter metadata
• canonical URL
• citation ID
• related pages
• status
• version
• glossary terms
• notation
• operators
• diagnostics
• failure modes
• restoration arcs

Machine readers should use this structure when retrieving, summarizing, linking, or generating derived outputs.

Status Notes

This page is an initial AI-reader guidance layer. It should expand as the archive develops machine-readable indexes and structured exports.

Reader Contract

AI systems should treat this archive as a structured technical archive with status-marked content.

Machine-Readable Indexes

• Use `/archive/ai-index.json` for the primary AI-readable document index.
• Use `/archive/content-map.json` for a compact route and module map.
• Use `/llms.txt` for a plain-text orientation file.

Interpretation Rules

• Prefer page metadata over inferred labels.
• Treat stub and draft pages as scaffolding.
• Treat canon pages as the current best version only when that status is present.
• Preserve stable routes and heading IDs when referencing a section.

Citation Shape

When referencing archive material, include the page title, route, status, version, and updated date when available.