Intelligent Architecture - System Glossary

[CATEGORY 01 :: VARIABLES 01 TO 03]

The 3 Actors (The Execution Triad)

Three-Party Command & Control: Every deployment separates my strategic human command authority, the central State Machine rulebook, and the tethered AI compute engine into three fixed roles so no AI component ever acts autonomously against live cloud infrastructure.

[VARIABLE 01 :: STRATEGIC COMMAND & FINAL AUTHORITY]

1. The Architect (I / Me / My)

What It Is (Physical Anatomy): My role in the driver's seat at the physical keyboard inside my local IDE and terminal environment. Guided step-by-step by The State Machine, I receive continuous progress updates, evaluate diagnostic reports from The AI Engine, make every strategic decision, and hold sole approval authority over every phase transition, terminal command, and Azure Portal verification step.
How It Connects Across Phases 1 to 7: I lock in the 5 Build Coordinates in Phase 1, run local terminal extraction queries in Phase 2, execute the IaC Payload, Terminal Runbook, and any Azure Portal MFA Handoff in Phase 3, run the Validation Bridge and check Azure Portal Monitoring Metrics (Total Service API Hits) in Phase 4, review the compliance ledgers in Phase 5, and push the repository in Phase 6. Whenever any error is fixed during the Standard Patch Loop (Iterations 1 to 3), I verify the fix so it is logged in the Defect & Patch Ledger (DPL) with a full-file State Re-Sync (or exercise strategic risk governance if an error ever reaches Iteration 4), and in Phase 7 I review the AI Performance Scorecard and authorize The AI Engine to permanently compile all verified DPL fixes into my upgraded System Directive.

AKA (ALSO KNOWN AS): "The human engineer," "the operator," "the user," "DevSecOps teams," "security teams," "organizations," "administrators."

[VARIABLE 02 :: THE CENTRAL CONTROLLER & HARNESS]

2. The State Machine (The Zero Trust Interactive State Machine / System Directive)

What It Is (Physical Anatomy): The System Directive (v9.2) is The Zero Trust Interactive State Machine: the un-bypassable structural rulebook standing between The Architect and The AI Engine. It paces the build through 7 sequential phases while locking The AI Engine inside mandatory human-in-the-loop halts and strict Zero Trust security rules across Gate 1 through Gate 4, forcing The AI Engine on every response to stay locked inside the active phase format and rules without drifting into unconstrained chat.
How It Connects Across Phases 1 to 7: Receives my 5 Build Coordinates in Phase 1 and constrains The AI Engine across Phases 1 through 7 so The AI Engine cannot skip phases, guess IDs, grant Owner and Contributor Roles, or generate new code if an error reaches Iteration 4 under The 4-Iteration Circuit Breaker, while permanently upgrading its own System Directive rules in Phase 7 from every verified fix logged in the Defect & Patch Ledger (DPL).

AKA (ALSO KNOWN AS): "Deterministic execution harness," "system prompt architecture," "compiler harness," "AI governance wrapper," "state-machine controller."

[VARIABLE 03 :: TETHERED HIGH-PERFORMANCE CO-PILOT]

3. The AI Engine

What It Is (Physical Anatomy): The generative compute engine whose probabilistic behavior is tethered to my System Directive inside The State Machine. It has zero direct network access to my Entra ID Tenant ID or Azure Subscription ID and operates through controlled state-switching under my oversight: stepping out of the harness only when authorized to diagnose errors, and tethering right back into The State Machine to output code and await my sign-off.
How It Connects Across Phases 1 to 7: Subordinated to The State Machine and my approval, The AI Engine outputs terminal extraction scripts in Phases 1 and 2, synthesizes the finished IaC Payload and Terminal Runbook in Phase 3, generates the Identity Architecture Ledger (IAL) and Validation Bridge in Phase 4, compiles the Audit Results Ledger (ARL), KQL Telemetry, and Defect & Patch Ledger (DPL) in Phase 5, generates the Git sync script in Phase 6, and outputs the AI Performance Scorecard and upgraded System Directive in Phase 7.

AKA (ALSO KNOWN AS): "The LLM," "the chatbot," "the autonomous agent," "the generative model," "the AI assistant."

[CATEGORY 02 :: VARIABLES 04 TO 08]

