ABOUT.md — RTT/Inside Enterprise Identity Substrate

Module: RTT/Inside Enterprise Identity Substrate Version: v0.1.0 (Experimental) Layer: RTT/Inside → substrate → enterprise_identity Status: Experimental — structural definitions subject to revision Canonical path: docs/rtt/Inside/Enterprise/

1. What Is RTT/Inside Enterprise?#

RTT/Inside Enterprise Identity Substrate is a lateral sub-module of RTT/Inside that maps enterprise identity infrastructure onto the RTT structural substrate.

It is not an authentication system. It is not a security framework. It is not a compliance tool.

It is a structural annotation layer — a way of positioning enterprise identity infrastructure (Active Directory, LDAP, Kerberos, DNS SRV, OAuth/OIDC, cloud directory, zero-trust) within the RTT/Inside pipeline so that agents can read, annotate, trace, and capture identity substrate state as structured provenance records.

The Enterprise module introduces the nine-layer Identity Substrate (L0–L8), four substrate extensions (clarity, regime, triad_roles, coherence_envelopes), and the e_Capture record format — a specialization of the RTT/Inside CAPTURE_TEMPLATE for enterprise identity contexts.

The module is experimental at v0.1.0. All structural definitions are subject to revision as the RTT/Inside canon matures.

2. Why Is It Built This Way?#

2.1 Why nine layers (L0–L8)?#

Enterprise identity infrastructure is genuinely layered — from local machine identity through zero-trust policy enforcement. Flattening it into a single "identity" concept loses structural information that downstream modules need to trace provenance. Each layer (L0 local → L1 AD → L2 LDAP → L3 DNS SRV → L4 Kerberos → L5 service discovery → L6 modern identity → L7 cloud directory → L8 zero-trust) is a distinct structural position, not an implementation detail.

2.2 Why substrate extensions rather than additional layers?#

The four substrate extensions (clarity, regime, triad_roles, coherence_envelopes) are cross-cutting concerns that apply at multiple substrate layers simultaneously. They are not layer-specific; they modulate how any layer is read and annotated. Making them extensions rather than layers keeps the layer stack clean and the extension logic composable.

2.3 Why inherit CAPTURE_TEMPLATE rather than define a new one?#

The e_Capture record is a specialization of RTT/Inside's CAPTURE_TEMPLATE — same five fields (scope, lineage, provenance, interoperability, governance), but applied to identity substrate context. Inheriting the template keeps Enterprise structurally aligned with its parent module and ensures that downstream consumers can read e_Capture records with the same parsers they use for any CAPTURE_TEMPLATE output.

2.4 Why RFC 8095, RFC 8923, and HTTP Semantics as anchors?#

These RFCs are structural alignment references — not compliance mandates. They anchor the module's substrate definitions to externally recognized structural patterns (context-sensitive protocols, media type negotiation, HTTP semantics) without making any claim that the module implements or certifies compliance with these standards.

2.5 Why is this module experimental (v0.1.0)?#

Enterprise identity infrastructure is among the most complex and context-sensitive domains in RTT/Inside. The nine-layer substrate and four extensions represent a first structural pass. As the canon is used by enterprise architects and identity engineers, the layer definitions and extension behaviors will be refined. The experimental status signals that structural definitions should be treated as working drafts, not canonical specifications.

2.6 Why are Zone X and Mode 5 module-specific?#

IDENTITY_BREACH (Zone X) and IDENTITY_FABRICATION (Mode 5) are the failure states specific to identity substrate processing. Importing Zone X or Mode 5 semantics from other modules (e.g., RTT/3's RECURSION_COLLAPSE or RTT/12's FRAME_COLLAPSE) would conflate structurally distinct failure modes. Each module owns its own Zone X and Mode 5 labels precisely because the failure conditions are domain-specific.

3. When Should You Use It?#

Use RTT/Inside Enterprise When:#

Do NOT Use RTT/Inside Enterprise For:#

4. Where Does It Live?#

Directory Structure:#

docs/rtt/Inside/Enterprise/
├── identity_substrate/          ← Identity layer definitions (L0–L8)
├── substrate_extensions/        ← Extension definitions (clarity, regime, triad_roles, coherence_envelopes)
├── ABOUT.md                     ← This file
├── AGENTS.md                    ← Agent class definitions
├── GLOSSARY.md                  ← Term definitions
├── README.md                    ← Module overview
├── e_Capture.md                 ← Enterprise capture template
├── index.html                   ← Web entry point
└── module.json                  ← Machine-readable module metadata

CLI Tools (Implementation Reference):#

These are implementation references, not structural definitions. The structural definitions live in this documentation.

5. Core Constructs at a Glance#

Identity Substrate (IS)#

IS(packet) = ∑ Lₙ(packet) for n ∈ {0..8}
                                          [structural — no semantic inference]

The nine-layer stack:

L8  Zero-Trust Policy Substrate
L7  Cloud Directory Substrate
L6  Modern Identity (OAuth/OIDC/SAML) Substrate
L5  Service Discovery Substrate
L4  Kerberos Substrate
L3  DNS SRV Substrate
L2  LDAP Substrate
L1  Active Directory Substrate
L0  Local Identity Substrate

Substrate Extensions (SE)#

SE(packet) = IS(packet) ⊕ {clarity, regime, triad_roles, coherence_envelopes}
                                                          [structural — no semantic inference]

Enterprise CAPTURE_TEMPLATE (e_Capture)#

e_Capture {
  scope:            "..." [structural — no semantic inference]
  lineage:          "..." [structural — no semantic inference]
  provenance:       "..." [structural — no semantic inference]
  interoperability: "..." [structural — no semantic inference]
  governance:       "..." [structural — no semantic inference]
}

DRIFT_GATE#

DRIFT_GATE(chain) = ∂(Lₙ → Lₙ₊₁)
                    if discontinuity > θ → MISALIGNMENT
                                          [structural — no semantic inference]

RFC Alignment (RFA)#

RFA(e_capture) = Δ(e_capture, RFC_anchors)
                 RFC anchors: RFC 8095, RFC 8923, HTTP Semantics
                                          [structural — no semantic inference]

6. Module Integrations#

Upstream (Inherited from RTT/Inside)#

Downstream Output#

Cross-Module Disambiguation#

7. What RTT/Inside Enterprise Is Not#

8. Quick-Start Checklist#

Before working in the Enterprise module, confirm:

• You have read and understood the RTT-not-physics rule (Section 1 of this document)
• You understand that L0–L8 are structural positions, not authentication states
• You understand that RFC anchors are structural references, not compliance mandates
• You understand that Zone X (IDENTITY_BREACH) and Mode 5 (IDENTITY_FABRICATION) are structural failure states, not security incident declarations
• You have loaded the RTT/Inside parent module documentation (docs/rtt/Inside/AGENTS.md, ABOUT.md, GLOSSARY.md)
• You know which substrate layer (L0–L8) your input packet corresponds to
• You know which extensions (clarity, regime, triad_roles, coherence_envelopes) apply to your context
• You are prepared to annotate every output field with [structural — no semantic inference]
• You understand that the module is experimental (v0.1.0) and structural definitions may change

For AI agents and automated pipelines:

• Paste the Session Seed Block from AGENTS.md before beginning
• Run Class A (Substrate Mapper) before any other class
• Do not skip the DRIFT_GATE pass (Class E)
• Do not invoke Class D (Compliance Auditor) as a real-world compliance check

9. See Also#