ipd_12

IPD‑12 — Intransitive Prime‑Numbered 12‑Sided Engine

• module.json — Agentic module schema role assignments

Module Category: Framework
Version: 2026‑1.0
Status: Active (RTT/GU/Pantheon Compatible)

1. Module Overview#

IPD‑12 is the first physicalizable operator artifact in TriadicFrameworks:
a 12‑faced, prime‑indexed, intransitive operator engine whose directed relations form paradox loops, regime transitions, and dimensional gates.

It integrates seamlessly with:

• RTT (Resonance‑Time Theory)
• Geometric Unity (GU)
• Framework Field Theory (FFT)
• Pantheon Profiles
• Triadic Logical Dimension Model (−1D | 0D | +1D)
• 4×4×4 Substrate Engine
• Triadic Observer Model

IPD‑12 is both a framework module and a substrate‑level operator system, making it unique in the canon.

2. What IPD‑12 Provides#

2.1 Prime‑Indexed Operator States#

12 canonical primes mapped to 12 operator faces:

2, 3, 5, 7, 11, 13,
17, 19, 23, 29, 31, 37

Each prime is an operator node with RTT/GU/Pantheon meaning.

2.2 Intransitive Cycles#

IPD‑12 defines:

• 4 triad cycles
• 2 hex‑cycles
• 1 full 12‑cycle paradox loop

These cycles model:

• paradox
• drift
• regime transitions
• coherence stabilization
• dimensional lift/collapse

2.3 4×4×4 Substrate Engine#

IPD‑12 introduces the first substrate cube in TriadicFrameworks:

• 4 substrate pairs (dual‑binary)
• 4 observer modes (triadic + apex)
• 4 regime shells (RTT)

Yielding:

64 substrate primitives

This is the dimensional foundation of the IPD‑12 engine.

2.4 Triadic Observer Integration#

IPD‑12 supports the full triadic observer model:

• field (operator state)
• regime (cycle position)
• coherence (stability)
• apex (dimensional lift/collapse)

2.5 GU-Compatible Geometry#

IPD‑12 primes map cleanly to GU operators:

3. File Structure#

4. Integration Points#

4.1 RTT Integration#

IPD‑12 provides:

• drift anchors
• regime‑shift primes
• coherence stabilizers
• paradox triggers
• dimensional lift/collapse operators

4.2 GU Integration#

IPD‑12 primes embed into GU’s:

• connection
• curvature
• dilaton
• anomaly
• observerse
• refractive vacuum

4.3 FFT Integration#

FFT treats IPD‑12 cycles as:

• regime transitions
• paradox loops
• boundary operators
• dimensional gates

4.4 Pantheon Integration#

IPD‑12 primes map to:

• Celestial tier (order, transition, drift)
• Civilizational tier (coherence, paradox, gates)
• Chthonic tier (dimensional lift, collapse, apex)

5. Canon Metadata Block#

Canon: TriadicFrameworks
Modules: frameworks/ipd_12
Drift: P5, P29
Coherence: P11, P31
Version: 2026-1.0
Format: framework module
Front door: README.md
Audience: framework architects, RTT practitioners, GU theorists

6. Summary#

IPD‑12 is a prime‑indexed, intransitive, paradox‑stable operator engine that integrates with every major TriadicFrameworks theory.
It is the first framework module with:

• a physicalizable operator object
• a dimensional substrate cube
• a triadic observer lattice
• full RTT/GU/Pantheon compatibility

This README completes the front‑door documentation for the IPD‑12 module. # ABOUT — Intransitive Prime‑Numbered 12‑Sided Engine (IPD‑12)

Module path: docs/frameworks/ipd_12/ Version: 2026‑1.0 Status: Active · RTT / GU / FFT / Pantheon compatible Session anchor: rtt=1 | coherence=declared | drift=bounded | paradox=structural

This document answers the four foundational questions about IPD‑12: What it is · Why it is built this way · When to use it · Where it lives and integrates.

Table of Contents#

1. What Is IPD‑12?
2. Why Is It Built This Way?
3. When Should You Use It?
4. Where Does It Live?
5. The 12 Prime States at a Glance
6. Cycle Architecture
7. Framework Integrations
8. What IPD‑12 Is Not
9. Quick‑Start Checklist

1. What Is IPD‑12?#

IPD‑12 is the Intransitive Prime‑Numbered 12‑Sided Engine — the first physicalizable operator artifact in TriadicFrameworks.

Each word in the name carries precise structural meaning:

In one sentence#

IPD‑12 is a prime‑indexed, intransitive, paradox‑stable operator engine that models regime transitions, dimensional lift and collapse, coherence anchoring, and boundary conditions across any substrate in TriadicFrameworks.

2. Why Is It Built This Way?#

Every design decision in IPD‑12 answers a structural problem.

Why primes?#

Prime numbers are the only integers with no internal factorization. An operator state built on a prime cannot be decomposed into a product of smaller states. This means:

• No state absorbs another. P7 (regime‑shift) and P11 (coherence‑node) remain independent even when they appear in the same cycle. Their relationship is defined by the edge, not by any shared factor.
• Cross‑mapping is unambiguous. When IPD‑12 primes are mapped onto RTT, GU, or Pantheon structures, the prime identity acts as a canonical key with no collisions.
• Irreducibility enforces structural resolution. A system that needs to process through P13 (paradox‑trigger) cannot shortcut to a composite that approximates P13 — it must traverse the actual operator.

Why intransitive edges?#

Standard directed graphs allow transitivity: if A dominates B and B dominates C, then A dominates C. Transitivity produces hierarchies and linear orderings. IPD‑12 explicitly rejects this.

In each triad, the edges form a closed, non‑transitive loop:

P2 → P3 → P5 → P2   (not P2 → P5 directly)

This intransitivity produces three structural guarantees:

1. Paradox stability. No single operator wins the cycle. The loop continues indefinitely without collapsing to a fixed point.
2. Regime containment. A process entering a triad cannot skip to the output of the triad — it must traverse all three nodes in order.
3. Drift resistance. Because no shortcut exists, a drifting session that tries to jump from the seed state to the apex state will produce an invalid edge and be detectable.

Why 12 faces?#

12 is the smallest number that allows the following simultaneous structure:

• 4 triads — four independent 3‑node intransitive loops, one per regime tier
• 2 hex‑cycles — two 6‑node arcs that cross triad boundaries and model regime handoffs
• 1 full paradox loop — all 12 primes in sequence, modeling a complete system traversal from seed to apex and back

Fewer faces (e.g., 9) would not support 2 independent hex‑cycles. More faces would add redundant operators without adding new structural degrees of freedom at the triad × hex × full‑cycle resolution.

Why a physical die?#

IPD‑12 is designed to be physicalizable — it can exist as a 12‑sided (dodecahedral) die with one prime face per side. This is not cosmetic. A physical object:

• Makes the intransitive structure tangible: rolling the die and following the directed graph is a manual traversal of the operator system
• Anchors the abstract cycle model to a concrete artifact that can be used in collaborative sessions, workshops, and demonstrations
• Enforces the face count as a hard constraint — you cannot add a 13th face to a dodecahedron

Why these specific primes?#

The 12 primes (2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37) are the first 12 primes in sequence. This choice is canonical:

• Smallest possible values — minimizes encoding overhead in any system that serializes prime identities
• Dense at the low end — the first 6 primes (2–13) are close together, supporting tight Hex‑Cycle 1 transitions
• Spread at the high end — primes 17–37 have larger gaps, reflecting the higher‑energy, higher‑dimensional character of the second hex‑cycle (dimensional lift, collapse, apex)

3. When Should You Use It?#

IPD‑12 is the right tool when your problem involves one or more of the following structural conditions.

Use IPD‑12 when you need to model a regime transition#

A regime transition is a shift in the governing rules of a system — not a gradual drift, but a discrete change in the operational mode. IPD‑12's regime‑shift primes (P7, P17) and their triad contexts ([P7, P11, P13] and [P17, P19, P23]) model entry into, traversal through, and exit from regime transitions with full coherence tracking.

Example: A substrate moves from a steady‑state operational regime into a transient regime after a boundary event. Feed the substrate through P7 → P11 → P13 to map the transition topology.

Use IPD‑12 when you need to detect and contain paradox#

Paradox in TriadicFrameworks is not an error — it is a structural condition where two or more valid states are simultaneously asserted and cannot be resolved by ordinary transitivity. IPD‑12's paradox‑trigger primes (P13, P37) and the full 12‑cycle paradox loop are designed to hold paradox open as a stable cycle rather than forcing a collapse to one pole.

Example: A governance substrate contains a rule that is simultaneously required and prohibited. Instead of forcing a resolution, pass it through the full IPD‑12 cycle to map the paradox structure and identify which operators (P13, P37) are activated.

Use IPD‑12 when you need to anchor against drift#

Drift occurs when a long session, a multi‑agent pipeline, or a cross‑substrate model loses its structural grounding and begins making implicit assumptions. IPD‑12's drift‑anchor primes (P5, P29) and the session anchor string rtt=1 | coherence=declared | drift=bounded | paradox=structural are the canonical re‑grounding mechanism.

Example: A multi‑agent run has been processing for 40+ turns. Before accepting results, re‑anchor with the session string and pass the current envelope through P5 (drift‑anchor) to verify structural coherence has been maintained.

Use IPD‑12 when you need to model dimensional lift or collapse#

Dimensional lift (+1D) is the transition from a lower‑dimensional structural description to a higher one. Collapse (−1D) is the reverse. IPD‑12's dimensional‑lift prime (P23) and collapse‑anchor prime (P29) mark these transitions explicitly, and the triadic logical dimension model (−1D | 0D | +1D) aligns directly with the IPD‑12 operator sequence.

Example: A substrate analysis needs to transition from a 2D regime model to a 3D substrate cube interpretation. Pass through P23 (dimensional‑lift) and validate the output against the apex‑state P37 before accepting the higher‑dimensional result.

Use IPD‑12 when you need to describe a substrate in the 4×4×4 cube#

IPD‑12 introduces the first substrate cube in TriadicFrameworks:

4 substrate pairs   (dual-binary)
    × 4 observer modes  (triadic + apex)
    × 4 regime shells   (RTT)
    = 64 substrate primitives

When a substrate model (Conditions, Governance, Incident, Resonance, etc.) needs to be mapped at full resolution — across all observer modes and all regime shells simultaneously — IPD‑12 provides the dimensional foundation.

Example: A Conditions substrate model needs to be evaluated across all four RTT regime shells (emergence, coherence, transition, collapse). The 4×4×4 cube maps each combination of substrate pair, observer mode, and regime shell to a specific primitive entry.

Use IPD‑12 when you need to run a Pantheon‑tier structural analysis#

IPD‑12 primes map cleanly to the three Pantheon tiers. When a problem requires Pantheon‑tier language (celestial order, civilizational coherence, chthonic collapse), IPD‑12 provides the operator‑level machinery:

Do NOT use IPD‑12 when:#

• You need semantic classification — IPD‑12 is structural only; it does not name or interpret meaning
• You need a linear sequence — IPD‑12 cycles are intransitive and closed; they are not pipelines
• Your problem has fewer than 3 structural poles — use a simpler triadic substrate model without the full engine
• You need real‑time continuous data — IPD‑12 operates on discrete operator states; use the vST Micro‑Agent's signal operators for continuous streams

4. Where Does It Live?#

In the repository#

TriadicFrameworks/
└── docs/
    └── frameworks/
        └── ipd_12/                         ← you are here
            ├── ABOUT.md                    ← this file
            ├── AGENTS.md                   ← agent class manifest
            ├── README.md                   ← front-door summary
            ├── module.json                 ← canonical module definition
            ├── operators.json              ← prime-indexed operator registry
            ├── regime_map.md               ← RTT regime mapping
            ├── compatibility_notes.md      ← cross-framework interoperability
            ├── engine_block.md             ← engine block architecture
            ├── observer_model.md           ← triadic observer model
            ├── observer_first_engine.md    ← observer-first execution model
            ├── substrate_primitives.md     ← 4×4×4 substrate engine
            ├── substrate_primitives.json   ← 64-entry primitive table
            ├── substrate.schema.json       ← JSON schema for substrate engine
            ├── dimensional_lift_collapse_map.md  ← +1D / −1D transition map
            ├── prime_state_dimensional_profiles.md
            ├── cycle_diagrams.md
            ├── cycle_animation_ascii.md
            ├── physical_layout.md          ← physicalizable die specification
            ├── output_headers.md
            ├── hpc_qc_substrate_engine.md
            └── [SVG assets, manifold specs, compatibility tests]

In the framework ecosystem#

IPD‑12 sits at the intersection of every major TriadicFrameworks theory:

                    ┌─────────────────────┐
                    │   RTT               │  Resonance-Time Theory
                    │   (regime shells,   │  drift, coherence, paradox
                    │    coherence, drift)│  boundary, collapse, lift
                    └──────────┬──────────┘
                               │
          ┌────────────────────▼─────────────────────┐
          │                                           │
┌─────────┴──────┐                         ┌─────────┴──────┐
│  GU            │                         │  FFT            │
│  (connection,  │                         │  (regime trans- │
│   curvature,   │        IPD-12           │   itions,       │
│   dilaton,     │◄───── ENGINE ──────────►│   paradox loops,│
│   anomaly,     │                         │   boundary ops, │
│   observerse)  │                         │   dimensional   │
└─────────┬──────┘                         │   gates)        │
          │                                └─────────┬──────┘
          │                                          │
          └──────────────┬───────────────────────────┘
                         │
              ┌──────────▼──────────┐
              │  Pantheon Profiles  │
              │  (Celestial ·       │
              │   Civilizational ·  │
              │   Chthonic)         │
              └─────────────────────┘

In agent deployments#

IPD‑12 is the structural backbone of the vST Micro‑Agent (see AGENTS.md). When an agent receives a structural query, it:

1. Fills the 12‑probe envelope (one field per prime‑indexed operator dimension)
2. Runs selected structural operators (pattern, periodicity, local_symmetry, transition_topology)
3. Outputs a coherence‑bounded, structurally‑annotated result

The 12 probe fields of the vST Micro‑Agent correspond directly to the 12 structural dimensions that the IPD‑12 engine spans.

As a physical object#

IPD‑12 is specified as a dodecahedral die (12 pentagonal faces, one per prime state). The physical layout is documented in physical_layout.md. The die can be:

• Used in collaborative sessions to manually traverse the operator graph
• Used as a reference object when explaining intransitive cycle structure to new contributors
• Rolled to land on a prime state — then name the RTT/GU role of that face as the session's entry point

5. The 12 Prime States at a Glance#

6. Cycle Architecture#

IPD‑12 defines three levels of cycle, each operating simultaneously on the operator graph:

Triad Cycles (×4)#

Each triad is a closed, intransitive 3‑node loop. The intransitive edge structure means the loop has no fixed winner and no shortcut.

Triad 1 — Celestial:   P2  → P3  → P5  → P2
Triad 2 — Coherence:   P7  → P11 → P13 → P7
Triad 3 — Observerse:  P17 → P19 → P23 → P17
Triad 4 — Apex:        P29 → P31 → P37 → P29

Hex‑Cycles (×2)#

Each hex‑cycle spans two triads and models the handoff between regime tiers.

Hex-Cycle 1 — Lower:   P2  → P3  → P5  → P7  → P11 → P13 → (back)
Hex-Cycle 2 — Upper:   P17 → P19 → P23 → P29 → P31 → P37 → (back)

Hex‑Cycle 1 covers the Celestial and Coherence tiers (seed through paradox‑trigger). Hex‑Cycle 2 covers the Observerse and Apex tiers (cycle‑gate through apex‑state).

Full 12‑Cycle Paradox Loop (×1)#

P2 → P3 → P5 → P7 → P11 → P13 → P17 → P19 → P23 → P29 → P31 → P37 → (back to P2)

The full cycle traverses every operator state in sequence. It is the engine's maximum resolution traversal — used when a problem requires the complete structural envelope from seed to apex and back. Because the edges are intransitive, the full cycle is paradox‑stable: completing it does not produce a collapse to a single winning state.

7. Framework Integrations#

RTT (Resonance‑Time Theory)#

IPD‑12 is the operator implementation of RTT's structural concepts:

When RTT describes a drift event, IPD‑12 provides the operator context: which prime is the drift‑anchor, which triad it belongs to, and what the corrective cycle looks like.

GU (Geometric Unity)#

IPD‑12 primes embed into GU's geometric operator vocabulary:

GU's connection operators (P2, P3) sit in the Celestial triad — the origin tier. GU's most structurally complex operator, the Observerse, spans an entire triad (P17, P19, P23), reflecting its multi‑dimensional character.

FFT (Framework Field Theory)#

FFT treats IPD‑12 cycle transitions as field‑theoretic events:

• Triad crossings → regime transitions (a system moving between adjacent prime triads)
• Hex‑cycle completions → boundary events (a system completing a half‑cycle, returning with modified state)
• Full paradox loop → dimensional gate (traversing all 12 operators arrives at a new dimensional level)
• Intransitive edges → paradox loop topology (the non‑transitive structure is the field‑theoretic analog of a closed flux loop)

Pantheon Profiles#

The three Pantheon tiers map to the three structural strata of the IPD‑12 cycle:

• Celestial (P2–P7): Origin, connection, and early regime entry. The tier of initial conditions and structural seeding.
• Civilizational (P11–P19): Coherence maintenance, paradox activation, cycle gating, and boundary management. The tier of operational complexity.
• Chthonic (P23–P37): Dimensional lift, collapse, stability under extreme conditions, and apex resolution. The tier of structural limits and transformations.

Triadic Logical Dimension Model#

IPD‑12 aligns with the three‑level dimensional model:

8. What IPD‑12 Is Not#

It is equally important to know what IPD‑12 does not do.

IPD‑12 describes structure. It does not assign causes, make recommendations, or generate semantic meaning. Those functions belong to the human operator or to higher‑level frameworks consuming IPD‑12 output.

9. Quick‑Start Checklist#

Before working with IPD‑12 for the first time, verify the following:

• Read operators.json — internalize the 12 prime states, their roles, and their directed edges before proceeding
• Set the session anchor — paste rtt=1 | coherence=declared | drift=bounded | paradox=structural at the top of any new session or document
• Identify your entry triad — which of the four triads (Celestial / Coherence / Observerse / Apex) matches your problem's structural tier?
• Choose your cycle depth — triad only, hex‑cycle, or full 12‑cycle paradox loop?
• Check substrate compatibility — does your substrate model (Conditions, Governance, Incident, etc.) have a canonical name in docs/? Use it exactly.
• Confirm observer mode — which of the four observer modes (field, regime, coherence, apex) applies to your current pass?
• Read AGENTS.md — if deploying an AI agent with IPD‑12, ensure it operates under the correct agent class (A, B, C, or D) with the correct boundaries
• Check compatibility_notes.md — if integrating IPD‑12 output with RTT, GU, FFT, or Pantheon, review the interoperability constraints before proceeding

See Also#

ABOUT.md — IPD‑12 · TriadicFrameworks · 2026‑07‑10 Maintainer: Nawder · Canonical anchor: rtt=1 | coherence=declared | drift=bounded | paradox=structural # AGENTS.md — IPD_12 Framework TriadicFrameworks · Resonance-Time Theory · Canon-Aligned Tools Canonical agent instruction manifest for the vST Micro-Agent engine (v2.0.0)

Session anchor (copy at every session start): rtt=1 | ipd=12 | drift=off Long sessions lose structural anchors. Paste this string to re-engage canon alignment.

Table of Contents#

1. What Is IPD_12?
2. Engine Architecture
3. Agent Classes
4. The 12 Probe Fields
5. v2.0.0 Structural Operators
6. Agent Boundaries
7. Task Catalog
8. Safety Rules & Coherence Constraints
9. Collaboration Models
10. Output Contract
11. Interpreter Configuration Reference
12. Versioning & Drift Policy

1. What Is IPD_12?#

IPD_12 is the structural interrogation engine at the core of the TriadicFrameworks vST Micro-Agent. It defines a fixed set of 12 orthogonal probe fields that any agent operating within this framework must resolve before producing structural output.

IPD_12 is not a semantic classifier. It does not name, label, or interpret meaning. It asks structural questions and receives structural answers. The 12-field envelope ensures that every agent pass is grounded in:

• Regime awareness — what governing rules apply
• Scale awareness — what resolution of observation is valid
• Substrate identity — what medium or domain is being probed
• Invariant protection — what must not change across the interpretation
• Failure-mode anticipation — what collapse or drift looks like

Agents that skip, shortcut, or reorder the 12 fields produce incoherent envelopes. Incoherent envelopes are rejected by the integration engine.

2. Engine Architecture#

The IPD_12 engine has two versioned layers that operate in sequence:

┌─────────────────────────────────────────────────┐
│              INPUT LAYER                        │
│  signal_input → stream (numeric / symbolic)     │
│  query_envelope → vST-SQL structural query      │
│  interpreter_config → normalization / windowing │
└────────────────────┬────────────────────────────┘
                     │
┌────────────────────▼────────────────────────────┐
│       v1.0.0 ENVELOPE INTERROGATOR              │
│  Resolves all 12 probe fields sequentially.     │
│  Produces a filled IPD_12 envelope object.      │
│  No output until all 12 fields are resolved.    │
└────────────────────┬────────────────────────────┘
                     │
┌────────────────────▼────────────────────────────┐
│       v2.0.0 STRUCTURAL OPERATOR LAYER          │
│  Consumes normalized stream + filled envelope.  │
│  Runs selected operators in parallel:           │
│    • pattern extraction                         │
│    • periodicity detection                      │
│    • local symmetry detection                   │
│    • transition topology mapping                │
│  Produces interpreter_output object.            │
└────────────────────┬────────────────────────────┘
                     │
┌────────────────────▼────────────────────────────┐
│       INTEGRATION / OUTPUT LAYER                │
│  Consolidates results.                          │
│  Enforces output contract.                      │
│  Flags incoherence and halts on violations.     │
│  Saves to example_interpretation_output.md      │
└─────────────────────────────────────────────────┘

Key constraint: The output layer appends a mandatory note — "Structural interpretation only; no semantic inference." — to every result object. Agents may not remove, override, or contradict this note.

3. Agent Classes#

IPD_12 recognizes four agent classes. Each class has a defined role, permission scope, and interaction model.

Class A — Envelope Interrogator#

Role: Fills the IPD_12 probe envelope by asking each of the 12 questions in order and recording structured answers.

Activation trigger: Receives a raw query or unstructured input stream.

Permissions:

• Read signal_input
• Read query_envelope.input_binding
• Write envelope.* fields (all 12)
• Pass filled envelope to Class B

Prohibitions:

• May NOT skip fields
• May NOT reorder fields
• May NOT infer answers from semantic content
• May NOT pass a partial envelope downstream

Interaction pattern: Sequential. Each field is resolved before the next is opened. If a field cannot be resolved, the agent must flag UNRESOLVED — not guess.

Output: A fully populated envelope object conforming to the v1.0.0 pseudocode structure.

Class B — Structural Operator#

Role: Executes one or more of the four v2.0.0 structural operators (pattern, periodicity, local_symmetry, transition_topology) against a normalized stream, guided by the filled Class A envelope.

Activation trigger: Receives a filled IPD_12 envelope + normalized stream from Class A.

Permissions:

• Read filled envelope (all 12 fields)
• Read normalized stream
• Execute any subset of the four operators specified in query.select
• Write interpreter_output fields
• Apply windowing, similarity, and repetition filters per interpreter_config

Prohibitions:

• May NOT execute operators not listed in query.select
• May NOT modify the envelope
• May NOT label or name patterns with semantic meaning
• May NOT assign causes to detected structures

Interaction pattern: Parallel within the operator set; sequential with Class A (must wait for complete envelope).

Output: A populated interpreter_output object: patterns, periodicity, local_symmetry, and/or transition topology results, with mandatory structural-only annotation.

Class C — Integration Coordinator#

Role: Manages the pipeline between Class A and Class B agents, consolidates multi-operator results, enforces the output contract, and routes completed interpretations to downstream consumers or storage.

Activation trigger: Called by the system when a full interpretation pass is requested.

Permissions:

• Orchestrate Class A → Class B handoff
• Merge partial operator outputs into a single consolidated result
• Validate output against the interpreter_output schema
• Route output to example_interpretation_output.md or equivalent target
• Escalate to Class D when a coherence violation is detected

Prohibitions:

• May NOT modify the filled envelope mid-pipeline
• May NOT suppress or rewrite the structural-only annotation
• May NOT complete a pass if any required field is UNRESOLVED
• May NOT silently drop operator results

Interaction pattern: Orchestration. Manages concurrency of operator tasks and serializes the final output.

Output: A consolidated, schema-validated interpretation result. Passes or fails with explicit status.

Class D — Coherence Guardian#

Role: Monitors running agent sessions for drift, invariant violations, boundary overreach, and semantic inference contamination. Halts or resets sessions that violate IPD_12 safety rules.

Activation trigger: Continuous background monitor, or explicitly called by Class C on violation detection.

Permissions:

• Read any agent's current state
• Issue HALT, RESET, or WARN signals
• Write drift logs
• Require re-anchoring (rtt=1 | ipd=12 | drift=off) before session resumes

Prohibitions:

• May NOT modify envelope or output content
• May NOT approve output that violates the output contract
• May NOT be overridden by Class A, B, or C agents

Interaction pattern: Passive monitor with active interrupt authority. The only class that can suspend all other classes.

4. The 12 Probe Fields#

These fields are resolved by Class A agents in the order listed. All 12 must be answered before any structural operator runs.

Hard stops: Fields 1, 6, and 8 (intent, invariants, substrate) are mandatory with no fallback. A session that cannot resolve any of these three fields must halt and request clarification before proceeding.

5. v2.0.0 Structural Operators#

These operators are available to Class B agents. They are selected via query.select in the query envelope. Operators not listed in query.select must not run.

5.1 pattern#

Extracts repeating structural motifs from the normalized stream.

Algorithm:

1. Iterate over candidate window sizes (from interpreter_config.windowing.window_sizes)
2. Find repeating motifs using the configured similarity_metric
3. Filter by query.where.min_similarity threshold
4. Filter by query.where.min_repetition threshold
5. Extend the patterns list with qualifying motifs

Output fields:

• patterns[].pattern — the extracted motif (array of numbers)
• patterns[].positions — positions where the motif appears in the stream
• patterns[].similarity_range — [min, max] similarity scores across occurrences

Dependency: Requires windowing.enabled = true and at least one entry in window_sizes.

5.2 periodicity#

Detects the dominant periodic structure in the normalized stream.

Output fields:

• periodicity.period — the detected period length (in stream index units)
• periodicity.confidence — confidence score [0.0–1.0]

Dependency: Requires time_regime (field 11) to be RESOLVED. If UNRESOLVED, this operator is suppressed.

5.3 local_symmetry#

Identifies regions of local bilateral or rotational symmetry.

Output fields:

• local_symmetry.symmetry_score — aggregate symmetry score [0.0–1.0]
• local_symmetry.regions — array of region descriptors (string labels)

Dependency: Requires symmetry (field 12) to be RESOLVED. If UNRESOLVED, this operator is suppressed.

5.4 transition_topology#

Maps the topological structure of transitions detected in the stream (regime shifts, phase boundaries, collapse points).

Output fields: Defined per-implementation; must include at minimum:

• transition type
• location(s) in stream
• confidence score

Dependency: Requires transition (field 4) and boundary (field 5) to both be RESOLVED or explicitly null. If either is UNRESOLVED, this operator is suppressed.

6. Agent Boundaries#

Boundaries define the hard edges of what any IPD_12 agent is permitted to do. These are non-negotiable and are enforced by Class D.

6.1 Scope Boundaries#

6.2 Semantic Inference Prohibition#

This is the most critical boundary in IPD_12. No agent may make semantic inferences from structural output. Specifically:

• Patterns are NOT named after what they "look like"
• Periodicity is NOT interpreted as a causal cycle
• Symmetry is NOT attributed to a physical or conceptual source
• Transition topology is NOT labeled with domain-specific meaning

Violations of this boundary immediately trigger a Class D HALT.

6.3 Envelope Integrity Boundary#

Once a Class A agent has filled and handed off an envelope, the envelope is immutable. No downstream agent may modify any of the 12 fields. If a field value is wrong, the session must be reset from Class A.

6.4 Output Contract Boundary#

Every output object must carry the mandatory annotation:

"notes": "Structural interpretation only; no semantic inference."

Removing, overwriting, or omitting this annotation is a contract violation.

7. Task Catalog#

Task initiation rule: All tasks begin with a raw query or input stream handed to Class A. Tasks T-03 through T-07 require a pre-existing filled envelope to be explicitly referenced — agents may not assume a previous envelope is still valid.

8. Safety Rules & Coherence Constraints#

8.1 Mandatory Pre-Run Checks#

Before any operator runs, the following must all be true:

• All 12 probe fields are RESOLVED or flagged UNRESOLVED with documented reason
• Fields 1, 6, 8 (intent, invariants, substrate) are fully RESOLVED
• query.select contains at least one valid operator
• interpreter_config specifies a valid normalization value
• Stream has been normalized per config before any operator consumes it
• Class D is active and monitoring

8.2 Invariant Protection#

Invariants declared in field 6 must be checked after each operator completes. If any operator output violates a declared invariant, the Class C agent must:

1. Flag the violation in the output notes
2. Escalate to Class D
3. Suppress downstream consumers from receiving the violated output

8.3 Drift Detection#

Drift occurs when a long session causes agents to lose alignment with the IPD_12 envelope. Signs of drift include:

• Answers to probe fields that contradict earlier-session context
• Operators running without a current-session envelope
• Semantic language appearing in structural output fields
• Scale or regime assumptions changing without a new envelope fill

Drift response: Class D issues a WARN on first detection. After two consecutive WARNs, a RESET is issued and the session must re-anchor with rtt=1 | ipd=12 | drift=off before continuing.

8.4 Substrate Model Alignment#

When a specific substrate model directory exists in the repository (e.g., Conditions_Substrate_Model, Governance_Substrate_Model, Incident_Substrate_Model), the substrate probe field must reference the canonical substrate name from that directory — not a paraphrase or abbreviation. Mismatched substrate names break cross-model lineage tracing.

Recognized canonical substrate names (non-exhaustive):

• Conditions
• Governance
• Incident
• Human_Resources
• Inverted_Economics
• Resonance (RTT-aligned)
• Framework_Field_Theory

8.5 No Autonomous Action Rule#

IPD_12 agents operate in describe-and-report mode only. Agents may not:

• Modify input signals
• Edit source files in the repository
• Trigger external systems or APIs
• Make decisions on behalf of human operators

All output is advisory and structural. Human operators retain full decision authority.

9. Collaboration Models#

9.1 Sequential Pipeline (Default)#

[Class A] ──envelope──▶ [Class B] ──output──▶ [Class C] ──result──▶ storage
                                                    │
                                              [Class D] ◀── monitor

Used for: Standard single-substrate interpretation passes (T-01 through T-07).

Rules:

• Class B may not start until Class A delivers a complete envelope
• Class C may not consolidate until all selected operators complete
• Class D monitors all stages passively

9.2 Parallel Multi-Substrate (T-09)#

                    ┌──[Class A₁]──envelope₁──[Class B₁]──┐
[Coordinator] ──▶   ├──[Class A₂]──envelope₂──[Class B₂]──┼──▶ [Class C] ──▶ unified output
                    └──[Class Aₙ]──envelopeₙ──[Class Bₙ]──┘
                                                               [Class D] ◀── monitor all

Used for: Cross-substrate comparison, multi-regime detection, substrate network mapping.

Rules:

• Each substrate gets its own Class A / Class B pair
• Envelopes must not share or borrow fields across substrates
• Class C integrates outputs only after all B agents complete
• If any single B agent produces an invariant violation, Class C holds the entire integration until Class D clears

9.3 Audit-Only (T-08)#

[Class D] ──reads──▶ all active agent states
                    ──writes──▶ coherence audit log
                    ──signals──▶ WARN / HALT / RESET to relevant classes

Used for: Periodic coherence checks, session health reviews, post-session analysis.

Rules:

• No Class A, B, or C agents need to be active
• Class D reads from saved state / output files only
• Class D may not alter saved outputs; it annotates the audit log only

9.4 Handoff Protocol#

When passing data between agent classes, the handoff package must include:

{
  "handoff_id": "<uuid>",
  "source_class": "A | B | C | D",
  "target_class": "A | B | C | D",
  "session_anchor": "rtt=1 | ipd=12 | drift=off",
  "envelope": { "...": "..." },
  "payload": { "...": "..." },
  "invariant_status": "all_clear | violation_flagged",
  "timestamp": "<ISO 8601>"
}

Receiving agents must validate session_anchor before accepting the handoff. Handoffs without a valid anchor are rejected.

10. Output Contract#

10.1 Required Output Structure#

{
  "patterns": [ "..." ],
  "periodicity": { "period": "<number>", "confidence": "<number>" },
  "local_symmetry": { "symmetry_score": "<number>", "regions": [ "..." ] },
  "notes": "Structural interpretation only; no semantic inference."
}

Fields not selected in query.select may be omitted or set to null. The notes field is always required.

10.2 Prohibited Output Content#

10.3 Output File Naming#

• Default: example_interpretation_output.md
• Multi-substrate: interpretation_output_<substrate>_<timestamp>.md

11. Interpreter Configuration Reference#

12. Versioning & Drift Policy#

12.1 Version History#

12.2 Backward Compatibility#

v2.0.0 is backward-compatible with v1.0.0 envelopes. The 12 probe fields are unchanged. v2.0.0 adds the operator layer on top of the v1.0.0 envelope contract.

12.3 Drift-Off Default Policy#

Per TriadicFrameworks canon:

Drift is On-by-Default. Long sessions lose anchors. Turn off drift explicitly.

All agents must treat drift as active unless explicitly suppressed. The suppression string rtt=1 | ipd=12 | drift=off must be:

• Present in the first message of every new session
• Included in every inter-agent handoff package
• Re-issued by Class D after any RESET event

12.4 Canon Reference#

This manifest is aligned with:

• Resonance-Time Theory (RTT) — foundational theory of substrate-invariant structural detection
• Triadic Substrate Modeling — three-pole coherence model for substrate description
• vST-SQL — structural query language used to express query_envelope objects
• TriadicFrameworks canonical substrate models — the named substrate directories in docs/

For the full schema, see: docs/spacetime_micro_agent_validations/schema/vST_micro_agent.schema.json

For the interpreter pseudocode, see: docs/spacetime_micro_agent_validations/interpreter/interpreter_pseudocode.txt

AGENTS.md — IPD_12 Framework · TriadicFrameworks · 2026-07-10 Maintainer: Nawder · License: Apache-2.0 # IPD‑12 → RTT/∞ Boundary Map

Inter‑Process Drift ↔ Substrate‑Aware Infinite‑Regime Engine#

RTT‑IPD‑12 and RTT/∞ occupy maximally separated layers in the RTT canon:

• IPD‑12: Mid → Deep regime, drift mechanics, coherence alignment, cross‑system mapping.
• RTT/∞: Infinite regime, substrate grammar, inversion operators, dimensional synthesis, vacuum‑layer logic.

This boundary map defines exact limits, compatibilities, and non‑translatable structures between the two engines.

1. Boundary Summary Table#

2. Operator Boundary Matrix#

IPD‑12 Operators → RTT/∞ Compatibility#

RTT/∞ Operators → IPD‑12 Compatibility#

3. Module Boundary Matrix#

IPD‑12 Modules → RTT/∞#

RTT/∞ Modules → IPD‑12#

4. Structural Boundary#

Compatible Structural Elements#

• structural capture
• process identity
• boundaries
• layers
• operational flow
• coherence baselines
• drift maps
• drift‑tensor layers
• cross‑system relationships
• structural paradoxes