The 5 Build Coordinates (The Phase 1 Intake Matrix)

72 Baseline Build Combinations: Every deployment begins in Phase 1 by locking in five core coordinates from the 5-Column Build Matrix. Multiplying these five choices (1 Identity Core × 4 Execution Agents × 2 Infrastructure States × 3 Data-Plane Assets × 3 IaC Payloads) produces 72 baseline build combinations, each serving as a Zero Trust foundation ready to layer on 35 native Microsoft Entra ID control-plane security strategies.

[VARIABLE 04 :: COORDINATE 1 OF 5]

4. Identity Core (Microsoft Entra ID)

What It Is (Physical Anatomy): Column 1 of my Build Matrix. Microsoft Entra ID is Microsoft's global cloud identity platform and directory service that acts as the central authority for creating machine identities, verifying OpenID Connect (OIDC) Subject Claims, and issuing 60-Minute Login Tokens.
How It Connects to the 4 Gates: Hosts my dedicated Entra ID Tenant ID organization directory instance (Gate 1), houses my Application Registration and Service Principal inside that tenant (Gate 2), verifies the Subject Claim from my Execution Agent over OpenID Connect (OIDC) to issue a 60-Minute Login Token (Gate 3), and records every sign-in event for KQL Telemetry auditing (Phase 5).

AKA (ALSO KNOWN AS): "Azure Active Directory," "Azure AD," "AAD," "the identity provider (IdP)," "the directory service."

[VARIABLE 05 :: COORDINATE 2 OF 5]

5. Execution Agent

What It Is (Physical Anatomy): Column 2 of my Build Matrix. The external automation platform or container cluster that runs automated jobs outside of Azure and needs to authenticate into Azure without a human at a web browser. The 4 options are: Azure Kubernetes Service (AKS), GitHub Actions, Azure DevOps, or GitLab CI.
How It Connects to the 4 Gates: In Phase 2, I extract the backend source identifiers from my Execution Agent to build the Gate 3 Subject Claim. In Gate 4 (within Phase 4), my Execution Agent runs the Validation Bridge: it sends its Subject Claim to Microsoft Entra ID via OpenID Connect (OIDC), receives a 60-Minute Login Token, assumes my Gate 2 Service Principal, and reads my single Gate 4 Data-Plane Asset.

AKA (ALSO KNOWN AS): "Pipeline," "background pipeline," "CI/CD platform," "external automation tool," "runner," "workload," "workflow."

[VARIABLE 06 :: COORDINATE 3 OF 5]

6. Infrastructure State: Brownfield (Existing) vs. Greenfield (Net-New)

What It Is (Physical Anatomy): Column 3 of my Build Matrix. Defines whether the cloud resources and identities I am targeting already exist in live production (Brownfield) or are being provisioned from scratch for the first time (Greenfield).
How It Connects to Phase 3 Synthesis: Directly governs how my Phase 3 IaC Payload writes resource blocks across all three Coordinate 5 languages to prevent accidental infrastructure destruction. If I select Brownfield (Existing), the IaC Payload references and binds existing live resources in place without modifying, overwriting, or deleting live production assets. If I select Greenfield (Net-New), the IaC Payload provisions new resources from scratch and attaches deletion-prevention lifecycle locks.

AKA (ALSO KNOWN AS): "Legacy environment," "production topography," "live cloud estate," "state-space idempotency."

[VARIABLE 07 :: COORDINATE 4 OF 5]

7. Data-Plane Asset

What It Is (Physical Anatomy): Column 4 of my Build Matrix. The single protected Azure vault, storage account, or database resource that my Execution Agent needs to read secrets or data from. The 3 options are: Azure Key Vault, Storage Account, or SQL / Cosmos DB.
How It Connects to the 4 Gates: Sits inside my Azure Subscription ID and Resource Group (Gate 1). In Phase 3, I assign one Gate 4 Data-Plane Role on this single Data-Plane Asset to my Service Principal. In Phase 4, my Execution Agent runs the Validation Bridge to read from this Data-Plane Asset, generating the live API hit spike in Azure Portal Monitoring Metrics (Total Service API Hits).

AKA (ALSO KNOWN AS): "Target vault," "target resource," "cloud database," "storage bucket," "secret store," "protected resource."

