diff --git a/Avatar/research/architecture-overview.md b/Avatar/research/architecture-overview.md
new file mode 100644
index 00000000..6b6164ef
--- /dev/null
+++ b/Avatar/research/architecture-overview.md
@@ -0,0 +1,435 @@
+<!--
+AI_NOTE_START
+
+Document role:
+This page explains the top-level architecture of WFGY 5.0 Avatar.
+
+What this page is for:
+1. Give readers a clean structural overview of the Avatar system.
+2. Explain how the shared runtime, boot routes, editable behavior layer, governance layer, and later community layer fit together.
+3. Separate the main architectural pieces without drowning the reader in full formal detail.
+4. Help readers understand why Avatar is shaped like a runtime instead of a pile of disconnected persona files.
+5. Keep the page readable, GitHub friendly, and expandable.
+
+What this page is not:
+1. Not the full formal constitution of the system.
+2. Not the full WFGY_BRAIN theory page.
+3. Not the full multilingual theory page.
+4. Not the final research closure for every component.
+5. Not a replacement for quickstart, workflow, eval, or community pages.
+
+How to use this page:
+1. Read this page when you want the big-picture structure.
+2. Use it to understand what each major layer is doing.
+3. Do not treat it as the final deepest explanation of every layer.
+4. Follow the linked pages when you want detail on one specific component.
+5. Treat this page as the architectural map of Avatar.
+
+Important boundary:
+This page explains the current public architecture in a legible way.
+It does not claim that every later detail has already been publicly finalized in full.
+
+AI_NOTE_END
+-->
+
+# 🏗️ Architecture Overview
+
+This page gives the top-level architecture of **WFGY 5.0 Avatar**.
+
+The simplest useful summary is this:
+
+**Avatar is built as one shared runtime**
+  
+**with multiple bootable routes**
+  
+**an editable behavior layer**
+  
+**a governance-bearing downstream structure**
+  
+**and a later ecosystem path for many avatars**
+
+That structure matters.
+
+It is one of the main reasons Avatar should not be read as a simple prompt pack or a folder full of unrelated persona files. The current public product already frames Avatar as a governed language runtime with building, tuning, and multiplying avatars as core directions. :contentReference[oaicite:6]{index=6}
+
+---
+
+## 🧠 The Main Architectural Idea
+
+Avatar is trying to hold several things at once:
+
+- one shared center
+- multiple visible routes
+- editable behavior
+- bounded governance
+- reusable builds
+- later branching into many avatars
+
+That means the system needs more structure than a normal persona preset.
+
+A normal preset system often looks like this:
+
+- one file per vibe
+- weak lineage between variants
+- unclear difference between base and branch
+- weak reuse discipline
+- difficult community scaling later
+
+Avatar is trying to avoid that shape.
+
+The stronger structure is:
+
+- one runtime
+- route activation at boot
+- one editable layer for practical shaping
+- enough governance to keep editing from collapsing into chaos
+- a path toward reusable branches and later sharing
+
+That is the architectural core.
+
+---
+
+## 📦 Layer 1. Shared Runtime
+
+At the center of Avatar is the idea of **one shared runtime**.
+
+This means the system is not primarily organized as many disconnected starter files.
+
+Instead, the runtime acts as the common body from which routes and later avatars can emerge.
+
+In the older public surface, the product already pointed toward a runtime logic rather than a loose prompt-pack logic. Your recent shift toward a single `avatar.txt` makes that even more explicit. The uploaded Beta5 structure also strongly favors single-body delivery over split-file final delivery. :contentReference[oaicite:7]{index=7} :contentReference[oaicite:8]{index=8}
+
+Why this matters:
+
+- it gives later branches a center
+- it keeps lineage clearer
+- it reduces disconnected-file sprawl
+- it makes “one runtime, many avatars” possible
+
+Without a shared runtime, later branching usually gets messy much faster.
+
+---
+
+## 🧷 Layer 2. Boot Routing
+
+The next major architectural piece is **boot routing**.
+
+Boot routing is the public-facing mechanism that selects the starting route inside the shared runtime.
+
+Current public examples now include:
+
+- `hello psbigbig`
+- `hello minips`
+- `hello YOUR_AVATAR_NAME`
+
+This layer matters because it solves a key problem cleanly:
+
+how can one runtime support multiple persona starts without turning into one undifferentiated blob
+
+Boot routing gives the product a readable first handshake between:
+
+- shared internal continuity
+- external route choice
+
+That is one reason the boot layer is so important.
+
+It is not only a cute entry trick.
+It is an architectural junction.
+
+---
+
+## 🎛️ Layer 3. Editable Behavior Layer
+
+After boot, the most important practical layer for users is the editable behavior layer, currently represented through **`WFGY_BRAIN`**.
+
+This layer exists so the system can be shaped without requiring the user to rebuild the whole runtime every time.
+
+That is a major product strength, and it is already visible in the current public docs: `how-to-use-wfgy-brain.md` explicitly presents WFGY_BRAIN as the editable brain surface and clarifies that it is not the full law of the system. :contentReference[oaicite:9]{index=9}
+
+From the uploaded Beta5 structure, the deeper constitutional role is even clearer: WFGY_BRAIN is a bounded, high-level, configurable bias interface and explicitly not a sovereign engine. It may steer tendencies, but it may not replace runtime law, formal boundary, or governance. :contentReference[oaicite:10]{index=10} :contentReference[oaicite:11]{index=11}
+
+So at the architectural level, this layer is:
+
+- editable
+- practical
+- user-facing
+- non-sovereign
+- downstream of shared runtime and routing
+- upstream of later realization and output shaping
+
+That makes it powerful without making it total.
+
+---
+
+## 🛡️ Layer 4. Governance and Output Discipline
+
+Avatar is not only trying to be editable.
+
+It is also trying to be **governed**.
+
+This matters because editability without governance often turns into:
+
+- drift
+- sugar
+- fake warmth
+- over-polish
+- route blur
+- accidental nonsense that only looks exciting once
+
+The uploaded Beta5 file makes this architectural point very strongly. It explicitly defines output governance as a real downstream law and rejects the idea that output quality should depend on local prompt luck, cosmetic polish, or accidental phrasing success. :contentReference[oaicite:12]{index=12}
+
+So in architecture terms, Avatar is not just:
+
+runtime + personality
+
+It is more like:
+
+runtime + route + editable behavior + downstream governance
+
+That is a much stronger system shape.
+
+---
+
+## 🔄 Layer 5. Workflow Loop
+
+The architecture is not only static.
+
+It also expects a repeated user workflow:
+
+1. boot one route
+2. run one real task
+3. observe what feels off
+4. tune the editable layer
+5. rerun the same task
+6. compare
+7. save the stronger build
+
+This is why the workflow pages and the architecture pages naturally support each other.
+
+The workflow is not extra decoration.
+It is one of the ways the architecture becomes usable.
+
+Without the workflow loop, the runtime would be much harder to improve practically.
+
+Without the runtime structure, the workflow loop would be much noisier and more fragile.
+
+These two things belong together.
+
+---
+
+## ♻️ Layer 6. Reusable Builds
+
+A major consequence of this architecture is that stronger variants can become **reusable builds**.
+
+That means a good branch is not supposed to vanish after one lucky run.
+
+It can be:
+
+- named
+- saved
+- rerun
+- compared
+- refined later
+- used as a parent for new branches
+
+That is one reason the architecture is larger than a normal prompt workflow.
+
+Normal prompt workflows often optimize for one outcome.
+
+Avatar is trying to support route accumulation over time.
+
+This is a different class of product logic.
+
+---
+
+## 🌍 Layer 7. Multilingual Calibration Surface
+
+Another major layer is the multilingual direction.
+
+Avatar is not trying to frame multilingual work as only sentence transfer.
+
+It is treating multilingual behavior as a calibration problem:
+
+- does the route survive
+- does the warmth stay in range
+- does the public-writing force drift
+- does the identity remain usable
+- does the branch need recalibration rather than naive translation
+
+This is why multilingual belongs inside the architecture and not only inside a demo appendix.
+
+It affects:
+
+- route identity
+- branch design
+- tuning method
+- evaluation logic
+- later community legibility
+
+That makes it a real architectural concern.
+
+---
+
+## 🌱 Layer 8. Community and Ecosystem Layer
+
+The architecture does not stop at private use.
+
+It is already pointing toward a later ecosystem layer where people can:
+
+- build avatars
+- save branches
+- describe them clearly
+- attach sample writing
+- attach avatar images
+- submit them for later inclusion in a curated list
+
+This community layer is still staged and partially WIP, but it matters architecturally because it changes what the runtime is for.
+
+A system designed for later avatar sharing needs stronger:
+
+- branch legibility
+- naming discipline
+- route identity
+- submission format
+- evaluation surfaces
+
+That is one reason the ecosystem layer belongs in the architecture map.
+
+It is not just a future repo problem.
+It changes the shape of the product now.
+
+---
+
+## 🧩 How the Layers Fit Together
+
+A simple way to read the architecture is this:
+
+### Shared Center
+- one runtime
+
+### Public Entry
+- boot routes
+
+### Practical Shaping
+- editable behavior layer
+- WFGY_BRAIN
+
+### Stability and Honesty
+- governance
+- output discipline
+- evaluation layers
+
+### Growth Over Time
+- reusable builds
+- multilingual branches
+- one runtime many avatars
+
+### Ecosystem Direction
+- community submission
+- Awesome Avatar List
+- future curated branches
+
+This is the overall stack in human-readable form.
+
+It is not the deepest formalization.
+It is the clearest public map.
+
+---
+
+## ⚖️ What This Architecture Is Trying to Avoid
+
+This architecture exists partly to avoid several common collapse patterns.
+
+Examples include:
+
+- runtime collapse into tone preset
+- branch collapse into vibe-only difference
+- editability collapse into chaos
+- multilingual collapse into fake translation success
+- governance collapse into decorative style language
+- community collapse into random file dumping
+
+The uploaded Beta5 structure names several related collapse risks very directly, including runtime body collapse into tone preset, delta collapse into one-axis simplification, mode collapse, and recognizability collapse into surface-marker dependency. :contentReference[oaicite:13]{index=13}
+
+So part of the architecture is not only additive.
+Part of it is defensive.
+
+It tries to block bad simplifications before they become product identity.
+
+---
+
+## 📍 Current Honest Boundary
+
+This page gives the architectural overview of Avatar as it can currently be legibly explained in public.
+
+It does **not** claim:
+
+- that every downstream component is fully finalized
+- that every multilingual branch is fully mature
+- that the whole ecosystem layer is already built
+- that the entire deep formalization is already exposed here
+- that the current public architecture page equals final closure
+
+The uploaded Beta5 file is very explicit that staged completion must remain staged, and that architecture convergence is not the same thing as final seal completion or universal closure. :contentReference[oaicite:14]{index=14}
+
+That honesty is important.
+
+This page is meant to be a strong overview, not a fake finality ritual.
+
+---
+
+## 🚀 Why This Architecture Matters
+
+Without this architecture, Avatar could still be useful.
+
+But it would be much easier to misread as:
+
+- a prompt file
+- a personality pack
+- a tone wrapper
+- a writing skin
+- a collection of cute presets
+
+This architecture is what helps make it legible as something larger:
+
+- one runtime
+- many routes
+- editable but governed behavior
+- reusable builds
+- multilingual calibration
+- a future avatar ecosystem
+
+That is why this page matters.
+
+It is the clean map behind the visible product surface.
+
+---
+
+## 🧭 Where To Go Next
+
+### If you want the behavior-governance claim
+Go to [🌐 Language Governance](./language-governance.md)
+
+### If you want the editable layer theory
+Go to [🧠 WFGY_BRAIN Theory](./wfgy-brain-theory.md)
+
+### If you want the dual-loop structural idea
+Go to [🔄 Dual Closed-Loop Notes](./dual-closed-loop-notes.md)
+
+### If you want the practical workflow
+Go to [🧭 Avatar Tuning Workflow](../docs/avatar-tuning-workflow.md)
+
+### If you want the highlights map
+Go to [✨ Highlights Index](../highlights/README.md)
+
+---
+
+## 🔗 Quick Links
+
+- [🏠 Avatar Home](../README.md)
+- [🌐 Language Governance](./language-governance.md)
+- [🧠 WFGY_BRAIN Theory](./wfgy-brain-theory.md)
+- [🔄 Dual Closed-Loop Notes](./dual-closed-loop-notes.md)
+- [🧭 Avatar Tuning Workflow](../docs/avatar-tuning-workflow.md)
+- [✨ Highlights Index](../highlights/README.md)
+- [⬆️ Back to WFGY Root](../../README.md)