Skip to content

🎨 Palette: [UX improvement] Enhanced architecture diagram and link accessibility #72

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
Igor Holt (igor-holt) wants to merge 1 commit into
base: main
Choose a base branch
from
Open

🎨 Palette: [UX improvement] Enhanced architecture diagram and link accessibility #72

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 5 additions & 0 deletions .Jules/palette.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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.
22 changes: 15 additions & 7 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
Comment on lines +18 to +46

@gemini-code-assist gemini-code-assist Bot Jun 19, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

While the new diagram is a great improvement with semantic shapes and the new VRAM component, removing GPU Resources makes it unclear what the 'VRAM Pinning' is acting upon. Since VRAM is part of a GPU, it would be clearer to show the GPU resources explicitly in the infrastructure layer.

Consider reintroducing GPU Resources and adjusting the connections to show that VRAM pinning acts on GPUs, which are part of the Bare Metal Hardware.

---
title: Arbiter Hybrid Scheduling Architecture
---
graph TD
    subgraph CloudNative [Cloud Native Layer]
        Workloads([AI Workloads])
        K8s([Kubernetes Cluster])
    end

    subgraph Orchestration [Orchestration Layer]
        Arbiter((Arbiter Core))
        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 <--> VRAM
    VRAM <--> GPU
    GPU --- 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
Expand All @@ -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").