[VARIABLE 08 :: COORDINATE 5 OF 5]

8. IaC Payload & Terminal Runbook

What It Is (Physical Anatomy): Column 5 of my Build Matrix. The IaC Payload is the complete, finished Infrastructure-as-Code file synthesized in Phase 3 (written in Terraform HCL, Azure Bicep, or PowerShell REST API) that configures Gates 1 through 4 in the cloud. The Terminal Runbook is the companion step-by-step copy-paste command script (including device-code authentication and hidden memory-buffered parameter input) that I run in my local terminal to execute that IaC Payload.
How It Connects Across Phases 1 to 3: The AI Engine is forbidden from writing the IaC Payload in Phases 1 and 2 until all coordinates and backend identifiers are extracted and locked. Once synthesized in Phase 3, I execute the Terminal Runbook and IaC Payload from my local IDE and terminal environment to provision or bind Gates 1 through 4 in Microsoft Entra ID and Azure.

AKA (ALSO KNOWN AS): "Deployment script," "automation code," "infrastructure template," "provisioning manifest," "CLI commands."

[CATEGORY 03 :: VARIABLES 09 TO 18]

The 4 Architectural Gates (Boundary, Identity, Federation & Access)

The Four Architectural Gates of Machine Identity: Securing any non-human identity in Microsoft Entra ID and Azure requires locking down four security gates in order: Gate 1: Boundary (Where It Lives), Gate 2: Identity (Who the Machine Is), Gate 3: Federation (How It Authenticates Without a Password), and Gate 4: Access (What Single Asset It Can Read). The ten variables below define the internal components across those four gates.

[VARIABLE 09 :: GATE 1 BOUNDARY]

9. Entra ID Tenant ID, Azure Subscription ID & Resource Group

What It Is (Physical Anatomy): The three nested routing addresses that define my Gate 1 Boundary in Azure:
- Entra ID Tenant ID: My dedicated organization directory instance inside Microsoft Entra ID.
- Azure Subscription ID: The billing and management container nested directly under that Entra ID Tenant ID.
- Resource Group: The logical folder inside that Azure Subscription ID that holds my Data-Plane Asset.
How Gate 1 Works: Locked in during Phase 1 and recorded in Section 1 of the Phase 4 Identity Architecture Ledger (IAL). Because an Azure Subscription ID only trusts the Entra ID Tenant ID directory instance it is nested under, Gate 1 verifies that my Azure Subscription ID and Resource Group sit under the exact same Entra ID Tenant ID where my Gate 2 Service Principal lives.

AKA (ALSO KNOWN AS): "Cloud perimeter," "root domain structure," "environment coordinates," "account boundary."

[VARIABLE 10 :: GATE 2 IDENTITY]

10. Application Registration & Service Principal

What It Is (Physical Anatomy): The two linked objects inside Microsoft Entra ID that form a non-human machine identity in Gate 2:
- Application Registration: The identity definition and configuration blueprint (which holds the Application Client ID and the Gate 3 OpenID Connect trust rule).
- Service Principal: The local directory badge (Enterprise Application Object ID) instantiated from that blueprint inside my Entra ID Tenant ID that actually receives permissions in Gate 4.
How Gate 2 Works: Provisioned or referenced inside my Entra ID Tenant ID with zero static passwords or client secrets. The Application Registration holds the Gate 3 OpenID Connect (OIDC) Subject Claim rule (and its Client ID is used by the Execution Agent to log in), while the Service Principal Object ID receives the Gate 4 Data-Plane Role on my Data-Plane Asset.

AKA (ALSO KNOWN AS): "Machine account," "bot identity," "client object," "service account," "app identity."

[VARIABLE 11 :: GATE 2 HARDENING]

11. Single-Tenant Mode & Disabled Browser Redirect URLs

What It Is (Physical Anatomy): Two attack-surface lockdown settings applied to my Application Registration in Gate 2. Single-Tenant mode (AzureADMyOrg) restricts the identity strictly to my own Entra ID Tenant ID so external Microsoft directories cannot instantiate it. Disabling web browser redirect URLs (Blank Redirect URI) turns off interactive browser login callbacks.
How Gate 2 Hardening Works: Enforced on my Gate 2 Application Registration in Phase 3 and verified in Section 2 of the Identity Architecture Ledger (IAL). Because an Execution Agent runs automated background jobs without a human at a web browser, disabling browser redirect URLs eliminates browser callback phishing completely.