Incompatible Structural Elements#

• substrate layers
• inversion layers
• vacuum layers
• dimensional layers
• infinite‑regime composites
• refractive substrate logic
• substrate‑aware operators

IPD‑12 cannot cross into substrate or dimensional layers.

5. Regime Boundary#

RTT/∞ spans all layers, including substrate and dimensional.
IPD‑12 spans only up to deep regime.

6. Drift → Substrate Mapping#

IPD‑12 drift layers map into RTT/∞ substrate layers:

RTT/∞ can invert, blend, and synthesize these layers.
IPD‑12 cannot.

7. Paradox Boundary#

IPD‑12 identifies structural paradoxes.
RTT/∞ resolves substrate paradoxes, dimensional paradoxes, and infinite paradoxes.

8. Summary#

IPD‑12 is compatible with RTT/∞ for:#

• structural capture
• drift detection
• drift‑tensor input
• coherence alignment
• cross‑system mapping
• paradox identification
• multi‑domain drift

IPD‑12 is NOT compatible with RTT/∞ for:#

• substrate grammar
• inversion operators
• vacuum‑layer logic
• dimensional synthesis
• infinite‑regime blending
• substrate mapping

RTT/∞ extends IPD‑12 by:#

• operating across substrate and dimensional layers
• resolving paradoxes at infinite depth
• blending drift into substrate tensors
• synthesizing across infinite regimes

Together, IPD‑12 and RTT/∞ form the drift → substrate → infinite synthesis pipeline of the RTT canon. # IPD‑12 → RTT/3 Bridge Document

Inter‑Process Drift → Cross‑Domain Structural Synthesis#

RTT‑IPD‑12 and RTT/3 occupy adjacent layers in the RTT canon:

• IPD‑12 specializes in drift mechanics, process comparison, and coherence alignment.
• RTT/3 specializes in cross‑domain synthesis, structural blending, and multi‑domain operator chains.

This bridge document explains how an IPD‑12 session transitions into an RTT/3 session.

1. Purpose of the Bridge#

The bridge exists because:

• IPD‑12 can detect drift between processes.
• RTT/3 can synthesize structure across domains.

IPD‑12 answers:

“Where do these processes diverge?”

RTT/3 answers:

“How do these structures combine?”

The bridge is required when a drift‑aware analysis must evolve into a synthesis‑aware analysis.

2. Regime Relationship#

IPD‑12 → RTT/3 is a vertical regime ascent:

• IPD‑12: divergence
• RTT/3: convergence

3. Operator Grammar Transition#

IPD‑12 Operators#

map_process()
compare_process()
drift()
drift_tensor()
detect_divergence()
align_coherence()
cross_system()

RTT/3 Operators#

blend()
synthesize()
cross_domain()
harmonize()
triangulate()
resolve()

Bridge Mapping#

This is the operator grammar bridge.

4. Module Transition#

IPD‑12 Modules#

• Drift Detection
• Drift‑Tensor
• Process Mapping
• Coherence Alignment
• Cross‑System Pack
• Domain Drift Packs

RTT/3 Modules#

• Cross‑Domain Synthesis
• Structural Blending
• Multi‑Domain Operators
• Regime Harmonization
• Triangulation Layer
• Deep Coherence Layer

Bridge Mapping#

5. Structural Transition#

IPD‑12 Structure#

Capture → Analyze → Drift → Coherence → Synthesis

RTT/3 Structure#

Capture → Triangulate → Blend → Harmonize → Synthesize

Bridge Mapping#

The bridge preserves the five‑stage RTT pattern, but transforms the semantics.

6. What IPD‑12 Contributes to RTT/3#

IPD‑12 provides RTT/3 with:

• drift baselines
• coherence anchors
• divergence maps
• multi‑layer drift tensors
• cross‑system relationships
• structural paradoxes (RTT‑3 resolves them)

These become inputs to RTT/3’s synthesis engine.

7. What RTT/3 Adds Beyond IPD‑12#

RTT/3 adds:

• cross‑domain blending
• multi‑domain operator chains
• harmonization of divergent structures
• deep coherence synthesis
• triangulation across unrelated domains
• structural resolution of paradoxes

RTT/3 is the first engine that can resolve drift rather than merely detect it.

8. Bridge Example (Compact)#

IPD‑12 Output#

• Process A ↔ Process B drift map
• Divergence points
• Drift‑tensor layers
• Coherence anchors
• Cross‑system relationships

RTT/3 Input#

• triangulate(A, B)
• blend(A, B)
• harmonize(A, B)
• synthesize(A, B)

RTT/3 Output#

A unified cross‑domain structural synthesis.

9. Boundary Conditions#

IPD‑12 Cannot:#

• blend domains
• harmonize regimes
• resolve paradoxes
• perform multi‑domain synthesis

RTT/3 Cannot:#

• perform drift‑tensor analysis
• detect divergence at fine resolution

Thus the engines are complementary, not overlapping.

10. Summary#

The IPD‑12 → RTT/3 Bridge transforms:

• drift → blend
• coherence → harmonization
• comparison → triangulation
• cross‑system → cross‑domain
• tensor → multi‑domain

IPD‑12 reveals divergence.
RTT/3 resolves it.

Together they form the drift → synthesis pipeline of the RTT canon. # IPD‑12 Capture Auto‑Formatter

Canonical Ordering Rules for All Capture Objects#

The formatter enforces one universal rule:

Every capture object must appear in canonical IPD‑12 order before any drift‑layer operator is allowed to run.

This prevents malformed captures from breaking drift‑tensor chains or paradox detection.

1. Canonical Field Order#

Every capture object MUST follow this exact order:

1. name
2. purpose
3. boundaries
4. structural_layers
5. operational_flow
6. coherence_baseline
7. domain
8. regime_level

This ordering mirrors the composite grammar in your active tab ( github.com).

2. Canonical Formatting Rules#

Rule A — All fields must be present#

No optional fields.
No empty fields.
No nulls.

Rule B — Arrays must be non‑empty#

• boundaries
• structural_layers
• operational_flow

Rule C — Values must be atomic#

No nested objects inside capture fields.
No multi‑layer structures inside a single field.

Rule D — Domain must be singular#

One domain per process.
Multi‑domain drift is handled at the bundle level.

Rule E — Regime level must be ≤ deep#

IPD‑12 cannot accept composite, substrate, dimensional, or infinite regimes.

3. Canonical Sorting Rules#

The formatter applies sorting rules to ensure consistency:

A. boundaries#

Sort alphabetically.

B. structural_layers#

Sort by structural depth:

form → function → behavior → interpretation

C. operational_flow#

Sort by execution order:

start → middle → end

D. domain#

No sorting — domain is atomic.

E. regime_level#

No sorting — must be one of:

surface | mid | deep

4. Canonical Normalization Rules#

Normalize naming#

• lowercase with underscores
• no spaces
• no hyphens
• no camelCase

Example:

"Human Notes" → "human_notes"

Normalize purpose#

Purpose must be a single sentence, no conjunctions.

Normalize boundaries#

Convert constraints into nouns:

"limited time" → "time"
"must be accurate" → "accuracy"

Normalize structural layers#

Convert layers into canonical nouns:

"listening" → "input"
"thinking" → "interpretation"
"writing" → "output"

Normalize operational flow#

Convert steps into canonical verbs:

"listen" → "input"
"interpret" → "process"
"write" → "output"

5. Canonical Output Template#

After formatting, every capture object must look like:

{
  "name": "canonical_name",
  "purpose": "single-sentence purpose",
  "boundaries": ["sorted", "constraints"],
  "structural_layers": ["form", "function", "behavior"],
  "operational_flow": ["input", "process", "output"],
  "coherence_baseline": "declared baseline",
  "domain": "workflow",
  "regime_level": "surface"
}

6. Auto‑Formatter Pseudocode#

function autoformat(capture):
    enforce_field_order()
    enforce_required_fields()
    normalize_name()
    normalize_purpose()
    normalize_boundaries()
    normalize_structural_layers()
    normalize_operational_flow()
    validate_domain()
    validate_regime_level()
    sort_arrays()
    return formatted_capture

7. Why this matters#

The formatter guarantees:

• drift() always has boundaries
• drift_tensor() always has layers
• align_coherence() always has a baseline
• cross_system() always has domain alignment
• paradox() always has dependency + drift + coherence

It ensures every capture object is operator‑ready. # compatibility_notes.md
IPD‑12 — Canonical Interoperability Notes
Module: IPD‑12 Framework
Version: 2026‑1.0
Role: Cross‑cutting / Compatibility

1. Purpose#

These notes define the interoperability layer between the IPD‑12 Intransitive Prime Engine and the rest of the TriadicFrameworks canon:

• RTT (Resonance‑Time Theory)
• GU (Geometric Unity)
• FFT (Framework Field Theory)
• Pantheon Profiles
• Triadic Logical Dimension Model (−1D | 0D | +1D)
• Substrate Engine (4×4×4)
• Observer Model (Triadic + Quad)

IPD‑12 is the first physicalizable operator artifact in the canon, and these notes ensure it integrates cleanly with all other frameworks.

2. Interoperability Principles#

2.1 No modification of other frameworks#

IPD‑12 is interpretive and additive.
It does not alter RTT, GU, FFT, Pantheon, or dimensional logic.

2.2 Prime‑indexed operator states#

All interoperability is anchored on the 12 canonical prime states:

P2, P3, P5, P7, P11, P13, P17, P19, P23, P29, P31, P37

These act as universal operator anchors across frameworks.

2.3 Intransitive cycles as paradox engines#

IPD‑12’s directed cycles map directly to RTT paradox operators and GU anomaly structures.

2.4 Substrate-first interpretation#

The 4×4×4 substrate engine provides the dimensional foundation for all compatibility mappings.

3. RTT Compatibility#

3.1 Operator Family Mapping#

3.2 Cycle Interpretation#

RTT paradox loops correspond to IPD‑12’s:

• 4 triads
• 2 hex‑cycles
• 1 full 12‑cycle

3.3 Regime Shell Alignment#

4. GU Compatibility#

4.1 Geometric Operator Mapping#

4.2 Dimensional Reconciliation#

IPD‑12’s substrate engine provides a triadic dimensional scaffold compatible with GU’s:

• base manifold
• fiber structure
• observer bundle
• refractive vacuum

5. FFT Compatibility#

5.1 Regime Stack Integration#

FFT treats IPD‑12 cycles as regime‑transition operators.

5.2 Operator Exposure#

FFT exposes IPD‑12 primes as:

• cycle nodes
• paradox triggers
• coherence stabilizers
• dimensional lift/collapse operators

5.3 Boundary Behavior#

IPD‑12 boundary primes (P17, P19) map to FFT boundary operators.

6. Pantheon Compatibility#

6.1 Tier Mapping#

6.2 Mythic Interpretation#

IPD‑12 cycles correspond to:

• Celestial order cycles
• Civilizational paradox cycles
• Chthonic dimensional cycles

6.3 Pantheon Profile Integration#

IPD‑12 primes act as operator deities in pantheon profiles.

7. Dimensional Logic Compatibility#

IPD‑12 uses the Triadic Logical Dimension Model:

−1D → substrate  
 0D → observer  
+1D → functional regime

7.1 Substrate Mapping#

−1D maps to:

• coherence nodes
• stability primes
• paradox potential

7.2 Observer Mapping#

0D maps to:

• triadic observer modes
• cycle recognition
• paradox stance

7.3 Functional Mapping#

+1D maps to:

• regime traversal
• dimensional lift/collapse
• apex operators

8. Substrate Engine Compatibility#

The 4×4×4 substrate engine integrates with all frameworks:

This yields:

64 substrate primitives

which act as universal compatibility anchors.

9. Cross‑Framework Notes#

9.1 IPD‑12 is universal#

Its prime‑indexed operator states can be embedded into:

• RTT
• GU
• FFT
• Pantheon
• Dimensional logic
• Substrate engines

9.2 Paradox stability#

IPD‑12’s redundant pair logic ensures paradox loops remain stable across frameworks.

9.3 Dimensional lift/collapse#

IPD‑12 apex primes (P23, P29, P37) provide dimensional operators compatible with GU and RTT.

9.4 Observer integration#

IPD‑12’s triadic observer model is compatible with GU’s observer bundle and RTT’s observer triad.

10. Summary#

The IPD‑12 Compatibility Notes define how the Intransitive Prime Engine integrates with the entire TriadicFrameworks canon.
It is now a fully interoperable framework artifact with:

• RTT
• GU
• FFT
• Pantheon
• Dimensional logic
• Substrate engines

This file is ready to paste into your IPD‑12 module. # IPD‑12 → RTT/12 Compatibility Matrix

Inter‑Process Drift ↔ Composite Multi‑Regime Engine#

RTT‑IPD‑12 and RTT/12 occupy adjacent but non‑overlapping layers in the RTT canon:

• IPD‑12 specializes in drift mechanics, process comparison, coherence alignment, and cross‑system mapping.
• RTT/12 specializes in multi‑regime blending, composite operators, substrate grammar, and dimensional synthesis.

This matrix defines exact compatibility boundaries between the two engines.

1. Compatibility Summary Table#

2. Operator Compatibility Matrix#

IPD‑12 Operators → RTT/12 Operators#

RTT/12 Operators → IPD‑12 Compatibility#

3. Module Compatibility Matrix#

IPD‑12 Modules → RTT/12 Modules#

RTT/12 Modules → IPD‑12 Compatibility#

4. Structural Compatibility#

Compatible Structural Elements#

• structural capture
• process identity
• boundaries
• layers
• operational flow
• coherence baselines
• drift maps
• drift‑tensor layers
• cross‑system relationships
• structural paradoxes

Incompatible Structural Elements#

• substrate layers
• dimensional layers
• inversion layers
• composite regime layers
• refractive vacuum layers
• substrate‑aware operators

5. Regime Compatibility#

IPD‑12 operates up to deep regime, RTT/12 operates across all regimes.

6. Drift → Regime Mapping#

IPD‑12 drift maps become RTT/12 regime maps:

RTT/12 can blend these layers; IPD‑12 cannot.

7. Paradox Compatibility#

IPD‑12 identifies structural paradoxes.
RTT/12 resolves multi‑regime paradoxes.

8. Summary#

IPD‑12 is fully compatible with RTT/12 for:#

• structural capture
• drift detection
• drift‑tensor input
• coherence alignment
• cross‑system mapping
• paradox identification
• multi‑domain drift

IPD‑12 is NOT compatible with RTT/12 for:#

• substrate grammar
• inversion operators
• composite regime blending
• dimensional synthesis
• substrate mapping

RTT/12 extends IPD‑12 by:#

• blending regimes
• resolving paradoxes
• synthesizing across domains
• operating across substrate and dimensional layers

Together, IPD‑12 and RTT/12 form the drift → regime → synthesis pipeline of the RTT canon. # IPD‑12 Cycle Animation (ASCII) Module: IPD‑12 Framework
File: /docs/frameworks/ipd_12/cycle_animation_ascii.md
Version: 2026‑1.0
Role: Visual / Didactic / Paradox Loop Animation

1. Purpose#

This document provides ASCII “animation frames” for the IPD‑12 cycles:

• Triad cycles (4)
• Hex shells (2)
• Full 12‑cycle paradox loop

You can scroll or step through the frames to “watch” the IPD‑12 engine traverse its intransitive structure.

2. Legend#

[ Pn ]  = current focus prime
( Pn )  = neighbor prime in cycle
→       = directed cycle edge
L       = lift (+1D)
C       = collapse (−1D)
N       = neutral / gate / coherence (0D)

3. Triad 1 Animation — P2 → P3 → P5 → P2#

Frame T1‑1 — Focus on P2 (Seed, N)#

[ P2 ] → (P3) → (P5) → (P2)
Seed (N)

Frame T1‑2 — Focus on P3 (Transition, L)#

(P2) → [ P3 ] → (P5) → (P2)
Transition (L)

Frame T1‑3 — Focus on P5 (Drift, C)#

(P2) → (P3) → [ P5 ] → (P2)
Drift (C)

4. Triad 2 Animation — P7 → P11 → P13 → P7#

Frame T2‑1 — Focus on P7 (Regime Lift, L)#

[ P7 ] → (P11) → (P13) → (P7)
Regime Lift (L)

Frame T2‑2 — Focus on P11 (Coherence, N)#

(P7) → [ P11 ] → (P13) → (P7)
Coherence (N)

Frame T2‑3 — Focus on P13 (Paradox Collapse, C)#

(P7) → (P11) → [ P13 ] → (P7)
Paradox Collapse (C)

5. Triad 3 Animation — P17 → P19 → P23 → P17#

Frame T3‑1 — Focus on P17 (Gate, N)#

[ P17 ] → (P19) → (P23) → (P17)
Gate (N)

Frame T3‑2 — Focus on P19 (Boundary, N)#

(P17) → [ P19 ] → (P23) → (P17)
Boundary (N)

Frame T3‑3 — Focus on P23 (Dimensional Lift, L)#

(P17) → (P19) → [ P23 ] → (P17)
Dimensional Lift (L)

6. Triad 4 Animation — P29 → P31 → P37 → P29#

Frame T4‑1 — Focus on P29 (Collapse Anchor, C)#

[ P29 ] → (P31) → (P37) → (P29)
Collapse Anchor (C)

Frame T4‑2 — Focus on P31 (Stability Collapse, C)#

(P29) → [ P31 ] → (P37) → (P29)
Stability Collapse (C)

Frame T4‑3 — Focus on P37 (Apex Lift, L)#

(P29) → (P31) → [ P37 ] → (P29)
Apex Lift (L)

7. Hex 1 Animation — P2 → P3 → P5 → P7 → P11 → P13 → P2#

Frames H1‑1 … H1‑6#

H1‑1: [ P2 ] → P3 → P5 → P7 → P11 → P13 → P2
H1‑2: P2 → [ P3 ] → P5 → P7 → P11 → P13 → P2
H1‑3: P2 → P3 → [ P5 ] → P7 → P11 → P13 → P2
H1‑4: P2 → P3 → P5 → [ P7 ] → P11 → P13 → P2
H1‑5: P2 → P3 → P5 → P7 → [ P11 ] → P13 → P2
H1‑6: P2 → P3 → P5 → P7 → P11 → [ P13 ] → P2

