diff --git a/.project/W2-ARCHITECTURE.md b/.project/W2-ARCHITECTURE.md
new file mode 100644
index 0000000..55a1b51
--- /dev/null
+++ b/.project/W2-ARCHITECTURE.md
@@ -0,0 +1,1167 @@
+# W2 — Ancient Egypt Media
+## Architecture
+
+**Project:** W2 — Ancient Egypt Media  
+**Portfolio:** Autonomous Enterprise Portfolio  
+**Classification:** Product / Business  
+**Ecosystem:** Withered Sanctum  
+**Initial Product:** Ancient Egypt historical media channel and associated digital publishing products  
+**Status:** Draft for approval  
+**Owner / Architecture Authority:** Ken Schaefer  
+**Development Lead:** ChatGPT  
+**Implementation Engineer:** Codex where software/automation is required  
+**Related documents:** `W2-REQUIREMENTS.md`, `ENTERPRISE-MODEL.md`, `VISION.md`, `PORTFOLIO.md`, `PROJECT-PLAN.md`, `PROJECT-CHARTER.md`
+
+---
+
+# Project Value Gates
+
+## Development Window
+
+**Target:** Publish the first complete, public W2 media product by **September 24, 2026**.
+
+The development gate is satisfied only when:
+
+- one original Ancient Egypt video is publicly available;
+- a public URL exists;
+- required source/provenance records exist;
+- the underlying production assets are preserved;
+- the product can be reproduced or continued from the formal project repository.
+
+The architecture must support rapid launch and must not introduce infrastructure whose value cannot be demonstrated inside the development window.
+
+If the September 24 publication gate cannot be met, the project must be reviewed before further development investment is authorized.
+
+No silent extension of the development window is permitted.
+
+---
+
+## Commercial Validation Window
+
+**Primary KPI:** One genuine arm's-length sale with collected revenue greater than $0 attributable to W2.
+
+**Maximum initial validation window:** 52 weeks from the authorized W2 kickoff date, subject to shorter portfolio review gates.
+
+The first sale may come from:
+
+- a companion historical publication;
+- a digital field guide;
+- a Pyramid-adjacent product;
+- a membership;
+- another explicitly attributable W2 product.
+
+YouTube views, subscribers, watch time, engagement, or advertising eligibility do not satisfy the commercial gate.
+
+The publication gate and first-sale gate are separate.
+
+---
+
+# 1. Architectural Purpose
+
+W2 exists to create and operate a real historical media business within the Withered Sanctum ecosystem.
+
+The architecture must support:
+
+- source-based historical research;
+- script development;
+- editorial review;
+- narration production;
+- visual asset management;
+- provenance and rights tracking;
+- video assembly;
+- publication;
+- companion-product creation;
+- repeatable episode production;
+- preservation of all important work product.
+
+W2 is not a shared service.
+
+W2 is a **standalone Product / Business** and therefore receives its own formal source project.
+
+---
+
+# 2. Enterprise Placement
+
+W2 is located within the Autonomous Enterprise Portfolio as:
+
+```text
+Autonomous Enterprise Portfolio
+    └── Products / Businesses
+        └── Withered Sanctum
+            └── Ancient Egypt Media
+```
+
+W2 may consume Shared Services in the future.
+
+Examples may include:
+
+- generic TTS generation;
+- research assistance;
+- asset processing;
+- publishing automation;
+- financial administration.
+
+However, W2 must remain operable without assuming that such shared services already exist.
+
+---
+
+# 3. Product Boundary
+
+W2 owns the work required to create and operate the Ancient Egypt media product.
+
+W2 includes:
+
+- editorial identity;
+- historical research;
+- episode concepts;
+- scripts;
+- narration assets;
+- voice identity;
+- visual assets;
+- provenance;
+- video-production source;
+- published-media metadata;
+- companion products;
+- production documentation.
+
+W2 does not automatically own:
+
+- generic portfolio-wide TTS infrastructure;
+- generic accounting systems;
+- generalized marketing automation;
+- generalized opportunity intelligence;
+- portfolio governance.
+
+Those belong elsewhere if and when they become shared capabilities.
+
+---
+
+# 4. Formal Source Project
+
+W2 will have a dedicated source project and Gitea repository.
+
+Recommended repository identity:
+
+**Withered-Sanctum-Media**
+
+The repository represents the **entire source of the product**, not only software code.
+
+Conceptual structure:
+
+```text
+Withered-Sanctum-Media/
+│
+├── .project/
+│   ├── REQUIREMENTS.md
+│   ├── ARCHITECTURE.md
+│   ├── PROJECT-PLAN.md
+│   ├── STATUS.md
+│   ├── DECISIONS/
+│   └── WORK-ORDERS/
+│
+├── research/
+│   ├── sources/
+│   ├── dossiers/
+│   └── claims/
+│
+├── episodes/
+│   └── ep01-unas/
+│       ├── research/
+│       ├── script/
+│       ├── narration/
+│       ├── assets/
+│       ├── provenance/
+│       ├── edit/
+│       ├── exports/
+│       └── publication/
+│
+├── voices/
+│   └── pyramid-narrator-v1/
+│
+├── products/
+│   └── field-notes/
+│
+├── templates/
+│
+├── production/
+│   ├── runbooks/
+│   ├── scripts/
+│   └── automation/
+│
+├── docs/
+│
+└── README.md
+```
+
+The exact folder names may be refined during project setup, but the project must preserve clear separation among:
+
+- project management;
+- reusable product assets;
+- episode-specific work;
+- production tooling;
+- commercial products.
+
+---
+
+# 5. `.project/` Control Plane
+
+Every W2 project-management artifact belongs under:
+
+```text
+.project/
+```
+
+The required contents are:
+
+```text
+.project/
+├── REQUIREMENTS.md
+├── ARCHITECTURE.md
+├── PROJECT-PLAN.md
+├── STATUS.md
+├── DECISIONS/
+└── WORK-ORDERS/
+```
+
+The `.project/` folder answers:
+
+- what W2 is;
+- what success means;
+- where the project is;
+- what decisions have been made;
+- what work is authorized next;
+- whether the project remains inside its value gates.
+
+A person opening the repository in VS Code should begin with `.project/`.
+
+---
+
+# 6. Product Source Definition
+
+For W2, source includes all work required to reproduce, maintain, continue, or transfer the product.
+
+This includes:
+
+- research dossiers;
+- source notes;
+- claim lists;
+- scripts;
+- episode outlines;
+- narration text;
+- voice references;
+- saved voice profiles;
+- generated narration;
+- pronunciation guidance;
+- images;
+- maps;
+- diagrams;
+- graphics;
+- music or score source where applicable;
+- edit project files;
+- caption files;
+- thumbnail source;
+- companion-product source;
+- publication metadata;
+- production runbooks;
+- automation code;
+- provenance records.
+
+The product source must not depend on chat transcripts as the sole location of important decisions or production knowledge.
+
+---
+
+# 7. Large Binary Asset Strategy
+
+Git is not an ideal store for every media binary.
+
+W2 therefore distinguishes:
+
+## Git-managed assets
+
+Prefer Git for:
+
+- Markdown;
+- text;
+- configuration;
+- scripts;
+- metadata;
+- provenance;
+- small diagrams;
+- small reference images where practical;
+- project files that diff meaningfully;
+- templates.
+
+## External or large-file assets
+
+Large files may be stored outside normal Git history, including:
+
+- high-resolution source images;
+- WAV masters;
+- large voice-model assets;
+- raw video footage;
+- rendered video;
+- large editing caches.
+
+If external storage is used, the repository must preserve:
+
+- logical asset ID;
+- file name;
+- location;
+- checksum where useful;
+- provenance;
+- relationship to episode/product;
+- recovery instructions.
+
+Git LFS may be considered later, but is not required for Sprint 0.
+
+The priority is reproducibility without bloating the repository.
+
+---
+
+# 8. Episode Architecture
+
+Each published episode is treated as a bounded product unit.
+
+Conceptual episode structure:
+
+```text
+episodes/
+└── epNN-topic/
+    ├── research/
+    ├── script/
+    ├── narration/
+    ├── assets/
+    ├── provenance/
+    ├── edit/
+    ├── exports/
+    └── publication/
+```
+
+Each episode should be independently understandable.
+
+An episode should contain or reference:
+
+- research dossier;
+- claim list;
+- approved script;
+- narration source;
+- asset register;
+- rights/provenance;
+- edit project;
+- final publication metadata;
+- public URL after release.
+
+---
+
+# 9. Episode Lifecycle
+
+The standard W2 episode lifecycle is:
+
+```text
+Topic
+  ↓
+Research
+  ↓
+Claim Review
+  ↓
+Script
+  ↓
+Editorial Approval
+  ↓
+Narration
+  ↓
+Asset Selection
+  ↓
+Rights / Provenance Review
+  ↓
+Video Assembly
+  ↓
+Factual / Quality Review
+  ↓
+Owner Approval
+  ↓
+Publication
+  ↓
+Commercial Follow-through
+```
+
+The project may automate individual stages later.
+
+The lifecycle itself should remain understandable and auditable.
+
+---
+
+# 10. Research Architecture
+
+Research is a formal product input.
+
+Each episode must have:
+
+- source dossier;
+- claim list;
+- identified uncertainties;
+- excluded or rejected claims where important;
+- source references.
+
+Research artifacts should be stored as structured Markdown or another human-readable format.
+
+The project should favor authoritative sources.
+
+AI may assist in discovery and synthesis but does not become the authoritative source.
+
+---
+
+# 11. Claim Architecture
+
+The claim list is the bridge between research and script.
+
+Each material claim should be traceable to supporting evidence.
+
+Conceptually:
+
+```text
+Claim
+    id
+    text
+    status
+    supporting_sources
+    uncertainty
+    notes
+    script_usage
+```
+
+A claim may be:
+
+- supported;
+- qualified;
+- debated;
+- excluded.
+
+The exact schema may remain simple during Sprint 0.
+
+The important requirement is traceability.
+
+---
+
+# 12. Script Architecture
+
+Scripts are versioned product assets.
+
+Each episode script should preserve:
+
+- working draft;
+- editorial revisions;
+- approved narration version;
+- notable source/claim references.
+
+The approved narration script should be clearly identifiable.
+
+Scripts should be human-readable Markdown or plain text.
+
+The project does not require a custom script-authoring application.
+
+---
+
+# 13. Narration Architecture
+
+W2 supports both human and synthetic narration.
+
+The initial architecture permits use of:
+
+**Pyramid Narrator v1**
+
+The narrator is a W2 / Withered Sanctum product asset.
+
+The narration workflow is:
+
+```text
+Approved script
+   ↓
+Segment into manageable passages
+   ↓
+Load approved narrator profile
+   ↓
+Generate narration segments
+   ↓
+Human review
+   ↓
+Regenerate weak segments
+   ↓
+Assemble narration master
+```
+
+Long-form narration should not require a single uninterrupted TTS generation pass.
+
+Segment-level regeneration is preferred.
+
+---
+
+# 14. Pyramid Narrator Asset Placement
+
+The canonical narrator package belongs in:
+
+```text
+voices/pyramid-narrator-v1/
+```
+
+Expected artifacts may include:
+
+- reference WAV;
+- saved voice profile;
+- voice description;
+- model/version information;
+- generation notes;
+- pronunciation notes;
+- version history.
+
+The narrator identity itself remains a W2 product asset.
+
+The generic TTS engine may later become a Shared Service if another product legitimately requires it.
+
+---
+
+# 15. TTS Engine Placement
+
+Qwen3-TTS is currently an enabling technology used by W2.
+
+For Sprint 0:
+
+- Qwen3-TTS remains W2-local as a production dependency;
+- the existing Forge installation may be used;
+- W2 may document how to invoke it;
+- no generalized portfolio TTS service is required.
+
+Future extraction into AEP Shared Services requires demonstrated cross-product reuse.
+
+This prevents premature infrastructure work.
+
+---
+
+# 16. Pronunciation Management
+
+Ancient Egyptian names, transliterations, locations, and technical terms require explicit QA.
+
+The project should maintain pronunciation guidance where useful.
+
+Potential structure:
+
+```text
+voices/
+└── pronunciation/
+    └── egyptian-terms.md
+```
+
+Pronunciation guidance should capture:
+
+- word/term;
+- preferred spoken form;
+- episode context;
+- notes where uncertain.
+
+The objective is consistent narration, not a universal linguistic authority.
+
+---
+
+# 17. Visual Asset Architecture
+
+Visual assets belong either:
+
+- at the reusable project level; or
+- within the episode that uses them.
+
+Reusable items may include:
+
+- logos;
+- typography;
+- recurring backgrounds;
+- channel graphics;
+- style templates.
+
+Episode-specific items may include:
+
+- archaeological photographs;
+- maps;
+- inscription images;
+- diagrams;
+- museum objects;
+- episode illustrations.
+
+Assets should not be duplicated unnecessarily across episodes.
+
+---
+
+# 18. Provenance and Rights Architecture
+
+Provenance is a first-class product requirement.
+
+Each material asset should have an associated provenance record.
+
+Conceptual record:
+
+```text
+Asset
+    id
+    file
+    source
+    creator
+    license
+    commercial_use
+    attribution
+    modification_notes
+    episode_usage
+```
+
+Provenance should be human-readable and easy to audit.
+
+The project should not rely on memory or browser history to determine whether an asset can be published commercially.
+
+---
+
+# 19. Synthetic Media Handling
+
+If W2 uses synthetic or materially altered realistic media:
+
+- it must not be presented as historical evidence;
+- the project must record that it is synthetic;
+- the image/video should be reviewed for historical plausibility;
+- applicable platform disclosure requirements must be followed.
+
+Synthetic media should be treated as illustration, not evidence.
+
+---
+
+# 20. Video Editing Architecture
+
+The video-editing workflow should use existing available tools wherever practical.
+
+The architecture requires:
+
+- reproducible project organization;
+- preserved edit source;
+- known asset references;
+- recoverable render settings;
+- final export tracking.
+
+The exact editor is an implementation decision to be finalized in the project plan or an ADR.
+
+The architecture does not require development of a custom editor.
+
+---
+
+# 21. Render / Export Architecture
+
+Final rendered outputs should be treated as published artifacts, not the sole product source.
+
+For each episode, preserve:
+
+- edit project;
+- narration master;
+- asset references;
+- final export;
+- publication metadata.
+
+Suggested structure:
+
+```text
+episodes/ep01-unas/
+├── edit/
+├── exports/
+└── publication/
+```
+
+Large final renders may reside outside Git with documented references.
+
+---
+
+# 22. Publication Architecture
+
+The intended initial publishing destination is a Withered Sanctum YouTube presence.
+
+Publication requires:
+
+- verified channel ownership;
+- verified account access;
+- approved title;
+- approved description;
+- approved thumbnail;
+- attribution/disclosure text where required;
+- owner approval;
+- final URL captured in project records.
+
+Publication metadata should be retained under the episode project.
+
+---
+
+# 23. Customer-Facing Product Architecture
+
+W2's first direct commercial product is expected to be:
+
+**Withered Sanctum Field Notes #1 — The Pyramid Texts of Unas**
+
+The companion product source belongs under:
+
+```text
+products/field-notes/
+```
+
+The product should reuse legitimate Episode 1 research and original graphics where appropriate.
+
+The product must remain independently identifiable from the video.
+
+---
+
+# 24. Payment and Delivery Architecture
+
+The companion product requires:
+
+- payment path;
+- delivery path;
+- transaction attribution;
+- product version;
+- fulfillment expectations.
+
+The project should reuse existing approved commercial infrastructure where practical.
+
+No new commerce platform should be introduced unless existing tools are inadequate.
+
+The exact payment/delivery system will be selected in the project plan.
+
+---
+
+# 25. Customer Data
+
+W2 should collect the minimum customer data necessary for the chosen commercial mechanism.
+
+Customer data should not be copied into media-production folders unless required.
+
+If a third-party commerce platform is used, that system remains authoritative for transaction/customer records.
+
+W2 project records should reference sales evidence without duplicating sensitive payment information.
+
+---
+
+# 26. Shared-Service Boundary
+
+W2 may consume Shared Services but is not itself a Shared Service.
+
+The following should remain W2-local initially:
+
+- Pyramid Narrator;
+- Episode research;
+- episode scripts;
+- production templates;
+- provenance model;
+- video workflow;
+- companion-product source.
+
+Potential future shared capabilities include:
+
+- generic TTS engine interface;
+- caption generation;
+- media transformation;
+- asset processing;
+- publication automation.
+
+Extraction requires actual reuse.
+
+---
+
+# 27. Relationship to Project Thoth
+
+Project Thoth may eventually support:
+
+- source retrieval;
+- research corpus management;
+- provenance;
+- historical knowledge organization;
+- source reuse across episodes.
+
+W2 must not depend on Project Thoth for Release 1.
+
+The first publication must be achievable using the formal W2 project itself and existing research tools.
+
+Thoth integration is optional future work.
+
+---
+
+# 28. Development Environment
+
+The formal W2 source project should be:
+
+- created in Gitea;
+- cloned/initialized on Forge;
+- opened in VS Code;
+- managed through `.project/`.
+
+Software or automation added to W2 follows AEP SDLC standards.
+
+Non-code media-production work remains version-controlled or otherwise documented through the same formal project structure.
+
+---
+
+# 29. Automation Boundary
+
+Automation is allowed where it directly reduces production effort.
+
+Potential automation includes:
+
+- TTS invocation;
+- file conversion;
+- caption generation;
+- metadata generation;
+- render scripting;
+- asset inventory updates.
+
+Automation should not delay publication.
+
+No generalized media-agent framework is required.
+
+The project should first prove a repeatable production workflow.
+
+---
+
+# 30. Human Approval Gates
+
+The following gates require owner approval:
+
+## Editorial Gate
+
+Before narration:
+
+- topic;
+- factual framing;
+- script.
+
+## Production Gate
+
+Before final render:
+
+- narration quality;
+- visual selections;
+- synthetic media where applicable;
+- rights/provenance exceptions.
+
+## Publication Gate
+
+Before public release:
+
+- final video;
+- title;
+- description;
+- thumbnail;
+- disclosures;
+- channel/account.
+
+## Commercial Gate
+
+Before companion-product launch:
+
+- final product;
+- price;
+- payment path;
+- fulfillment terms.
+
+---
+
+# 31. Backup and Recovery
+
+W2 is intended to become a durable media catalog.
+
+The architecture therefore requires recovery of:
+
+- research;
+- scripts;
+- narrator assets;
+- provenance;
+- edit projects;
+- companion products;
+- publication metadata.
+
+Git/Gitea should protect text and manageable source assets.
+
+Large binary assets should have a documented backup location.
+
+No single workstation copy should become the only copy of irreplaceable product assets.
+
+---
+
+# 32. Portability and Transferability
+
+W2 is a standalone Product / Business and should be structured so it can eventually:
+
+- continue operating;
+- be licensed;
+- be transferred;
+- be sold;
+- be archived.
+
+The project should therefore maintain identifiable:
+
+- brand assets;
+- product source;
+- production process;
+- rights/provenance;
+- narrator assets;
+- customer/product dependencies;
+- publishing accounts;
+- external services.
+
+Transferability depends on actual platform/account/license terms and is not assumed.
+
+---
+
+# 33. Existing W2 Assets
+
+Existing pre-architecture work is valid discovery/pre-production material.
+
+Known assets include:
+
+- business canvas;
+- Episode 1 source dossier;
+- Episode 1 claim list;
+- Episode 1 production plan;
+- PMO status report;
+- Qwen3-TTS Forge environment;
+- Pyramid Narrator v1;
+- TTS runbook.
+
+These should be assessed during project setup and classified as:
+
+- `MIGRATE`
+- `REFERENCE`
+- `SUPERSEDE`
+- `EXTERNAL DEPENDENCY`
+
+No existing folder or file location is automatically grandfathered into the formal product structure.
+
+---
+
+# 34. Existing Asset Migration Strategy
+
+Before production resumes, the project should:
+
+1. establish the formal Gitea repository;
+2. establish `.project/`;
+3. create the approved folder structure;
+4. inventory existing W2 artifacts;
+5. migrate/refer to each artifact intentionally;
+6. record large external assets;
+7. verify critical narrator files are backed up.
+
+This prevents the product from remaining scattered across chats and workstation folders.
+
+---
+
+# 35. Observability and Status
+
+`W2/.project/STATUS.md` should provide a concise operational view.
+
+Minimum information:
+
+```text
+Current episode:
+Current phase:
+Publication deadline:
+Owner hours consumed:
+Incremental spend:
+Research status:
+Script status:
+Narration status:
+Asset/provenance status:
+Edit status:
+Publication status:
+Companion product status:
+First-sale status:
+Blockers:
+Next authorized work:
+```
+
+The PMO receives summary reports from this local record.
+
+---
+
+# 36. Testing and Quality Assurance
+
+W2 is not primarily a software project, so quality assurance is broader than automated tests.
+
+Required QA domains include:
+
+## Historical QA
+
+- claims supported;
+- uncertainty represented;
+- misleading claims removed.
+
+## Rights QA
+
+- licenses checked;
+- attribution identified;
+- commercial use confirmed.
+
+## Narration QA
+
+- pronunciation;
+- intelligibility;
+- pacing;
+- consistency.
+
+## Visual QA
+
+- images appropriate;
+- diagrams accurate;
+- synthetic media clearly handled.
+
+## Production QA
+
+- audio levels acceptable;
+- captions where applicable;
+- render free of obvious defects.
+
+## Publication QA
+
+- metadata correct;
+- links work;
+- attribution/disclosures present.
+
+Where software or automation is introduced, normal automated testing standards apply.
+
+---
+
+# 37. Release 1 Architecture
+
+Release 1 is intentionally simple.
+
+It requires:
+
+```text
+Formal W2 repository
+        ↓
+Episode 1 research
+        ↓
+Approved script
+        ↓
+Narration
+        ↓
+Licensed/provenanced assets
+        ↓
+Existing video editor
+        ↓
+Final render
+        ↓
+Human review
+        ↓
+YouTube publication
+        ↓
+Companion-product path
+```
+
+No custom application is required to launch W2.
+
+The formal repository and production structure are the operating system for the product.
+
+---
+
+# 38. Deferred Architecture
+
+The following are deliberately deferred:
+
+- automated publishing;
+- scheduled media generation;
+- custom content-management system;
+- multi-channel orchestration;
+- custom asset-management application;
+- custom commerce platform;
+- custom analytics system;
+- generalized media-production Shared Service;
+- Project Thoth integration;
+- fully automated script-to-video pipeline;
+- autonomous editorial approval.
+
+These items require future evidence before investment.
+
+---
+
+# 39. Architectural Decisions Summary
+
+| Decision | Architecture |
+|---|---|
+| Enterprise classification | Product / Business |
+| Ecosystem | Withered Sanctum |
+| Repository | Dedicated W2 / Withered Sanctum Media repository |
+| Project control | `.project/` |
+| Source definition | Entire media/product work product |
+| Episode organization | Bounded episode folders |
+| Research | Source dossier + claim list |
+| Narration | Human or Qwen3-TTS; Pyramid Narrator v1 available |
+| Pyramid Narrator | W2 product asset |
+| Generic TTS | W2-local initially; future Shared Service candidate |
+| Visual source | Authentic/open/owned assets preferred |
+| Provenance | First-class requirement |
+| Video editing | Existing toolchain preferred |
+| Publication | Withered Sanctum YouTube presence |
+| Companion product | Field Notes concept |
+| Commerce | Reuse existing approved infrastructure where possible |
+| Project Thoth | Optional future dependency |
+| Custom application | Not required for Release 1 |
+| Automation | Only where it directly accelerates production |
+| Large binaries | External storage allowed with documented references |
+| Development deadline | September 24, 2026 |
+| Commercial gate | First attributable collected sale within validation window |
+
+---
+
+# 40. Architecture Acceptance Criteria
+
+This architecture is accepted when the project can proceed into detailed planning without unresolved foundational questions about:
+
+- product boundary;
+- repository ownership;
+- `.project/` structure;
+- source/work-product definition;
+- episode organization;
+- research;
+- narration;
+- narrator asset ownership;
+- provenance;
+- video-production flow;
+- large binary handling;
+- publication;
+- companion product;
+- commercial path;
+- shared-service extraction;
+- Project Thoth relationship;
+- existing artifact migration.
+
+Technology/tool choices that do not alter these boundaries may be finalized in `W2-PROJECT-PLAN.md` or project ADRs.
+
+---
+
+# 41. Next Project Gate
+
+Upon approval of this architecture, the next required artifact is:
+
+**`W2-PROJECT-PLAN.md`**
+
+The project plan must:
+
+1. establish the formal W2 source project;
+2. migrate existing research and TTS assets;
+3. verify the publishing account;
+4. select/confirm the video editing toolchain;
+5. lock primary sources and script;
+6. produce narration;
+7. build the asset/provenance package;
+8. create the first video cut;
+9. perform factual, rights, and quality review;
+10. publish by September 24;
+11. define the companion-product implementation sequence;
+12. preserve actual owner effort and incremental spending;
+13. maintain the first-sale validation clock.
+
+No W2 production-expansion work order should be issued until that project plan is approved.
+
+---
+
+# 42. Architecture Principle
+
+> **W2 is a media business, not a content-generation demo. Its architecture preserves the research, assets, rights, voice, production process, and commercial products required to build a durable catalog while keeping the first launch simple enough to complete inside the development window.**
diff --git a/.project/W2-PROJECT-PLAN.md b/.project/W2-PROJECT-PLAN.md
new file mode 100644
index 0000000..77d1329
--- /dev/null
+++ b/.project/W2-PROJECT-PLAN.md
@@ -0,0 +1,1068 @@
+# W2 — Ancient Egypt Media
+## Project Plan
+
+**Project:** W2 — Ancient Egypt Media  
+**Portfolio:** Autonomous Enterprise Portfolio  
+**Classification:** Product / Business  
+**Ecosystem:** Withered Sanctum  
+**Initial Product:** Ancient Egypt historical media channel and associated digital publishing products  
+**Status:** Draft for approval  
+**Owner / Architecture Authority:** Ken Schaefer  
+**Development Lead:** ChatGPT  
+**Implementation Engineer:** Codex where software/automation is required  
+**Related documents:** `W2-REQUIREMENTS.md`, `W2-ARCHITECTURE.md`, `ENTERPRISE-MODEL.md`
+
+---
+
+# Project Value Gates
+
+## Development Window
+
+**Target:** Publish the first complete, public W2 media product by **September 24, 2026**.
+
+The development gate is satisfied only when:
+
+- one original Ancient Egypt video is publicly available;
+- a verifiable public URL exists;
+- required source/provenance records exist;
+- production source is preserved in the formal W2 project;
+- actual owner effort and incremental spending are recorded.
+
+This project is explicitly time-boxed.
+
+If the September 24 publication gate cannot be met, additional development requires explicit review of:
+
+- what remains incomplete;
+- actual owner effort consumed;
+- whether the product scope is too broad;
+- whether production tooling is creating unnecessary delay;
+- whether commercial follow-through still justifies continued investment.
+
+No silent extension of the development window is permitted.
+
+---
+
+## Commercial Validation Window
+
+**Primary KPI:** One genuine arm's-length sale with collected revenue greater than $0 attributable to W2.
+
+**Maximum initial validation window:** 52 weeks from authorized W2 kickoff, subject to shorter portfolio review gates.
+
+Potential qualifying transactions include:
+
+- purchase of a W2 companion publication;
+- purchase of a Field Notes product;
+- purchase of another W2 historical product;
+- another explicitly attributable W2 product or membership.
+
+The following do not satisfy the commercial gate:
+
+- YouTube views;
+- subscribers;
+- likes;
+- comments;
+- watch time;
+- unpaid downloads;
+- advertising eligibility;
+- internal or artificial purchases used only to manufacture validation.
+
+The first publication and first sale are separate gates.
+
+---
+
+# 1. Purpose
+
+This plan translates the approved W2 requirements and architecture into a bounded implementation effort.
+
+W2 will establish the first operating historical-media product in the Withered Sanctum ecosystem.
+
+The initial implementation objective is to:
+
+1. formalize the W2 product repository;
+2. consolidate existing research and production assets;
+3. produce Episode 1;
+4. publish Episode 1 by September 24;
+5. define and prepare the first direct-revenue companion product;
+6. establish a repeatable production process suitable for future episodes.
+
+The project is not intended to build a fully automated media factory during Sprint 0.
+
+---
+
+# 2. Project State at Plan Approval
+
+W2 is not starting from zero.
+
+Existing work includes:
+
+- approved initial business canvas;
+- defined channel/product positioning;
+- defined intended audience;
+- Episode 1 topic;
+- Episode 1 source dossier;
+- Episode 1 claim list;
+- Episode 1 production plan;
+- initial companion-product concept;
+- Qwen3-TTS Forge environment;
+- Pyramid Narrator v1;
+- TTS runbook;
+- initial rights/provenance strategy.
+
+Existing artifacts are valid discovery and pre-production work.
+
+They are not yet considered properly organized product source until they are migrated into the approved W2 project structure.
+
+---
+
+# 3. Definition of Ready
+
+W2 production resumes under the formal project plan only when:
+
+- `W2-REQUIREMENTS.md` approved;
+- `W2-ARCHITECTURE.md` approved;
+- `W2-PROJECT-PLAN.md` approved;
+- Gitea repository established;
+- Forge working copy initialized/cloned;
+- repository opened in VS Code;
+- `.project/` created;
+- approved product structure created;
+- existing W2 assets inventoried;
+- Episode 1 source materials identified;
+- publishing account verification scheduled;
+- production toolchain verification scheduled.
+
+---
+
+# 4. Formal Source Project
+
+Recommended repository:
+
+**Withered-Sanctum-Media**
+
+Target conceptual structure:
+
+```text
+Withered-Sanctum-Media/
+│
+├── .project/
+│   ├── REQUIREMENTS.md
+│   ├── ARCHITECTURE.md
+│   ├── PROJECT-PLAN.md
+│   ├── STATUS.md
+│   ├── DECISIONS/
+│   └── WORK-ORDERS/
+│
+├── research/
+│
+├── episodes/
+│   └── ep01-unas/
+│       ├── research/
+│       ├── script/
+│       ├── narration/
+│       ├── assets/
+│       ├── provenance/
+│       ├── edit/
+│       ├── exports/
+│       └── publication/
+│
+├── voices/
+│   └── pyramid-narrator-v1/
+│
+├── products/
+│   └── field-notes/
+│
+├── templates/
+├── production/
+│   ├── runbooks/
+│   ├── scripts/
+│   └── automation/
+│
+├── docs/
+└── README.md
+```
+
+The final folder structure may be refined during environment setup while preserving the approved architectural boundaries.
+
+---
+
+# 5. Development Roles
+
+## Ken — Owner / Senior Architect / Editor
+
+Responsible for:
+
+- editorial authority;
+- architecture authority;
+- historical judgment;
+- topic approval;
+- script approval;
+- narration approval;
+- visual approval;
+- publication approval;
+- product-pricing approval;
+- operating VS Code and production tools;
+- reviewing Codex output where software/automation is involved;
+- accepting or rejecting completed work.
+
+## ChatGPT — Product / AppDev Manager
+
+Responsible for:
+
+- requirements;
+- architecture;
+- project planning;
+- production work decomposition;
+- research support;
+- editorial support;
+- work orders;
+- acceptance criteria;
+- review against project gates.
+
+## Codex — Implementation Engineer
+
+Used only where software or automation is required.
+
+Responsible for:
+
+- implementation of approved automation/scripts;
+- tests;
+- technical verification;
+- reporting changes.
+
+Codex does not define editorial requirements or change architecture independently.
+
+---
+
+# 6. Development Method
+
+W2 is primarily a media-production project, not a software project.
+
+The project therefore uses a production lifecycle rather than a conventional software-only SDLC.
+
+Core production sequence:
+
+```text
+Topic
+  ↓
+Research
+  ↓
+Claim Review
+  ↓
+Script
+  ↓
+Editorial Approval
+  ↓
+Narration
+  ↓
+Asset Selection
+  ↓
+Rights / Provenance Review
+  ↓
+Video Assembly
+  ↓
+Factual / Quality Review
+  ↓
+Owner Approval
+  ↓
+Publication
+  ↓
+Commercial Follow-through
+```
+
+Where software or automation is introduced, AEP software-development standards apply.
+
+---
+
+# 7. Release 1 Scope
+
+Release 1 includes:
+
+- formal W2 repository;
+- Episode 1 research package;
+- approved Episode 1 script;
+- narration;
+- verified asset/provenance package;
+- completed video edit;
+- public publication;
+- publication metadata;
+- companion-product definition;
+- attributable commercial path;
+- production runbook;
+- recorded owner effort and incremental spending.
+
+Release 1 excludes:
+
+- high-volume production;
+- multiple channels;
+- fully autonomous publishing;
+- custom CMS;
+- custom commerce system;
+- generalized media-agent framework;
+- full automation of script-to-video;
+- YouTube monetization dependency;
+- large-scale Pyramid development.
+
+---
+
+# 8. Phase 0 — Environment and Product Project Setup
+
+**Purpose:** Establish the formal W2 product environment before further production expansion.
+
+### Tasks
+
+1. Create the W2 Gitea repository.
+2. Clone/initialize on Forge.
+3. Open in VS Code.
+4. Create `.project/`.
+5. Add approved:
+   - `REQUIREMENTS.md`
+   - `ARCHITECTURE.md`
+   - `PROJECT-PLAN.md`
+6. Create approved product folder structure.
+7. Verify Git remote connectivity.
+8. Establish `STATUS.md`.
+9. Establish `DECISIONS/`.
+10. Establish `WORK-ORDERS/`.
+
+### Exit Criteria
+
+- repository exists;
+- project opens cleanly in VS Code;
+- project-control documents are present;
+- product folder structure exists;
+- W2 no longer depends on chat history for project state.
+
+---
+
+# 9. Phase 1 — Existing Asset Inventory and Migration
+
+**Purpose:** Consolidate existing W2 work into the formal product repository.
+
+### Assets to inventory
+
+- `EGYPT-MEDIA-CANVAS.md`
+- `EP01-SOURCE-DOSSIER.md`
+- `EP01-CLAIM-LIST.md`
+- `EP01-PRODUCTION-PLAN.md`
+- PMO status material
+- Qwen3-TTS runbook
+- Pyramid Narrator v1 reference audio
+- Pyramid Narrator saved voice profile
+- narrator description and notes
+- any existing episode graphics or production materials
+
+### Classification
+
+Each artifact should be marked:
+
+- `MIGRATE`
+- `REFERENCE`
+- `SUPERSEDE`
+- `EXTERNAL DEPENDENCY`
+
+### Exit Criteria
+
+All critical existing W2 work has an intentional home or reference in the formal project.
+
+---
+
+# 10. Phase 2 — Publishing Account Verification
+
+**Purpose:** Remove account access as a late publication blocker.
+
+### Tasks
+
+1. Verify whether an appropriate Withered Sanctum YouTube channel already exists.
+2. Verify account ownership.
+3. Verify access.
+4. Verify channel identity is appropriate for W2.
+5. If unsuitable or absent, create/prepare the appropriate Withered Sanctum publishing presence.
+6. Record account decision in `.project/DECISIONS/`.
+
+### Exit Criteria
+
+The team knows exactly where Episode 1 will be published and has verified access.
+
+---
+
+# 11. Phase 3 — Production Toolchain Verification
+
+**Purpose:** Confirm the tools required to complete Episode 1 without introducing unnecessary purchases.
+
+### Required tool categories
+
+- research/editorial tools;
+- narration generation;
+- audio review/editing;
+- image/asset preparation;
+- video editing;
+- rendering/export;
+- thumbnail creation.
+
+### Tasks
+
+1. Identify existing available tools.
+2. Verify they can complete Episode 1.
+3. Prefer current tools over new software.
+4. Record any tooling limitation.
+5. Escalate any purchase requirement before spending.
+6. Document the chosen toolchain.
+
+### Exit Criteria
+
+Episode 1 can proceed using a known toolchain within the portfolio spending ceiling.
+
+---
+
+# 12. Phase 4 — Lock Research and Primary Sources
+
+**Purpose:** Establish the final evidentiary basis before script completion.
+
+### Tasks
+
+1. Review the existing source dossier.
+2. Review the claim list.
+3. Lock the claims intended for Episode 1.
+4. Identify primary-text passages.
+5. Verify translation/source for each selected passage.
+6. Remove unsupported claims.
+7. Flag scholarly uncertainty.
+8. Update research artifacts in the formal project.
+
+### Exit Criteria
+
+The script can be written from an approved claim/evidence set.
+
+---
+
+# 13. Phase 5 — Episode 1 Script
+
+**Purpose:** Produce the approved narration text.
+
+### Target
+
+Approximately:
+
+- 1,100–1,300 words;
+- 7–9 minute final video.
+
+### Tasks
+
+1. Draft the episode.
+2. Tie material sections to approved claims.
+3. Review tone and pacing.
+4. Remove unsupported statements.
+5. Review transitions.
+6. Review quoted material.
+7. Verify copyright-safe use of modern translations.
+8. Conduct editorial review.
+9. Produce approved narration script.
+
+### Exit Criteria
+
+Ken approves the narration script.
+
+---
+
+# 14. Phase 6 — Narration Production
+
+**Purpose:** Produce final narration suitable for edit.
+
+### Primary candidate
+
+**Pyramid Narrator v1**
+
+### Tasks
+
+1. Confirm whether Episode 1 will use Pyramid Narrator v1.
+2. Segment script into manageable narration units.
+3. Maintain pronunciation notes.
+4. Generate narration segments.
+5. Review every segment.
+6. Regenerate weak or incorrect delivery.
+7. Correct Egyptian-name pronunciation issues.
+8. Assemble narration master.
+9. Preserve generation assets and voice references.
+
+### Exit Criteria
+
+A complete approved narration master exists.
+
+---
+
+# 15. Phase 7 — Visual Asset Acquisition and Provenance
+
+**Purpose:** Assemble the visual package without creating a late rights problem.
+
+### Potential asset sources
+
+- Wikimedia Commons;
+- museum open-access collections;
+- public-domain historical sources;
+- original maps;
+- original diagrams;
+- original typography/graphics.
+
+### Tasks
+
+1. Build scene/visual requirements from the script.
+2. Identify candidate assets.
+3. Verify source.
+4. Verify creator where known.
+5. Verify license/public-domain status.
+6. Confirm commercial use.
+7. Record attribution.
+8. Record modifications.
+9. Store or reference the asset.
+10. Build the Episode 1 asset register.
+
+### Exit Criteria
+
+All material production assets have known rights/provenance status before final publication.
+
+---
+
+# 16. Phase 8 — Video Assembly
+
+**Purpose:** Produce the first complete video cut.
+
+### Tasks
+
+1. Create edit project.
+2. Import narration.
+3. Place visual assets.
+4. Add maps/diagrams/typography.
+5. Add titles.
+6. Add transitions where appropriate.
+7. Add captions/subtitles where appropriate.
+8. Add score/music only if rights and production needs justify it.
+9. Render first cut.
+
+### Exit Criteria
+
+A complete first cut exists.
+
+---
+
+# 17. Phase 9 — Factual, Rights, and Quality Review
+
+**Purpose:** Prevent publication defects.
+
+### Historical QA
+
+- claims remain supported;
+- uncertainty is represented accurately;
+- no misleading additions entered during edit.
+
+### Rights QA
+
+- visual assets checked;
+- attribution complete;
+- commercial-use rights verified;
+- synthetic content documented if used.
+
+### Narration QA
+
+- pronunciation;
+- intelligibility;
+- pacing;
+- delivery consistency.
+
+### Production QA
+
+- audio balance;
+- readability;
+- image quality;
+- transitions;
+- captions;
+- render integrity.
+
+### Exit Criteria
+
+All publication-blocking defects are resolved or explicitly waived by the owner.
+
+---
+
+# 18. Phase 10 — Publication Package
+
+**Purpose:** Prepare the video as an actual market-facing product.
+
+### Required publication artifacts
+
+- final title;
+- description;
+- thumbnail;
+- attribution;
+- disclosures;
+- tags/metadata where appropriate;
+- final export;
+- public channel destination.
+
+### Tasks
+
+1. Prepare title.
+2. Prepare description.
+3. Prepare thumbnail.
+4. Add source/attribution information.
+5. Add disclosure if required.
+6. Upload.
+7. Complete final owner review.
+8. Publish.
+9. Record public URL.
+10. Update project status.
+
+### Exit Criteria
+
+Episode 1 is publicly available.
+
+**Deadline:** September 24, 2026.
+
+---
+
+# 19. Phase 11 — Companion Product Definition
+
+**Purpose:** Create the first direct commercial path.
+
+### Initial product
+
+**Withered Sanctum Field Notes #1 — The Pyramid Texts of Unas**
+
+### Working scope
+
+- approximately 10–12 pages;
+- chronology;
+- glossary;
+- original diagram;
+- key episode claims;
+- debated/uncertain issues;
+- annotated sources/further reading.
+
+### Tasks
+
+1. Confirm product scope.
+2. Confirm working price.
+3. Determine source format.
+4. Determine final delivery format.
+5. Determine payment path.
+6. Determine delivery path.
+7. Define attributable sales evidence.
+8. Record fulfillment/refund obligations.
+
+### Exit Criteria
+
+The companion product has an implementation-ready definition and an identified path to sale.
+
+The product does not need to be fully released before the September 24 video publication unless the schedule allows.
+
+---
+
+# 20. Phase 12 — Commercial Launch
+
+**Purpose:** Begin the first-sale validation clock in practice.
+
+### Tasks
+
+1. Complete companion product.
+2. Configure approved payment/delivery path.
+3. Test purchase flow.
+4. Publish product.
+5. Link from relevant W2 surfaces.
+6. Record sales evidence.
+7. Track first qualifying collected transaction.
+
+### Exit Criteria
+
+W2 has a live, attributable path to a qualifying sale.
+
+Commercial validation remains open until an actual sale occurs.
+
+---
+
+# 21. Phase 13 — Production Runbook and Repeatability
+
+**Purpose:** Ensure Episode 1 produces a repeatable media-production process.
+
+### Runbook should document
+
+- topic intake;
+- research workflow;
+- claim review;
+- script process;
+- narration;
+- pronunciation;
+- asset sourcing;
+- provenance;
+- edit;
+- render;
+- QA;
+- publication;
+- product follow-through.
+
+### Exit Criteria
+
+Episode 2 can begin using project artifacts rather than reconstructing the process from memory or chat history.
+
+---
+
+# 22. Milestone Schedule
+
+## M0 — Project Ready
+
+**Gate:** Formal repository, `.project/`, structure, Git/Gitea, and status file established.
+
+## M1 — Existing Assets Consolidated
+
+**Gate:** Current research, production documents, and narrator assets are intentionally migrated or referenced.
+
+## M2 — Publication Path Ready
+
+**Gate:** YouTube account/channel and production toolchain verified.
+
+## M3 — Research Locked
+
+**Gate:** Episode 1 claims and source basis approved.
+
+## M4 — Script Approved
+
+**Gate:** Narration script complete and owner-approved.
+
+## M5 — Narration Complete
+
+**Gate:** Approved narration master exists.
+
+## M6 — Asset Package Complete
+
+**Gate:** Required visual assets and provenance are ready.
+
+## M7 — First Cut
+
+**Gate:** Complete edit exists.
+
+## M8 — Release Candidate
+
+**Gate:** Historical, rights, narration, and production QA passed.
+
+## M9 — Episode 1 Published
+
+**Deadline:** **September 24, 2026**
+
+## M10 — Commercial Path Live
+
+**Gate:** Companion product is purchasable or ready for immediate launch.
+
+## M11 — First Sale
+
+**Gate:** First genuine attributable payment > $0.
+
+---
+
+# 23. Critical Path
+
+The critical path to the September 24 publication is:
+
+```text
+Repository / project setup
+        ↓
+Research lock
+        ↓
+Script approval
+        ↓
+Narration
+        ↓
+Visual asset package
+        ↓
+Video assembly
+        ↓
+QA
+        ↓
+Publication
+```
+
+The following should not be allowed to delay publication unless they become actual dependencies:
+
+- generalized TTS service extraction;
+- Udio-alternative research;
+- custom publishing automation;
+- custom website;
+- custom CMS;
+- advanced media automation;
+- elaborate analytics;
+- companion-product perfection.
+
+---
+
+# 24. Time and Owner-Effort Tracking
+
+Owner time must be recorded beginning with approval of this plan.
+
+Track human time separately for:
+
+- project/environment setup;
+- research review;
+- script writing/editing;
+- narration review;
+- asset selection;
+- rights/provenance;
+- video editing;
+- QA;
+- publication;
+- companion-product creation.
+
+Machine runtime remains separate.
+
+At the September 24 development gate, report:
+
+- total owner hours;
+- incremental spending;
+- elapsed calendar time;
+- major production bottlenecks;
+- degree of AI leverage;
+- release status.
+
+This is a core AEP measurement.
+
+---
+
+# 25. Incremental Spending
+
+W2 shares the portfolio-wide Sprint 0 incremental-spending ceiling.
+
+Current known W2 incremental spending:
+
+**$0**
+
+Use existing:
+
+- Forge;
+- local GPU;
+- Qwen3-TTS;
+- editing software;
+- existing AI access;
+- open/public-domain assets;
+- existing publishing accounts where appropriate.
+
+No new paid subscription, music license, stock library, software package, or platform should be introduced without explicit approval.
+
+---
+
+# 26. Work-Order Strategy
+
+W2 should use work orders only where formal bounded execution helps.
+
+Not all media-production activity requires Codex or a software work order.
+
+Work orders are appropriate for:
+
+- repository/environment setup;
+- automation;
+- file organization;
+- repeatable processing scripts;
+- technical production tooling.
+
+Editorial and creative work should remain governed by project phases and acceptance gates.
+
+---
+
+# 27. Initial Work-Order Sequence
+
+## W2-WO-001 — Formal Product Project Setup
+
+Create:
+
+- Gitea repository;
+- Forge working copy;
+- VS Code project;
+- `.project/`;
+- approved folder structure;
+- Git verification.
+
+No production automation beyond setup.
+
+---
+
+## W2-WO-002 — Existing Asset Migration
+
+Move/reference:
+
+- research artifacts;
+- narrator assets;
+- runbooks;
+- production-plan materials.
+
+Produce inventory.
+
+---
+
+## W2-WO-003 — Production Tooling Support
+
+Only if required.
+
+Potential scope:
+
+- narration-generation helper;
+- file naming;
+- audio segmentation;
+- caption generation;
+- asset inventory generation.
+
+No generalized media platform.
+
+---
+
+# 28. Project Status Reporting
+
+`.project/STATUS.md` should include:
+
+```text
+Current phase:
+Current episode:
+Development deadline:
+Commercial validation state:
+Owner hours consumed:
+Incremental spend:
+Research status:
+Script status:
+Narration status:
+Asset/provenance status:
+Edit status:
+Publication status:
+Companion product status:
+First-sale status:
+Completed:
+In progress:
+Blocked:
+Next authorized work:
+Latest evidence:
+```
+
+The PMO should receive concise summaries based on this record.
+
+---
+
+# 29. Definition of Done — Release 1
+
+W2 Release 1 is done when:
+
+1. the formal W2 project exists in Gitea;
+2. the project is operational on Forge/VS Code;
+3. `.project/` contains approved control documents;
+4. existing W2 work is migrated/referenced;
+5. Episode 1 research is preserved;
+6. claim list is approved;
+7. script is approved;
+8. narration is complete and approved;
+9. material visual assets have provenance;
+10. edit source is preserved;
+11. final video is complete;
+12. factual/rights/quality QA is complete;
+13. Episode 1 is publicly published;
+14. public URL is recorded;
+15. actual owner time is recorded;
+16. incremental spending is recorded;
+17. companion product is defined;
+18. commercial path is identified;
+19. Ken accepts Release 1.
+
+---
+
+# 30. Stop / Review Conditions
+
+Stop or return to project review if:
+
+- September 24 can no longer reasonably be met;
+- production scope expands beyond one Episode 1 launch;
+- custom application development begins without a demonstrated requirement;
+- generalized production infrastructure begins delaying the product;
+- a required purchase would exceed approved portfolio spending;
+- rights cannot be established for key assets;
+- the selected publishing account cannot be used;
+- historical accuracy cannot be brought to an acceptable level;
+- narration quality cannot be made acceptable;
+- major assets exist only in untracked local locations.
+
+---
+
+# 31. Deferred Backlog
+
+Explicitly deferred:
+
+- automated publication;
+- scheduled content generation;
+- recurring autonomous channel operation;
+- generalized TTS Shared Service;
+- local music-generation platform;
+- automated script-to-video pipeline;
+- custom CMS;
+- custom analytics dashboard;
+- sponsorship automation;
+- YouTube monetization work;
+- additional history channels;
+- large Pyramid/game development;
+- Project Thoth integration.
+
+These require later prioritization and must not silently enter the Release 1 critical path.
+
+---
+
+# 32. Commercial Validation Tracking
+
+After launch, W2 remains in commercial validation until the first qualifying sale.
+
+Track:
+
+- product launch date;
+- payment path;
+- product price;
+- collected receipts;
+- refunds;
+- fees;
+- fulfillment obligations;
+- transaction attribution.
+
+At the first valid sale:
+
+```text
+FIRST SALE VALIDATED
+```
+
+W2 then returns to the PMO for a new investment decision.
+
+A first sale does not automatically authorize scaling.
+
+---
+
+# 33. Post-Launch Review
+
+After Episode 1 publication, perform a short review covering:
+
+- actual production hours;
+- incremental cash cost;
+- research burden;
+- narration burden;
+- asset/provenance burden;
+- editing burden;
+- tooling problems;
+- reusable templates;
+- automation opportunities;
+- whether Episode 2 should proceed;
+- whether any production capability has now demonstrated enough reuse to consider Shared Service extraction.
+
+---
+
+# 34. Release Decision
+
+At the September 24 development gate, record one of:
+
+- `ACCEPT`
+- `ACCEPT WITH DEFERRED ITEMS`
+- `REWORK WITHIN APPROVED WINDOW`
+- `EXTEND AFTER REVIEW`
+- `STOP / REDESIGN`
+
+The commercial-validation gate remains separately open after development acceptance unless a qualifying sale has already occurred.
+
+---
+
+# 35. Project Principle
+
+> **Launch the media business, not the machinery around it. Preserve the research, source assets, voice, rights, and production process required to make the product durable; publish inside the time box; then ask the market to pay.**
diff --git a/.project/W2-REQUIREMENTS.md b/.project/W2-REQUIREMENTS.md
new file mode 100644
index 0000000..bc3bbdd
--- /dev/null
+++ b/.project/W2-REQUIREMENTS.md
@@ -0,0 +1,882 @@
+# W2 — Ancient Egypt Media
+## Requirements
+
+**Project:** W2 — Ancient Egypt Media  
+**Portfolio:** Autonomous Enterprise Portfolio  
+**Classification:** Product / Business  
+**Ecosystem:** Withered Sanctum  
+**Initial Product:** Ancient Egypt historical media channel and associated digital publishing products  
+**Status:** Draft for approval  
+**Owner:** Ken Schaefer  
+**Related portfolio documents:** `VISION.md`, `PORTFOLIO.md`, `PROJECT-PLAN.md`, `PROJECT-CHARTER.md`, `ARCHITECTURE.md`, `ENTERPRISE-MODEL.md`
+
+---
+
+# Project Value Gates
+
+## Development Window
+
+**Target:** Make the first real, publicly available W2 media product available by **September 24, 2026**.
+
+The first development gate is satisfied only when an original Ancient Egypt video has been published and can be viewed through a public URL.
+
+The development window measures whether AI-assisted research, writing, narration, media production, and publishing can materially compress the time required to launch a real media business.
+
+The detailed project plan will define:
+
+- production phases;
+- required assets;
+- human effort;
+- implementation sequence;
+- publication workflow;
+- companion-product timing;
+- technical setup;
+- acceptance criteria.
+
+If the September 24 publication gate cannot be met, the project must be reviewed before further development investment is authorized.
+
+No silent extension of the development window is permitted.
+
+---
+
+## Commercial Validation Window
+
+**Primary KPI:** One genuine arm's-length sale with collected revenue greater than $0 attributable to W2.
+
+**Maximum initial validation window:** 52 weeks from the authorized W2 kickoff date, subject to shorter portfolio review gates.
+
+The first sale may come from a W2 product or revenue mechanism such as:
+
+- a digital companion publication;
+- a paid historical guide;
+- a Pyramid-adjacent publication;
+- a membership;
+- a direct-support product;
+- another clearly attributable W2 commercial mechanism.
+
+YouTube views, subscribers, watch time, likes, comments, or advertising eligibility do **not** satisfy the first-sale KPI.
+
+The initial publication milestone and the commercial validation milestone are separate.
+
+A published video proves launch capability.
+
+A collected sale proves market willingness to pay.
+
+---
+
+# 1. Business Problem
+
+AI can make media production dramatically faster, but the ability to generate content is not itself a business.
+
+The commercial challenge is to determine whether AI-assisted production can create a distinctive, accurate, repeatable historical-media product that:
+
+- attracts an audience;
+- can be produced efficiently;
+- develops reusable intellectual property;
+- creates direct commercial opportunities;
+- can operate as an identifiable media business.
+
+Traditional documentary and historical-media production can require substantial time and cost for:
+
+- research;
+- writing;
+- narration;
+- visual sourcing;
+- rights review;
+- editing;
+- publishing;
+- companion-product creation.
+
+W2 exists to test whether the Autonomous Enterprise Portfolio can compress this process while maintaining:
+
+- historical rigor;
+- editorial quality;
+- provenance;
+- commercial usability;
+- a distinctive creative identity.
+
+---
+
+# 2. Product / Business Purpose
+
+W2 is not a shared production service.
+
+W2 is a **Product / Business** within the Withered Sanctum ecosystem.
+
+The project is intended to create a historical media company whose products may include:
+
+- original video essays;
+- historical documentary-style media;
+- short digital publications;
+- source guides;
+- annotated research products;
+- educational or reference materials;
+- Pyramid-adjacent products where commercially appropriate.
+
+The business should be capable of developing its own:
+
+- audience;
+- identity;
+- catalog;
+- intellectual property;
+- production workflow;
+- revenue streams;
+- asset inventory.
+
+Shared capabilities may later be extracted from W2 only when reuse across multiple products is demonstrated.
+
+---
+
+# 3. Intended Audience
+
+The initial audience is historically curious adults interested in:
+
+- Ancient Egypt;
+- archaeology;
+- Egyptian religion and ritual;
+- ancient texts;
+- mythology;
+- historical storytelling;
+- source-based historical interpretation.
+
+The product should appeal to viewers who want more depth than generic entertainment content but do not require an academic lecture format.
+
+The intended tone is:
+
+- informed;
+- atmospheric;
+- accessible;
+- source-based;
+- immersive;
+- skeptical of unsupported sensational claims.
+
+---
+
+# 4. Product Positioning
+
+W2 should produce:
+
+> **Source-based historical essays presented with an atmospheric Withered Sanctum style.**
+
+The product must avoid dependence on:
+
+- pseudoarchaeology;
+- sensational unsupported claims;
+- manufactured controversy;
+- misleading AI reconstruction;
+- fabricated historical certainty.
+
+The differentiator should come from the combination of:
+
+- good research;
+- strong storytelling;
+- distinctive narration and presentation;
+- reusable historical source work;
+- product adjacency with Withered Sanctum and Pyramid.
+
+---
+
+# 5. Initial Product Scope
+
+The initial W2 release includes two related products:
+
+1. **An original Ancient Egypt video**
+2. **A directly purchasable companion product**
+
+The video satisfies the initial development gate.
+
+The companion product establishes a direct path to commercial validation.
+
+---
+
+# 6. Initial Video Requirement
+
+## 6.1 Episode 1
+
+The first episode is currently defined as:
+
+**Working title:**  
+**Inside the Pyramid of Unas: Egypt's First Pyramid Texts and the Road to the Stars**
+
+The episode will examine:
+
+- Unas and the late Fifth Dynasty;
+- the Pyramid of Unas at Saqqara;
+- the earliest currently known Pyramid Text inscriptions in a royal pyramid;
+- ritual and funerary context;
+- transformation of the deceased king;
+- celestial imagery;
+- references to the imperishable stars;
+- later influence on Egyptian funerary traditions.
+
+---
+
+## 6.2 Format
+
+Initial production target:
+
+- approximately 7–9 minutes;
+- approximately 1,100–1,300 narrated words;
+- historical essay / documentary format;
+- human editorial approval before publication;
+- visual support from historical, archaeological, textual, cartographic, and graphic materials.
+
+The final runtime may vary where editorial quality requires it.
+
+---
+
+# 7. Editorial Requirements
+
+W2 must prioritize historical accuracy over speed where the two conflict.
+
+The episode must:
+
+- distinguish established evidence from interpretation;
+- identify uncertainty where relevant;
+- avoid presenting scholarly disagreement as settled fact;
+- avoid unsupported causal claims;
+- avoid fabricated quotations;
+- avoid fabricated archaeological evidence;
+- avoid attributing claims to sources that do not support them.
+
+Potentially misleading claims should be explicitly excluded during research and review.
+
+Examples already identified for Episode 1 include avoiding claims that:
+
+- Unas personally invented the Pyramid Texts;
+- the Pyramid Texts can unqualifiedly be called the oldest religious writing in the world;
+- the "imperishable stars" can confidently be identified as Polaris;
+- unrelated Great Pyramid shaft theories belong in the episode.
+
+---
+
+# 8. Research Requirements
+
+Every episode must have a research package sufficient to support editorial review.
+
+The initial research package must include:
+
+- source dossier;
+- claim list;
+- source references;
+- identification of debated claims;
+- identification of claims excluded for insufficient support;
+- notes on primary versus secondary sources where relevant.
+
+The research process should favor:
+
+- authoritative archaeological sources;
+- reputable academic or museum sources;
+- high-quality translations;
+- open-access primary or near-primary materials where practical.
+
+The project must not rely solely on AI-generated summaries as evidence.
+
+---
+
+# 9. Primary Text Requirements
+
+When quoting or paraphrasing ancient texts or modern translations:
+
+- use authoritative source material;
+- preserve attribution;
+- respect copyright restrictions on modern translations;
+- avoid excessive quotation;
+- distinguish translation from interpretation.
+
+Primary-text passages used in Episode 1 must be locked and reviewed before final publication.
+
+---
+
+# 10. Narration Requirements
+
+Narration is a core W2 product asset.
+
+The product may use:
+
+- human narration;
+- synthetic narration;
+- a combination where appropriate.
+
+The current production candidate is:
+
+**Pyramid Narrator v1**
+
+This voice is an existing W2 / Withered Sanctum product asset created using Qwen3-TTS.
+
+The intended voice character is:
+
+> A learned elder, archivist, scholar, court historian, or well-traveled merchant from within the world being described, speaking as though he belongs to the land and knows its history personally.
+
+The voice should support:
+
+- clarity;
+- intelligibility;
+- consistency;
+- atmosphere;
+- long-form listening.
+
+Synthetic narration must receive human review.
+
+Pronunciation problems, especially Egyptian names and transliterations, must be corrected before publication.
+
+---
+
+# 11. Voice Asset Governance
+
+Narrator voice assets must be versioned.
+
+Changes to a canonical narrator should create a new version rather than silently modifying an existing one.
+
+Relevant assets may include:
+
+- reference WAV;
+- saved voice profile;
+- creative description;
+- generation notes;
+- pronunciation guidance;
+- version history;
+- model/version information.
+
+The initial canonical asset is:
+
+**Pyramid Narrator v1**
+
+---
+
+# 12. Visual Requirements
+
+The visual strategy should favor authentic or clearly identified source materials.
+
+Potential sources include:
+
+- Wikimedia Commons;
+- museum open-access collections;
+- archaeological site imagery;
+- maps;
+- diagrams;
+- public-domain historical works;
+- original graphics;
+- original typography.
+
+Photorealistic synthetic historical reconstruction is not required for Release 1.
+
+If synthetic reconstruction is used:
+
+- it must not be presented as archaeological evidence;
+- it must be reviewed for factual plausibility;
+- relevant disclosure requirements must be followed.
+
+---
+
+# 13. Asset Provenance and Rights
+
+Every production asset must have enough information to establish lawful commercial use.
+
+The asset record should include where applicable:
+
+- asset identifier;
+- source;
+- creator;
+- license;
+- public-domain status;
+- commercial-use permission;
+- attribution requirement;
+- modification requirement;
+- local project location;
+- episode usage.
+
+Hosting on an open platform does not itself establish commercial-use rights.
+
+Rights must be verified at the individual asset level.
+
+---
+
+# 14. Production Requirements
+
+The production workflow must be reproducible.
+
+The initial workflow should support:
+
+```text
+Topic
+  ↓
+Research dossier
+  ↓
+Claim list
+  ↓
+Script
+  ↓
+Editorial / factual review
+  ↓
+Narration
+  ↓
+Asset selection
+  ↓
+Rights / provenance review
+  ↓
+Video assembly
+  ↓
+Quality review
+  ↓
+Owner approval
+  ↓
+Publication
+```
+
+The workflow may be manual, AI-assisted, or automated in individual stages.
+
+Automation is not itself a success criterion.
+
+The objective is reliable product production.
+
+---
+
+# 15. Human Authority
+
+The following remain human-controlled in Release 1:
+
+- topic approval;
+- historical interpretation;
+- final script approval;
+- final narration approval;
+- final visual approval;
+- rights exceptions;
+- product pricing;
+- public publication;
+- customer commitments;
+- commercial launch decisions.
+
+AI may assist with:
+
+- research;
+- drafting;
+- editing;
+- source organization;
+- narration generation;
+- graphic generation;
+- production assistance;
+- metadata;
+- publication preparation.
+
+---
+
+# 16. Initial Publishing Destination
+
+The intended initial publishing destination is a dedicated or appropriately owned **Withered Sanctum YouTube presence**.
+
+Before publication, the project must verify:
+
+- account ownership;
+- account access;
+- appropriate channel identity;
+- suitability for the W2 product.
+
+If an existing channel is unsuitable, a dedicated Withered Sanctum publishing channel may be created.
+
+No assumption should be made that the correct publishing account already exists until verified.
+
+---
+
+# 17. Companion Product Requirement
+
+The first commercial mechanism should not depend on YouTube advertising eligibility.
+
+The current proposed companion product is:
+
+**Withered Sanctum Field Notes #1 — The Pyramid Texts of Unas**
+
+Working content may include:
+
+- approximately 10–12 pages;
+- original pyramid / Pyramid Text diagram;
+- historical chronology;
+- glossary;
+- key claims from the episode;
+- "what we know / what remains debated";
+- annotated bibliography or further reading.
+
+The companion product should reuse legitimate research and production work from Episode 1 rather than create an unrelated product.
+
+---
+
+# 18. Initial Pricing Hypothesis
+
+Working test price:
+
+**Approximately $5**
+
+The final price must be explicitly approved before release.
+
+The pricing hypothesis is intended to create a low-friction first-sale test.
+
+The commercial test is not intended to establish long-term optimal pricing.
+
+---
+
+# 19. Payment and Delivery Requirements
+
+Before the companion product can launch, W2 must establish:
+
+- payment mechanism;
+- delivery mechanism;
+- attributable transaction record;
+- refund/fulfillment obligations;
+- product version;
+- purchase confirmation.
+
+Where practical, existing approved Fractional Insight / Withered Sanctum commercial infrastructure should be reused.
+
+A qualifying sale must be attributable specifically to W2.
+
+---
+
+# 20. Human User Interface / Customer Experience
+
+W2 is a product business rather than an internal agent.
+
+Its primary human interface is therefore the customer-facing product experience.
+
+Release 1 must provide:
+
+- accessible public video;
+- clear title and description;
+- professional thumbnail or presentation;
+- appropriate source / attribution information;
+- a clear path to the companion product when available.
+
+Internal production tools may use existing interfaces and do not require a custom W2 application unless a demonstrated production need justifies one.
+
+---
+
+# 21. Product Source Project
+
+W2 must have its own formal source project because W2 is an independent Product / Business.
+
+The source project represents the entire body of work, not merely software code.
+
+Working project/repository identity:
+
+**Withered Sanctum Media**
+
+Conceptual project contents may include:
+
+```text
+Withered-Sanctum-Media/
+│
+├── .project/
+│   ├── REQUIREMENTS.md
+│   ├── ARCHITECTURE.md
+│   ├── PROJECT-PLAN.md
+│   ├── STATUS.md
+│   ├── DECISIONS/
+│   └── WORK-ORDERS/
+│
+├── research/
+├── scripts/
+├── narration/
+├── audio/
+├── images/
+├── video/
+├── products/
+├── production/
+├── provenance/
+└── README.md
+```
+
+The exact structure will be finalized in `W2-ARCHITECTURE.md`.
+
+---
+
+# 22. Source / Work Product Definition
+
+For W2, "source" includes all materials required to reproduce, maintain, continue, or transfer the media product.
+
+This may include:
+
+- research dossiers;
+- claim lists;
+- scripts;
+- outlines;
+- narration text;
+- narrator voice assets;
+- generated narration;
+- music or score source;
+- graphics;
+- maps;
+- diagrams;
+- image assets;
+- editing project files;
+- product source files;
+- templates;
+- production automation;
+- rights/provenance records;
+- publication metadata;
+- runbooks.
+
+Large binary files may live outside Git if required, but their location and relationship to the project must be documented.
+
+---
+
+# 23. Shared-Service Extraction
+
+W2 may produce reusable capabilities.
+
+Examples:
+
+- generic TTS workflow;
+- media asset processing;
+- caption generation;
+- rendering automation.
+
+These remain W2-local until reuse across another Product / Business creates a legitimate shared-service requirement.
+
+The specific **Pyramid Narrator** voice remains a Withered Sanctum product asset even if the generic TTS capability later becomes a Shared Service.
+
+---
+
+# 24. Initial Scope
+
+Release 1 includes:
+
+- one original Ancient Egypt episode;
+- verified publishing account;
+- source dossier;
+- claim list;
+- completed script;
+- narration;
+- asset provenance;
+- visual assembly;
+- final video;
+- publication;
+- production records;
+- companion-product definition;
+- attributable commercial path.
+
+---
+
+# 25. Explicitly Out of Scope for Release 1
+
+Release 1 does not require:
+
+- high-volume channel production;
+- daily publishing;
+- automated channel operation;
+- autonomous publishing;
+- YouTube advertising eligibility;
+- sponsorship acquisition;
+- membership platform;
+- elaborate website;
+- large Pyramid game development;
+- video-game development;
+- multiple simultaneous historical channels;
+- fully automated media factory;
+- generalized shared-production infrastructure.
+
+These may become future work only after the initial product demonstrates value.
+
+---
+
+# 26. Success Criteria
+
+W2 Release 1 succeeds when all development criteria below are met.
+
+## Product Launch
+
+- One original Ancient Egypt video is publicly published.
+- The video has a verifiable public URL.
+- Publication occurs with owner approval.
+
+## Research and Editorial Quality
+
+- Source dossier exists.
+- Claim list exists.
+- Material historical claims are supported.
+- Important uncertainties are identified.
+- Unsupported or misleading claims have been removed.
+- Primary-text usage has been reviewed.
+
+## Narration
+
+- Narration is complete.
+- Narration has been reviewed by the owner.
+- Pronunciation and delivery are acceptable for publication.
+
+## Visual Production
+
+- Required visual assets are present.
+- Material assets have provenance records.
+- Commercial-use rights have been reviewed.
+- Synthetic reconstruction, if used, is appropriately identified.
+
+## Reproducibility
+
+- Script and production source are preserved.
+- Narration assets are preserved.
+- Relevant production steps are documented.
+- Another production session can begin from the project artifacts without reconstructing the process from chat history.
+
+## Commercial Readiness
+
+- Initial companion product is sufficiently defined to implement.
+- A proposed price exists.
+- A payment/delivery path is identified or explicitly recorded as the next dependency.
+- Sales can be attributed to W2.
+
+## Measurement
+
+- Actual incremental cash spending is recorded.
+- Actual owner effort is recorded.
+- Publication date is recorded.
+- Significant production problems are recorded.
+
+---
+
+# 27. Commercial Success Criteria
+
+The initial commercial KPI is separate from Release 1 development acceptance.
+
+W2 achieves initial commercial validation when:
+
+> **At least one genuine arm's-length customer pays more than $0 for a W2-attributable product or service within the approved commercial validation window.**
+
+Examples that may qualify:
+
+- purchase of Field Notes;
+- purchase of another W2 historical publication;
+- direct paid W2 membership or product;
+- another explicitly attributable W2 transaction.
+
+The following do not qualify:
+
+- views;
+- subscribers;
+- likes;
+- unpaid downloads;
+- email signups;
+- pledges not collected;
+- promotional exchanges;
+- internal purchases designed solely to manufacture validation.
+
+---
+
+# 28. Secondary Business Metrics
+
+W2 should also track diagnostic metrics such as:
+
+- publication frequency;
+- production time per episode;
+- owner hours per episode;
+- incremental cash cost;
+- views;
+- watch time;
+- retention;
+- subscribers;
+- click-through to commercial products;
+- product page visits;
+- conversion;
+- repeat customers;
+- attributable revenue.
+
+These metrics inform investment decisions but do not replace the first-sale KPI.
+
+---
+
+# 29. Measurement Requirements
+
+At all times, the project should make it possible to determine:
+
+- current production phase;
+- development deadline;
+- work completed;
+- work remaining;
+- current blockers;
+- owner hours consumed;
+- incremental spending;
+- publication status;
+- commercial product status;
+- first-sale status;
+- evidence supporting continuation.
+
+The project must not require reconstruction from conversation history to determine current state.
+
+---
+
+# 30. Maintainability Requirements
+
+W2 must be maintainable as an ongoing media product.
+
+Project organization should:
+
+- use human-readable folder names;
+- separate project management from product assets;
+- preserve provenance;
+- version canonical assets;
+- avoid undocumented one-off production steps;
+- keep reusable templates identifiable;
+- document external dependencies;
+- preserve enough source material to reproduce or modify products later.
+
+Where software or automation is introduced, AEP software-development standards apply.
+
+---
+
+# 31. Existing W2 Work
+
+Work completed before approval of these requirements is considered legitimate discovery and pre-production work.
+
+Existing artifacts include:
+
+- business canvas;
+- Episode 1 source dossier;
+- Episode 1 claim list;
+- Episode 1 production plan;
+- PMO status report;
+- Qwen3-TTS local environment;
+- Pyramid Narrator v1;
+- TTS production runbook.
+
+These artifacts may be incorporated into the formal W2 source project after architecture approval.
+
+They do not by themselves define the final repository structure or production architecture.
+
+---
+
+# 32. Architecture Decisions Required
+
+`W2-ARCHITECTURE.md` must determine:
+
+- formal product-project name;
+- Gitea repository identity;
+- Forge / VS Code project structure;
+- `.project/` organization;
+- research organization;
+- episode organization;
+- provenance/rights model;
+- asset-storage strategy;
+- handling of large binaries;
+- narration architecture;
+- TTS asset placement;
+- video editing/rendering workflow;
+- production tooling;
+- publishing workflow;
+- companion-product source organization;
+- backup / recovery expectations;
+- which existing W2 artifacts migrate into the formal project;
+- whether any production capability should remain W2-local or become a Shared Service.
+
+---
+
+# 33. Next Project Gate
+
+Upon approval of this document, the next required artifact is:
+
+**`W2-ARCHITECTURE.md`**
+
+No additional W2 production-expansion work order should be issued until the architecture and detailed project plan define the product project, production environment, source structure, and remaining work required for the September 24 launch gate.
+
+---
+
+# 34. Project Principle
+
+> **W2 is not an experiment in generating content. It is an experiment in launching a real media business quickly: produce something worth watching, preserve the work required to reproduce it, offer something worth buying, and let the market determine whether the product has commercial value.**
diff --git a/.project/decisions/W2-NARRATOR-CONTENT-MODES-DECISION.md b/.project/decisions/W2-NARRATOR-CONTENT-MODES-DECISION.md
new file mode 100644
index 0000000..d91a3d6
--- /dev/null
+++ b/.project/decisions/W2-NARRATOR-CONTENT-MODES-DECISION.md
@@ -0,0 +1,305 @@
+# W2 Decision Record — Narrator Role, Content Modes, and AI-Native Production
+
+**Project:** W2 — Ancient Egypt Media  
+**Portfolio:** Autonomous Enterprise Portfolio  
+**Location:** `.project/DECISIONS/`  
+**Status:** Approved direction  
+**Date:** September 18, 2026  
+**Owner:** Ken Schaefer
+
+---
+
+# 1. Decision Summary
+
+W2 will remain an **AI-native media product**, and the recurring narrator will be treated as an **in-world Pyramid TTRPG character**, not merely as a conventional documentary narrator.
+
+Episode 1 will remain historically accurate and source-bounded.
+
+The narrator's character role changes the **perspective and presentation**, but it does not relax the factual requirements of historical-mode episodes.
+
+W2 may later produce content in multiple clearly identified narrative modes:
+
+- Historical
+- Speculative / Fringe
+- Pyramid Fiction
+
+The audience must be able to distinguish which mode is being used.
+
+---
+
+# 2. AI-Native Production Principle
+
+W2 should use AI wherever it improves:
+
+- creative quality;
+- production speed;
+- production cost;
+- consistency;
+- experimentation;
+- commercial potential.
+
+Potential AI-assisted or AI-generated production areas include:
+
+- research assistance;
+- drafting;
+- narration;
+- imagery;
+- animation;
+- music;
+- editing;
+- metadata;
+- production automation.
+
+Platform disclosure requirements are treated as **compliance obligations**, not as editorial filters.
+
+The project should not avoid otherwise desirable AI-created content merely to avoid an AI disclosure label.
+
+Creative and commercial decisions should instead be driven by:
+
+- audience value;
+- originality;
+- quality;
+- product identity;
+- factual intent;
+- production efficiency.
+
+W2 should avoid generic, repetitive, low-value mass production regardless of whether the content is produced by AI or humans.
+
+---
+
+# 3. Narrator Role
+
+The W2 narrator is not simply an external documentary presenter.
+
+The narrator is conceived as a recurring **Pyramid-universe priest-character** who is familiar with:
+
+- funerary rites;
+- sacred language;
+- ritual practice;
+- temple or court traditions;
+- religious symbolism;
+- the worldview of the setting.
+
+The narrator should sound like a person who understands the rites from the inside rather than a modern lecturer explaining them from outside the culture.
+
+This distinction is part of the W2 product identity.
+
+---
+
+# 4. Historical Episode Mode
+
+Episode 1 will use:
+
+**Mode:** Historical  
+**Narrator:** Pyramid-universe priest-character
+
+The episode remains historically accurate and source-based.
+
+The narrator may influence:
+
+- tone;
+- cadence;
+- emphasis;
+- metaphor;
+- ritual perspective;
+- emotional framing;
+- storytelling style.
+
+The narrator may not introduce unsupported material as historical fact.
+
+In Historical Mode, the narrator is constrained by the episode research package.
+
+---
+
+# 5. Historical-Mode Knowledge Boundary
+
+In Historical Mode, the narrator may speak only from claims supported by the approved:
+
+- source dossier;
+- claim list;
+- primary-text references;
+- editorial interpretation.
+
+The narrator must not introduce:
+
+- invented historical events;
+- invented quotations;
+- invented archaeological evidence;
+- unsupported causal claims;
+- unmarked Pyramid game lore;
+- speculative claims presented as established fact.
+
+The character voice changes the **perspective**, not the evidence standard.
+
+---
+
+# 6. Example of the Difference in Voice
+
+A conventional documentary narrator might say:
+
+> The Pyramid Texts contain ritual utterances intended to assist the deceased king in his transformation and afterlife.
+
+The Pyramid priest-character might convey the same supported idea in a more internal voice:
+
+> These are not merely words carved for remembrance. They are rites for a king who must rise, transform, and join those who do not perish.
+
+The second form may be used only when the underlying historical meaning is supported by the episode's research.
+
+---
+
+# 7. Narrative Modes
+
+W2 may eventually publish content in three major modes.
+
+## 7.1 Historical Mode
+
+Purpose:
+
+Present source-based history through the perspective of the recurring Pyramid narrator.
+
+Requirements:
+
+- claims must be evidence-based;
+- uncertainty must remain visible;
+- narrator voice may enrich presentation but not invent facts.
+
+---
+
+## 7.2 Speculative / Fringe Mode
+
+Purpose:
+
+Explore disputed, fringe, alternative, or unconventional interpretations.
+
+Requirements:
+
+- the content must be clearly identified as speculative;
+- established evidence must be distinguished from conjecture;
+- the narrator may explore possibilities without presenting them as settled fact.
+
+Examples may include:
+
+- disputed astronomical interpretations;
+- alternative ritual readings;
+- fringe historical theories;
+- speculative reconstruction.
+
+---
+
+## 7.3 Pyramid Fiction Mode
+
+Purpose:
+
+Present explicit fictional material from the Pyramid TTRPG setting.
+
+Requirements:
+
+- game-world fiction must be clearly identified as fiction;
+- the narrator may speak freely as an in-world character;
+- fictional lore may diverge from historical evidence where appropriate to the setting.
+
+This mode may support:
+
+- lore videos;
+- fictional histories;
+- character monologues;
+- ritual descriptions;
+- game-world stories;
+- product promotion.
+
+---
+
+# 8. Audience Clarity Principle
+
+W2 should preserve audience trust by clearly distinguishing among:
+
+- historical evidence;
+- scholarly interpretation;
+- speculation;
+- game-world fiction.
+
+Creative freedom is encouraged, but mode confusion is not.
+
+The audience should not need to guess whether a statement is intended as:
+
+- historically supported;
+- debated;
+- speculative;
+- fictional.
+
+---
+
+# 9. Pyramid Narrator as Product IP
+
+The recurring narrator should be treated as a **cross-product intellectual-property asset**, not merely a TTS voice.
+
+Potential future uses include:
+
+- historical videos;
+- Pyramid fiction videos;
+- Field Notes;
+- sourcebooks;
+- audiobooks;
+- trailers;
+- game dialogue;
+- interactive media;
+- promotional material;
+- future digital games.
+
+The character identity may therefore include more than:
+
+- voice profile;
+- reference audio.
+
+Future product development may define:
+
+- name;
+- background;
+- role within the Pyramid world;
+- visual identity;
+- narrative history;
+- relationships to other game characters;
+- canon boundaries.
+
+No additional character development is required for Sprint 0 unless needed for Episode 1.
+
+---
+
+# 10. Sprint 0 Decision
+
+Episode 1 remains:
+
+**Historically accurate**
+
+The narrator will be used as:
+
+**A Pyramid priest-character presenting source-bounded historical material from an in-world ritual perspective.**
+
+Sprint 0 should not expand into:
+
+- fringe-history episodes;
+- fictional Pyramid lore episodes;
+- full narrator-character development;
+- additional channel formats
+
+until Episode 1 is published.
+
+---
+
+# 11. Architectural Consequences
+
+This decision affects W2 architecture in the following ways:
+
+1. **Narrator assets remain W2 product assets.**
+2. **Pyramid Narrator v1 should be preserved as a versioned canonical asset.**
+3. Episode metadata should identify the content mode.
+4. Historical-mode production must reference the approved research package.
+5. Future speculative and fiction modes should use explicit labeling.
+6. The narrator may become reusable across multiple W2 product forms.
+7. Generic TTS infrastructure may later become a Shared Service, but the narrator identity remains part of Withered Sanctum / Pyramid product IP.
+
+---
+
+# 12. Product Principle
+
+> **The narrator is not a machine reading history. He is a character from the Pyramid world interpreting history through the language and worldview of a priest — while Historical Mode remains bound to evidence.**
diff --git a/voices/pyramid-narrator-v1/pyramid-narrator-v1.md b/voices/pyramid-narrator-v1/pyramid-narrator-v1.md
new file mode 100644
index 0000000..e17da24
--- /dev/null
+++ b/voices/pyramid-narrator-v1/pyramid-narrator-v1.md
@@ -0,0 +1,21 @@
+# Pyramid Narrator v1
+
+## Role
+
+Primary historical storyteller / in-world narrator.
+
+## Voice concept
+
+A learned elder from within the world of Pyramid rather than an external documentary presenter.
+
+## VoiceDesign instruction
+
+Mature male storyteller, approximately 50 to 65 years old. Warm resonant baritone with a subtle Eastern Mediterranean or Near Eastern influence in his English accent. He should sound like a learned elder, archivist, temple scholar, court historian, or well-traveled merchant from an ancient land speaking to a visitor. Highly intelligent and articulate, but never modern-corporate or broadcast-like. Measured cadence, precise diction, quiet confidence, subtle humor, and the sense that he has lived with these stories all his life. The listener should feel as though they are being told the history of the land by someone who belongs to it. Natural and immersive, not theatrical. Avoid exaggerated fantasy accents, caricature, movie-trailer delivery, booming gravitas, or melodrama.
+
+## Reference transcript
+
+For more than four thousand years, the pyramids of Giza have stood at the edge of the desert. Their scale is overwhelming, but their real story is not one of mystery. It is the story of organization, engineering, belief, and a society capable of sustaining one of the largest construction projects of the ancient world.
+
+## Reference audio
+
+pyramid-narrator-v1.wav
\ No newline at end of file
diff --git a/voices/pyramid-narrator-v1/pyramid-narrator-v1.pt b/voices/pyramid-narrator-v1/pyramid-narrator-v1.pt
new file mode 100644
index 0000000..0ab77f2
Binary files /dev/null and b/voices/pyramid-narrator-v1/pyramid-narrator-v1.pt differ
diff --git a/voices/pyramid-narrator-v1/pyramid-narrator-v1.wav b/voices/pyramid-narrator-v1/pyramid-narrator-v1.wav
new file mode 100644
index 0000000..b6a9ff6
Binary files /dev/null and b/voices/pyramid-narrator-v1/pyramid-narrator-v1.wav differ