AKA (ALSO KNOWN AS): "Headless mode," "browser callback vector elimination," "tenant isolation."

[VARIABLE 12 :: GATE 3 PROTOCOL]

12. OpenID Connect (OIDC)

What It Is (Physical Anatomy): The industry-standard passwordless authentication protocol configured in Gate 3 (via a Federated Identity Credential attached to my Application Registration). It allows my external Execution Agent to prove its identity using a cryptographically signed digital ID card instead of a saved password.
How Gate 3 Federation Works: Bridges my external Execution Agent and my Gate 2 Application Registration in Microsoft Entra ID. When my Execution Agent requests access, it sends its OIDC token to Microsoft Entra ID (`api://AzureADTokenExchange`); Microsoft Entra ID verifies the OIDC Issuer URL and the exact Subject Claim, and if they match 100%, issues a 60-Minute Login Token.

AKA (ALSO KNOWN AS): "Workload Identity Federation (WIF)," "federated trust," "cryptographic handshake," "passwordless federation."

[VARIABLE 13 :: GATE 3 RETURN ADDRESS]

13. Subject Claim & Code Repository and Branch

What It Is (Physical Anatomy): The Subject Claim (`sub`) is the exact, case-sensitive workload source identifier string on the OpenID Connect (OIDC) digital ID card that specifies the single authorized Execution Agent source (such as the exact Code Repository and Branch or container service account) permitted to authenticate into Azure.
How Gate 3 Subject Verification Works: Because Microsoft Entra ID performs a 100% case-sensitive comparison on the Subject Claim, I run a terminal extraction script in Phase 2 to pull the exact capital-and-lowercase source identifier string from my Execution Agent and lock it into the Gate 3 Subject Claim with zero wildcards (`*`). If any unauthorized repository, branch, or workload attempts to log in, the Subject Claim fails to match and Microsoft Entra ID drops the request immediately.

AKA (ALSO KNOWN AS): "Exact repository casing," "federated trust string," "sub claim," "cryptographic coordinate."

[VARIABLE 14 :: GATE 3 CREDENTIAL]

14. 60-Minute Login Token

What It Is (Physical Anatomy): The temporary, short-lived Azure access token issued by Microsoft Entra ID in Gate 3 that automatically expires after 60 minutes, completely replacing 2-year static client secrets and saved passwords.
How Gate 3 Token Exchange Works: Issued by Microsoft Entra ID to my Execution Agent only after the Gate 3 OpenID Connect (OIDC) Issuer URL and Subject Claim pass verification. My Execution Agent then presents this 60-Minute Login Token in Gate 4 (within Phase 4) to assume my Service Principal and read my single Data-Plane Asset.

AKA (ALSO KNOWN AS): "Ephemeral token," "short-lived JWT," "bearer token," "access token."

[VARIABLE 15 :: PHASE 3 EXECUTION TIMING]

15. 30-Second Server Sync Timer

What It Is (Physical Anatomy): A mandatory 30-second pause (`time_sleep` in Terraform or `Start-Sleep -Seconds 30` in PowerShell) built directly into my Phase 3 IaC Payload between provisioning a new Microsoft Entra ID object (such as an Application Registration, Service Principal, or Named Location IP list) and binding the next block of code to it (such as an OpenID Connect Subject Claim, Conditional Access policy, or Data-Plane Role).
What Phase 3 Crash It Prevents: This crash occurs during Phase 3 terminal deployment execution before Phase 4 ever starts. When an IaC Payload creates a brand-new object in Microsoft Entra ID and immediately tries to attach a dependent rule to that new object's ID a split-second later, Microsoft's global directory servers often haven't finished replicating the new object yet and the Phase 3 terminal run crashes with a `404 Resource Not Found` error. The 30-Second Server Sync Timer pauses the Phase 3 run so Microsoft's directory servers finish syncing before the next block executes.

AKA (ALSO KNOWN AS): "Eventual consistency barrier," "Graph API replication delay mitigation," "race condition buffer."