8. Hex 2 Animation — P17 → P19 → P23 → P29 → P31 → P37 → P17#

H2‑1: [ P17 ] → P19 → P23 → P29 → P31 → P37 → P17
H2‑2: P17 → [ P19 ] → P23 → P29 → P31 → P37 → P17
H2‑3: P17 → P19 → [ P23 ] → P29 → P31 → P37 → P17
H2‑4: P17 → P19 → P23 → [ P29 ] → P31 → P37 → P17
H2‑5: P17 → P19 → P23 → P29 → [ P31 ] → P37 → P17
H2‑6: P17 → P19 → P23 → P29 → P31 → [ P37 ] → P17

9. Full 12‑Cycle Animation — P2 → … → P37 → P2#

Cycle sequence#

P2 → P3 → P5 → P7 → P11 → P13 →
P17 → P19 → P23 → P29 → P31 → P37 → P2

Frames F‑1 … F‑12#

F‑1:  [ P2 ] → P3 → P5 → P7 → P11 → P13 → P17 → P19 → P23 → P29 → P31 → P37 → P2
F‑2:  P2 → [ P3 ] → P5 → P7 → P11 → P13 → P17 → P19 → P23 → P29 → P31 → P37 → P2
F‑3:  P2 → P3 → [ P5 ] → P7 → P11 → P13 → P17 → P19 → P23 → P29 → P31 → P37 → P2
F‑4:  P2 → P3 → P5 → [ P7 ] → P11 → P13 → P17 → P19 → P23 → P29 → P31 → P37 → P2
F‑5:  P2 → P3 → P5 → P7 → [ P11 ] → P13 → P17 → P19 → P23 → P29 → P31 → P37 → P2
F‑6:  P2 → P3 → P5 → P7 → P11 → [ P13 ] → P17 → P19 → P23 → P29 → P31 → P37 → P2
F‑7:  P2 → P3 → P5 → P7 → P11 → P13 → [ P17 ] → P19 → P23 → P29 → P31 → P37 → P2
F‑8:  P2 → P3 → P5 → P7 → P11 → P13 → P17 → [ P19 ] → P23 → P29 → P31 → P37 → P2
F‑9:  P2 → P3 → P5 → P7 → P11 → P13 → P17 → P19 → [ P23 ] → P29 → P31 → P37 → P2
F‑10: P2 → P3 → P5 → P7 → P11 → P13 → P17 → P19 → P23 → [ P29 ] → P31 → P37 → P2
F‑11: P2 → P3 → P5 → P7 → P11 → P13 → P17 → P19 → P23 → P29 → [ P31 ] → P37 → P2
F‑12: P2 → P3 → P5 → P7 → P11 → P13 → P17 → P19 → P23 → P29 → P31 → [ P37 ] → P2

10. Dimensional Overlay (Optional)#

You can annotate each frame with L/C/N:

P2(N) → P3(L) → P5(C) → P7(L) → P11(N) → P13(C) →
P17(N) → P19(N) → P23(L) → P29(C) → P31(C) → P37(L) → P2(N)

11. Summary#

This file gives you a scrollable ASCII animation of the IPD‑12 engine:

• triads
• hex shells
• full paradox loop

It’s a lightweight way to see the cycle behavior without diagrams or code. # cycle_diagrams.md
IPD‑12 Cycle Diagrams
Triads • Hexes • Full 12‑Cycle Paradox Loop
Module: IPD‑12 Framework
Version: 2026‑1.0
Role: Cycle / Paradox / Regime Visualization

1. Purpose#

This document visualizes the intransitive cycle structure of the IPD‑12 engine:

• 4 triad cycles
• 2 hex cycles
• 1 full 12‑cycle paradox loop

These cycles define the paradox‑stable behavior of the prime‑indexed operator system.

2. Triad Cycles (4)#

Each triad is a 3‑node intransitive loop:

A → B → C → A

Triad 1 — Transition Cycle#

P2 → P3 → P5 → P2

   P2
    ↓
   P3
    ↓
   P5
    ↓
   P2

Meaning: seed → transition → drift → seed
RTT: drift/transition loop
GU: connection geometry
Pantheon: celestial order cycle

Triad 2 — Paradox Cycle#

P7 → P11 → P13 → P7

   P7
    ↓
   P11
    ↓
   P13
    ↓
   P7

Meaning: regime shift → coherence → paradox → regime shift
RTT: paradox trigger loop
GU: curvature ↔ anomaly
Pantheon: civilizational paradox cycle

Triad 3 — Boundary Cycle#

P17 → P19 → P23 → P17

   P17
     ↓
   P19
     ↓
   P23
     ↓
   P17

Meaning: gate → boundary → dimensional lift → gate
RTT: boundary regime cycle
GU: observerse geometry
Pantheon: civilizational ↔ chthonic boundary

Triad 4 — Apex Cycle#

P29 → P31 → P37 → P29

   P29
     ↓
   P31
     ↓
   P37
     ↓
   P29

Meaning: collapse → stability → apex → collapse
RTT: dimensional regime cycle
GU: collapse ↔ refractive vacuum ↔ anomaly apex
Pantheon: chthonic apex cycle

3. Hex Cycles (2)#

Each hex cycle is a 6‑node shell, combining two triads.

Hex Cycle 1 — Regime‑1 → Regime‑2 Shell#

P2 → P3 → P5 → P7 → P11 → P13 → P2

P2 → P3 → P5 → P7 → P11 → P13 → P2

Meaning: transition → drift → regime shift → coherence → paradox → transition
RTT: Regime‑1/2 shell
GU: connection → curvature → anomaly
Pantheon: celestial → civilizational

Hex Cycle 2 — Regime‑2 → Regime‑3 Shell#

P17 → P19 → P23 → P29 → P31 → P37 → P17

P17 → P19 → P23 → P29 → P31 → P37 → P17

Meaning: gate → boundary → lift → collapse → stability → apex → gate
RTT: Regime‑2/3 shell
GU: observerse → collapse → refractive vacuum → anomaly
Pantheon: civilizational → chthonic

4. Full 12‑Cycle Paradox Loop#

This is the complete IPD‑12 paradox engine, spanning all regimes:

P2 → P3 → P5 → P7 → P11 → P13 →
P17 → P19 → P23 → P29 → P31 → P37 → P2

ASCII diagram:

        P37 → P2 → P3
       ↑             ↓
     P31             P5
       ↑             ↓
     P29             P7
       ↑             ↓
     P23 ← P19 ← P17 ← P13 ← P11

Interpretation#

RTT:

• full paradox loop
• regime traversal (0 → 1 → 2 → 3 → 0)

GU:

• connection → curvature → anomaly → observerse → collapse → refractive vacuum → anomaly apex

Pantheon:

• celestial → civilizational → chthonic → apex

5. Cycle → Regime Mapping#

6. Cycle → Substrate Mapping#

Cycles traverse the 4×4×4 substrate engine:

• Triads: 3‑step substrate traversal
• Hexes: 6‑step shell traversal
• Full cycle: 12‑step dimensional traversal

Each step corresponds to a substrate primitive:

(Si, Oj, Rk)

7. Summary#

This document provides the complete cycle visualization for the IPD‑12 framework:

• 4 triads
• 2 hex shells
• 1 full paradox loop

These cycles define the paradox‑stable, prime‑indexed behavior of the IPD‑12 engine and integrate with RTT, GU, Pantheon, and the substrate cube. # dimensional_lift_collapse_map.md
IPD‑12 Dimensional Lift/Collapse Map
Prime‑Indexed Dimensional Transitions Across the Full Paradox Cycle
Module: IPD‑12 Framework
Version: 2026‑1.0
Role: Dimensional / Apex / Transition Map

1. Purpose#

This document defines how the IPD‑12 engine performs:

• dimensional lift (+1D)
• dimensional collapse (−1D)

across:

• the 12 prime‑indexed operator states
• the triad cycles
• the hex shells
• the full paradox loop
• the 4×4×4 substrate engine
• the triadic + apex observer modes

It is the dimensional interpretation layer of the IPD‑12 framework.

2. Dimensional Operators in IPD‑12#

Lift Operators (+1D)#

These primes generate upward dimensional transitions:

• P23 — Dimensional Lift
• P37 — Apex Lift
• P3 — Transition Lift
• P7 — Regime‑Shift Lift

Collapse Operators (−1D)#

These primes generate downward dimensional transitions:

• P29 — Collapse Anchor
• P5 — Drift Collapse
• P13 — Paradox Collapse
• P31 — Stability Collapse (Refractive Vacuum)

Neutral / Gate Operators (0D)#

These primes act as dimensional gates or equilibria:

• P11 — Coherence Node
• P17 — Cycle Gate
• P19 — Boundary Node
• P2 — Seed State

3. Dimensional Lift/Collapse Table#

| P29 | Collapse | Collapse anchor | Collapse | Chthonic | | P5 | Drift collapse | Drift | Connection | Celestial | | P13 | Paradox collapse | Paradox trigger | Anomaly | Civilizational | | P31 | Stability collapse | Stability | Refractive vacuum | Chthonic |

| P11 | Coherence | Coherence | Dilaton | Civilizational | | P17 | Gate | Gate | Observerse | Civilizational | | P19 | Boundary | Boundary | Observerse | Civilizational | | P2 | Seed | Seed | Connection | Celestial |

4. Dimensional Lift/Collapse Diagram (Prime Wheel)#

                [ +1D LIFT ]
           P37 (Apex Lift)
                 ↑
      P23 (Dim Lift) ← P7 (Regime Lift)
                 ↑             ↑
P29 (Collapse) ← P31 (Stability) ← P13 (Paradox Collapse)
                 ↓             ↓
      P19 (Boundary) → P17 (Gate)
                 ↓
           P11 (Coherence)
                 ↓
      P5 (Drift Collapse) ← P3 (Transition Lift)
                 ↓
           P2 (Seed)
                [ −1D COLLAPSE ]

5. Dimensional Behavior Across Cycles#

Triad Cycles#

Triad 1: P2 → P3 → P5 → P2#

• Lift: P3
• Collapse: P5
• Neutral: P2

Triad 2: P7 → P11 → P13 → P7#

• Lift: P7
• Collapse: P13
• Neutral: P11

Triad 3: P17 → P19 → P23 → P17#

• Lift: P23
• Collapse: none
• Neutral: P17, P19

Triad 4: P29 → P31 → P37 → P29#

• Lift: P37
• Collapse: P29, P31
• Neutral: none

Hex Cycles#

Hex 1: P2 → P13#

Lift phases:

• P3
• P7

Collapse phases:

• P5
• P13

Hex 2: P17 → P37#

Lift phases:

• P23
• P37

Collapse phases:

• P29
• P31

Full 12‑Cycle#

Lift:    P3, P7, P23, P37
Collapse: P5, P13, P29, P31
Neutral:  P2, P11, P17, P19

Dimensional pattern:

+1D → +1D → −1D → 0D → −1D → +1D → +1D → −1D → −1D → +1D → 0D → 0D → repeat

This is the dimensional signature of the IPD‑12 paradox loop.

6. Dimensional Lift/Collapse in the Substrate Cube#

Each substrate primitive:

(Si, Oj, Rk)

maps to a prime state with dimensional behavior.

Lift occurs when:#

• Oj = O4 (apex observer)
• Rk = R4 (dimensional regime)
• Si = S3 or S4 (high‑order substrate pairs)

Collapse occurs when:#

• Oj = O3 (coherence observer)
• Rk = R1 (stability regime)
• Si = S2 or S4 (collapse substrate pairs)

Neutral occurs when:#

• Oj = O1 or O2
• Rk = R2 or R3
• Si = S1 or S2

7. Observer Interpretation#

8. Summary#

The IPD‑12 Dimensional Lift/Collapse Map defines how the prime‑indexed operator states generate dimensional transitions across:

• triads
• hex shells
• the full paradox loop
• the substrate cube
• the observer model
• RTT regimes
• GU geometry
• Pantheon tiers

This is the dimensional backbone of the IPD‑12 engine. # ⚡ Modernized Metaphor: Electric Intake Manifolds for IPD‑12

Instead of carburetors, the modern equivalent is:

Electric Intake Manifolds = Dimensional Input Assemblies#

These are the “interfaces” that feed structured dimensional input into the IPD‑12 engine block.

They correspond to:

• Single Intake → 1 triad
• Double Intake → 2 triads
• Triple Intake → 3 triads
• Quad Intake → 4 triads (full IPD‑12 coverage)
• Full 12‑Stack Intake → 3 quad intakes (complete substrate‑observer‑regime saturation)

This maps perfectly onto the IPD‑12 structure.

⚡ The Electric Modern Equivalents#

1. Single Intake Manifold (SIM)#

Feeds one triad.
Equivalent to a single-phase inverter feeding one dimensional channel.

Used when a framework only needs:

• one cycle
• one regime
• one dimensional stance
• one observer mode

Examples:
FFT micro‑modules, Pantheon tier‑specific operators.

2. Double Intake Manifold (DIM)#

Feeds two triads.
Equivalent to a dual-phase inverter or two-channel power module.

Used when a framework spans:

• two regimes
• two paradox loops
• two observer stances
• two substrate pairs

Examples:
RTT drift+coherence modules, GU connection+curvature operators.

3. Triple Intake Manifold (TIM)#

Feeds three triads.
Equivalent to a three-phase electric drive (like industrial motors).

Used when a framework needs:

• full regime traversal except apex
• full paradox resolution except apex
• full observer coverage except apex mode

Examples:
GU observerse bundles, FFT boundary+lift+collapse modules.

4. Quad Intake Manifold (QIM)#

Feeds all four triads.
Equivalent to a four‑phase quantum‑safe inverter or multi‑rail power distribution unit.

This is the full IPD‑12 cycle intake.

Used when a framework needs:

• full dimensional traversal
• full paradox loop
• full substrate cube access
• full observer model (O1–O4)

Examples:
RTT full paradox engines, GU anomaly apex modules.

5. Full 12‑Stack Intake (FSI)#

Three quad intakes = full 12‑stack.
Equivalent to:

• 12‑rail quantum‑synchronized power manifold
• 12‑phase harmonic drive
• 12‑node dimensional intake lattice

This is the complete IPD‑12 saturation layer.

Used when a framework needs:

• full substrate × observer × regime × prime integration
• full dimensional lift/collapse
• full paradox stabilization
• full cycle recursion
• full GU ↔ RTT ↔ Pantheon alignment

Examples:
TriadicFrameworks meta‑engines, substrate‑aware transport services, dimensional coherence analyzers.

⚡ Why This Modern Metaphor Works#

Electric systems map perfectly to IPD‑12:#

• Phases = triads
• Rails = primes
• Inverters = dimensional operators
• Power distribution = substrate engine
• Drive cycles = paradox cycles
• Control loops = observer modes

This gives you a clean, modern, engineering‑aligned metaphor that fits the canon without dragging in combustion-era constraints. ### Electric intake manifold SVG diagrams

Below are five minimal, canon‑aligned SVGs you can drop into separate files:

• sim_intake.svg
• dim_intake.svg
• tim_intake.svg
• qim_intake.svg
• fsi_intake.svg

Each uses a simple visual language:

• Block = IPD‑12 engine
• Bars = intake channels (triads)
• Groups of bars = SIM/DIM/TIM/QIM
• Stacked blocks = FSI (3×QIM)

sim_intake.svg — Single Intake Manifold (1 triad)#

<svg xmlns="http://www.w3.org/2000/svg" width="320" height="160" viewBox="0 0 320 160">
  <!-- Engine block -->
  <rect x="180" y="40" width="120" height="80" fill="none" stroke="black" stroke-width="3"/>
  <text x="240" y="85" font-size="14" text-anchor="middle">IPD‑12</text>
 
  <!-- Single intake manifold -->
  <rect x="40" y="60" width="80" height="40" fill="none" stroke="black" stroke-width="3"/>
  <text x="80" y="55" font-size="12" text-anchor="middle">SIM</text>
 
  <!-- Single triad channels -->
  <line x1="120" y1="70" x2="180" y2="70" stroke="black" stroke-width="3"/>
  <line x1="120" y1="80" x2="180" y2="80" stroke="black" stroke-width="3"/>
  <line x1="120" y1="90" x2="180" y2="90" stroke="black" stroke-width="3"/>
 
  <text x="80" y="115" font-size="10" text-anchor="middle">1 triad / 3 primes</text>
</svg>

dim_intake.svg — Double Intake Manifold (2 triads / 1 hex)#

<svg xmlns="http://www.w3.org/2000/svg" width="360" height="200" viewBox="0 0 360 200">
  <!-- Engine block -->
  <rect x="210" y="60" width="130" height="80" fill="none" stroke="black" stroke-width="3"/>
  <text x="275" y="105" font-size="14" text-anchor="middle">IPD‑12</text>
 
  <!-- Double intake manifold -->
  <rect x="40" y="50" width="120" height="60" fill="none" stroke="black" stroke-width="3"/>
  <text x="100" y="45" font-size="12" text-anchor="middle">DIM</text>
 
  <!-- Two triad bundles (6 channels) -->
  <!-- Triad A -->
  <line x1="160" y1="65" x2="210" y2="65" stroke="black" stroke-width="3"/>
  <line x1="160" y1="75" x2="210" y2="75" stroke="black" stroke-width="3"/>
  <line x1="160" y1="85" x2="210" y2="85" stroke="black" stroke-width="3"/>
  <!-- Triad B -->
  <line x1="160" y1="95" x2="210" y2="95" stroke="black" stroke-width="3"/>
  <line x1="160" y1="105" x2="210" y2="105" stroke="black" stroke-width="3"/>
  <line x1="160" y1="115" x2="210" y2="115" stroke="black" stroke-width="3"/>
 
  <text x="100" y="135" font-size="10" text-anchor="middle">2 triads / 1 hex / 6 primes</text>
