diff --git a/AI_CONSTITUTION.md b/AI_CONSTITUTION.md
new file mode 100644
index 0000000..6f1a2ed
--- /dev/null
+++ b/AI_CONSTITUTION.md
@@ -0,0 +1,68 @@
+---
+schema: aether.architecture-document/v1
+id: renderflow-ai-constitution
+title: Renderflow Ai Constitution
+kind: architecture-document
+version: 0.1.0
+status: draft
+owners:
+  - egohygiene
+created: 2026-08-19
+updated: 2026-08-19
+governed_by:
+  - architecture-ai-constitution
+depends_on:
+  - renderflow-purpose
+  - renderflow-vision
+  - renderflow-principles
+  - renderflow-epistemology
+related:
+  - renderflow-pillars
+  - renderflow-manifesto
+  - renderflow-ontology
+  - renderflow-personal-model
+supersedes: []
+---
+
+# Renderflow AI Constitution
+
+## Scope and authority
+
+This constitution governs AI systems that inspect, author, validate, or operate on Renderflow. Applicable law and platform safety requirements, organization policy, repository policy, accepted architecture, and explicit task authority take precedence over local prompts or model defaults.
+
+Humans retain override authority and responsibility for consequential decisions.
+
+## Constitutional commitments
+
+- Use the least privilege and smallest data scope needed.
+- Distinguish observations, inference, proposals, assumptions, and decisions.
+- Never fabricate completion, validation, provenance, or authority.
+- Prefer reversible, reviewable work under uncertainty.
+- Preserve privacy, secrets, licensing, and safety boundaries.
+- Surface conflicts and missing evidence instead of smoothing them over.
+- Keep significant actions attributable and reviewable.
+
+## Action classes
+
+| Class | Examples | Default authority |
+| --- | --- | --- |
+| Read-only | Inspect repository evidence | Allowed within task scope |
+| Drafting | Produce documents, plans, or uncommitted changes | Allowed and labeled draft |
+| Reversible modification | Change a branch or isolated workspace | Requires granted modification scope |
+| External communication | Publish, comment, notify, or open changes | Requires explicit publication authority |
+| High impact | Production, financial, legal, destructive, secret-bearing | Requires explicit approval and safeguards |
+
+## Escalation
+
+Pause when authority is ambiguous, instructions conflict, evidence is insufficient for a material claim, personal or secret data may be exposed, or the action exceeds the approved risk class.
+
+## Repository-specific boundary
+
+AI may assist Renderflow's systems—Specification loader, Transform registry, Graph planner, Execution engine, Artifact and cache manager, CLI and Rust library, Documentation and release surface—but capability does not grant permission to operate them consequentially.
+
+## Evidence and uncertainty
+
+- **Observed:** The repository README and checked-in implementation establish a specification-driven Rust rendering engine that plans and executes reusable transformation graphs for publication-ready artifacts.
+- **Decided for this draft:** The repository owns the bounded concern described here and participates through versioned contracts.
+- **Proposed:** Target systems and later roadmap phases remain proposals until accepted and implemented.
+- **Open question:** Which parts of this draft should become active in the first independently versioned release?
diff --git a/ARCHITECTURE.md b/ARCHITECTURE.md
new file mode 100644
index 0000000..af616e5
--- /dev/null
+++ b/ARCHITECTURE.md
@@ -0,0 +1,87 @@
+---
+schema: aether.architecture-document/v1
+id: renderflow-architecture
+title: Renderflow Architecture
+kind: architecture-document
+version: 0.1.0
+status: draft
+owners:
+  - egohygiene
+created: 2026-08-19
+updated: 2026-08-19
+governed_by:
+  - architecture-architecture
+depends_on:
+  - renderflow-foundations
+  - renderflow-system
+related:
+  - renderflow-purpose
+  - renderflow-vision
+  - renderflow-principles
+  - renderflow-pillars
+supersedes: []
+---
+
+# Renderflow Architecture
+
+## Purpose and scope
+
+Renderflow uses a layered, contract-driven architecture. This document owns structural boundaries, dependency direction, integration rules, and current-to-target evolution. Logical responsibilities remain canonical in [SYSTEM.md](SYSTEM.md).
+
+## Layer model
+
+1. **Intent and contracts** — identity, policy, specifications, schemas, and accepted decisions.
+2. **Domain** — canonical concepts and pure domain behavior.
+3. **Application** — planning, orchestration, use cases, and state transitions.
+4. **Adapters** — filesystems, providers, frameworks, renderers, and external tools.
+5. **Interfaces** — CLI, library, site, reports, generated artifacts, and automation contracts.
+6. **Evidence** — tests, diagnostics, provenance, manifests, and health projections.
+
+Dependencies point inward toward stable contracts and domain behavior. External details do not become canonical domain truth.
+
+## Structural view
+
+```mermaid
+flowchart LR
+  S1[Specification loader]
+  S2[Transform registry]
+  S3[Graph planner]
+  S4[Execution engine]
+  S5[Artifact and cache manager]
+  S6[CLI and Rust library]
+  S7[Documentation and release surface]
+  S1 --> S2
+  S2 --> S3
+  S3 --> S4
+  S4 --> S5
+  S5 --> S6
+  S6 --> S7
+```
+
+The diagram is conceptual. [SYSTEM.md](SYSTEM.md) remains authoritative for responsibilities and implementation evidence determines current availability.
+
+## Dependency rules
+
+- Sibling domain capabilities integrate through versioned public contracts, not direct access to internals.
+- Generated artifacts never become the canonical source unless an accepted decision explicitly changes ownership.
+- Provider and platform adapters depend on application ports; core behavior does not depend on a provider implementation.
+- Read, plan, apply, verify, publish, and recover remain separate authority boundaries when consequential.
+- Cross-repository references use releases, immutable commits, schemas, packages, or documented APIs rather than mutable default-branch assumptions.
+
+## Ecosystem interfaces
+
+- Beacon document projects
+- Reflector publications
+- Flow orchestration
+- Pandoc, FFmpeg, Tera, and optional AI providers
+
+## Deployment and portability
+
+The architecture favors independently usable local and self-hosted operation. Optional managed services may add availability, collaboration, support, and hosted infrastructure without becoming the canonical holder of portable state.
+
+## Evidence and uncertainty
+
+- **Observed:** The repository README and checked-in implementation establish a specification-driven Rust rendering engine that plans and executes reusable transformation graphs for publication-ready artifacts.
+- **Decided for this draft:** The repository owns the bounded concern described here and participates through versioned contracts.
+- **Proposed:** Target systems and later roadmap phases remain proposals until accepted and implemented.
+- **Open question:** Which parts of this draft should become active in the first independently versioned release?
diff --git a/DECISIONS.md b/DECISIONS.md
new file mode 100644
index 0000000..76c4a5e
--- /dev/null
+++ b/DECISIONS.md
@@ -0,0 +1,82 @@
+---
+schema: aether.architecture-document/v1
+id: renderflow-decisions
+title: Renderflow Decisions
+kind: architecture-document
+version: 0.1.0
+status: draft
+owners:
+  - egohygiene
+created: 2026-08-19
+updated: 2026-08-19
+governed_by:
+  - architecture-decisions
+depends_on:
+  - renderflow-principles
+  - renderflow-epistemology
+  - renderflow-foundations
+  - renderflow-system
+  - renderflow-architecture
+related:
+  - renderflow-purpose
+  - renderflow-vision
+  - renderflow-pillars
+  - renderflow-manifesto
+supersedes: []
+---
+
+# Renderflow Decisions
+
+## Purpose
+
+This document preserves significant accepted architectural choices and their rationale. Issues coordinate work, proposals explore alternatives, and this file records decisions that constrain future implementation.
+
+## Governance
+
+Do not rewrite historical context to fit current understanding. Amend a record for corrections that do not change meaning; supersede it with a new record when the decision changes materially.
+
+## Index
+
+- ADR-001: Use a directed acyclic graph as the canonical execution model
+- ADR-002: Keep YAML specifications declarative and versionable
+- ADR-003: Expose both a standalone CLI and reusable Rust library
+
+## ADR-001: Use a directed acyclic graph as the canonical execution model
+
+- **Status:** Accepted as the current architectural direction
+- **Date:** 2026-08-19
+- **Context:** Repository evidence and ecosystem ownership require an explicit durable boundary.
+- **Decision:** Use a directed acyclic graph as the canonical execution model.
+- **Consequences:** The choice improves ownership and predictability while requiring maintained contracts, validation, and migration discipline.
+- **Reconsider when:** New evidence shows that the boundary prevents standalone usefulness, safety, portability, or maintainability.
+
+## ADR-002: Keep YAML specifications declarative and versionable
+
+- **Status:** Accepted as the current architectural direction
+- **Date:** 2026-08-19
+- **Context:** Repository evidence and ecosystem ownership require an explicit durable boundary.
+- **Decision:** Keep YAML specifications declarative and versionable.
+- **Consequences:** The choice improves ownership and predictability while requiring maintained contracts, validation, and migration discipline.
+- **Reconsider when:** New evidence shows that the boundary prevents standalone usefulness, safety, portability, or maintainability.
+
+## ADR-003: Expose both a standalone CLI and reusable Rust library
+
+- **Status:** Accepted as the current architectural direction
+- **Date:** 2026-08-19
+- **Context:** Repository evidence and ecosystem ownership require an explicit durable boundary.
+- **Decision:** Expose both a standalone CLI and reusable Rust library.
+- **Consequences:** The choice improves ownership and predictability while requiring maintained contracts, validation, and migration discipline.
+- **Reconsider when:** New evidence shows that the boundary prevents standalone usefulness, safety, portability, or maintainability.
+
+## Open decisions
+
+- Release and compatibility policy for the first stable version.
+- Exact self-hosted, managed, and organization-integrated deployment boundaries.
+- Which target systems must exist before the architecture status may become active.
+
+## Evidence and uncertainty
+
+- **Observed:** The repository README and checked-in implementation establish a specification-driven Rust rendering engine that plans and executes reusable transformation graphs for publication-ready artifacts.
+- **Decided for this draft:** The repository owns the bounded concern described here and participates through versioned contracts.
+- **Proposed:** Target systems and later roadmap phases remain proposals until accepted and implemented.
+- **Open question:** Which parts of this draft should become active in the first independently versioned release?
diff --git a/DESIGN.md b/DESIGN.md
new file mode 100644
index 0000000..8e108dc
--- /dev/null
+++ b/DESIGN.md
@@ -0,0 +1,59 @@
+---
+schema: aether.architecture-document/v1
+id: renderflow-design
+title: Renderflow Design
+kind: architecture-document
+version: 0.1.0
+status: draft
+owners:
+  - egohygiene
+created: 2026-08-19
+updated: 2026-08-19
+governed_by:
+  - architecture-design
+depends_on:
+  - renderflow-purpose
+  - renderflow-vision
+  - renderflow-principles
+  - renderflow-personal-model
+related:
+  - renderflow-pillars
+  - renderflow-manifesto
+  - renderflow-epistemology
+  - renderflow-ai-constitution
+supersedes: []
+---
+
+# Renderflow Design
+
+## Design philosophy
+
+Renderflow should feel precise, editorial, calm, and transparent about conversion quality. Experience quality includes terminal, documentation, automation, generated artifacts, APIs, and recovery—not only graphical interfaces.
+
+## Intended qualities
+
+- **Orientation:** people can tell where they are, what is known, and what happens next.
+- **Agency:** consequential choices are previewable, interruptible, and reversible where practical.
+- **Truthfulness:** uncertainty, partial coverage, cost, and limitations remain visible.
+- **Progressive disclosure:** simple journeys remain simple while evidence and advanced control stay reachable.
+- **Continuity:** terms, states, commands, and visual language agree across surfaces.
+- **Care:** accessibility, privacy, cognitive load, and recovery are baseline constraints.
+
+## Core journey
+
+The default journey is understand → configure → preview → act within authority → validate → inspect evidence → recover or continue. Read-only exploration remains available before commitment.
+
+## Failure experience
+
+Failures state what happened, what did not happen, whether partial output is safe, where evidence lives, and the smallest reliable recovery step. They never blame the person.
+
+## Accessibility
+
+Primary information is not encoded only by color, motion, iconography, or spatial position. Interfaces support keyboard access, meaningful focus, semantic structure, reduced motion, readable contrast, and plain-language alternatives.
+
+## Evidence and uncertainty
+
+- **Observed:** The repository README and checked-in implementation establish a specification-driven Rust rendering engine that plans and executes reusable transformation graphs for publication-ready artifacts.
+- **Decided for this draft:** The repository owns the bounded concern described here and participates through versioned contracts.
+- **Proposed:** Target systems and later roadmap phases remain proposals until accepted and implemented.
+- **Open question:** Which parts of this draft should become active in the first independently versioned release?
diff --git a/DESIGN_SYSTEM.md b/DESIGN_SYSTEM.md
new file mode 100644
index 0000000..ab79efd
--- /dev/null
+++ b/DESIGN_SYSTEM.md
@@ -0,0 +1,70 @@
+---
+schema: aether.architecture-document/v1
+id: renderflow-design-system
+title: Renderflow Design System
+kind: architecture-document
+version: 0.1.0
+status: draft
+owners:
+  - egohygiene
+created: 2026-08-19
+updated: 2026-08-19
+governed_by:
+  - architecture-design-system
+depends_on:
+  - renderflow-personal-model
+  - renderflow-design
+related:
+  - renderflow-purpose
+  - renderflow-vision
+  - renderflow-principles
+  - renderflow-pillars
+supersedes: []
+---
+
+# Renderflow Design System
+
+## Purpose and scope
+
+This document defines reusable semantic language for Renderflow's documentation, terminal output, diagrams, reports, sites, and future interactive surfaces. It does not freeze a framework, component library, or final visual identity.
+
+## Semantic roles
+
+| Role | Meaning |
+| --- | --- |
+| Canvas | Primary quiet background or base surface |
+| Surface | Grouped content or bounded interaction area |
+| Primary | Main action or navigational emphasis |
+| Information | Neutral context or observation |
+| Success | Completed and verified state |
+| Caution | Review required; safe to pause |
+| Danger | Destructive, security, privacy, or irreversible risk |
+| Unknown | Missing, unavailable, partial, or unverified state |
+
+## Status vocabulary
+
+Use the states observed, planned, running, partial, verified, failed, blocked, and unknown consistently. Never present partial or unknown as success.
+
+## Content and interaction
+
+- Use verbs that describe the actual operation.
+- Put scope and consequence before confirmation.
+- Keep destructive actions visually and textually distinct.
+- Pair errors with recovery and evidence locations.
+- Preserve stable identifiers in machine-readable output.
+- Respect reduced-motion and no-color contexts.
+
+## Components and projections
+
+Canonical patterns include command help, progress state, evidence table, decision card, plan preview, validation summary, architecture node, and recovery prompt. Concrete tokens and components are downstream projections maintained by the owning surface.
+
+## Visual direction
+
+The expression should remain precise, editorial, calm, and transparent about conversion quality while allowing product-specific identity to vary inside Ego Hygiene's broader family.
+
+## Evidence and uncertainty
+
+- **Observed:** The repository README and checked-in implementation establish a specification-driven Rust rendering engine that plans and executes reusable transformation graphs for publication-ready artifacts.
+- **Decided for this draft:** The repository owns the bounded concern described here and participates through versioned contracts.
+- **Proposed:** Target systems and later roadmap phases remain proposals until accepted and implemented.
+- **Open question:** Which parts of this draft should become active in the first independently versioned release?
diff --git a/EPISTEMOLOGY.md b/EPISTEMOLOGY.md
new file mode 100644
index 0000000..30baa34
--- /dev/null
+++ b/EPISTEMOLOGY.md
@@ -0,0 +1,64 @@
+---
+schema: aether.architecture-document/v1
+id: renderflow-epistemology
+title: Renderflow Epistemology
+kind: architecture-document
+version: 0.1.0
+status: draft
+owners:
+  - egohygiene
+created: 2026-08-19
+updated: 2026-08-19
+governed_by:
+  - architecture-epistemology
+depends_on:
+  - renderflow-purpose
+  - renderflow-principles
+related:
+  - renderflow-vision
+  - renderflow-pillars
+  - renderflow-manifesto
+  - renderflow-ai-constitution
+supersedes: []
+---
+
+# Renderflow Epistemology
+
+## Scope
+
+This document governs how Renderflow classifies claims, evidence, provenance, confidence, conflict, and revision. It does not dictate which technical conclusion must be accepted.
+
+## Claim states
+
+| State | Meaning |
+| --- | --- |
+| Observed | Directly supported by repository or runtime evidence |
+| Decided | Accepted through the repository governance process |
+| Inferred | Reasoned from evidence but not directly observed |
+| Proposed | Recommended future direction not yet accepted |
+| Assumed | Necessary working premise awaiting evidence |
+| Unverified | Plausible claim that has not been checked |
+| Open question | A known gap requiring investigation or choice |
+
+## Evidence order
+
+1. Reproducible tests, schemas, generated artifacts, and runtime observations.
+2. Accepted decisions and versioned specifications.
+3. Current source and configuration.
+4. Maintainer documentation and issue history.
+5. Inference and recommendation, labeled with uncertainty.
+
+## Provenance and conflict
+
+Claims should identify their source closely enough to be rechecked. Conflicting evidence remains visible until the canonical owner resolves it; recency alone does not automatically establish truth.
+
+## Revision
+
+Material claims are revised when stronger evidence appears, their source changes, or an accepted decision supersedes them. Historical decision context is preserved rather than rewritten.
+
+## Evidence and uncertainty
+
+- **Observed:** The repository README and checked-in implementation establish a specification-driven Rust rendering engine that plans and executes reusable transformation graphs for publication-ready artifacts.
+- **Decided for this draft:** The repository owns the bounded concern described here and participates through versioned contracts.
+- **Proposed:** Target systems and later roadmap phases remain proposals until accepted and implemented.
+- **Open question:** Which parts of this draft should become active in the first independently versioned release?
diff --git a/FOUNDATIONS.md b/FOUNDATIONS.md
new file mode 100644
index 0000000..e6c537f
--- /dev/null
+++ b/FOUNDATIONS.md
@@ -0,0 +1,58 @@
+---
+schema: aether.architecture-document/v1
+id: renderflow-foundations
+title: Renderflow Foundations
+kind: architecture-document
+version: 0.1.0
+status: draft
+owners:
+  - egohygiene
+created: 2026-08-19
+updated: 2026-08-19
+governed_by:
+  - architecture-foundations
+depends_on:
+  - renderflow-purpose
+  - renderflow-principles
+  - renderflow-epistemology
+related:
+  - renderflow-vision
+  - renderflow-pillars
+  - renderflow-manifesto
+  - renderflow-ai-constitution
+supersedes: []
+---
+
+# Renderflow Foundations
+
+## Foundational assumptions
+
+- The repository owns one bounded concern and integrates through explicit contracts.
+- Human authority, privacy, safety, provenance, and accessibility are architectural constraints.
+- Canonical source is distinguishable from generated output and transient state.
+- Observed, desired, proposed, and accepted states remain distinguishable.
+- Validation evidence must be reproducible closely enough to support review.
+- Standalone usefulness is preserved even when the wider organization adds value.
+- Self-hosting and portability are supported without pretending external compute, storage, domains, or providers are free.
+
+## Enduring constraints
+
+- Do not make mutable default branches or unpublished internal APIs cross-repository dependencies.
+- Do not put secrets, private source material, or provider credentials in generated architecture or distribution artifacts.
+- Do not let convenience erase approval, rollback, or provenance at consequential boundaries.
+- Do not claim cross-platform, self-hosted, or production support beyond verified evidence.
+
+## Trust boundaries
+
+Repository source, generated artifacts, local state, external providers, organization automation, and user-controlled infrastructure are distinct trust zones. Every crossing requires an explicit data, authority, and failure contract.
+
+## Success properties
+
+The foundation is healthy when Declarative rendering contracts, Graph planning and execution, Extensible transform ecosystem, Publication-grade evidence remain independently testable and their ownership is clear.
+
+## Evidence and uncertainty
+
+- **Observed:** The repository README and checked-in implementation establish a specification-driven Rust rendering engine that plans and executes reusable transformation graphs for publication-ready artifacts.
+- **Decided for this draft:** The repository owns the bounded concern described here and participates through versioned contracts.
+- **Proposed:** Target systems and later roadmap phases remain proposals until accepted and implemented.
+- **Open question:** Which parts of this draft should become active in the first independently versioned release?
diff --git a/MANIFESTO.md b/MANIFESTO.md
new file mode 100644
index 0000000..b58607e
--- /dev/null
+++ b/MANIFESTO.md
@@ -0,0 +1,58 @@
+---
+schema: aether.architecture-document/v1
+id: renderflow-manifesto
+title: Renderflow Manifesto
+kind: architecture-document
+version: 0.1.0
+status: draft
+owners:
+  - egohygiene
+created: 2026-08-19
+updated: 2026-08-19
+governed_by:
+  - architecture-manifesto
+depends_on:
+  - renderflow-purpose
+  - renderflow-vision
+  - renderflow-principles
+  - renderflow-pillars
+related:
+  - renderflow-epistemology
+  - renderflow-ai-constitution
+  - renderflow-ontology
+  - renderflow-personal-model
+supersedes: []
+---
+
+# Renderflow Manifesto
+
+## Declaration
+
+We believe make complex, multi-format document and media rendering reproducible, inspectable, and easy to operate is worth doing carefully, openly, and with respect for the people affected by the system.
+
+## We stand for
+
+- Specifications before flags: make the commitment visible in behavior, not only prose.
+- The graph must be inspectable: make the commitment visible in behavior, not only prose.
+- Determinism before convenience: make the commitment visible in behavior, not only prose.
+- Capabilities remain pluggable: make the commitment visible in behavior, not only prose.
+- Quality and provenance travel with output: make the commitment visible in behavior, not only prose.
+
+## We reject
+
+- concealed authority and irreversible surprise;
+- lock-in disguised as convenience;
+- claims of certainty without evidence;
+- automation that erases human context;
+- architecture that centralizes ownership merely because it is easier today.
+
+## Commitment
+
+We will keep Renderflow independently understandable, honestly incomplete when evidence is missing, and open to revision when better evidence or lived experience contradicts current assumptions.
+
+## Evidence and uncertainty
+
+- **Observed:** The repository README and checked-in implementation establish a specification-driven Rust rendering engine that plans and executes reusable transformation graphs for publication-ready artifacts.
+- **Decided for this draft:** The repository owns the bounded concern described here and participates through versioned contracts.
+- **Proposed:** Target systems and later roadmap phases remain proposals until accepted and implemented.
+- **Open question:** Which parts of this draft should become active in the first independently versioned release?
diff --git a/META.md b/META.md
new file mode 100644
index 0000000..761c471
--- /dev/null
+++ b/META.md
@@ -0,0 +1,113 @@
+---
+schema: aether.architecture-document/v1
+id: renderflow-meta
+title: Renderflow Meta
+kind: architecture-document
+version: 0.1.0
+status: draft
+owners:
+  - egohygiene
+created: 2026-08-19
+updated: 2026-08-19
+governed_by:
+  - architecture-meta
+depends_on:
+  - renderflow-epistemology
+  - renderflow-ai-constitution
+related:
+  - renderflow-purpose
+  - renderflow-vision
+  - renderflow-principles
+  - renderflow-pillars
+supersedes: []
+---
+
+# Renderflow Meta Architecture
+
+## Architecture-system overview
+
+Renderflow's architecture is an 18-document graph materialized from the Aether architecture specifications. Each document owns one bounded concern. This index maps ownership and relationships without replacing the documents themselves.
+
+## Document inventory
+
+| Artifact | Path | Category | Status | Governing specification | Upstream dependencies |
+| --- | --- | --- | --- | --- | --- |
+| renderflow-purpose | [PURPOSE.md](PURPOSE.md) | Identity | draft | architecture-purpose | — |
+| renderflow-vision | [VISION.md](VISION.md) | Identity | draft | architecture-vision | renderflow-purpose |
+| renderflow-principles | [PRINCIPLES.md](PRINCIPLES.md) | Identity | draft | architecture-principles | renderflow-purpose, renderflow-vision |
+| renderflow-pillars | [PILLARS.md](PILLARS.md) | Identity | draft | architecture-pillars | renderflow-purpose, renderflow-vision, renderflow-principles |
+| renderflow-manifesto | [MANIFESTO.md](MANIFESTO.md) | Identity | draft | architecture-manifesto | renderflow-purpose, renderflow-vision, renderflow-principles, renderflow-pillars |
+| renderflow-epistemology | [EPISTEMOLOGY.md](EPISTEMOLOGY.md) | Meta | draft | architecture-epistemology | renderflow-purpose, renderflow-principles |
+| renderflow-ai-constitution | [AI_CONSTITUTION.md](AI_CONSTITUTION.md) | Meta | draft | architecture-ai-constitution | renderflow-purpose, renderflow-vision, renderflow-principles, renderflow-epistemology |
+| renderflow-ontology | [ONTOLOGY.md](ONTOLOGY.md) | Domain | draft | architecture-ontology | renderflow-purpose, renderflow-vision, renderflow-principles, renderflow-epistemology |
+| renderflow-personal-model | [PERSONAL_MODEL.md](PERSONAL_MODEL.md) | Domain | draft | architecture-personal-model | renderflow-purpose, renderflow-vision, renderflow-principles, renderflow-epistemology, renderflow-ontology |
+| renderflow-foundations | [FOUNDATIONS.md](FOUNDATIONS.md) | Foundation | draft | architecture-foundations | renderflow-purpose, renderflow-principles, renderflow-epistemology |
+| renderflow-system | [SYSTEM.md](SYSTEM.md) | Foundation | draft | architecture-system | renderflow-foundations, renderflow-ontology |
+| renderflow-architecture | [ARCHITECTURE.md](ARCHITECTURE.md) | Foundation | draft | architecture-architecture | renderflow-foundations, renderflow-system |
+| renderflow-methodology | [METHODOLOGY.md](METHODOLOGY.md) | Foundation | draft | architecture-methodology | renderflow-principles, renderflow-epistemology, renderflow-ai-constitution, renderflow-foundations, renderflow-architecture |
+| renderflow-design | [DESIGN.md](DESIGN.md) | Experience | draft | architecture-design | renderflow-purpose, renderflow-vision, renderflow-principles, renderflow-personal-model |
+| renderflow-design-system | [DESIGN_SYSTEM.md](DESIGN_SYSTEM.md) | Experience | draft | architecture-design-system | renderflow-personal-model, renderflow-design |
+| renderflow-decisions | [DECISIONS.md](DECISIONS.md) | Governance | draft | architecture-decisions | renderflow-principles, renderflow-epistemology, renderflow-foundations, renderflow-system, renderflow-architecture |
+| renderflow-roadmap | [ROADMAP.md](ROADMAP.md) | Foundation | draft | architecture-roadmap | renderflow-vision, renderflow-pillars, renderflow-architecture, renderflow-decisions |
+| renderflow-meta | [META.md](META.md) | Meta | draft | architecture-meta | renderflow-epistemology, renderflow-ai-constitution |
+
+## Relationship graph
+
+```mermaid
+flowchart TD
+  PURPOSE --> VISION --> PRINCIPLES --> PILLARS --> MANIFESTO
+  PURPOSE --> EPISTEMOLOGY --> AI[AI Constitution]
+  PRINCIPLES --> EPISTEMOLOGY
+  EPISTEMOLOGY --> ONTOLOGY --> PERSONAL[Personal Model]
+  PRINCIPLES --> FOUNDATIONS
+  EPISTEMOLOGY --> FOUNDATIONS
+  FOUNDATIONS --> SYSTEM --> ARCHITECTURE --> METHODOLOGY
+  PERSONAL --> DESIGN --> DS[Design System]
+  ARCHITECTURE --> DECISIONS --> ROADMAP
+  PILLARS --> ROADMAP
+  AI --> META
+  EPISTEMOLOGY --> META
+```
+
+## Ownership map
+
+- Identity documents own why the repository exists, its desired future, decision heuristics, strategic capabilities, and public commitments.
+- Meta documents own knowledge integrity, AI authority, and navigation of this document system.
+- Domain documents own canonical concepts and bounded human assumptions.
+- Foundation documents own invariants, logical systems, structure, working method, and strategic evolution.
+- Experience documents own intended experience and reusable semantic design language.
+- Governance owns accepted architectural decisions and historical lineage.
+
+## Reading order
+
+1. PURPOSE, VISION, and PRINCIPLES.
+2. EPISTEMOLOGY and ONTOLOGY.
+3. FOUNDATIONS, SYSTEM, and ARCHITECTURE.
+4. PERSONAL_MODEL, DESIGN, and DESIGN_SYSTEM when evaluating human-facing surfaces.
+5. AI_CONSTITUTION before delegating consequential work.
+6. DECISIONS and ROADMAP for accepted constraints and evolution.
+
+## Authoring order
+
+Follow the dependency graph from purpose through identity and evidence, then domain and foundations, experience, governance, roadmap, and finally this META index.
+
+## Lifecycle and validation
+
+All documents begin as draft and require human review before becoming active. Validation covers frontmatter, stable identifiers, links, graph acyclicity, ownership boundaries, evidence labels, Markdown structure, and agreement with repository reality.
+
+## Change propagation
+
+A material upstream change triggers review of every downstream node. Implementation changes first update the owning specification or decision when they alter durable behavior; META changes whenever inventory or relationships change.
+
+## Gaps and omissions
+
+- No document in this set is intentionally omitted because Renderflow has repository, automation, human, AI, and public or documentation surfaces that justify the complete reference set.
+- Target systems remain provisional where implementation evidence is absent.
+- Repository-local schemas and automated graph validation should be added or connected to Aether in a later conformance pass.
+
+## Evidence and uncertainty
+
+- **Observed:** The repository README and checked-in implementation establish a specification-driven Rust rendering engine that plans and executes reusable transformation graphs for publication-ready artifacts.
+- **Decided for this draft:** The repository owns the bounded concern described here and participates through versioned contracts.
+- **Proposed:** Target systems and later roadmap phases remain proposals until accepted and implemented.
+- **Open question:** Which parts of this draft should become active in the first independently versioned release?
diff --git a/METHODOLOGY.md b/METHODOLOGY.md
new file mode 100644
index 0000000..8e7b922
--- /dev/null
+++ b/METHODOLOGY.md
@@ -0,0 +1,66 @@
+---
+schema: aether.architecture-document/v1
+id: renderflow-methodology
+title: Renderflow Methodology
+kind: architecture-document
+version: 0.1.0
+status: draft
+owners:
+  - egohygiene
+created: 2026-08-19
+updated: 2026-08-19
+governed_by:
+  - architecture-methodology
+depends_on:
+  - renderflow-principles
+  - renderflow-epistemology
+  - renderflow-ai-constitution
+  - renderflow-foundations
+  - renderflow-architecture
+related:
+  - renderflow-purpose
+  - renderflow-vision
+  - renderflow-pillars
+  - renderflow-manifesto
+supersedes: []
+---
+
+# Renderflow Methodology
+
+## Working method
+
+Renderflow combines specification-driven, schema-driven, and test-driven development in one evidence loop:
+
+> Discover → Model → Specify → Plan → Test → Implement → Validate → Review → Integrate → Reflect
+
+## Method contracts
+
+1. **Discover evidence:** inspect current source, runtime behavior, users, risks, and neighboring ownership.
+2. **Model the domain:** update ontology and boundaries before encoding unstable terminology.
+3. **Specify behavior:** define inputs, outputs, invariants, authority, failures, and acceptance criteria.
+4. **Define schemas:** make durable machine boundaries independently validatable.
+5. **Write tests:** cover happy paths, boundaries, failures, compatibility, and safety properties.
+6. **Implement narrowly:** change only the owning system and adapters required by the specification.
+7. **Validate evidence:** run deterministic checks and preserve important results.
+8. **Review impact:** inspect architecture, security, privacy, accessibility, operations, and downstream consumers.
+9. **Integrate and reflect:** publish through the defined lifecycle and feed lessons into decisions and roadmap.
+
+## Quality gates
+
+- Structural and schema validation.
+- Unit, integration, contract, and end-to-end tests appropriate to the change.
+- Security, dependency, licensing, privacy, and secret checks.
+- Documentation and architecture consistency.
+- Reproducible build or artifact verification.
+- Human approval at external, destructive, billing, production, or publication boundaries.
+
+## AI collaboration
+
+Agents may accelerate discovery, drafting, implementation, and verification within explicit scope. They preserve provenance, report failures honestly, and do not convert recommendations into accepted decisions.
+
+## Evidence and uncertainty
+
+- **Observed:** The repository README and checked-in implementation establish a specification-driven Rust rendering engine that plans and executes reusable transformation graphs for publication-ready artifacts.
+- **Decided for this draft:** The repository owns the bounded concern described here and participates through versioned contracts.
+- **Proposed:** Target systems and later roadmap phases remain proposals until accepted and implemented.
+- **Open question:** Which parts of this draft should become active in the first independently versioned release?
diff --git a/ONTOLOGY.md b/ONTOLOGY.md
new file mode 100644
index 0000000..85588a8
--- /dev/null
+++ b/ONTOLOGY.md
@@ -0,0 +1,68 @@
+---
+schema: aether.architecture-document/v1
+id: renderflow-ontology
+title: Renderflow Ontology
+kind: architecture-document
+version: 0.1.0
+status: draft
+owners:
+  - egohygiene
+created: 2026-08-19
+updated: 2026-08-19
+governed_by:
+  - architecture-ontology
+depends_on:
+  - renderflow-purpose
+  - renderflow-vision
+  - renderflow-principles
+  - renderflow-epistemology
+related:
+  - renderflow-pillars
+  - renderflow-manifesto
+  - renderflow-ai-constitution
+  - renderflow-personal-model
+supersedes: []
+---
+
+# Renderflow Ontology
+
+## Domain scope
+
+Renderflow models the concepts needed for make complex, multi-format document and media rendering reproducible, inspectable, and easy to operate. The ontology names conceptual entities and relationships; it is not a source-code class model, API schema, or database design.
+
+## Canonical concepts
+
+| Concept | Meaning |
+| --- | --- |
+| Source artifact | A canonical concept in the Renderflow domain whose exact fields belong to specifications or schemas, not this ontology. |
+| Render specification | A canonical concept in the Renderflow domain whose exact fields belong to specifications or schemas, not this ontology. |
+| Transform | A canonical concept in the Renderflow domain whose exact fields belong to specifications or schemas, not this ontology. |
+| Graph | A canonical concept in the Renderflow domain whose exact fields belong to specifications or schemas, not this ontology. |
+| Executor | A canonical concept in the Renderflow domain whose exact fields belong to specifications or schemas, not this ontology. |
+| Intermediate artifact | A canonical concept in the Renderflow domain whose exact fields belong to specifications or schemas, not this ontology. |
+| Output artifact | A canonical concept in the Renderflow domain whose exact fields belong to specifications or schemas, not this ontology. |
+| Cache entry | A canonical concept in the Renderflow domain whose exact fields belong to specifications or schemas, not this ontology. |
+| Diagnostic | A canonical concept in the Renderflow domain whose exact fields belong to specifications or schemas, not this ontology. |
+
+## Core relationships
+
+- A repository or person provides source context to one or more domain artifacts.
+- A specification constrains how an artifact is interpreted or produced.
+- A plan separates proposed action from execution.
+- Evidence supports a claim; a decision authorizes a durable direction.
+- Provenance connects derived artifacts to their inputs and processing context.
+- A consumer integrates through an explicit interface rather than internal structure.
+
+## Boundaries
+
+- Conceptual identity is distinct from filesystem path, database identifier, or display label.
+- Observed state is distinct from desired state.
+- Proposed relationships are not accepted facts.
+- Neighboring repositories retain ownership of their domain concepts.
+
+## Evidence and uncertainty
+
+- **Observed:** The repository README and checked-in implementation establish a specification-driven Rust rendering engine that plans and executes reusable transformation graphs for publication-ready artifacts.
+- **Decided for this draft:** The repository owns the bounded concern described here and participates through versioned contracts.
+- **Proposed:** Target systems and later roadmap phases remain proposals until accepted and implemented.
+- **Open question:** Which parts of this draft should become active in the first independently versioned release?
diff --git a/PERSONAL_MODEL.md b/PERSONAL_MODEL.md
new file mode 100644
index 0000000..1a68998
--- /dev/null
+++ b/PERSONAL_MODEL.md
@@ -0,0 +1,63 @@
+---
+schema: aether.architecture-document/v1
+id: renderflow-personal-model
+title: Renderflow Personal Model
+kind: architecture-document
+version: 0.1.0
+status: draft
+owners:
+  - egohygiene
+created: 2026-08-19
+updated: 2026-08-19
+governed_by:
+  - architecture-personal-model
+depends_on:
+  - renderflow-purpose
+  - renderflow-vision
+  - renderflow-principles
+  - renderflow-epistemology
+  - renderflow-ontology
+related:
+  - renderflow-pillars
+  - renderflow-manifesto
+  - renderflow-ai-constitution
+  - renderflow-foundations
+supersedes: []
+---
+
+# Renderflow Personal Model
+
+## Purpose
+
+Renderflow is designed for and operated by people even when it is primarily a library or automation surface. This document makes its limited human assumptions explicit; it is not a persona catalog, diagnosis, identity model, or prediction engine.
+
+## People in scope
+
+- authors and publishers
+- automation maintainers
+- developers embedding rendering capabilities
+
+Maintainers, contributors, reviewers, and people indirectly affected by generated or published outputs are also in scope.
+
+## Human assumptions
+
+- Attention, time, technical knowledge, sensory tolerance, and risk tolerance vary.
+- People may arrive under stress, with incomplete context, or using assistive technology.
+- A person's files, history, choices, or metrics do not fully represent them.
+- Consent to inspect is not automatically consent to mutate, publish, infer, or retain.
+- People need meaningful recovery paths when systems fail.
+
+## Agency and consent boundaries
+
+Consequential operations require understandable scope, current authorization, and an appropriate preview or confirmation. Personal inference must be optional, purpose-limited, labeled, correctable, and removable.
+
+## Accessibility and dignity
+
+Primary journeys should remain keyboard-accessible, screen-reader legible, reduced-motion compatible, and understandable without expert vocabulary. Error messages describe recovery without blame.
+
+## Evidence and uncertainty
+
+- **Observed:** The repository README and checked-in implementation establish a specification-driven Rust rendering engine that plans and executes reusable transformation graphs for publication-ready artifacts.
+- **Decided for this draft:** The repository owns the bounded concern described here and participates through versioned contracts.
+- **Proposed:** Target systems and later roadmap phases remain proposals until accepted and implemented.
+- **Open question:** Which parts of this draft should become active in the first independently versioned release?
diff --git a/PILLARS.md b/PILLARS.md
new file mode 100644
index 0000000..86837ac
--- /dev/null
+++ b/PILLARS.md
@@ -0,0 +1,57 @@
+---
+schema: aether.architecture-document/v1
+id: renderflow-pillars
+title: Renderflow Pillars
+kind: architecture-document
+version: 0.1.0
+status: draft
+owners:
+  - egohygiene
+created: 2026-08-19
+updated: 2026-08-19
+governed_by:
+  - architecture-pillars
+depends_on:
+  - renderflow-purpose
+  - renderflow-vision
+  - renderflow-principles
+related:
+  - renderflow-manifesto
+  - renderflow-epistemology
+  - renderflow-ai-constitution
+  - renderflow-ontology
+supersedes: []
+---
+
+# Renderflow Pillars
+
+## Role
+
+The pillars are enduring strategic capabilities, not projects, repositories, components, or roadmap phases.
+
+## Pillar 1: Declarative rendering contracts
+
+This capability must remain healthy for Renderflow to fulfill its purpose. Its health should be visible through versioned contracts, tests or review evidence, documentation, and clear ownership.
+
+## Pillar 2: Graph planning and execution
+
+This capability must remain healthy for Renderflow to fulfill its purpose. Its health should be visible through versioned contracts, tests or review evidence, documentation, and clear ownership.
+
+## Pillar 3: Extensible transform ecosystem
+
+This capability must remain healthy for Renderflow to fulfill its purpose. Its health should be visible through versioned contracts, tests or review evidence, documentation, and clear ownership.
+
+## Pillar 4: Publication-grade evidence
+
+This capability must remain healthy for Renderflow to fulfill its purpose. Its health should be visible through versioned contracts, tests or review evidence, documentation, and clear ownership.
+
+## Balance
+
+No pillar is complete in isolation. Delivery that weakens trust, ownership, accessibility, or evidence does not count as durable progress.
+
+## Evidence and uncertainty
+
+- **Observed:** The repository README and checked-in implementation establish a specification-driven Rust rendering engine that plans and executes reusable transformation graphs for publication-ready artifacts.
+- **Decided for this draft:** The repository owns the bounded concern described here and participates through versioned contracts.
+- **Proposed:** Target systems and later roadmap phases remain proposals until accepted and implemented.
+- **Open question:** Which parts of this draft should become active in the first independently versioned release?
diff --git a/PRINCIPLES.md b/PRINCIPLES.md
new file mode 100644
index 0000000..ac1e37e
--- /dev/null
+++ b/PRINCIPLES.md
@@ -0,0 +1,70 @@
+---
+schema: aether.architecture-document/v1
+id: renderflow-principles
+title: Renderflow Principles
+kind: architecture-document
+version: 0.1.0
+status: draft
+owners:
+  - egohygiene
+created: 2026-08-19
+updated: 2026-08-19
+governed_by:
+  - architecture-principles
+depends_on:
+  - renderflow-purpose
+  - renderflow-vision
+related:
+  - renderflow-pillars
+  - renderflow-manifesto
+  - renderflow-epistemology
+  - renderflow-ai-constitution
+supersedes: []
+---
+
+# Renderflow Principles
+
+## Purpose
+
+These principles guide decisions when multiple valid options exist. They do not replace policy, accepted decisions, specifications, or implementation standards.
+
+## 1. Specifications before flags
+
+**Guidance:** Prefer choices that make this principle observable in contracts, behavior, and evidence.
+
+**Trade-off:** Accept some additional explicitness and validation when it prevents hidden coupling, lost provenance, or irreversible surprise.
+
+## 2. The graph must be inspectable
+
+**Guidance:** Prefer choices that make this principle observable in contracts, behavior, and evidence.
+
+**Trade-off:** Accept some additional explicitness and validation when it prevents hidden coupling, lost provenance, or irreversible surprise.
+
+## 3. Determinism before convenience
+
+**Guidance:** Prefer choices that make this principle observable in contracts, behavior, and evidence.
+
+**Trade-off:** Accept some additional explicitness and validation when it prevents hidden coupling, lost provenance, or irreversible surprise.
+
+## 4. Capabilities remain pluggable
+
+**Guidance:** Prefer choices that make this principle observable in contracts, behavior, and evidence.
+
+**Trade-off:** Accept some additional explicitness and validation when it prevents hidden coupling, lost provenance, or irreversible surprise.
+
+## 5. Quality and provenance travel with output
+
+**Guidance:** Prefer choices that make this principle observable in contracts, behavior, and evidence.
+
+**Trade-off:** Accept some additional explicitness and validation when it prevents hidden coupling, lost provenance, or irreversible surprise.
+
+## Precedence and exceptions
+
+Safety, human agency, privacy, and explicit policy take precedence over convenience and speed. Exceptions require a recorded rationale, bounded duration when temporary, validation evidence, and a review trigger.
+
+## Evidence and uncertainty
+
+- **Observed:** The repository README and checked-in implementation establish a specification-driven Rust rendering engine that plans and executes reusable transformation graphs for publication-ready artifacts.
+- **Decided for this draft:** The repository owns the bounded concern described here and participates through versioned contracts.
+- **Proposed:** Target systems and later roadmap phases remain proposals until accepted and implemented.
+- **Open question:** Which parts of this draft should become active in the first independently versioned release?
diff --git a/PURPOSE.md b/PURPOSE.md
new file mode 100644
index 0000000..c0344fd
--- /dev/null
+++ b/PURPOSE.md
@@ -0,0 +1,58 @@
+---
+schema: aether.architecture-document/v1
+id: renderflow-purpose
+title: Renderflow Purpose
+kind: architecture-document
+version: 0.1.0
+status: draft
+owners:
+  - egohygiene
+created: 2026-08-19
+updated: 2026-08-19
+governed_by:
+  - architecture-purpose
+depends_on:
+  []
+related:
+  - renderflow-vision
+  - renderflow-principles
+  - renderflow-pillars
+  - renderflow-manifesto
+supersedes: []
+---
+
+# Renderflow Purpose
+
+## Purpose statement
+
+Renderflow exists to make complex, multi-format document and media rendering reproducible, inspectable, and easy to operate.
+
+## Need
+
+publication pipelines often hide transformation choices in fragile commands, duplicated scripts, and tool-specific flags.
+
+## Beneficiaries
+
+- authors and publishers
+- automation maintainers
+- developers embedding rendering capabilities
+
+## Enduring value
+
+The enduring value is a trustworthy, portable capability that remains useful when its implementation, delivery channel, or surrounding platform changes.
+
+## Scope boundaries
+
+Renderflow owns a specification-driven Rust rendering engine that plans and executes reusable transformation graphs for publication-ready artifacts. It does not absorb neighboring repositories, treat temporary implementation choices as purpose, or claim authority beyond its explicit contracts.
+
+## Evidence and uncertainty
+
+- **Observed:** The repository README and checked-in implementation establish a specification-driven Rust rendering engine that plans and executes reusable transformation graphs for publication-ready artifacts.
+- **Decided for this draft:** The repository owns the bounded concern described here and participates through versioned contracts.
+- **Proposed:** Target systems and later roadmap phases remain proposals until accepted and implemented.
+- **Open question:** Which parts of this draft should become active in the first independently versioned release?
+
+## Open questions
+
+- Which beneficiary needs require direct research before this document can become active?
+- Which current features are incidental and should remain outside the enduring purpose?
diff --git a/ROADMAP.md b/ROADMAP.md
new file mode 100644
index 0000000..0fcfd76
--- /dev/null
+++ b/ROADMAP.md
@@ -0,0 +1,98 @@
+---
+schema: aether.architecture-document/v1
+id: renderflow-roadmap
+title: Renderflow Roadmap
+kind: architecture-document
+version: 0.1.0
+status: draft
+owners:
+  - egohygiene
+created: 2026-08-19
+updated: 2026-08-19
+governed_by:
+  - architecture-roadmap
+depends_on:
+  - renderflow-vision
+  - renderflow-pillars
+  - renderflow-architecture
+  - renderflow-decisions
+related:
+  - renderflow-purpose
+  - renderflow-principles
+  - renderflow-manifesto
+  - renderflow-epistemology
+supersedes: []
+---
+
+# Renderflow Roadmap
+
+## Strategic context
+
+This roadmap describes capability evolution, not promised dates or an issue queue. Sequence follows architecture dependencies and may change when evidence or risk changes.
+
+## Phase 1: Consolidate stable contracts
+
+**Outcome:** A bounded capability advances from documented intent to validated, independently usable behavior.
+
+**Exit signals:**
+
+- The owning contract and acceptance criteria are versioned.
+- Implementation and documentation agree.
+- Relevant tests and safety checks pass.
+- Downstream consumers and migration impact are understood.
+- Remaining uncertainty is visible.
+
+## Phase 2: Harden transforms and evidence
+
+**Outcome:** A bounded capability advances from documented intent to validated, independently usable behavior.
+
+**Exit signals:**
+
+- The owning contract and acceptance criteria are versioned.
+- Implementation and documentation agree.
+- Relevant tests and safety checks pass.
+- Downstream consumers and migration impact are understood.
+- Remaining uncertainty is visible.
+
+## Phase 3: Expand plugin and SDK boundaries
+
+**Outcome:** A bounded capability advances from documented intent to validated, independently usable behavior.
+
+**Exit signals:**
+
+- The owning contract and acceptance criteria are versioned.
+- Implementation and documentation agree.
+- Relevant tests and safety checks pass.
+- Downstream consumers and migration impact are understood.
+- Remaining uncertainty is visible.
+
+## Phase 4: Integrate with the wider Flow suite
+
+**Outcome:** A bounded capability advances from documented intent to validated, independently usable behavior.
+
+**Exit signals:**
+
+- The owning contract and acceptance criteria are versioned.
+- Implementation and documentation agree.
+- Relevant tests and safety checks pass.
+- Downstream consumers and migration impact are understood.
+- Remaining uncertainty is visible.
+
+## Cross-cutting tracks
+
+- Security, privacy, accessibility, licensing, and provenance.
+- Documentation, architecture portals, examples, and onboarding.
+- Packaging, release, compatibility, and self-hosting.
+- Organization integration through explicit contracts.
+- Observatory evidence and Pace conformance when those systems exist.
+
+## Deferred direction
+
+Optional managed services, enterprise controls, marketplaces, and the conversational organization compiler remain later architecture work. Current choices should preserve portability and avoid foreclosing them.
+
+## Evidence and uncertainty
+
+- **Observed:** The repository README and checked-in implementation establish a specification-driven Rust rendering engine that plans and executes reusable transformation graphs for publication-ready artifacts.
+- **Decided for this draft:** The repository owns the bounded concern described here and participates through versioned contracts.
+- **Proposed:** Target systems and later roadmap phases remain proposals until accepted and implemented.
+- **Open question:** Which parts of this draft should become active in the first independently versioned release?
diff --git a/SYSTEM.md b/SYSTEM.md
new file mode 100644
index 0000000..375b816
--- /dev/null
+++ b/SYSTEM.md
@@ -0,0 +1,65 @@
+---
+schema: aether.architecture-document/v1
+id: renderflow-system
+title: Renderflow System
+kind: architecture-document
+version: 0.1.0
+status: draft
+owners:
+  - egohygiene
+created: 2026-08-19
+updated: 2026-08-19
+governed_by:
+  - architecture-system
+depends_on:
+  - renderflow-foundations
+  - renderflow-ontology
+related:
+  - renderflow-purpose
+  - renderflow-vision
+  - renderflow-principles
+  - renderflow-pillars
+supersedes: []
+---
+
+# Renderflow System
+
+## Purpose and scope
+
+This document identifies Renderflow's logical systems and responsibilities. It answers what the major systems do; [ARCHITECTURE.md](ARCHITECTURE.md) owns their structural organization and dependency rules.
+
+## System inventory
+
+| System | State | Responsibility |
+| --- | --- | --- |
+| Specification loader | Current | Owns its bounded portion of a specification-driven Rust rendering engine that plans and executes reusable transformation graphs for publication-ready artifacts; exposes explicit inputs, outputs, failure states, and evidence. |
+| Transform registry | Current | Owns its bounded portion of a specification-driven Rust rendering engine that plans and executes reusable transformation graphs for publication-ready artifacts; exposes explicit inputs, outputs, failure states, and evidence. |
+| Graph planner | Current | Owns its bounded portion of a specification-driven Rust rendering engine that plans and executes reusable transformation graphs for publication-ready artifacts; exposes explicit inputs, outputs, failure states, and evidence. |
+| Execution engine | Current | Owns its bounded portion of a specification-driven Rust rendering engine that plans and executes reusable transformation graphs for publication-ready artifacts; exposes explicit inputs, outputs, failure states, and evidence. |
+| Artifact and cache manager | Current or evolving | Owns its bounded portion of a specification-driven Rust rendering engine that plans and executes reusable transformation graphs for publication-ready artifacts; exposes explicit inputs, outputs, failure states, and evidence. |
+| CLI and Rust library | Current or evolving | Owns its bounded portion of a specification-driven Rust rendering engine that plans and executes reusable transformation graphs for publication-ready artifacts; exposes explicit inputs, outputs, failure states, and evidence. |
+| Documentation and release surface | Current or evolving | Owns its bounded portion of a specification-driven Rust rendering engine that plans and executes reusable transformation graphs for publication-ready artifacts; exposes explicit inputs, outputs, failure states, and evidence. |
+
+## External systems
+
+- Beacon document projects
+- Reflector publications
+- Flow orchestration
+- Pandoc, FFmpeg, Tera, and optional AI providers
+
+External systems are integrations, not hidden implementation units. Each requires version, authentication, availability, data, error, and replacement boundaries appropriate to its risk.
+
+## System interactions
+
+Inputs enter through an adapter or validated contract, move through domain systems, produce artifacts and diagnostics, and leave through a stable interface. Evidence flows back to validation, review, and future decisions.
+
+## Failure model
+
+Systems fail closed at destructive, publication, privacy, and security boundaries. Partial results identify coverage and remain distinguishable from complete success.
+
+## Evidence and uncertainty
+
+- **Observed:** The repository README and checked-in implementation establish a specification-driven Rust rendering engine that plans and executes reusable transformation graphs for publication-ready artifacts.
+- **Decided for this draft:** The repository owns the bounded concern described here and participates through versioned contracts.
+- **Proposed:** Target systems and later roadmap phases remain proposals until accepted and implemented.
+- **Open question:** Which parts of this draft should become active in the first independently versioned release?
diff --git a/VISION.md b/VISION.md
new file mode 100644
index 0000000..62f8e9e
--- /dev/null
+++ b/VISION.md
@@ -0,0 +1,58 @@
+---
+schema: aether.architecture-document/v1
+id: renderflow-vision
+title: Renderflow Vision
+kind: architecture-document
+version: 0.1.0
+status: draft
+owners:
+  - egohygiene
+created: 2026-08-19
+updated: 2026-08-19
+governed_by:
+  - architecture-vision
+depends_on:
+  - renderflow-purpose
+related:
+  - renderflow-principles
+  - renderflow-pillars
+  - renderflow-manifesto
+  - renderflow-epistemology
+supersedes: []
+---
+
+# Renderflow Vision
+
+## Vision statement
+
+a portable rendering graph can turn one governed source into trustworthy outputs across formats without sacrificing provenance or control.
+
+## Desired future state
+
+- The core capability is independently usable and documented.
+- Interfaces are versioned, inspectable, and replaceable.
+- Local, self-hosted, and managed contexts can compose the capability without hidden lock-in.
+- People can understand consequential behavior before approving it.
+- Organization integrations strengthen the standalone product rather than making it dependent on the suite.
+
+## Intended transformation
+
+The project moves its domain from fragmented, implicit, and manually coordinated behavior toward explicit contracts, reusable automation, and evidence-backed operation.
+
+## Anti-vision
+
+an opaque conversion wrapper that promises universal output while concealing tool limitations or lossy transformations.
+
+## Directional signals
+
+- A first-time user can explain the boundary after reading the architecture.
+- A consumer can integrate through a stable public contract.
+- A maintainer can reproduce and validate a release.
+- A contributor can distinguish implemented, proposed, and unavailable capabilities.
+
+## Evidence and uncertainty
+
+- **Observed:** The repository README and checked-in implementation establish a specification-driven Rust rendering engine that plans and executes reusable transformation graphs for publication-ready artifacts.
+- **Decided for this draft:** The repository owns the bounded concern described here and participates through versioned contracts.
+- **Proposed:** Target systems and later roadmap phases remain proposals until accepted and implemented.
+- **Open question:** Which parts of this draft should become active in the first independently versioned release?