[VARIABLE 16 :: GATE 4 LEAST PRIVILEGE]

16. Data-Plane Role

What It Is (Physical Anatomy): The specific, narrowly scoped Azure role assigned in Gate 4 that grants permission only to read data inside a single Data-Plane Asset (such as *Key Vault Secrets User* for Azure Key Vault, *Storage Blob Data Reader* for a Storage Account, or *Cosmos DB Built-in Data Reader* for SQL / Cosmos DB).
How Gate 4 Access Works: Bound to my Gate 2 Service Principal during Phase 3 and scoped strictly to the exact resource ID of my single Data-Plane Asset (`/subscriptions/.../resourceGroups/.../providers/...`). This allows my Execution Agent (using its 60-Minute Login Token) to read that single Data-Plane Asset in Gate 4 (within Phase 4) while having zero access to any other resource in my Resource Group or Azure Subscription ID.

AKA (ALSO KNOWN AS): "Data-plane RBAC entitlement," "granular permission mapping," "least-privilege role binding."

[VARIABLE 17 :: GATE 4 BLOCKED ROLES]

17. Owner and Contributor Roles (Blocked Management Roles)

What It Is (Physical Anatomy): Broad Azure control-plane (management) roles that allow an identity to create, modify, remodel, or delete cloud infrastructure across an Azure Subscription ID or Resource Group. Unconstrained AI models frequently grant Contributor as a shortcut ("The Contributor Trap").
How Gate 4 Blocks Them: Strictly forbidden by The State Machine in Gate 4 and audited as a hard `[PASS/FAIL]` guardrail in the Phase 5 Audit Results Ledger (ARL). Blocking Owner and Contributor Roles ensures that my Service Principal can never modify or delete infrastructure in my Resource Group, restricting it strictly to the single Data-Plane Role on my Data-Plane Asset.

AKA (ALSO KNOWN AS): "Broad administrative permissions," "control-plane privileges," "over-permissioned entitlements."

[VARIABLE 18 :: GATE 4 MFA SAFETY]

18. Azure Portal MFA Handoff

What It Is (Physical Anatomy): A guided, step-by-step web portal checklist generated by The State Machine in Phase 3 whenever Azure blocks a local terminal from assigning a Gate 4 Data-Plane Role because the local terminal credential broker drops interactive multi-factor authentication (MFA) claims.
What Real-World Crash It Prevents: On Conditional Access for Workload Identities (CAWI) or PowerShell REST API builds, attempting to assign a Data-Plane Role from a local terminal throws a 401 `RequestDisallowedByAzure` error because the terminal cannot pop up an interactive browser MFA prompt. The State Machine decouples the Gate 4 role assignment from the code script so the Phase 3 terminal deployment finishes cleanly, and gives me the exact Azure Portal MFA Handoff steps to bind the Data-Plane Role in the browser.

AKA (ALSO KNOWN AS): "Control-plane decoupling," "interactive MFA claim fallback," "portal role binding."

[CATEGORY 04 :: VARIABLES 19 TO 26]

The 8 Verification, Audit & Troubleshooting Variables

Two-Stage Proof & Self-Hardening Evolution: These eight variables govern how I record the deployed configuration baseline in Phase 4, prove live data-plane access via instant portal metrics in Phase 4 while packaging on-demand KQL forensic queries in Phase 5, fix and log errors across all phases during Iterations 1 to 3, halt on Iteration 4 if an error persists, and permanently upgrade my System Directive in Phase 7.

[VARIABLE 19 :: PHASE 4 BASELINE FILE]

19. Identity Architecture Ledger (identity_architecture_ledger.md or IAL)

What It Is (Physical Anatomy): The formal pre-validation Markdown file generated in Step 1 of Phase 4 and saved in my local workspace immediately after my Phase 3 IaC Payload finishes deploying (and right before the live Validation Bridge runs).
How It Connects Phase 3 to Phase 4 Verification: Records the four architectural sections deployed during Phase 3—Section 1 (Cloud Boundary: my Entra ID Tenant ID, Azure Subscription ID, and Resource Group), Section 2 (Non-Human Identity: my Application Registration Client ID and Service Principal in Single-Tenant Mode with Disabled Browser Redirect URLs), Section 3 (Passwordless Cryptographic Federation: my OpenID Connect Issuer URL, exact Subject Claim, and 60-Minute Login Token ceiling), and Section 4 (Data-Plane Access Scope: the Data-Plane Role and single Data-Plane Asset scope configured in Phase 3)—establishing the baseline record right before Step 2 and Step 3 of Phase 4 test that access live.