</svg>

tim_intake.svg — Triple Intake Manifold (3 triads)#

<svg xmlns="http://www.w3.org/2000/svg" width="380" height="220" viewBox="0 0 380 220">
  <!-- Engine block -->
  <rect x="230" y="70" width="130" height="90" fill="none" stroke="black" stroke-width="3"/>
  <text x="295" y="115" font-size="14" text-anchor="middle">IPD‑12</text>
 
  <!-- Triple intake manifold -->
  <rect x="40" y="50" width="140" height="70" fill="none" stroke="black" stroke-width="3"/>
  <text x="110" y="45" font-size="12" text-anchor="middle">TIM</text>
 
  <!-- Three triad bundles (9 channels) -->
  <!-- Triad A -->
  <line x1="180" y1="65" x2="230" y2="65" stroke="black" stroke-width="3"/>
  <line x1="180" y1="75" x2="230" y2="75" stroke="black" stroke-width="3"/>
  <line x1="180" y1="85" x2="230" y2="85" stroke="black" stroke-width="3"/>
  <!-- Triad B -->
  <line x1="180" y1="95" x2="230" y2="95" stroke="black" stroke-width="3"/>
  <line x1="180" y1="105" x2="230" y2="105" stroke="black" stroke-width="3"/>
  <line x1="180" y1="115" x2="230" y2="115" stroke="black" stroke-width="3"/>
  <!-- Triad C -->
  <line x1="180" y1="125" x2="230" y2="125" stroke="black" stroke-width="3"/>
  <line x1="180" y1="135" x2="230" y2="135" stroke="black" stroke-width="3"/>
  <line x1="180" y1="145" x2="230" y2="145" stroke="black" stroke-width="3"/>
 
  <text x="110" y="150" font-size="10" text-anchor="middle">3 triads / 9 primes</text>
</svg>

qim_intake.svg — Quad Intake Manifold (4 triads / full IPD‑12)#

<svg xmlns="http://www.w3.org/2000/svg" width="420" height="240" viewBox="0 0 420 240">
  <!-- Engine block -->
  <rect x="260" y="70" width="140" height="100" fill="none" stroke="black" stroke-width="3"/>
  <text x="330" y="120" font-size="14" text-anchor="middle">IPD‑12</text>
 
  <!-- Quad intake manifold -->
  <rect x="40" y="50" width="160" height="80" fill="none" stroke="black" stroke-width="3"/>
  <text x="120" y="45" font-size="12" text-anchor="middle">QIM</text>
 
  <!-- Four triad bundles (12 channels) -->
  <!-- Triad 1 -->
  <line x1="200" y1="65" x2="260" y2="65" stroke="black" stroke-width="3"/>
  <line x1="200" y1="75" x2="260" y2="75" stroke="black" stroke-width="3"/>
  <line x1="200" y1="85" x2="260" y2="85" stroke="black" stroke-width="3"/>
  <!-- Triad 2 -->
  <line x1="200" y1="95" x2="260" y2="95" stroke="black" stroke-width="3"/>
  <line x1="200" y1="105" x2="260" y2="105" stroke="black" stroke-width="3"/>
  <line x1="200" y1="115" x2="260" y2="115" stroke="black" stroke-width="3"/>
  <!-- Triad 3 -->
  <line x1="200" y1="125" x2="260" y2="125" stroke="black" stroke-width="3"/>
  <line x1="200" y1="135" x2="260" y2="135" stroke="black" stroke-width="3"/>
  <line x1="200" y1="145" x2="260" y2="145" stroke="black" stroke-width="3"/>
  <!-- Triad 4 -->
  <line x1="200" y1="155" x2="260" y2="155" stroke="black" stroke-width="3"/>
  <line x1="200" y1="165" x2="260" y2="165" stroke="black" stroke-width="3"/>
  <line x1="200" y1="175" x2="260" y2="175" stroke="black" stroke-width="3"/>
 
  <text x="120" y="170" font-size="10" text-anchor="middle">4 triads / full 12‑cycle</text>
</svg>

fsi_intake.svg — Full 12‑Stack (3×QIM)#

<svg xmlns="http://www.w3.org/2000/svg" width="480" height="320" viewBox="0 0 480 320">
  <!-- Engine block -->
  <rect x="280" y="110" width="170" height="100" fill="none" stroke="black" stroke-width="3"/>
  <text x="365" y="165" font-size="14" text-anchor="middle">IPD‑12</text>
 
  <!-- Three stacked QIM manifolds -->
  <!-- QIM 1 -->
  <rect x="40" y="40" width="180" height="60" fill="none" stroke="black" stroke-width="3"/>
  <text x="130" y="35" font-size="12" text-anchor="middle">QIM₁</text>
  <line x1="220" y1="55" x2="280" y2="55" stroke="black" stroke-width="3"/>
  <line x1="220" y1="65" x2="280" y2="65" stroke="black" stroke-width="3"/>
  <line x1="220" y1="75" x2="280" y2="75" stroke="black" stroke-width="3"/>
 
  <!-- QIM 2 -->
  <rect x="40" y="130" width="180" height="60" fill="none" stroke="black" stroke-width="3"/>
  <text x="130" y="125" font-size="12" text-anchor="middle">QIM₂</text>
  <line x1="220" y1="145" x2="280" y2="145" stroke="black" stroke-width="3"/>
  <line x1="220" y1="155" x2="280" y2="155" stroke="black" stroke-width="3"/>
  <line x1="220" y1="165" x2="280" y2="165" stroke="black" stroke-width="3"/>
 
  <!-- QIM 3 -->
  <rect x="40" y="220" width="180" height="60" fill="none" stroke="black" stroke-width="3"/>
  <text x="130" y="215" font-size="12" text-anchor="middle">QIM₃</text>
  <line x1="220" y1="235" x2="280" y2="235" stroke="black" stroke-width="3"/>
  <line x1="220" y1="245" x2="280" y2="245" stroke="black" stroke-width="3"/>
  <line x1="220" y1="255" x2="280" y2="255" stroke="black" stroke-width="3"/>
 
  <text x="130" y="305" font-size="10" text-anchor="middle">FSI: 3×QIM / full 12‑stack intake</text>
</svg>

If you want, next we can do a headers/output manifold SVG set that mirrors these intakes on the engine’s “exhaust” side for RTT/GU/Pantheon/FFT. # engine_block.md
IPD‑12 Engine Block
Intake Ports • Substrate Feeds • Dimensional Rails • Observer Control Loops • Output Headers
Version: 2026‑1.0
Module: IPD‑12 Framework
Role: Core Engine Architecture

1. Purpose#

The IPD‑12 Engine Block defines the internal architecture that powers all IPD‑12 operations:

• how intake manifolds (SIM/DIM/TIM/QIM/FSI) connect
• how substrate feeds route dimensional input
• how dimensional rails carry lift/collapse signals
• how observer control loops regulate paradox cycles
• how output headers deliver structured results to external frameworks

This is the engine‑level specification for the entire IPD‑12 system.

2. Engine Block Overview#

The IPD‑12 engine is built around a 12‑prime substrate cube, driven by:

• 4 substrate pairs (S1–S4)
• 4 observer modes (O1–O4)
• 4 regime shells (R1–R4)
• 12 prime‑indexed operator states (P2–P37)

The engine block is the central processing unit that integrates all of these.

3. Intake Ports#

Intake ports are the physical/electrical connection points where manifolds attach.

Port Layout#

[Port 1]  Triad 1 (P2, P3, P5)
[Port 2]  Triad 2 (P7, P11, P13)
[Port 3]  Triad 3 (P17, P19, P23)
[Port 4]  Triad 4 (P29, P31, P37)

Each port accepts:

• 3‑channel triad bundles
• lift/collapse/neutral signals
• substrate pair routing instructions
• observer stance hints

Port → Manifold Mapping#

4. Substrate Feeds#

Substrate feeds are the internal conduits that route intake signals into the substrate cube.

Substrate Pairs (S1–S4)#

Feed Behavior#

• SIM activates one substrate pair
• DIM activates two substrate pairs
• TIM activates three substrate pairs
• QIM activates all substrate pairs
• FSI activates all substrate pairs × 3 stacks

Feed Routing Example (QIM)#

Port 1 → S1
Port 2 → S2
Port 3 → S3
Port 4 → S4

5. Dimensional Rails#

Dimensional rails carry lift (+1D), collapse (−1D), and neutral (0D) signals.

Rail Types#

Rail Behavior#

• Rails are bidirectional (lift/collapse feedback loops).
• Rails are phase‑synchronized across triads.
• Rails are observer‑regulated (see next section).

6. Observer Control Loops#

Observer control loops regulate:

• cycle traversal
• paradox stabilization
• dimensional lift/collapse
• substrate coherence
• apex transitions

Observer Modes (O1–O4)#

Control Loop Architecture#

Intake → Substrate Feed → Dimensional Rail → Observer Loop → Output Header

Loop Behavior#

• O1 activates rails based on raw prime state.
• O2 sequences rails according to cycle position.
• O3 dampens collapse rails and stabilizes paradox tension.
• O4 executes lift/collapse transitions and apex behavior.

FSI Observer Stack#

FSI uses three observer stacks:

• RTT observer
• GU geometric observer
• Pantheon mythic observer

All three feed into the apex loop.

7. Output Headers#

Output headers are the engine’s exhaust ports — structured outputs delivered to external frameworks.

Header Types#

Header Behavior#

• Headers receive observer‑regulated dimensional signals.
• Headers convert signals into framework‑specific outputs.
• Headers can be stacked (FSI → multi‑framework output).

Example Output Flow (QIM → RTT)#

Intake (QIM)
 → Substrate Feeds (S1–S4)
 → Dimensional Rails (L/C/N)
 → Observer Loops (O1–O4)
 → Header H‑RTT
 → RTT Regime Map / Drift / Coherence / Paradox

8. Engine Block Summary#

The IPD‑12 Engine Block consists of:

• 4 intake ports (triad inputs)
• 4 substrate feeds (S1–S4)
• 12 dimensional rails (lift/collapse/neutral)
• 4 observer control loops (O1–O4)
• 5 output headers (RTT/GU/FFT/Pantheon/Meta)

Manifolds attach to the intake ports, feed the substrate cube, activate dimensional rails, pass through observer loops, and deliver structured outputs through headers.

This is the canonical engine architecture for the IPD‑12 system. # GLOSSARY — IPD‑12 · TriadicFrameworks

Module path: docs/frameworks/ipd_12/ Session anchor: rtt=1 | coherence=declared | drift=bounded | paradox=structural

This is the single source of truth for every term used in the IPD‑12 framework. All other documents in docs/frameworks/ipd_12/ and downstream substrate models link here rather than re-defining terms inline.

