autonomous-enterprise/ancient-egypt-media

Fork 0

Files

T

kenschae ef968cb54d Initial setup

2026-09-18 09:34:26 -05:00

25 KiB

Raw Blame History

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:

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:

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:

.project/

The required contents are:

.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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

establish the formal Gitea repository;
establish .project/;
create the approved folder structure;
inventory existing W2 artifacts;
migrate/refer to each artifact intentionally;
record large external assets;
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:

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:

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:

establish the formal W2 source project;
migrate existing research and TTS assets;
verify the publishing account;
select/confirm the video editing toolchain;
lock primary sources and script;
produce narration;
build the asset/provenance package;
create the first video cut;
perform factual, rights, and quality review;
publish by September 24;
define the companion-product implementation sequence;
preserve actual owner effort and incremental spending;
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.

25 KiB Raw Blame History