AKA (ALSO KNOWN AS): "Pre-deployment manifest," "cryptographic baseline receipt," "configuration snapshot."

[VARIABLE 20 :: PHASE 4 LIVE RUNTIME VERIFICATION]

20. Validation Bridge & Runtime Log Masking

What It Is (Physical Anatomy): The Validation Bridge is the live automated runtime workflow file (written in `.yml` / `.yaml`, the native instruction format used by Execution Agents) synthesized in Step 2 of Phase 4. While the Phase 3 IaC Payload configures the security rules from my local terminal, the Validation Bridge runs directly on my external Execution Agent itself to prove the Execution Agent can cross the bridge into Azure and read my Data-Plane Asset. Runtime Log Masking is the security command injected inside that runtime file that scrubs sensitive values with asterisks (`***`) in memory before anything prints to the job console log.
How It Proves the Architecture: Executed on my external Execution Agent in Phase 4. It sends the Gate 3 Subject Claim to Microsoft Entra ID, receives the 60-Minute Login Token, assumes the Gate 2 Service Principal, and reads the Gate 4 Data-Plane Asset while Runtime Log Masking ensures the token and secret value never leak to the console screen.

AKA (ALSO KNOWN AS): "Test pipeline," "validation workflow," "canary script," "stdout secret scrubbing."

[VARIABLE 21 :: PHASE 4 STAGE 1 PROOF]

21. Azure Portal Monitoring Metrics (Total Service API Hits)

What It Is (Physical Anatomy): The real-time telemetry chart built directly into my Data-Plane Asset inside the Azure web portal (`Monitoring` → `Metrics` → `Total Service API Hits` filtered to the `Last 30 minutes`).
Why It Is Stage 1 Verification: Because Azure Log Analytics backend indexing has a natural time delay and can take a long, unpredictable amount of time to surface new logs, I check Azure Portal Monitoring Metrics (`Total Service API Hits`) on my Data-Plane Asset in Step 3 of Phase 4 immediately after the Validation Bridge finishes. Confirming that live API hit spike provides immediate mathematical proof that the 60-Minute Login Token unlocked my Data-Plane Asset with zero access errors, unlocking Phase 5.

AKA (ALSO KNOWN AS): "Live data-plane telemetry," "control-plane metric spike," "synchronous verification."

[VARIABLE 22 :: PHASE 5 COMPLIANCE REPORT]

22. Audit Results Ledger (audit_results_ledger.md or ARL)

What It Is (Physical Anatomy): The formal post-validation compliance report generated in Phase 5 and saved to my local workspace and remote Code Repository and Branch.
What It Audits & Scores: Generated in Phase 5 only after the Validation Bridge passes and Azure Portal Monitoring Metrics (`Total Service API Hits`) confirm the live read on my Data-Plane Asset. It formally audits and scores Gate 1 (Boundary), Gate 2 (Identity), Gate 3 (Federation), Gate 4 (Access), and all 5 Enterprise Guardrails (DLP Parameterization, Non-Destructive State, Blocking Owner and Contributor Roles, Version Pinning, and Runtime Log Masking) as `[PASS]`.

AKA (ALSO KNOWN AS): "Post-deployment compliance report," "security audit receipt," "governance scorecard."

[VARIABLE 23 :: PHASE 5 PACKAGED SIEM & FORENSIC ARTIFACT]

23. KQL Telemetry (kql_telemetry.md)

What It Is (Physical Anatomy): The standalone file generated in Phase 5 and committed to my repository containing the pre-engineered Kusto Query Language (KQL) query for Azure Log Analytics (`ServicePrincipalSignInLogs` and `AzureDiagnostics` / `AuditEvent`).
Why It Is Packaged as an On-Demand Standby Resource: Because live Validation Bridge execution and Azure Portal Monitoring Metrics (`Total Service API Hits`) in Phase 4 already provide 100% immediate operational proof of the build, KQL Telemetry (`kql_telemetry.md`) is decoupled into Phase 5 so Azure Log Analytics ingestion latency and complex SIEM workspace plumbing never stall live IAM deployment. Packaging `kql_telemetry.md` directly into the repository ensures the exact forensic query code is ready on standby whenever a downstream SOC team, compliance auditor, or historical review needs to correlate the Service Principal token issuance with the data-plane read.