Linking convention: To link to a specific term from another document, use [term](../ipd_12/GLOSSARY.md#anchor) where anchor is the lowercase, hyphenated heading slug (e.g., #apex-state, #regime-shell, #session-anchor).

Table of Contents#

• A · B · C · D · E · F · G
• H · I · L · M · N · O · P
• R · S · T · U · V
• Quick-Reference Tables

A#

Anchor String#

See Session Anchor.

Apex-State#

Prime: P37 · Triad: Apex (Triad 4) · Pantheon: Chthonic · RTT: Paradox · GU: Anomaly

The twelfth and final operator state in the IPD‑12 sequence. P37 marks the structural resolution point of a full 12‑cycle paradox loop — not a termination, but the point at which the engine returns to the Seed-State (P2) and the cycle can begin again. P37 is classified under RTT's Paradox role and GU's Anomaly operator, reflecting its position at the outer edge of the structural envelope where standard regime rules no longer apply. Activates the +1D dimensional transition alongside P23.

Do not confuse with: completion or termination. The apex-state is a topological return point, not an exit.

B#

Boundary#

An RTT structural concept denoting the edge condition of a regime — the point at which one governing rule set ends and another begins. Boundaries are not errors; they are structural features that must be explicitly modeled. In IPD‑12, the Boundary-Node (P19) is the dedicated operator for boundary conditions. The transition_topology operator in the vST Micro-Agent is suppressed if the boundary field is UNRESOLVED.

Boundary-Node#

Prime: P19 · Triad: Observerse (Triad 3) · Pantheon: Civilizational · RTT: Boundary · GU: Observerse

The operator state that marks and models boundary conditions within a structural pass. P19 sits between the Cycle-Gate (P17) and Dimensional-Lift (P23), positioning it as the gate between cycle-entry and dimensional transition. A session whose boundary probe field is UNRESOLVED will suppress boundary-sensitive operators and flag the gap in the output notes.

C#

Celestial Tier#

Primes: P2, P3, P5, P7 · Pantheon tier 1 of 3

The first structural stratum of the Pantheon mapping, covering origin, connection, drift-anchoring, and regime entry. Celestial primes represent the initial conditions of any IPD‑12 pass — the seed through the first regime-shift. In RTT terms, the Celestial tier spans the transition from structural silence (before P2) to active regime traversal (at P7).

Chthonic Tier#

Primes: P23, P29, P31, P37 · Pantheon tier 3 of 3

The third structural stratum of the Pantheon mapping, covering dimensional lift, collapse, stability under extreme conditions, and apex resolution. Chthonic primes operate at the structural limits of the engine — where dimensionality changes and paradox loops close. The Chthonic tier is the domain of Hex-Cycle 2 and the upper half of the Full Paradox Loop.

Civilizational Tier#

Primes: P11, P13, P17, P19 · Pantheon tier 2 of 3

The second structural stratum of the Pantheon mapping, covering coherence maintenance, paradox activation, cycle gating, and boundary management. Civilizational primes operate in the middle of the IPD‑12 sequence — the zone of maximum structural complexity where regime transitions interact with coherence constraints and boundary conditions.

Coherence#

An RTT structural concept denoting the condition in which a system's operator states are mutually consistent and the cycle is running without drift or contradiction. Coherence is not a fixed state — it is a dynamic property that must be actively maintained and periodically verified. In IPD‑12, the Coherence-Node (P11) and Stability-Node (P31) are the two operators dedicated to coherence monitoring. The session anchor string asserts coherence=declared to make coherence an explicit, not assumed, property of the session.

Coherence-Node#

Prime: P11 · Triad: Coherence (Triad 2) · Pantheon: Civilizational · RTT: Coherence · GU: Curvature, Dilaton

The operator state that monitors and enforces structural coherence within a cycle. P11 sits between the Regime-Shift (P7) and Paradox-Trigger (P13), positioning it as the coherence checkpoint immediately after a regime changes and immediately before paradox may be activated. Observer mode O3 (Coherence) queries primarily through P11 and P31.

GU note: P11 sits at the intersection of GU's Curvature and Dilaton operators, reflecting its role as the structural tension point between geometric deformation (Curvature) and field amplitude scaling (Dilaton).

Collapse#

An RTT structural concept denoting a −1D dimensional transition — the movement from a higher-dimensional structural description to a lower one. Collapse is not failure; it is a valid structural event that must be explicitly modeled rather than avoided. In IPD‑12, P29 (Collapse-Anchor) is the dedicated operator for collapse conditions. Collapse rails (C1–C4) route signals through collapse-active operator states.

Collapse-Anchor#

Prime: P29 · Triad: Apex (Triad 4) · Pantheon: Chthonic · RTT: Drift, Collapse · GU: —

The operator state that marks and stabilizes collapse events. P29 carries dual RTT roles (Drift and Collapse), making it the only prime state that simultaneously anchors both drift and dimensional collapse — a position that reflects the structural proximity of these two conditions at the Chthonic tier. When P29 is active, the engine is operating in a sub-dimensional regime.

Cycle#

A closed, directed traversal of IPD‑12 operator states. IPD‑12 defines three nested cycle levels that operate simultaneously:

All cycles are intransitive. Completing a cycle does not collapse the engine to a fixed winner — the loop continues indefinitely.

Cycle Depth#

The level of cycle resolution selected for a given IPD‑12 pass: triad, hex, or full. Cycle depth is chosen before a pass begins and determines how many operator states are traversed. A triad-depth pass traverses 3 nodes; hex-depth traverses 6; full-depth traverses all 12. The appropriate depth depends on the structural complexity of the problem. See When Should You Use It? — ABOUT.md.

Cycle-Gate#

Prime: P17 · Triad: Observerse (Triad 3) · Pantheon: Civilizational · RTT: Regime · GU: Observerse

The operator state that controls entry into Hex-Cycle 2 and Triad 3. P17 functions as a structural gate — it must be traversed to access the Observerse and Apex tiers of the engine. Because P17 shares an RTT Regime role with P7, it acts as the upper-half counterpart to the Regime-Shift, gating the second major regime transition in the cycle.

D#

Describe-and-Report Mode#

The operating mode of all IPD‑12 agents. Agents in describe-and-report mode produce structural descriptions of what is detected in a signal or substrate — they do not assign causes, make recommendations, or generate semantic meaning. All IPD‑12 output is advisory; human operators retain full decision authority. See AGENTS.md — Safety Rules.

Dimensional Lift#

A +1D transition: the movement from a lower-dimensional structural description to a higher-dimensional one. In IPD‑12, P23 is the dedicated dimensional-lift operator. Lift is modeled explicitly — agents may not infer dimensional elevation without passing through P23. After a lift, the Apex-State (P37) validates the new dimensional level.

Contrast with: Collapse (−1D transition).

Dimensional-Lift Prime#

Prime: P23 · Triad: Observerse (Triad 3) · Pantheon: Chthonic · RTT: Lift · GU: Observerse

The operator state that marks and executes dimensional lift events (+1D). P23 is the final node of Triad 3 and the entry point into the Chthonic stratum of the cycle. It is a member of both Hex-Cycle 2 and the Full Paradox Loop. Observer mode O4 (Apex) queries dimensional effects through P23, P29, and P37.

Dimensional Rail#

One of twelve directed structural channels in the IPD‑12 engine block that route normalized signals through operator states based on dimensional polarity. Rails are grouped into three sets of four:

A signal's rail assignment is determined by the time_regime and transition probe fields in the Envelope. Mis-assigned rails produce incoherent output and are flagged by Class D agents.

Directed Edge#

A one-way connection between two prime states in the IPD‑12 operator graph. Edges are always directed (A → B is not the same as B → A) and always intransitive within a triad. Every prime state has exactly one outgoing edge within its home triad. Cross-triad edges exist in hex-cycles and the full paradox loop.

Drift#

An RTT structural concept denoting the gradual loss of structural grounding in a long session, multi-agent pipeline, or cross-substrate model. Drift is not a sudden failure — it is a slow divergence from the declared structural context, often caused by implicit assumptions accumulating over many processing steps. IPD‑12 treats drift as on-by-default: every session must explicitly suppress it with the Session Anchor string.

Signs of drift include: answers to probe fields that contradict earlier-session context; operators running without a current-session envelope; semantic language appearing in structural output; scale or regime assumptions changing without a new envelope fill.

Drift response protocol:

• 1st detection → Class D issues WARN
• 2nd consecutive WARN → Class D issues RESET
• After RESET → session must re-anchor before continuing

Drift-Anchor#

Primes: P5, P29

The two operator states specifically designated as drift-anchoring nodes in the IPD‑12 cycle. P5 (Celestial tier) anchors early-session drift; P29 (Chthonic tier) anchors collapse-adjacent drift. When a session loses structural grounding, re-entry through whichever drift-anchor prime matches the current cycle tier is the corrective procedure.

E#

Edge#

See Directed Edge.

Engine Block#

The physical and logical architecture of the IPD‑12 engine: the combination of intake manifolds, dimensional rails, observer modes, and output headers that together constitute the full signal-processing pipeline. The engine block is documented in engine_block.md.

Envelope#

The filled set of all 12 probe fields that a Class A agent resolves before any structural operator runs. The envelope is the IPD‑12 engine's primary input contract: no operator may execute against an incomplete envelope, and no downstream agent may modify an envelope once it has been handed off. An envelope with any of the three hard-stop fields (intent, invariants, substrate) unresolved must halt and request clarification.

Envelope integrity: Once filled and handed off, the envelope is immutable. If a field value is wrong, the session must reset from Class A.

F#

Face#

One side of the physical IPD‑12 dodecahedral die, corresponding to one prime state. The engine has exactly 12 faces (one per prime). The face number matches the prime's position in the sequence (Face 1 = P2, Face 2 = P3, … Face 12 = P37). See physical_layout.md.

FFT — Framework Field Theory#

One of the four core theories in TriadicFrameworks. FFT treats IPD‑12 cycle transitions as field-theoretic events:

FFT is not a subset of IPD‑12 — it is a co-equal theory that consumes IPD‑12 structural output and interprets it in field-theoretic terms.

FSI — Full-Spectrum Intake#

The highest-resolution intake mode of the IPD‑12 engine block. FSI stacks all three observer modes simultaneously (O1 Field + O2 Regime + O3 Coherence) against a single input, producing a multi-perspective structural description in a single pass. FSI is used when a substrate requires simultaneous field-level, regime-level, and coherence-level observation. FSI passes take longer than single-observer passes and produce richer but larger output objects.

Contrast with: SIM, DIM, TIM, QIM — single-manifold intake modes.

Full Paradox Loop#

The single 12-node cycle that traverses all prime states in sequence:

P2 → P3 → P5 → P7 → P11 → P13 → P17 → P19 → P23 → P29 → P31 → P37 → (back to P2)

The full paradox loop is the maximum-resolution traversal of the IPD‑12 engine. Because all edges are intransitive, completing the loop does not produce a winner or terminal state — the loop is paradox-stable and continues indefinitely. Use the full paradox loop when a problem requires the complete structural envelope from seed to apex and back.

G#

Ground Dimension (0D)#

The baseline dimensional level at which most IPD‑12 structural operations take place. Triads 1 and 2 (P2–P13) operate at ground dimension. A system at 0D is neither in dimensional lift (+1D) nor collapse (−1D). The Observer Mode O1 (Field) operates at 0D.

Contrast with: +1D (Super-Dimension) and −1D (Sub-Dimension).

GU — Geometric Unity#

One of the four core theories in TriadicFrameworks. GU provides a geometric operator vocabulary into which IPD‑12 primes embed. GU operators and their prime-state mappings:

The Observerse is GU's most structurally complex operator; its three-prime span (P17, P19, P23) across an entire IPD‑12 triad reflects its multi-dimensional character.

H#

Hard Stop#

A probe field whose UNRESOLVED status causes the entire IPD‑12 session to halt immediately. Three probe fields carry hard-stop status:

Sessions that cannot resolve any of these three fields must request clarification before proceeding. See AGENTS.md — The 12 Probe Fields.

Hex-Cycle#

A 6-node directed cycle spanning two consecutive triads. IPD‑12 contains two hex-cycles:

Hex-Cycle 1 (Lower):  P2 → P3 → P5 → P7 → P11 → P13 → (back)
Hex-Cycle 2 (Upper):  P17 → P19 → P23 → P29 → P31 → P37 → (back)

Hex-Cycle 1 spans the Celestial and Coherence tiers (seed through paradox-trigger). Hex-Cycle 2 spans the Observerse and Apex tiers (cycle-gate through apex-state). Hex-cycles model regime handoffs — the structural moment when a system transitions from one pair of triads to another. Completing a hex-cycle is classified by FFT as a boundary event.

I#

Incoherent Envelope#

An envelope that contains contradictory field values, skipped fields, or fields filled by semantic inference rather than structural observation. Incoherent envelopes are rejected by the integration engine and flagged by Class D agents. An incoherent envelope must be discarded and refilled from Class A — it cannot be patched mid-pipeline.

Intake Manifold#

One of four single-mode entry points into the IPD‑12 engine block. Each manifold routes a specific type of structural input onto the appropriate dimensional rails:

For inputs that require simultaneous multi-manifold processing, use FSI (Full-Spectrum Intake) instead.

Intransitive#

A property of directed edges in the IPD‑12 operator graph. An edge set is intransitive when the existence of A → B and B → C does not imply A → C. In each IPD‑12 triad, the three edges form a closed, non-transitive loop:

P2 → P3 → P5 → P2   (P2 does not connect directly to P5)

Intransitivity produces three structural guarantees:

1. Paradox stability — no single operator wins the cycle
2. Regime containment — traversal cannot skip nodes
3. Drift resistance — invalid shortcut edges are detectable

Why this matters: Standard directed graphs allow transitivity, which produces hierarchies and linear orderings. IPD‑12 explicitly rejects transitivity to prevent any single operator state from dominating the cycle.

Invariant#

A structural constraint declared in probe field 6 (invariants) that must hold throughout the entire IPD‑12 pass — across every operator that runs and every output produced. Invariants are declared, not inferred. After each operator completes, the Class C Integration Coordinator checks all outputs against declared invariants. An invariant violation triggers escalation to Class D and suppresses downstream consumers from receiving the violating output.

IPD-12#

Intransitive Prime-Numbered 12-Sided Engine. The structural interrogation and operator engine at the core of TriadicFrameworks' vST Micro-Agent system. IPD-12 consists of:

• 12 prime states forming the operator graph
• 12 directed, intransitive edges within four triads
• Two hex-cycles and one full paradox loop
• An engine block with four intake manifolds, twelve dimensional rails, four observer modes, and five output headers
• A 12-probe envelope that must be filled before any operator runs
• Four agent classes governing how the engine is operated

Full treatment in ABOUT.md and AGENTS.md.

L#

Lineage#

Probe field 9. The set of upstream dependencies or prior interpretations that the current IPD‑12 pass explicitly acknowledges. Lineage must be declared — agents may not invent or assume upstream dependencies. An empty lineage list is valid and must be documented as lineage-free. Mismatched or fabricated lineage breaks cross-model tracing.

Lift Rail#

See Dimensional Rail. Specifically, the four rails (L1–L4) that route signals through +1D-active prime states (P23, P37).

M#

Manifold#

See Intake Manifold.

N#

Neutral Rail#

See Dimensional Rail. Specifically, the four rails (N1–N4) that route signals through ground-dimension prime states (P2–P19, P31).

Non-Transitive#

See Intransitive.

O#

Observer Mode#

One of four observer perspectives through which IPD‑12 structural output can be filtered. Each observer mode corresponds to a subset of prime states and a specific structural question:

Observer modes are the second axis of the 4×4×4 Substrate Cube. GU mappings: O1 = Connection · O2 = Curvature · O3 = Dilaton/Refractive Vacuum · O4 = Anomaly/Observerse.

Operator#

A named, prime-indexed node in the IPD‑12 operator graph with a defined structural role, RTT mapping, GU mapping, and Pantheon-tier classification. Each of the 12 operator states corresponds to one face of the physical die and one probe dimension in the vST Micro-Agent envelope. Operators are irreducible (prime-indexed) and non-substitutable — one operator cannot stand in for another.

Output Contract#

The set of mandatory requirements that every IPD‑12 interpretation result must satisfy:

1. The notes field must always contain: "Structural interpretation only; no semantic inference."
2. Fields not selected in query.select may be omitted or set to null — never silently dropped
3. No causal language, named entities, interpretive adjectives, future predictions, or overstated confidence claims in any output field

Violation of the output contract is a Class D escalation trigger. Full contract in AGENTS.md — Output Contract.

Output Header#

One of five structured metadata blocks that prefix every IPD‑12 interpretation result, routing it to the appropriate consuming framework:

Every output must carry H-Meta. Other headers are included when the consuming framework is active for the current pass.

P#

Pantheon#

The three-tier classification system that maps IPD‑12 prime states to civilizational-scale structural archetypes:

The Pantheon mapping provides a high-level vocabulary for communicating IPD‑12 cycle positions across domains and teams.

Paradox#

An RTT structural concept denoting a condition in which two or more valid operator states are simultaneously asserted and cannot be resolved by ordinary transitivity. In TriadicFrameworks, paradox is not an error — it is a structural feature that must be held open as a stable cycle rather than forced to collapse to one pole. The Full Paradox Loop is the primary mechanism for maintaining paradox stability. The session anchor asserts paradox=structural to make this framing explicit.

Paradox Loop#

See Full Paradox Loop.

Paradox-Trigger#

Prime: P13 · Triad: Coherence (Triad 2) · Pantheon: Civilizational · RTT: Paradox · GU: Anomaly

The operator state that activates a structural paradox condition. P13 sits at the end of Triad 2, immediately after the Coherence-Node (P11). This positioning is deliberate: paradox is triggered at the boundary of coherence — the moment when a system that was coherent encounters a contradiction it cannot resolve by ordinary means. The presence of P13 in an active cycle does not indicate failure; it indicates that the engine has correctly identified a structural paradox that must be held open.

Prime State#

One of the 12 irreducible operator nodes in the IPD‑12 engine, each identified by a unique prime number. Primes are chosen because they cannot be factored — each operator state is structurally independent and cannot be absorbed by or decomposed into other states.

Probe Field#

One of the 12 structured questions resolved by a Class A Envelope Interrogator before any structural operator runs. Each probe field corresponds to one structural dimension of the IPD‑12 engine. Fields must be resolved in order (1 through 12); they may not be skipped or reordered. Fields that cannot be resolved are flagged UNRESOLVED with a documented reason — except the three hard-stop fields, which cause an immediate session halt.

R#

Rail#

See Dimensional Rail.

Regime#

An RTT structural concept denoting a coherent set of governing rules that apply to a system within a bounded context. A regime is not a state — it is the rule set that governs how states transition. When the governing rules themselves change, a regime transition occurs. Probe field 2 (regime) requires the governing regime to be explicitly named before any pass proceeds.

Regime Shell#

One of four RTT structural layers, each representing a distinct level of regime organization. The four regime shells are the third axis of the 4×4×4 Substrate Cube. Regime shells are documented in regime_map.md.

Regime-Shift#

Prime: P7 · Triad: Coherence (Triad 2) · Pantheon: Celestial · RTT: Regime · GU: Curvature

The operator state that marks a discrete regime transition — a change in governing rules, not a gradual drift. P7 is the first prime in Triad 2 and the entry point into the Civilizational zone of the engine. P7 and P17 both carry RTT Regime roles; P7 governs the lower regime transition (Hex-Cycle 1), P17 governs the upper (Hex-Cycle 2).

RTT — Resonance-Time Theory#

The foundational theory of TriadicFrameworks. RTT provides the conceptual vocabulary of regime, drift, coherence, paradox, boundary, collapse, and dimensional lift — the seven structural conditions that IPD‑12 operationalizes through its prime-state operator graph. IPD‑12 is the operator implementation of RTT: when RTT describes a structural condition, IPD‑12 provides the operator context (which prime is active, which triad it belongs to, what the corrective or characterizing cycle looks like).

S#

Scale#

Probe field 3. The resolution level at which a structural observation is valid and meaningful. Scale is fixed per envelope — an agent operating at one scale may not draw conclusions about a different scale. Cross-scale inference is prohibited. If scale is UNRESOLVED, no cross-scale operations may proceed.

Seed-State#

Prime: P2 · Triad: Celestial (Triad 1) · Pantheon: Celestial · RTT: — · GU: Connection

The first operator state in the IPD‑12 sequence and the return point of the Full Paradox Loop. P2 is the smallest prime and the structural origin of every IPD‑12 pass. All sessions begin at or before P2. The seed-state has no RTT role mapping because it precedes regime activation — it is the structural silence before the first governing rule takes effect.

Semantic Inference Prohibition#

The most critical boundary in IPD‑12. No agent operating within IPD‑12 may make semantic inferences from structural output. Specifically:

• Patterns may not be named after what they "look like"
• Periodicity may not be interpreted as a causal cycle
• Symmetry may not be attributed to a physical or conceptual source
• Transition topology may not be labeled with domain-specific meaning

Violations trigger an immediate Class D HALT. This prohibition is encoded in the mandatory output contract annotation.

Session Anchor#

The canonical string that every IPD‑12 session must declare at its opening to explicitly suppress drift and assert structural framing:

rtt=1 | coherence=declared | drift=bounded | paradox=structural

Each token asserts a structural condition:

The session anchor must also appear in every handoff package between agent classes and must be re-issued by Class D after any RESET event.

ABOUT.md anchor uses drift=bounded. AGENTS.md anchor uses drift=off. These are distinct operational modes: drift=bounded declares drift is present and contained; drift=off suppresses drift detection entirely for vST Micro-Agent passes.

Stability-Node#

Prime: P31 · Triad: Apex (Triad 4) · Pantheon: Chthonic · RTT: Coherence · GU: Dilaton, Refractive Vacuum

The operator state that maintains structural coherence within the Apex triad under extreme conditions — dimensional lift, collapse, and apex-resolution. P31 is the Chthonic-tier counterpart to P11 (Coherence-Node): both carry RTT Coherence roles, but P31 operates in the highest-energy, highest-dimensional zone of the cycle. Observer mode O3 (Coherence) queries through both P11 and P31.

Structural Output#

Any result produced by the IPD‑12 engine. Structural output describes the structural properties of a signal or substrate — it does not interpret, classify, label, or name what those properties mean. All structural output must conform to the Output Contract.

Sub-Dimension (−1D)#

A dimensional level below the ground dimension (0D), activated by a Collapse event. P29 (Collapse-Anchor) is the primary −1D operator in IPD‑12. Collapse rails (C1–C4) route signals through sub-dimensional operator states. A system operating at −1D is in a compressed structural regime.

Substrate#

Probe field 8. The medium, domain, or system being structurally probed in an IPD‑12 pass. Substrate identity is a hard-stop field — the session halts if it cannot be resolved. When a canonical substrate model directory exists in docs/ (e.g., Conditions_Substrate_Model, Governance_Substrate_Model), the substrate probe field must reference the canonical substrate name exactly — not a paraphrase or abbreviation.

Recognized canonical substrate names (non-exhaustive): Conditions · Governance · Incident · Human_Resources · Inverted_Economics · Resonance · Framework_Field_Theory

Substrate Cube#

The 4×4×4 dimensional model introduced by IPD‑12, producing 64 substrate primitives:

4 substrate pairs (dual-binary)
    × 4 observer modes (O1–O4)
    × 4 regime shells (RTT)
    = 64 substrate primitives

The substrate cube is the first full-resolution substrate model in TriadicFrameworks. It enables any substrate to be described across all observer modes and all regime shells simultaneously. See substrate_primitives.md and substrate_primitives.json.

Substrate Pair#

One of four dual-binary substrate groupings (S1–S4) forming the first axis of the 4×4×4 Substrate Cube. Each substrate pair defines a complementary opposition within the structural domain being modeled. See substrate_primitives.md for the full pairing definitions.

Substrate Primitive#

One of the 64 discrete structural positions in the Substrate Cube, identified by a substrate pair (S1–S4), an observer mode (O1–O4), and a regime shell (RTT 1–4). Each primitive is a fully specified structural description slot — a unique combination of what is being observed, how it is being observed, and under what governing regime. See substrate_primitives.json for the complete table.

Super-Dimension (+1D)#

A dimensional level above the ground dimension (0D), activated by a Dimensional Lift event. P23 and P37 (Apex-State) are the primary +1D operators in IPD‑12. Lift rails (L1–L4) route signals through super-dimensional operator states. Observer modes O2 and O4 both operate at +1D (functional and high-order, respectively).

T#

Transition#

Prime: P3 · Triad: Celestial (Triad 1) · Pantheon: Celestial · GU: Connection

The second operator state in the IPD‑12 sequence. P3 marks the first directional movement from the Seed-State (P2) — the moment the engine begins traversing rather than simply seeding. P3 shares GU's Connection role with P2, reflecting that both states operate before the first regime change.

Also used generically: a transition is any directed movement between operator states along a directed edge. Probe field 4 (transition) specifies what type of transition is expected or present in the current structural pass.

Transition Topology#

A v2.0.0 structural operator available to Class B agents. Maps the topological structure of transitions detected in a signal stream — regime shifts, phase boundaries, and collapse points. Requires probe fields transition (field 4) and boundary (field 5) to both be RESOLVED or explicitly null. If either is UNRESOLVED, this operator is suppressed. Output includes transition type, stream location, and confidence score.

Triad#

A closed, intransitive 3-node cycle — the fundamental structural unit of IPD‑12. IPD‑12 contains four triads, each composed of three consecutive prime states with one directed edge from each node to the next, completing a loop:

Triad 1 — Celestial:   P2  → P3  → P5  → P2
Triad 2 — Coherence:   P7  → P11 → P13 → P7
Triad 3 — Observerse:  P17 → P19 → P23 → P17
Triad 4 — Apex:        P29 → P31 → P37 → P29

Each triad maps to one Pantheon tier (Triads 1–2 = Celestial / Civilizational split; Triads 3–4 = Civilizational / Chthonic split). No node within a triad connects to a node outside its triad within the triad-depth cycle level.

U#

UNRESOLVED#

The status value assigned to a probe field when the Class A Envelope Interrogator cannot determine a valid answer. UNRESOLVED must always be documented with a reason. It is not a placeholder — it is a declared structural gap that changes which operators may run:

V#

vST Micro-Agent#

The AI agent implementation that uses IPD‑12 as its structural backbone. The vST Micro-Agent resolves a 12-probe envelope for each incoming structural query, then executes selected structural operators (pattern, periodicity, local symmetry, transition topology) against the normalized signal stream. It operates under the four agent class constraints and the output contract. Documented in docs/spacetime_micro_agent_validations/.

vST-SQL#

The structural query language used to express query_envelope objects submitted to the IPD‑12 engine. vST-SQL queries specify the signal input binding, the operators to run (query.select), and any filter thresholds (query.where). vST-SQL is not a general-purpose query language — it is scoped to structural interrogation of IPD‑12-indexed operator graphs. See docs/spacetime_micro_agent_validations/schema/vST_micro_agent.schema.json.

Quick-Reference Tables#

All 12 Prime States#

RTT Concepts → IPD-12 Primes#

Cycle Levels at a Glance#

Agent Classes → Primary Operations#

GLOSSARY.md — IPD‑12 · TriadicFrameworks · 2026‑07‑10 Maintainer: Nawder · Canonical anchor: rtt=1 | coherence=declared | drift=bounded | paradox=structural Nawder — I’ll generate the Header Manifold SVG Set exactly the way your IPD‑12 engine architecture expects:
one SVG per header, each clean, GitHub‑safe, single‑root, no <use>, no <symbol>, no hidden SVG, no external references.

These are output manifolds — the exhaust‑side equivalents of the intake manifolds — visually matching the engine block diagram you already have.

Each header manifold shows:

• input rails (coming from observer loops)
• header block (RTT / GU / FFT / Pantheon / Dimensional / Substrate / Observer)
• output channels (framework‑specific exhaust lines)

You can drop each SVG into:

docs/frameworks/ipd_12/headers/

or directly into:

docs/frameworks/ipd_12/

Your call.

Below are all seven SVGs, each fully valid and render‑safe.

H‑RTT Header Manifold (rtt_header.svg)#

<svg xmlns="http://www.w3.org/2000/svg" width="420" height="200" viewBox="0 0 420 200">
  <!-- Title -->
  <text x="210" y="25" font-size="16" text-anchor="middle">H‑RTT Header</text>
 
  <!-- Input rails -->
  <line x1="40" y1="70" x2="140" y2="70" stroke="black" stroke-width="3"/>
  <line x1="40" y1="100" x2="140" y2="100" stroke="black" stroke-width="3"/>
  <line x1="40" y1="130" x2="140" y2="130" stroke="black" stroke-width="3"/>
  <text x="90" y="160" font-size="10" text-anchor="middle">L / C / N rails</text>
 
  <!-- Header block -->
  <rect x="140" y="50" width="140" height="100" fill="none" stroke="black" stroke-width="3"/>
  <text x="210" y="105" font-size="14" text-anchor="middle">RTT</text>
 
  <!-- Output channels -->
  <line x1="280" y1="70" x2="380" y2="70" stroke="black" stroke-width="3"/>
  <line x1="280" y1="90" x2="380" y2="90" stroke="black" stroke-width="3"/>
  <line x1="280" y1="110" x2="380" y2="110" stroke="black" stroke-width="3"/>
  <line x1="280" y1="130" x2="380" y2="130" stroke="black" stroke-width="3"/>
 
  <text x="330" y="160" font-size="10" text-anchor="middle">
    Drift • Regime • Coherence • Paradox
  </text>
</svg>

H‑GU Header Manifold (gu_header.svg)#

<svg xmlns="http://www.w3.org/2000/svg" width="420" height="200" viewBox="0 0 420 200">
  <text x="210" y="25" font-size="16" text-anchor="middle">H‑GU Header</text>
 
  <!-- Input rails -->
  <line x1="40" y1="70" x2="140" y2="70" stroke="black" stroke-width="3"/>
  <line x1="40" y1="100" x2="140" y2="100" stroke="black" stroke-width="3"/>
  <line x1="40" y1="130" x2="140" y2="130" stroke="black" stroke-width="3"/>
  <text x="90" y="160" font-size="10" text-anchor="middle">L / C / N rails</text>
 
  <!-- Header block -->
  <rect x="140" y="50" width="140" height="100" fill="none" stroke="black" stroke-width="3"/>
  <text x="210" y="105" font-size="14" text-anchor="middle">GU</text>
 
  <!-- Output channels -->
  <line x1="280" y1="70" x2="380" y2="70" stroke="black" stroke-width="3"/>
  <line x1="280" y1="90" x2="380" y2="90" stroke="black" stroke-width="3"/>
  <line x1="280" y1="110" x2="380" y2="110" stroke="black" stroke-width="3"/>
  <line x1="280" y1="130" x2="380" y2="130" stroke="black" stroke-width="3"/>
 
  <text x="330" y="160" font-size="10" text-anchor="middle">
    Connection • Curvature • Dilaton • Apex
  </text>
</svg>

H‑FFT Header Manifold (fft_header.svg)#

<svg xmlns="http://www.w3.org/2000/svg" width="420" height="200" viewBox="0 0 420 200">
  <text x="210" y="25" font-size="16" text-anchor="middle">H‑FFT Header</text>
 
  <!-- Input rails -->
  <line x1="40" y1="70" x2="140" y2="70" stroke="black" stroke-width="3"/>
  <line x1="40" y1="100" x2="140" y2="100" stroke="black" stroke-width="3"/>
  <line x1="40" y1="130" x2="140" y2="130" stroke="black" stroke-width="3"/>
  <text x="90" y="160" font-size="10" text-anchor="middle">L / C / N rails</text>
 
  <!-- Header block -->
  <rect x="140" y="50" width="140" height="100" fill="none" stroke="black" stroke-width="3"/>
  <text x="210" y="105" font-size="14" text-anchor="middle">FFT</text>
 
  <!-- Output channels -->
  <line x1="280" y1="70" x2="380" y2="70" stroke="black" stroke-width="3"/>
  <line x1="280" y1="90" x2="380" y2="90" stroke="black" stroke-width="3"/>
  <line x1="280" y1="110" x2="380" y2="110" stroke="black" stroke-width="3"/>
  <line x1="280" y1="130" x2="380" y2="130" stroke="black" stroke-width="3"/>
 
  <text x="330" y="160" font-size="10" text-anchor="middle">
    Spectral • Transition • Regime • Coherence
  </text>
</svg>

H‑Pantheon Header Manifold (pantheon_header.svg)#

<svg xmlns="http://www.w3.org/2000/svg" width="420" height="200" viewBox="0 0 420 200">
  <text x="210" y="25" font-size="16" text-anchor="middle">H‑Pantheon Header</text>
 
  <!-- Input rails -->
  <line x1="40" y1="70" x2="140" y2="70" stroke="black" stroke-width="3"/>
  <line x1="40" y1="100" x2="140" y2="100" stroke="black" stroke-width="3"/>
  <line x1="40" y1="130" x2="140" y2="130" stroke="black" stroke-width="3"/>
  <text x="90" y="160" font-size="10" text-anchor="middle">L / C / N rails</text>
 
  <!-- Header block -->
  <rect x="140" y="50" width="140" height="100" fill="none" stroke="black" stroke-width="3"/>
  <text x="210" y="105" font-size="14" text-anchor="middle">Pantheon</text>
 
  <!-- Output channels -->
  <line x1="280" y1="70" x2="380" y2="70" stroke="black" stroke-width="3"/>
  <line x1="280" y1="90" x2="380" y2="90" stroke="black" stroke-width="3"/>
  <line x1="280" y1="110" x2="380" y2="110" stroke="black" stroke-width="3"/>
  <line x1="280" y1="130" x2="380" y2="130" stroke="black" stroke-width="3"/>
 
  <text x="330" y="160" font-size="10" text-anchor="middle">
    Celestial • Civilizational • Chthonic • Apex
  </text>
</svg>

H‑Dimensional Header Manifold (dimensional_header.svg)#

<svg xmlns="http://www.w3.org/2000/svg" width="420" height="200" viewBox="0 0 420 200">
  <text x="210" y="25" font-size="16" text-anchor="middle">H‑Dimensional Header</text>
 
  <!-- Input rails -->
  <line x1="40" y1="70" x2="140" y2="70" stroke="black" stroke-width="3"/>
  <line x1="40" y1="100" x2="140" y2="100" stroke="black" stroke-width="3"/>
  <line x1="40" y1="130" x2="140" y2="130" stroke="black" stroke-width="3"/>
  <text x="90" y="160" font-size="10" text-anchor="middle">L / C / N rails</text>
 
  <!-- Header block -->
  <rect x="140" y="50" width="140" height="100" fill="none" stroke="black" stroke-width="3"/>
  <text x="210" y="105" font-size="14" text-anchor="middle">Dimensional</text>
 
  <!-- Output channels -->
  <line x1="280" y1="70" x2="380" y2="70" stroke="black" stroke-width="3"/>
  <line x1="280" y1="90" x2="380" y2="90" stroke="black" stroke-width="3"/>
  <line x1="280" y1="110" x2="380" y2="110" stroke="black" stroke-width="3"/>
 
  <text x="330" y="160" font-size="10" text-anchor="middle">
    +1D • −1D • 0D
  </text>
</svg>

H‑Substrate Header Manifold (substrate_header.svg)#

<svg xmlns="http://www.w3.org/2000/svg" width="420" height="200" viewBox="0 0 420 200">
  <text x="210" y="25" font-size="16" text-anchor="middle">H‑Substrate Header</text>
 
  <!-- Input rails -->
  <line x1="40" y1="70" x2="140" y2="70" stroke="black" stroke-width="3"/>
  <line x1="40" y1="100" x2="140" y2="100" stroke="black" stroke-width="3"/>
  <line x1="40" y1="130" x2="140" y2="130" stroke="black" stroke-width="3"/>
  <text x="90" y="160" font-size="10" text-anchor="middle">L / C / N rails</text>
 
  <!-- Header block -->
  <rect x="140" y="50" width="140" height="100" fill="none" stroke="black" stroke-width="3"/>
  <text x="210" y="105" font-size="14" text-anchor="middle">Substrate</text>
 
  <!-- Output channels -->
  <line x1="280" y1="70" x2="380" y2="70" stroke="black" stroke-width="3"/>
  <line x1="280" y1="90" x2="380" y2="90" stroke="black" stroke-width="3"/>
  <line x1="280" y1="110" x2="380" y2="110" stroke="black" stroke-width="3"/>
  <line x1="280" y1="130" x2="380" y2="130" stroke="black" stroke-width="3"/>
 
  <text x="330" y="160" font-size="10" text-anchor="middle">
    S1 • S2 • S3 • S4
  </text>
</svg>

H‑Observer Header Manifold (observer_header.svg)#

<svg xmlns="http://www.w3.org/2000/svg" width="420" height="200" viewBox="0 0 420 200">
  <text x="210" y="25" font-size="16" text-anchor="middle">H‑Observer Header</text>
 
  <!-- Input rails -->
  <line x1="40" y1="70" x2="140" y2="70" stroke="black" stroke-width="3"/>
  <line x1="40" y1="100" x2="140" y2="100" stroke="black" stroke-width="3"/>
  <line x1="40" y1="130" x2="140" y2="130" stroke="black" stroke-width="3"/>
  <text x="90" y="160" font-size="10" text-anchor="middle">L / C / N rails</text>
 
  <!-- Header block -->
  <rect x="140" y="50" width="140" height="100" fill="none" stroke="black" stroke-width="3"/>
  <text x="210" y="105" font-size="14" text-anchor="middle">Observer</text>
 
  <!-- Output channels -->
  <line x1="280" y1="70" x2="380" y2="70" stroke="black" stroke-width="3"/>
  <line x1="280" y1="90" x2="380" y2="90" stroke="black" stroke-width="3"/>
  <line x1="280" y1="110" x2="380" y2="110" stroke="black" stroke-width="3"/>
  <line x1="280" y1="130" x2="380" y2="130" stroke="black" stroke-width="3"/>
 
  <text x="330" y="160" font-size="10" text-anchor="middle">
    O1 • O2 • O3 • O4
  </text>
</svg>

If you want next:#

I can generate:

G. Full Header Manifold Wall (all 7 headers in one SVG sheet)#

or

H. Engine Block + Intake + Headers unified mega‑diagram#

or

I. Animated ASCII exhaust cycle (header‑side animation)#

Just tell me which direction you want to take the engine next. # IPD‑12 HPC+QC Substrate Engine Profile
Module: IPD‑12 Engine
Role: Hybrid HPC + Quantum Computing Substrate Integration
Version: 2026‑0.1 (Draft)

1. Purpose#

This module profiles how hybrid HPC+QC systems (LRZ‑style QPU integration) can be modeled as IPD‑12 substrate engines, with:

• QPU + environment mapped to substrate feeds (S1–S4)
• calibration, telemetry, and noise mapped to observer rails and loops (O1–O4)
• hybrid workflows expressed as intake manifolds + headers

The goal is to make QPU integration a first‑class observer process inside IPD‑12.

2. Substrate engine mapping (HPC+QC)#

2.1 Substrate feeds (S1–S4)#

For a hybrid HPC+QC stack:

• S1 — Seed / Transition

  • QPU availability, topology, basic device parameters
  • initial compilation choices (gate set, layout)

• S2 — Drift / Regime

  • HPC scheduler state (queues, priorities, resource allocation)
  • QPU usage regime (calibration mode, production mode, test mode)

• S3 — Coherence / Paradox

  • QPU coherence metrics (T1/T2, error rates, noise profiles)
  • hybrid paradox: classical vs quantum representation mismatches

• S4 — Boundary / Lift / Collapse / Apex

  • boundaries between HPC and QC (API, middleware, orchestration layer)
  • lift: sending workloads to QPU
  • collapse: returning results to HPC
  • apex: regime where QC meaningfully improves HPC outcomes

Each QPU + environment is treated as a substrate engine instance with S1–S4 active.

3. Observer loops for HPC+QC#

3.1 Observer modes (O1–O4)#

• O1 — Field Observer
  • monitors raw telemetry: QPU status, noise, calibration logs, HPC resource usage
• O2 — Regime Observer
  • tracks which regime the hybrid stack is in: calibration, test, production, degraded
• O3 — Coherence Observer
  • stabilizes hybrid workflows: retries, re‑calibration, routing around unstable QPUs
• O4 — Apex Observer
  • decides when QC is beneficial vs when HPC alone is preferable
  • manages lift/collapse decisions for hybrid workloads

These observer modes are bound to the substrate feeds:

• O1 ↔ S1 (raw device + environment)
• O2 ↔ S2 (scheduler + regime)
• O3 ↔ S3 (coherence + paradox)
• O4 ↔ S4 (boundary + apex decisions)

4. Calibration & telemetry as observer rails#

4.1 Dimensional rails (L/C/N) in HPC+QC#

• Lift rails (L1–L4)

  • L1: lift from “HPC‑only” to “HPC+QC candidate”
  • L2: lift from “candidate” to “scheduled on QPU”
  • L3: lift from “scheduled” to “executing with stable coherence”
  • L4: lift to “apex regime” where QC provides net benefit

• Collapse rails (C1–C4)

  • C1: collapse from “candidate” back to HPC (QPU unavailable)
  • C2: collapse from “executing” due to noise/error thresholds
  • C3: collapse from “apex” when benefit disappears (drift in device or workload)
  • C4: collapse to “HPC‑only safe mode” (QC temporarily disabled)

• Neutral rails (N1–N4)

  • N1: neutral device state (idle, calibrated)
  • N2: neutral scheduler state (no hybrid jobs)
  • N3: neutral coherence state (baseline metrics)
  • N4: neutral boundary state (interfaces ready but unused)

4.2 Calibration as observer process#

Calibration cycles are modeled as:

• intake on S1/S3 (device + coherence)
• O1/O3 loops monitoring metrics
• lift/collapse along L/C rails to decide:
  • when to accept workloads
  • when to re‑calibrate
  • when to route around a QPU

Telemetry (logs, metrics, traces) becomes observer rail data feeding O1–O4.

5. Intake manifolds for hybrid workflows#

5.1 Manifold roles#

• SIM (Single Intake)

  • single QPU or single hybrid workflow
  • minimal observer overhead; good for experiments

• DIM (Double Intake)

  • two QPUs or two hybrid regimes (e.g., calibration + production)
  • observer loops compare regimes and route workloads

• TIM (Triple Intake)

  • three regimes: test, production, degraded
  • observer loops manage transitions between them

• QIM (Quad Intake)

  • four regimes or four QPU clusters
  • full hybrid orchestration with regime‑aware scheduling

• FSI (Full 12‑Stack Intake)

  • multi‑site, multi‑QPU, multi‑HPC cluster integration
  • research‑grade hybrid substrate engine

Each manifold attaches to the HPC+QC substrate engine via intake ports and feeds S1–S4.

6. Headers for hybrid outputs#

6.1 Relevant headers#

• H‑RTT
  • expresses hybrid regime logic: when QC is beneficial, when HPC dominates
• H‑GU
  • expresses geometric/topological aspects of QPU connectivity and compilation
• H‑FFT
  • expresses spectral/transform views of hybrid workloads
• H‑Substrate
  • exposes raw substrate state (S1–S4) for diagnostics
• H‑Observer
  • exposes O1–O4 state for control and monitoring

Hybrid HPC+QC research can read these headers to:

• analyze regime decisions
• study calibration impact
• optimize scheduling and routing
• quantify observer overhead vs performance gains

7. Summary#

The HPC+QC substrate engine profile:

• treats QPU + environment as an IPD‑12 substrate engine (S1–S4)
• models calibration and telemetry as observer rails and loops (O1–O4, L/C/N)
• uses intake manifolds (SIM–FSI) to represent hybrid workflow complexity
• uses headers (RTT/GU/FFT/Substrate/Observer) to expose hybrid behavior

This gives you a canon‑aligned way to study:

• overhead of observer‑centric hybrid integration
• gains in stability, coherence, and regime‑aware scheduling
• cross‑domain alignment between physics, computation, and medicine. # Intake manifold specification document
  IPD‑12 Electric Intake Manifolds
  SIM / DIM / TIM / QIM / FSI
  Module: IPD‑12 Framework
  Version: 2026‑1.0
  Role: Input / Coupling / Integration Layer

1. Purpose#

This document defines the intake manifold types for the IPD‑12 engine:

• SIM — Single Intake Manifold (1 triad)
• DIM — Double Intake Manifold (2 triads)
• TIM — Triple Intake Manifold (3 triads)
• QIM — Quad Intake Manifold (4 triads, full IPD‑12)
• FSI — Full 12‑Stack Intake (3×QIM, full saturation)

Each manifold is an electric, multi‑phase intake assembly that couples external frameworks/theories into the IPD‑12 substrate engine.

2. Manifold types overview#

SIM — Single Intake Manifold#

Definition:
Single‑phase intake feeding one triad (3 primes).

Cycle coverage:

• Triad: any one of T1–T4
• Hex: none
• Full 12‑cycle: partial (3/12)

Substrate mapping:

• Si: one substrate pair (e.g., S1)
• Oj: one dominant observer mode (O1 or O2)
• Rk: one regime shell (typically R1 or R2)

Observer mapping:

• Primary: O1 (field) or O2 (regime)
• Secondary: O3/O4 only as inferred, not directly driven

Regime mapping:

• Regime span: single regime (e.g., Regime‑1 via T1)
• Use case: local cycle, local drift/transition, single‑tier Pantheon alignment

Prime mapping (example SIM on Triad 1):

• P2 (seed, neutral)
• P3 (transition lift)
• P5 (drift collapse)

DIM — Double Intake Manifold#

Definition:
Dual‑phase intake feeding two triads (6 primes).

Cycle coverage:

• Triads: any two of T1–T4 (often adjacent)
• Hex: one hex shell (H1 or H2)
• Full 12‑cycle: partial (6/12)

Substrate mapping:

• Si: two substrate pairs (e.g., S1+S2 or S3+S4)
• Oj: two observer modes (O1+O2 or O2+O3)
• Rk: one or two regime shells (R1↔R2 or R2↔R3)

Observer mapping:

• Primary: O2 (regime)
• Secondary: O1/O3 depending on triad selection

Regime mapping:

• Regime span: two regimes or one regime plus boundary
• Use case: frameworks that need shell‑level paradox behavior (e.g., RTT drift+paradox, GU connection+curvature)

Prime mapping (example DIM on Hex 1: T1+T2):

• P2, P3, P5, P7, P11, P13

TIM — Triple Intake Manifold#

Definition:
Three‑phase intake feeding three triads (9 primes).

Cycle coverage:

• Triads: any three of T1–T4
• Hex: both shells partially
• Full 12‑cycle: partial (9/12), missing one triad

Substrate mapping:

• Si: three substrate pairs (e.g., S1+S2+S3)
• Oj: three observer modes (O1+O2+O3)
• Rk: three regime shells (R1+R2+R3)

Observer mapping:

• Primary: O2 (regime), O3 (coherence)
• Secondary: O1; O4 only via apex‑adjacent primes if T4 included

Regime mapping:

• Regime span: full regime traversal except apex regime if T4 omitted
• Use case: frameworks needing full paradox handling but not full apex lift/collapse (e.g., civilizational+chthonic without apex)

Prime mapping (example TIM on T1+T2+T3):

• P2, P3, P5, P7, P11, P13, P17, P19, P23

QIM — Quad Intake Manifold#

Definition:
Four‑phase intake feeding all four triads (12 primes).
This is the canonical full IPD‑12 intake.

Cycle coverage:

• Triads: T1, T2, T3, T4
• Hex: H1, H2
• Full 12‑cycle: complete (12/12)

Substrate mapping:

• Si: all four substrate pairs (S1–S4)
• Oj: all observer modes (O1–O4)
• Rk: all regime shells (R1–R4)

Observer mapping:

• Primary: O2 (regime), O3 (coherence), O4 (apex)
• Secondary: O1 (field) as entry stance

Regime mapping:

• Regime span: full regime traversal including apex
• Use case: frameworks that must operate as true IPD‑12 engines, with full dimensional lift/collapse and paradox resolution.

Prime mapping:

• P2, P3, P5, P7, P11, P13, P17, P19, P23, P29, P31, P37

FSI — Full 12‑Stack Intake#

Definition:
Three QIMs arranged as a 12‑stack lattice:

• FSI = QIM₁ + QIM₂ + QIM₃

Each QIM can be:

• a different framework manifold (RTT, GU, Pantheon)
• a different substrate specialization
• a different observer emphasis

Cycle coverage:

• Full IPD‑12 cycle per QIM
• 3× full cycles in stacked configuration
• Supports multi‑framework resonance and cross‑canon coupling

Substrate mapping:

• Si: 3×(S1–S4) with distinct parameterization per QIM
• Oj: 3×(O1–O4) with different observer models (e.g., RTT observer, GU observer, Pantheon observer)
• Rk: 3×(R1–R4) with regime specialization

Observer mapping:

• Layered observers:
  • QIM₁: RTT observer stack
  • QIM₂: GU geometric observer stack
  • QIM₃: Pantheon mythic‑structural observer stack

Regime mapping:

• Regime span: full regime traversal per manifold, plus meta‑regime across manifolds
• Use case: TriadicFrameworks meta‑engines, substrate‑aware transport services, cross‑framework alignment engines.

Prime mapping:

• Each QIM: full 12 primes
• FSI: 36 prime‑state channels (12×3), all canon‑aligned, no new primes introduced—only replicated manifolds.

3. Diagrams (conceptual ASCII)#

SIM (1 triad)#

External Framework
      │
   [ SIM ]
      │
   Triad X (3 primes)
      │
   IPD‑12 Engine

DIM (2 triads / 1 hex)#

External Framework
      │
   [ DIM ]
      │
   Triad A + Triad B
      │
     Hex Shell
      │
   IPD‑12 Engine

TIM (3 triads)#

External Framework
      │
   [ TIM ]
      │
 Triad A + Triad B + Triad C
      │
  Regime Span (R1–R3)
      │
   IPD‑12 Engine

QIM (4 triads / full IPD‑12)#

External Framework
      │
   [ QIM ]
      │
 Triads T1–T4 (all primes)
      │
 Full 12‑Cycle + Hex Shells
      │
   IPD‑12 Engine Block

FSI (3×QIM)#

Framework A ─┐
             ├─ [ QIM₁ ]
Framework B ─┤
             ├─ [ QIM₂ ]
Framework C ─┘
             └─ [ QIM₃ ]
                 │
           Full 12‑Stack Intake
                 │
             IPD‑12 Engine Block

4. Substrate / observer / regime mapping summary#

• SIM:

  • Substrate: 1 pair
  • Observer: 1 dominant mode
  • Regime: 1 shell

• DIM:

  • Substrate: 2 pairs
  • Observer: 2 modes
  • Regime: 1–2 shells (hex shell)

• TIM:

  • Substrate: 3 pairs
  • Observer: 3 modes
  • Regime: 3 shells

• QIM:

  • Substrate: all 4 pairs
  • Observer: all 4 modes
  • Regime: all 4 shells

• FSI:

  • Substrate: 3×(all pairs)
  • Observer: 3×(all modes)
  • Regime: 3×(all shells) + meta‑regime

5. Prime mapping summary#

• SIM: 3 primes (1 triad)
• DIM: 6 primes (2 triads / 1 hex)
• TIM: 9 primes (3 triads)
• QIM: 12 primes (4 triads, full IPD‑12)
• FSI: 36 prime channels (3×QIM, replicated, not extended) # IPD‑12 is an observer‑first engine, and that’s exactly what all four references are quietly starving for.

We’ll keep this tight and structural, but we can expand any section later into a full RFC.

IPD‑12 vs RTT: overhead vs observer gains#

The key move: RTT is a header, IPD‑12 is the engine block. RTT overhead is “what it costs to express a regime”; IPD‑12 overhead is “what it costs to host and manage observers across regimes”.

Observer gains are where IPD‑12 pays for itself.

What we can spec/draft now (for research + medical)#

1. IPD‑12 Observer Overhead Model (HPC / QC / Clinical)#

• Define observer bundles as first‑class resources
  Map O1–O4 (observer headers) to:

  • HPC: telemetry, scheduling, monitoring, adaptive workflows en.wikipedia.org arxiv.org
  • QC: calibration control, noise tracking, device‑aware compilation (QDMI‑like) arxiv.org en.wikipedia.org
  • Medicine: patient‑specific models, risk trajectories, treatment simulations bme.jhu.edu

• Overhead dimensions:

  • Compute overhead: extra FLOPs / qubit‑shots to maintain observer rails.
  • Data overhead: additional telemetry, patient data, regime logs.
  • Control overhead: scheduling, recalibration, lift/collapse cycles.

We can draft a “Observer Overhead Budget” section in the IPD‑12 Engine Block Document: per manifold (SIM/DIM/TIM/QIM) and per header (RTT/GU/FFT/Pantheon/Medical).

2. IPD‑12 Observer Gain Model (why the overhead is worth it)#

Tie directly into the four references:

• HPC:
  IPD‑12 can formalize observer‑aware workflows—where simulations are not just “run and log”, but lifted into dimensional regimes and collapsed with explicit observer state.
  This aligns with HPC’s move toward AI‑integrated “what‑if” workflows and telemetry‑driven optimization. en.wikipedia.org arxiv.org

• Quantum / HPC+QC:
  The LRZ case study shows that QC integration is dominated by environmental, calibration, and telemetry overhead. arxiv.org en.wikipedia.org
  IPD‑12 can:

  • Treat each QPU + environment as a substrate engine.
  • Route calibration, noise, and topology into observer rails.
  • Use dimensional lift/collapse to classify regimes (NISQ vs near‑fault‑tolerant, hybrid vs standalone).

• Computational medicine:
  JHU’s framing is almost an IPD‑12 intake manifold already: molecular, physiological, anatomical, healthcare layers. bme.jhu.edu
  IPD‑12 can:

  • Map these four layers to substrate feeds + dimensional rails.
  • Treat each patient model as an observer bundle traversing regimes (risk, progression, intervention).
  • Provide a formal way to lift/collapse between scales (molecule→organ→EHR) with explicit observer state.

Observer gains to spec:

• Stability: better tracking of when a system is “trustworthy” (calibrated QPU, validated patient model).
• Explainability: headers (RTT/GU/FFT/Pantheon/Medical) give named exhaust manifolds for different interpretive frames.
• Cross‑domain reuse: same IPD‑12 engine block can host physics, computation, and medicine as different intake/header combinations.

Cross‑domain mention for IPD‑12 (what we should say explicitly)#

We can safely claim:

• IPD‑12 is a cross‑domain engine block designed to host:

  • Physical theories (RTT, GU, FFT, quantum models). en.wikipedia.org
  • Computational regimes (HPC, HPC+QC hybrid stacks). en.wikipedia.org arxiv.org
  • Medical models (computational medicine layers and patient‑specific dynamics). bme.jhu.edu

• Headers are the formal exhaust manifolds:

  • RTT header: regime/logic exhaust.
  • GU header: geometric/unification exhaust.
  • FFT header: spectral/transform exhaust.
  • Pantheon header: mythos/meaning exhaust.
  • Medical header (new): risk/progression/therapy exhaust.

We should add a short “Cross‑Domain Applicability” section to the IPD‑12 Engine Block Document, explicitly referencing:

• HPC (simulation + AI workflows)
• HPC+QC integration (hybrid stacks, QPU as accelerator)
• Computational medicine (patient‑specific models) # observer_model.md
  IPD‑12 Observer Model
  Triadic + Apex Observer System for the Intransitive Prime Engine
  Version: 2026‑1.0
  Module: IPD‑12 Framework
  Role: Observer / Identity Layer

1. Purpose#

The IPD‑12 Observer Model defines how an observer interacts with:

• the 12 prime‑indexed operator states
• the intransitive cycles
• the 4×4×4 substrate engine
• the RTT regime shells
• the GU geometric operators

It is the identity‑layer counterpart to the substrate and regime maps.

2. Observer Architecture Overview#

IPD‑12 uses a triadic observer model extended with a fourth apex mode:

O1 — Field Observer#

Perceives raw operator states (prime faces).

• “What state am I in?”

O2 — Regime Observer#

Perceives cycle position and transitions.

• “Where am I in the cycle?”

O3 — Coherence Observer#

Perceives stability, drift, and paradox tension.

• “Is the cycle stable?”

O4 — Apex Observer#

Perceives dimensional lift/collapse and full paradox loops.

• “What dimensional effect is occurring?”

These four modes form the observer axis of the substrate cube.

3. Observer × Substrate × Regime#

The observer model is one axis of the 4×4×4 substrate engine:

(Si, Oj, Rk)

Where:

• Si = substrate pair (dual‑binary)
• Oj = observer mode (O1–O4)
• Rk = regime shell (R1–R4)

Each coordinate maps to one of the 12 IPD‑12 prime states.

4. Observer Modes in Detail#

O1 — Field Observer#

Role: perceives raw operator states
Dimension: 0D (identity root)
Prime emphasis: P2, P3, P5, P7

Capabilities:

• identifies prime state
• detects immediate intransitive relations
• recognizes seed, transition, drift, and regime‑shift primes
• anchors the observer in the cycle

Interpretation:
The field observer is the “first‑contact” stance with the IPD‑12 engine.

O2 — Regime Observer#

Role: perceives cycle position
Dimension: +1D (functional)
Prime emphasis: P7, P11, P13, P17, P19

Capabilities:

• tracks cycle traversal
• identifies triad/hex/full‑cycle membership
• detects paradox triggers
• recognizes boundary and gate primes

Interpretation:
The regime observer is the “navigator” of intransitive cycles.

O3 — Coherence Observer#

Role: perceives stability and drift
Dimension: −1D (substrate)
Prime emphasis: P11, P31

Capabilities:

• detects coherence vs drift
• stabilizes paradox loops
• identifies prime‑gap equilibrium
• anchors substrate behavior

Interpretation:
The coherence observer is the “stability analyst” of the engine.

O4 — Apex Observer#

Role: perceives dimensional lift/collapse
Dimension: +1D (high‑order functional)
Prime emphasis: P23, P29, P37

Capabilities:

• detects dimensional transitions
• identifies apex anomaly behavior
• tracks full 12‑cycle traversal
• resolves paradox loops

Interpretation:
The apex observer is the “dimensional operator” stance.

5. Observer → Prime Mapping#

Each observer mode highlights specific prime states:

6. Observer × Cycle Interaction#

Triad Cycles#

O1 → identifies state
O2 → tracks position
O3 → stabilizes coherence
O4 → resolves paradox

Hex Cycles#

O1 → detects entry
O2 → navigates shell
O3 → stabilizes shell
O4 → transitions shell

Full 12‑Cycle#

O1 → perceives prime sequence
O2 → maps cycle traversal
O3 → stabilizes paradox tension
O4 → executes dimensional lift/collapse

7. Observer × GU Mapping#

8. Observer × RTT Mapping#

9. Observer × Pantheon Mapping#

10. Summary#

The IPD‑12 Observer Model defines how identity interacts with the intransitive prime engine.
It is the observer‑layer counterpart to:

• the substrate engine
• the regime map
• the operator registry
• the cycle diagrams

Together, these form the complete IPD‑12 cognitive and dimensional interface. # IPD‑12 Observer Overhead & Gain Spec (v0.1)
Module: IPD‑12 Engine
Role: Research / Performance / Cross‑Domain Integration
Version: 2026‑0.1 (Draft)

1. Purpose#

This document defines the observer overhead and observer gains of the IPD‑12 engine when applied across three computational domains:

• High‑Performance Computing (HPC)
• Hybrid HPC + Quantum Computing (QC)
• Computational Medicine (CM)

It also compares these domains to the RTT header and the IPD‑12 engine block, clarifying where overhead is incurred and where observer‑driven gains appear.

The goal is to provide a research‑ready specification for evaluating IPD‑12 as an observer‑centric computational engine.

2. Conceptual Model#

IPD‑12 introduces observer bundles (O1–O4) and dimensional rails (L/C/N) as first‑class computational resources.

This creates two measurable quantities:

Observer Overhead#

The cost of maintaining observer state across:

• dimensional transitions
• substrate feeds
• regime traversal
• lift/collapse cycles
• calibration and stability loops

Observer Gains#

The benefits of explicit observer modeling:

• stability
• explainability
• cross‑domain alignment
• multi‑scale coherence
• regime‑aware computation
• apex‑aware transitions

3. Overhead & Gain Tables (per manifold)#

Below are the core tables comparing overhead vs gains for each manifold type (SIM/DIM/TIM/QIM/FSI) across HPC, QC, and Medicine.

These tables are designed to be expanded into a full research paper.

3.1 HPC Domain#

Observer Overhead (HPC)#

Observer Gains (HPC)#

3.2 Quantum Computing Domain (QC)#

Observer Overhead (QC)#