diff --git a/.Jules/palette.md b/.Jules/palette.md
index 091d600..1d7db6f 100644
--- a/.Jules/palette.md
+++ b/.Jules/palette.md
@@ -11,3 +11,8 @@ This journal contains critical UX/accessibility learnings discovered during the
 **Learning:** In complex orchestration projects, Mermaid diagrams benefit significantly from visual hierarchy. Distinguishing the "Core" component using specific styling (different colors, thicker borders) provides immediate cognitive relief and helps users identify the primary system anchor within multiple layers.
 
 **Action:** Use Mermaid `style` definitions and distinct node shapes (like double circles `((...))`) for primary architectural components in infrastructure documentation.
+
+## 2026-05-21 - Semantic Node Shapes for Infrastructure DX
+**Learning:** In technical documentation for orchestration systems, using semantic node shapes in Mermaid diagrams (e.g., stadium shapes `([ ... ])` for Kubernetes/Workloads and hexagons `{{ ... }}` for specialized algorithms or hardware pinning) provides immediate visual cues about the nature of the component. This reduces the cognitive load required to understand the relationship between software and hardware layers.
+
+**Action:** Apply stadium shapes for high-level abstractions (K8s, clusters) and hexagons for specialized/low-level logic (Schedulers, VRAM pinning) in infrastructure diagrams.
diff --git a/README.md b/README.md
index 81bb976..7a08b71 100644
--- a/README.md
+++ b/README.md
@@ -15,27 +15,35 @@ Dual nature—combining bare-metal virtualized hardware management (aSHARD VRAM
 ## 🏗️ Architecture
 
 ```mermaid
+---
+title: Arbiter Hybrid Scheduling Architecture
+---
 graph TD
     subgraph CloudNative [Cloud Native Layer]
-        K8s[Kubernetes Cluster]
+        Workloads([AI Workloads])
+        K8s([Kubernetes Cluster])
     end
 
     subgraph Orchestration [Orchestration Layer]
         Arbiter((Arbiter Core))
-        QS[Quantum Scheduler]
+        QS{{Quantum Scheduler}}
     end
 
     subgraph Infrastructure [Infrastructure Layer]
+        VRAM{{aSHARD VRAM Pinning}}
         BM[Bare Metal Hardware]
-        GPU[GPU Resources]
     end
 
+    Workloads --> K8s
     K8s <--> Arbiter
     Arbiter <--> QS
-    Arbiter <--> BM
-    BM --- GPU
+    Arbiter <--> VRAM
+    VRAM <--> BM
 
     style Arbiter fill:#f96,stroke-width:4px
+    style CloudNative stroke-dasharray: 5 5
+    style Orchestration stroke-dasharray: 5 5
+    style Infrastructure stroke-dasharray: 5 5
 ```
 
 ## 🚀 Key Features
@@ -47,8 +55,8 @@ graph TD
 
 ## 🧪 Context
 
-`arbiter` was created by **Igor Holt** (AI Architect) as part of the **Genesis Conductor Engine**. It serves as the resource orchestration layer for AI workloads, bridging low-level hardware management with cloud-native scheduling to ensure optimal utilization of specialized compute resources.
+`arbiter` was created by **Igor Holt** (AI Architect) as part of the [Genesis Conductor Engine](https://genesisconductor.io "Genesis Conductor Engine - Official Website"). It serves as the resource orchestration layer for AI workloads, bridging low-level hardware management with cloud-native scheduling to ensure optimal utilization of specialized compute resources.
 
 ## ⚖️ License
 
-This project is licensed under the [MIT License](LICENSE).
+This project is licensed under the [MIT License](LICENSE "MIT License - Open source software license agreement").