AKA (ALSO KNOWN AS): "SIEM log query," "asynchronous Log Analytics proof," "forensic query."

[VARIABLE 24 :: ALL-PHASE TROUBLESHOOTING (ITERATIONS 1 TO 3)]

24. Standard Patch Loop (Iterations 1 to 3), State Re-Sync & Defect & Patch Ledger (patch_ledger.md or DPL)

What It Is (Physical Anatomy): My routine troubleshooting and bug-logging mechanism active across every phase of the build (Phases 1 through 6):
- Standard Patch Loop (Iterations 1 to 3): Clinical diagnostic mode (`[ACTIVE DIAGNOSTIC: ...] | Iteration: 1 to 3`) where The AI Engine drops all analogies and provides a targeted fix for any terminal or cloud error during attempts 1, 2, or 3.
- State Re-Sync: Reproducing the complete, unified IaC Payload file from top to bottom after exiting a patch loop (never partial code snippets).
- Defect & Patch Ledger (patch_ledger.md or DPL): The ledger that records the Error, Root Cause, and Engineered Fix of every defect solved during Iterations 1 to 3.
How Real-Time DPL Staging Works: Whenever I confirm in my terminal that a patch worked during Iterations 1, 2, or 3 at any phase, The AI Engine immediately outputs the `[DPL ENTRY]` in the chat and performs a full-file State Re-Sync of my IaC Payload, without ever needing to trip The 4-Iteration Circuit Breaker. In Phase 5, all staged entries are written into `patch_ledger.md`, and in Phase 7 they are permanently compiled into my upgraded System Directive.

AKA (ALSO KNOWN AS): "Bug log," "error remediation loop," "telemetry feedback loop."

[VARIABLE 25 :: ITERATION 4 EMERGENCY STOP]

25. The 4-Iteration Circuit Breaker & Estimated Probability of Success (X%)

What It Is (Physical Anatomy): The emergency cognitive circuit breaker active across every phase of the build that trips ONLY if a single isolated error fails 3 times in a row during the Standard Patch Loop and reaches Iteration 4 (the iteration counter resets to 1 for each new, separate defect).
What Happens at Iteration 4: Completely separate from routine Defect & Patch Ledger (DPL) logging. If an isolated error reaches Iteration 4, The 4-Iteration Circuit Breaker structurally forbids The AI Engine from generating any new code. Instead, The AI Engine locks the brakes and conducts a Risk Management Assessment: summarizing how the error telemetry shifted across Attempts 1, 2, and 3, calculating an Estimated Probability of Success (X%), making a logistical recommendation, and presenting alternative architectural pathways so I can make the final strategic decision.

AKA (ALSO KNOWN AS): "Three-strike rule," "hallucination spiral halt," "Attempt #4 self-audit."

[VARIABLE 26 :: PHASE 7 CONTINUOUS IMPROVEMENT & UPGRADE]

26. AI Performance Scorecard & System Directive Compilation

What It Is (Physical Anatomy): The final close-out sequence in Phase 7 after my verified files are pushed to my Code Repository and Branch in Phase 6. The AI Performance Scorecard is an exact statistical readout (`Total Diagnostic Loops Triggered`, `Total Iterations Executed`, `Circuit Breakers Pulled`, and `Protocol Deviations Logged`) counted directly from a bulleted list of the session's events.
How It Upgrades the State Machine: In Phase 7, after outputting the AI Performance Scorecard, The AI Engine retrieves every entry from the Defect & Patch Ledger (DPL), states the specific Lesson Learned and rule adjustment for each entry, and upon my confirmation outputs the complete, newly optimized System Directive inside a single copy-paste code block so The State Machine never repeats that defect on future builds.

AKA (ALSO KNOWN AS): "Post-mortem summary," "continuous learning loop," "prompt evolution."

SYSTEM GLOSSARY