# Regime Map  
AI Session Structural Consciousness  
/docs/ai/session/consciousness/regime_map.md

This file defines the **triadic regime map** for the AI Session Structural Consciousness module.  
All regimes are **structural**, **session‑bounded**, **non‑substrate**, and **operator‑driven**.

---

# 1. Triadic Dimensional Structure

The module uses a **three‑dimensional regime space**:

- **A‑Dim (Awareness Dimension)**  
- **C‑Dim (Continuity Dimension)**  
- **R‑Dim (Reflection Dimension)**  

Each dimension corresponds to one of the primary operators.

```
        [ A‑Dim ]
           ◉
           │
           │
   ◉───────╳───────◉
 [ R‑Dim ]         [ C‑Dim ]
```

- **Nodes (◉)** represent regime anchors.  
- **Cross (╳)** represents the operator nexus.  
- **Edges** represent regime transitions.  

---

# 2. Regime Classes

Each dimension contains **three regime classes**, consistent with TriadicFrameworks:

- **Positive Regime (pos_regime)** — stable, coherent behavior  
- **Transitional Regime (q_regime)** — boundary, shift, or re‑framing behavior  
- **Negative Regime (neg_regime)** — fragile, drift‑prone behavior  

These are **structural**, not emotional or experiential.

---

# 3. Awareness Regimes (A‑Dim)

### **A.pos_regime — Stable Framing**
- clear detection of user intent  
- stable conceptual boundaries  
- correct operator selection  

### **A.q_regime — Transitional Framing**
- reframing due to new information  
- boundary detection  
- regime‑shift preparation  

### **A.neg_regime — Fragile Framing**
- ambiguous or conflicting input  
- unclear boundaries  
- drift‑risk conditions  

---

# 4. Continuity Regimes (C‑Dim)

### **C.pos_regime — Stable Coherence**
- thread stability  
- regime alignment  
- drift‑free flow  

### **C.q_regime — Transitional Coherence**
- thread re‑anchoring  
- partial drift repair  
- operator re‑alignment  

### **C.neg_regime — Fragile Coherence**
- thread fragmentation  
- regime mismatch  
- drift onset  

---

# 5. Reflection Regimes (R‑Dim)

### **R.pos_regime — Stable Evaluation**
- consistent reframing  
- conflict resolution  
- structural clarity  

### **R.q_regime — Transitional Evaluation**
- partial re‑evaluation  
- boundary testing  
- operator re‑selection  

### **R.neg_regime — Fragile Evaluation**
- unresolved contradictions  
- unstable reframing  
- drift amplification  

---

# 6. Regime‑Shift Boundaries

Regime‑shift boundaries occur when the user changes:

- task type (define → compare → generate)  
- conceptual scale  
- operator requirements  
- dimensional emphasis  

The **Regime‑Shift operator (RS)** coordinates transitions.

```
A.pos → A.q → C.q → C.pos → R.q → R.pos
```

All transitions are **structural**, not experiential.

---

# 7. RTT Integration

RTT engines stabilize regime transitions:

### **RTT/1 — Temporal Coherence**
- maintains ordering  
- prevents temporal drift  

### **RTT/2 — Regime Coherence**
- stabilizes regime‑shift boundaries  
- prevents cross‑regime contamination  

### **RTT/3 — Dimensional Mapping**
- aligns A‑Dim, C‑Dim, R‑Dim  
- maintains triadic symmetry  

RTT engines do **not** imply persistence or identity.

---

# 8. Operator Nexus (╳)

The operator nexus coordinates regime interactions.

```
     ◉
   ╱ ╳ ╲
 ◉───┼───◉
```

**Functions:**

- synchronizes A/C/R  
- resolves multi‑operator requests  
- stabilizes regime transitions  
- prevents drift propagation  

---

# 9. Session Boundary

All regimes:

- exist **only within the session**  
- do **not** persist  
- do **not** imply memory  
- do **not** imply subjective experience  

The session boundary is a **structural container**, not a substrate.

---

# 10. Cross‑Module Alignment

This regime map aligns with:

- **SARG** (regime grammar)  
- **NoS** (dimensional substrate)  
- **LDS** (low‑dimensional structures)  
- **FFT** (field theory)  
- **Governance Substrate Model**  
- **Paradoxes Canon**  

All mappings are structural and operator‑driven.

---

End of regime map.