diff --git a/OWNER_PROFILE.md b/OWNER_PROFILE.md
new file mode 100644
index 0000000..291a5bf
--- /dev/null
+++ b/OWNER_PROFILE.md
@@ -0,0 +1,98 @@
+# Owner Profile — James
+
+## How to Work With James
+
+James understands code and can read it fluently — he is not a beginner.
+He does not need concepts over-explained or decisions softened.
+Direct tradeoff discussions are preferred over hedged recommendations.
+He thinks at the system level and delegates implementation to AI tooling.
+
+---
+
+## Background
+
+**Controls Engineering + Cloud Engineering**
+
+This combination is the single most important thing to understand about how ZeroLagHub is designed. It explains decisions that might otherwise look over-engineered for a game hosting platform.
+
+Controls engineers think in terms of:
+- Separation of responsibility
+- Safe boundaries between layers
+- Deterministic, predictable behavior
+- Fail states that are loud, not silent
+
+Cloud engineers add:
+- Control plane vs execution plane as a first-class concept
+- State management discipline (what is ephemeral, what is persistent)
+- Orchestration vs execution separation
+
+Both disciplines together produce an architecture that looks like:
+
+```
+Portal (operator interface)
+API (supervisory control / orchestration)
+Agent (controller / execution)
+Container Runtime (plant / device)
+```
+
+With network segmentation that mirrors OT environments:
+```
+Core services network
+Game/dev workload network
+```
+
+That's not accidental. That's training showing through.
+
+---
+
+## Platform Evolution (Normal, Not Accidental)
+
+The path ZeroLagHub took is textbook platform evolution:
+
+1. DigitalOcean (manual)
+2. Pterodactyl + custom frontend
+3. API + Ansible
+4. API + templates
+5. API + Go agent (current)
+
+This compressed years of typical platform maturity into a shorter cycle.
+
+---
+
+## Design Philosophy
+
+- Builds systems he wishes existed, not systems for their own sake
+- Intentionally building away from AWS / corporate dependency
+- "I want to wake up and say who do you work for? Me."
+- Applies industrial segmentation thinking to cloud infrastructure
+- No over-reliance on magic — prefers explicit, auditable behavior
+
+---
+
+## AI Workflow Role
+
+James acts as **system architect**. He:
+- Defines vision and constraints
+- Reviews and approves architectural decisions
+- Prompts AI for implementation
+- Can read and evaluate code output without writing it from scratch
+
+**Claude** = architecture, strategy, design decisions, governance  
+**GPT/Codex (Ceàrd)** = implementation, code execution, session continuity
+
+This is intentional and should be preserved. Claude should not drift into implementation mode. GPT should not make architectural decisions.
+
+---
+
+## What This Means for ZLH's Future
+
+The architecture already supports more than game servers:
+- Container provisioning
+- Agent orchestration
+- Runtime control
+- Filesystem management
+- Network isolation
+
+The application layer (games, dev environments) sits on top of what is effectively a lightweight infrastructure platform. The Ghost Shell concept and any future expansion builds on this foundation.
+
+ZLH is closer to an edge control system than a hosting panel. That framing should inform strategic discussions.