# Oshun V1 Features > **Brand & release scope (2026-08-05).** The V1 consumer product is named > **Lilith** (app + in-app assistant persona; company **Oshun Synthetics LTD**; > app at `lilith.oshunsynthetics.com`, company site `oshunsynthetics.com`) — > naming record in [`V1/BRAND.md`](./BRAND.md). "Oshun V1" below refers to the > platform release, not the consumer brand. > > **The V1 line ships in three releases.** This document is the feature map for > the whole line; it is not a V1.0 shipping list. Read every feature below > against this table: > > | Release | Ships | > | -------- | ------------------------------------------------------------------------------------------- | > | **V1.0** | Customer web app + PWA. Four rooms: **Tara, Nyx, Arete, Nisaba**. Crypto payment rail only. | > | **V1.1** | Native mobile apps (iOS/Android/watch) and the fiat payment rails. | > | **V1.2** | The **Veritas** and **Metis** rooms. | > > Three consequences for reading this document: > > 1. **Mobile app surfaces described as V1 are V1.1 deliverables.** The mobile > codebase stays in-tree; its rebrand to Lilith is a V1.1 work item. > 2. **The Veritas and Metis sections are V1.2.** Their libraries, contracts, > routes, and services stay in the tree and stay worth building — governance > stocks those rooms before they open — but no V1.0 console may advertise, > link to, count, or compose them. > 3. **Payment features other than the Aje crypto rail are V1.1.** Card, bank, > wallet, PayPal, mobile-money, and the app-store rails all move with the > native apps. > > The cut is declared once in `libs/oshun/navigation/src/release-scope.ts` and > read by every console; see the _V1 release scope_ section of > [`V1/BRAND.md`](./BRAND.md) for the enforcement points. Status: Derived V1 feature inventory Source: `V1/TODOS.md` Audience: Product, design, engineering, and governance leads scoping V1 Date: 2026-05-11 (originated) · 2026-06-24 (refined, decomposed into `features/` pages, and audited against code — see [`AUDIT_2026-06-24.md`](./AUDIT_2026-06-24.md)) ## Purpose This document is the feature map for Oshun V1. It translates the V1 execution backlog into a product-shaped scope document and describes what V1 is expected to ship across customer, admin, assistant, and platform surfaces. It does not replace the backlog checklist — the checklist at `V1/TODOS.md` remains the source of truth for completion state — but every feature listed here is grounded in tasks explicitly laid out in that backlog plus the product behavior those tasks imply. The companion [`V1/ARCHITECTURE.md`](./ARCHITECTURE.md) describes the runtime and package architecture; the dependency registry lives at [`V1/DEPENDENCIES.md`](./DEPENDENCIES.md). Oshun V1 is a unified customer, admin, assistant, and platform product. The customer experience is Tara-centered and spans six first-class domains: Tara, Arete, Veritas, Nyx, Nisaba, and Metis — of which **V1.0 opens four** (Tara, Nyx, Arete, Nisaba); Veritas and Metis arrive in V1.2. Six platform substrates — Sophia, Iris, Psyche, Lilith, Isis, and Aje — provide grounding, assistant memory, real-time runtime, contemplative safety, governed generation, and non-custodial payment settlement, respectively. The admin products operate review, safety, support, privacy, research integrity, persona operations, model operations, rights, provenance, incident response, and launch readiness on top of those substrates. The Subsystem Glossary below describes each name and its ownership in one place; the rest of the document expands those responsibilities into shippable features. ## Subsystem Glossary This glossary fixes the vocabulary used across the entire V1 feature set. Each entry names a subsystem and the product responsibility it owns, and — because the names are also the names of real code — points at the actual library or app that backs it. It serves anyone reading the domain, substrate, surface, or governance pages who needs to know exactly what "Sophia" or "Aje" or "Studio" refers to. The glossary is about **product responsibility and code grounding**, not architecture internals; the runtime layout lives in Architecture, Platform Foundations, and Security. 📄 **Full detail:** [Subsystem Glossary](./features/glossary.md) ## Cross-Reference Convention This document and its companion architecture doc use a consistent reference notation so a reader can always tell which artifact a citation points at. - A bare `§N` or `§N.M` resolves to a numbered section of the V1 execution backlog, [`V1/TODOS.md`](./TODOS.md) — e.g., `§ 25` is the Living Scenes backlog section. - `deps§N` resolves to a numbered section of the V1 dependency registry, [`V1/DEPENDENCIES.md`](./DEPENDENCIES.md). - `arch§""` resolves to a named section of [`V1/ARCHITECTURE.md`](./ARCHITECTURE.md) by its heading anchor. - `features§""` resolves to a named section of this document by its heading anchor. The features and architecture documents use named heading anchors (the lowercased, hyphenated heading text). The backlog and dependency registry use numbered sections. Within this document a cross-reference to another section is written as plain prose ("see the Living Scenes section") or as a Markdown link; a bare `§N` always points at the backlog, never at a section of this document. ## How this document is organized > **This feature map has been decomposed into focused pages under > [`features/`](./features/README.md).** This file remains the canonical hub: it > preserves every section heading (so existing `features§"…"` and > `features.md#…` anchors keep resolving) and, under each, links to the in-depth > page that expands it. Start at the > [features page index](./features/README.md). The runtime/package architecture > is in [`ARCHITECTURE.md`](./ARCHITECTURE.md) / > [`architecture/`](./architecture/README.md); the 2026-06-24 review/audit > ledger is in [`AUDIT_2026-06-24.md`](./AUDIT_2026-06-24.md). ## V1 Product Promise The Product Promise is the contract V1 makes to everyone who builds it, operates it, or uses it: that Oshun ships as **one coherent product** — a single shell with continuous identity, memory, and trust signals across web, mobile, assistant, and notifications — rather than a directory of disconnected domain apps stitched together at launch. It is the north star that the domain pages, the platform-substrate pages, and the Subsystem Glossary all serve. This page expands the promise into testable commitments, names the real code that already encodes (or contradicts) each one, and is candid about where the promise is aspirational rather than shipped. 📄 **Full detail:** [V1 Product Promise](./features/product-promise.md) ## Product Surfaces This page is the customer-facing inventory of _where_ Oshun V1 is touched: the web app and its two coordinated namespaces, the phone-first mobile app, the shared shell every customer app composes from, the desktop companion, the offline substrate, and the public distribution funnel. It serves product and design leads who need the real list of what ships versus what is reachable but launch-gated, and engineers deciding which surface a customer capability belongs in. It is the feature-side companion to the architecture catalog at Product Surfaces, which documents how the same surfaces are _assembled_ from shared libraries and the single BFF; the hub for this set is ../features.md. 📄 **Full detail:** [Product Surfaces](./features/product-surfaces.md) ### Customer Web ↳ Detailed in [Product Surfaces](./features/product-surfaces.md). #### Dual customer-surface namespaces ### Customer Mobile ↳ Detailed in [Product Surfaces](./features/product-surfaces.md). ### Shared Consumer Shell ↳ Detailed in [Product Surfaces](./features/product-surfaces.md). ### Account The account hub (`/profile`, `/settings`, and seven specialization routes) is where a member manages identity, plan, preferences, privacy and consent, data rights, devices, notifications, assistant memory, persona voice, Telegram linking, and crisis-aware safety settings — one authenticated panel (`ProfileSettingsPanel`) over the `/v1/profile` and `/v1/preferences` BFF projections, composing controls whose enforcement lives in the Iris, Lilith, privacy, and billing subsystems. 📄 **Full detail:** [Account, Profile, and Settings](./features/account-and-profile.md) ### Public Web and Distribution ↳ Detailed in [Product Surfaces](./features/product-surfaces.md). ## Domain Features ### Tara Tara is Oshun V1's experiential spine: the contemplative-practice domain that turns a stated mood or moment into a single trustworthy invitation to sit, breathe, or rest, and then carries the person humanely across days, programs, and lineages. It serves people seeking meditation, breathwork, sound, and prayer-style practice as everyday customers (the consumer hub at `/tara`) and practitioners or operators who need depth tools (the `/domains/tara/*` surface tree). This page is the feature-side companion to the architecture catalog; the hub for the set is ../features.md. Unlike a CRUD library of audio files, Tara's domain model is genuinely contemplative: per-mood recommendation slates with crisis handoff, breathwork cadences measured in inhale/hold/exhale seconds, lineage syncretism gates, a session state machine, and a continuation model that respects prerequisites — all of it shipped as validated contracts in `libs/contracts/src/tara/index.ts` (2,688 lines, re-exported via `export * from './tara'` at `libs/contracts/src/index.ts:25`). 📄 **Full detail:** [Tara — Rituals and Contemplative Practice](./features/domain-tara.md) #### Tara Taxonomies and Session Model #### Tara Triggers, Scheduling, and Humane Recovery #### Tara Audio, Accessibility, and Save/Share ### Arete Arete is the goals, habits, discipline, reflection, and coaching domain of Oshun V1 — the place a member declares who they are trying to become, checks in against that intention day by day, and is met with humane recovery rather than shame when life interrupts the rhythm. It serves the self-directed practitioner who wants structure without a punishing streak counter, and it sits inside the single Oshun shell alongside the contemplative domain (Tara — Rituals and Contemplative Practice), the grounded-claims domain (Veritas — Grounded Stories and Claims), and the assistant. Among the V1 domains it is one of the most code-complete: the data model and the core recovery and friction algorithms are real and domain-specific, while a handful of end-to-end UI and persistence seams — habit wizard cross-device sync, the Living Offerings intention-capture textarea, and the session→streak write — are still in progress. 📄 **Full detail:** [Arete — Goals, Habits, and Reflection](./features/domain-arete.md) #### Arete Habit, Goal, and Routine Schema #### Humane Streak and Recovery Policy #### Friction, Interventions, and Pattern Analysis #### Weekly Review and Reflection #### Living Offerings ### Veritas > **Release: V1.2.** Veritas is not part of V1.0. Everything below stays in the > tree and stays worth building — the room has to be stocked and reviewed before > it opens — but no V1.0 console may advertise, link to, count, or compose it. > See the release table at the top of this document. Veritas is the grounded story, claim, evidence, source, and explainer domain of Oshun V1 — the place a reader meets the news and the empirical record with the _sourcing_ attached: every claim carries a confidence band, every source carries a quality band and a reviewer attestation, every competing view is surfaced side-by-side rather than silently hidden, and when a source later retracts, the correction _cascades_ to every dependent surface the reader ever saw. It serves the reader who wants to know not just _what_ is claimed but _how strongly it is supported and by whom_, and it sits inside the single Oshun shell alongside the contemplative domain (Tara — Rituals and Contemplative Practice), the goals domain (Arete — Goals, Habits, and Reflection), the scholarly-study domain (Nisaba — Scholarly Study), the education domain (Metis — Education and Tutoring), and the assistant. 📄 **Full detail:** [Veritas — Grounded Stories and Claims](./features/domain-veritas.md) #### Veritas Trust, Confidence, and Counterclaim Model #### Story, Topic, and Timeline Schema #### Story Update, Correction, and Retraction #### Editorial Workflow, Source Verification, and Contradiction Detection ##### Source-quality scoring algorithm ##### Expert-attestation workflow ##### Counterclaim-balance rules ##### Topic-hub composition algorithm ##### Retraction-cascade UX ##### Contradiction-detection loop with Sophia ##### Veritas editorial state machine ##### Tests ### Nyx Nyx is V1's sky, awe, calendar, event, and cosmic-perspective domain — the place a member opens to find out what is happening overhead tonight, whether it is worth going outside, what it means, and how to keep a record of what they saw. It serves the curious and the contemplative alike: a casual stargazer checking the next meteor shower, an enthusiast logging an aurora through binoculars, or someone who wants a Tara perspective meditation tied to the night sky. Nyx sits among the six customer-facing domains (Tara, Arete, Veritas, Nyx, Nisaba, Metis; V1.0 opens Tara, Arete, Nyx, and Nisaba) hubbed at ../features.md, and it is unusual among them in carrying a **genuine astronomical compute core** rather than a thin CRUD layer — see the companion architecture deep-dive Customer Domains. 📄 **Full detail:** [Nyx — Sky Events and Perspective](./features/domain-nyx.md) #### Nyx Event and Observation Model #### Nyx Cross-Domain Companions ### Nisaba Nisaba is Oshun V1's scholarly study domain: the home for primary-source texts, manuscript witnesses, critical editions, translations, lexicon and morphology data, a text-anchored concept graph, annotations, notebooks, study plans, and citations. It serves the reader who wants to study a passage in depth — comparing editions and translations, inspecting a manuscript image beside its transcription, looking up a word's morphology, or tracing a concept across traditions — and it serves credentialed scholars who review and constitute that material. Architecturally, Nisaba sits as one of the V1 consumer domains under the unified shell (alongside Tara, Arete, Veritas, Nyx, and Metis), backed by a deep contracts substrate and a large collection of philology engines. This page is the canonical reference for what is implemented today, what is contract-modeled but not yet wired at runtime, and what is honestly aspirational. 📄 **Full detail:** [Nisaba — Scholarly Study](./features/domain-nisaba.md) #### Nisaba Text, Edition, and Concept-Graph Model #### Nisaba Study, Scholar Mode, and Cross-Domain Companions ### Metis > **Release: V1.2.** Metis is not part of V1.0. Everything below stays in the > tree and stays worth building — the room has to be stocked and reviewed before > it opens — but no V1.0 console may advertise, link to, count, or compose it. > See the release table at the top of this document. Metis is the educational substrate of Oshun V1 — the domain that turns approved source material into grounded courses, runs an adaptive tutor loop, calibrates assessments with real psychometrics, and emits grades and integrity verdicts to institutional systems. It serves three audiences at once: the self-directed learner who wants a structured path through hard ideas, the teacher or institution that needs standards-conformant delivery and a defensible gradebook, and the platform operator who has to keep a high-risk bring-your-own-model surface safe. It sits in the same single Oshun shell as the contemplative domain (Tara — Rituals and Contemplative Practice), the goals domain (Arete — Goals, Habits, and Reflection), and the scholarly-study domain (Nisaba — Scholarly Study). 📄 **Full detail:** [Metis — Education and Tutoring](./features/domain-metis.md) #### Tutor Runtime Modes #### Academic Integrity Modes and Verdicts #### Misconception Graph #### Mastery Model and Item Calibration #### Standards, Rostering, and Institutional Delivery Conformance #### Living Scenes integration #### Adaptive Learning Loop, Themis Adjudication, and BYOM Safety ##### Mastery transition model ##### Personalization manifold ##### Adaptive loop sequence ##### Themis adjudication mechanics ##### BYOM safety surface ##### Institutional gradebook contract ##### Tests ## Content Authoring, Curation, and Editorial Operations Oshun V1 ships large amounts of grounded, expert-curated, and AI-assisted content across rituals, practices, stories, claims, sources, passages, sky events, lessons, courses, and assistant-explainer modules. That content does not appear by magic: it is produced by named creators working a structured pipeline inside **Oshun Studio**, a first-class product surface rather than an afterthought buried in the admin shell. This page covers the two foundations of that surface — **who is allowed to do what** (the creator role and contributor model) and **the authoring workspace itself** (the structured block editor, the live source panel, the inline AI-assist panels, preview-as-customer parity, and the authoring-time evaluation harness). It is the feature-side companion to the architecture catalog; the hub for the set is ../features.md. The editorial calendar, lifecycle, and asset library that this workspace feeds into are covered in Editorial Calendar and Asset & Media Library; taxonomy, localization, and versioning in Taxonomy, Localization, and Versioning; and collaboration, review, and templates in Collaboration, Review, and Templates. 📄 **Full detail:** [Creator Roles and the Authoring Workspace](./features/authoring-workspace-and-roles.md) ### Creator and Contributor Roles ↳ Detailed in [Creator Roles and the Authoring Workspace](./features/authoring-workspace-and-roles.md). ### Authoring Workspace ↳ Detailed in [Creator Roles and the Authoring Workspace](./features/authoring-workspace-and-roles.md). ### The Tara Content Workbench The Tara meditation-content domain gets its own pipeline built on the authoring foundation: a spark is triaged into a concept, developed through premise, outline, and script, cleared by a five-gate safety/grounding battery and a human approval ladder, then carried across a schema-validated publishing bridge into the real `apps/tara/content` tree. Program steering is tighten-only by construction, and every unconfigured integration refuses fail-closed rather than fabricating a result. ↳ Detailed in [The Tara Content Workbench](./features/tara-content-workbench.md). ### Editorial Calendar and Lifecycle Once a creator has drafted an artifact in the authoring workspace, two cross-cutting systems carry it the rest of the way: the **editorial calendar and lifecycle** that schedules, gates, and publishes it, and the **asset and media library** that holds every image, audio clip, voiceover, rendering, and scan it depends on. Both are domain logic in `libs/oshun/studio-authoring` (`@oshun/studio-authoring`), shared across every content domain so a Tara passage, a Veritas briefing, and a Metis lesson all move through the same state machine and draw from the same asset pool. This page is the feature-side companion to the architecture catalog; the hub is ../features.md. It assumes the creator-role and authoring foundations described in Creator Roles and the Authoring Workspace, and it feeds into Taxonomy, Localization, and Versioning and Collaboration, Review, and Templates. 📄 **Full detail:** [Editorial Calendar and Asset & Media Library](./features/editorial-and-asset-library.md) ### Asset and Media Library ↳ Detailed in [Editorial Calendar and Asset & Media Library](./features/editorial-and-asset-library.md). ### Taxonomy, Ontology, and Concept Graph Curation These three Oshun Studio disciplines — concept-graph curation, the translation workspace, and per-artifact version control — are the connective tissue that keeps published content coherent, multilingual, and reversible as it ages. They serve curators, translators, reviewers, and editors who work behind the customer experience, and they sit inside the §16 Studio surface (a route tree under `apps/oshun/web/src/app/studio/`, not a separate app). All three are **implemented as real, domain-specific logic** — not CRUD stubs — in the source library `@oshun/studio-authoring` (v0.1.0, pure ESM, `main`/`types` pointing at `./src/index.ts`), which re-exports nine subdomain modules including `taxonomy-curation`, `localization-workflow`, and `versioning`. This page is the feature-side companion to the architecture catalog; the hub for the set is ../features.md. 📄 **Full detail:** [Taxonomy, Localization, and Versioning](./features/taxonomy-localization-versioning.md) ### Localization and Translation Workspace ↳ Detailed in [Taxonomy, Localization, and Versioning](./features/taxonomy-localization-versioning.md). ### Versioning, Diff, and Rollback ↳ Detailed in [Taxonomy, Localization, and Versioning](./features/taxonomy-localization-versioning.md). ### Collaboration, Comments, and Review Threads Two Oshun Studio disciplines sit at the human edge of authoring: the **collaboration** layer (presence, comments, suggestions, review signoff, and activity feeds) and the **templates** library (a role-aware gallery of governed, pre-bound content scaffolds). They serve editors, reviewers, SMEs, translators, and tenant operators working inside the §16 Studio surface (a route tree under `apps/oshun/web/src/app/studio/`, not a separate app). Both are **implemented as real, domain-specific logic** in the source library `@oshun/studio-authoring` (v0.1.0, pure ESM, `main`/`types` → `./src/index.ts`), which re-exports nine subdomain modules including `collaboration` and `templates`. This page is the feature-side companion to the architecture catalog; the hub for the set is ../features.md. 📄 **Full detail:** [Collaboration, Review, and Templates](./features/collaboration-and-templates.md) ### Customer Curation, Notebooks, Collections, and Sharing Customer Curation is V1's **personal-knowledge layer**: the customer-facing surfaces that let a member keep, organize, annotate, share, and re-find anything they encounter anywhere on the platform — a Veritas claim, a Nisaba passage, a Nyx sky event, a Metis lesson, a Tara meditation transcript, an Arete habit, or a generated artifact. It serves every domain rather than belonging to any one of them, and it is the substrate that Search, Discovery, Recommendations, and Knowledge Graph read back from. The curation **logic is real and non-stub** — it ships as a pure, dependency-free contracts-and-logic library, `@oshun/customer-curation` — while the _platform plumbing_ (durable persistence, deletion propagation, audit logging, cross-device _sync_) lives outside that library. This page documents both layers honestly. The backlog is §17; the companion deep-dive is Customer Curation. 📄 **Full detail:** [Customer Curation, Notebooks, Collections, and Sharing](./features/customer-curation-notebooks.md) ### Templates Library ↳ Detailed in [Collaboration, Review, and Templates](./features/collaboration-and-templates.md). ## Assistant, Memory, Persona, and Embodiment ### Assistant Experience The Oshun assistant is the conversational surface that sits on top of every V1 domain — it is the thing a member talks to from the shell home, a customer launches from a story or a sky chart, and an operator invokes from the admin cockpit. This page covers the **shell** half of that experience: how the assistant is invoked, what travels with it from the screen, the interaction modes it runs in, how personas hand off, how it degrades safely when a subsystem is down, and how it bridges into the two substrates that own the hard policy — Iris (durable memory) and Psyche (real-time runtime). It is the feature-side companion to the two substrate pages it depends on: Iris Memory and Identity and Psyche Real-Time Runtime. Persona roles and tone come from Lilith Persona Policy; the hub for the whole set is ../features.md. Backlog for this surface lives at `§2.5` in `../TODOS.md`. 📄 **Full detail:** [Assistant Experience](./features/assistant-experience.md) ### Iris Memory and Identity Iris is the subsystem that decides **what the assistant remembers, for how long, under what conditions, and who else can ever see it.** It owns assistant identity, the memory scope hierarchy, retention and decay, conflict resolution, privacy-aware suppression, cross-device continuity, and the operator-inspection regime. Iris serves every customer-facing surface in V1 — the Assistant Experience, Tara, Arete, Veritas, Nyx, Nisaba, and Metis — plus the governed admin path described in Review, Compliance, and Trust & Safety and Privacy, Consent, Data Portability, and User Controls. It sits between the Psyche Real-Time Runtime, which produces the conversational turns, and the durable governance substrate, which audits every recall, write, and inspection. Backlog and acceptance criteria live under `§10` of `V1/TODOS.md`; the contracts referenced here are shipping Zod schemas in `libs/contracts/src/iris/` and the runtime lives in the `@oshun/memory-iris` package (`libs/oshun/memory-iris/`). 📄 **Full detail:** [Iris Memory and Identity](./features/iris-memory-identity.md) #### Memory Scope Hierarchy #### Retention, Decay, and Compaction #### Conflict Resolution #### Privacy-Aware Suppression #### User-Facing Memory Controls #### Operator Inspection Regime #### Evaluation and Safety #### Memory Entry Schema, Recall Mechanics, and Workflows ##### MemoryEntry contract ##### Recall-resolution algorithm ##### Inference vs confirmation policy ##### Customer memory UX flows ##### Multi-actor memory ##### Cross-device continuity protocol ##### Admin inspection state machine ##### Tests ### Psyche Real-Time Runtime Psyche is the V1 **real-time embodiment substrate**: it owns the contract for a live text, voice, and avatar session — the session envelope, the event model, turn-taking, interruption, reconnect, transcript sync, lip-sync, expression coherence, latency budgets, quality thresholds, fallback routing, crisis-frame continuity, and diagnostics. It serves every customer-facing surface that needs to _embody_ a persona in real time (the assistant voice mode, a Metis tutor session, a Living Scene), and it sits underneath the persona/policy substrate (Lilith Persona Policy) and alongside identity and memory (Iris Memory and Identity). For the substrate's place in the platform see the companion Psyche — Real-Time Runtime Substrate. 📄 **Full detail:** [Psyche Real-Time Runtime](./features/psyche-realtime-runtime.md) #### Session Envelope and Event Model #### Latency Budgets and Quality Thresholds #### Fallback Chain #### Diagnostics, Replay, and Audit #### Continuity Tests #### Living Scenes integration ### Lilith Persona Policy Lilith is the V1 **contemplative policy substrate** — the deterministic rule engine that decides _how Oshun is allowed to speak_ whenever a persona, a generated artifact, or an assistant turn touches contemplative, spiritual, therapeutic, or safety-sensitive ground. It is a substrate, not a customer domain: there is no first-read Lilith surface; instead its tone, claim, crisis, voice, lineage, and unsafe-output rules are meant to fire _inline_ across whichever surface the member is on — a Tara ritual, a Veritas claim, a Sophia answer, a Metis tutor exchange, a Living Scene render. This page documents the policy catalogs and detectors that exist as real, versioned, tested code, names the concrete TypeScript symbols that back each rule, and is candid about which parts are fully wired into every runtime surface versus which are catalog-complete but only partially fanned out. It serves platform and trust-and-safety readers who need to reason about exactly what Lilith refuses, where its teeth actually bite, and what is still design intent. 📄 **Full detail:** [Lilith Persona Policy](./features/lilith-persona-policy.md) #### Contemplative Tone Rubric #### Teacher Persona Safety Policy #### Crisis-Aware Behavior #### Voice-Quality Policy #### Voice-Abuse Policy #### Spiritual-Domain Boundary Rules #### Unsafe-Claim Handling #### Wiring, Versioning, and Evaluation #### Continuous-video tone class (Living Scenes) #### Persona Taxonomy, Tone Band Catalog, and Crisis Recovery Journey ##### Persona taxonomy ##### Tone band catalog ##### Cultural and lineage sensitivity policy ##### Persona lifecycle ##### Crisis recovery journey ##### Tests ### Persona, Avatar, and Voice Packs Personas, avatars, and voice packs are the platform's governed _embodiments_ — the named characters a customer talks to (a Tara contemplative teacher, an Arete coach, a Metis explainer, the shell concierge), together with the optional synthetic voice and avatar that give them a face and a sound. They are first-class, lifecycle-managed assets with declared modality combinations, consent artifacts, watermarks, lineage attribution, and multi-party release gates — never ad-hoc prompt strings. This page sits at the cross-domain layer of V1: every domain (`tara`, `arete`, `veritas`, `nyx`, `nisaba`, `metis`) and every operator surface (`shell-assistant`, `studio`, `admin`) looks personas up by id, and a premium voiced or avatar experience ships only after Lilith Persona Policy, Sophia Grounding (where pedagogical), Iris Memory and Identity, the Isis Generation Control release gate, rights/provenance, and trust-and-safety review have all signed off. 📄 **Full detail:** [Persona, Avatar, and Voice Packs](./features/persona-avatar-voice-packs.md) #### Persona Registry and Metadata #### Avatar Pack Contracts #### Voice Profile Contracts #### Trust Gates #### Lifecycle, Rehearsal, and Release Gates #### Evaluation Suites ### Mentor Presence — Meditating with a Master Mentor Presence is the extension that turns the meditation player's static artwork into an embodied guide: when a customer begins a guided sit with the experience turned on, the player opens onto a contemplative setting and one to three governed mentor personas arrive — already present, walking in from beyond the frame, rising from the water, or condensing out of mist — settle into a lineage-appropriate meditation posture, and guide the session with voice, cadence-locked breath, and held silence. It composes the persona registry's avatar/voice/consent contracts, the Tara session state machine and breathwork cadences, the Living Scenes decision layer, and the Lilith disclosure and crisis gates; it is opt-in, entitlement-gated, and degrades down a strict fallback ladder to today's artwork experience. **Implemented 2026-07-06** — 20 of 22 §36 tasks are checked with evidence notes; the two open tasks are human gates (lineage review; release rehearsals + signoffs), on which the release-gate routing fails closed. 📄 **Full detail:** [Mentor Presence — Meditating with a Master](./features/mentor-presence.md) #### The Seam It Replaces #### The Experience, Precisely #### Delivery: Authored Performances First, Live Rendering Later #### What Exists Today vs. What Must Be Built #### Governance — the Non-Negotiables #### Accessibility #### Tiering and Opt-In ## Grounding, Generation, Media, and Search ↳ Detailed in [Persona, Avatar, and Voice Packs](./features/persona-avatar-voice-packs.md). ### Sophia Grounding Sophia is OSHUN's **grounding substrate** — the subsystem that any product output leans on when correctness or attribution matters. It scores source credibility, composes grounded answers that never assert beyond their evidence, models evidence packs and citation trails, and (in spec) gates the publication of high-stakes content. Sophia is explicitly a _substrate, not a shell peer_: it has no consumer-facing tab of its own (its `directSurface` is `workbench_only`), and its evidence flows into the assistant, Veritas, Nisaba, Metis, Tara, Arete, and Nyx. This page distinguishes, candidly, between what ships live in V1, what exists in the repo as real-but-unwired engines, and what is specified for later — because Sophia's documentation has historically described the aspiration as though it were the running system. 📄 **Full detail:** [Sophia Grounding](./features/sophia-grounding.md) #### Evidence and Citation Contracts #### Retrieval Methods and Labeling #### Fact-Check Loop #### Contradiction Loop #### Unsupported-Claim Loop #### Orchestration, Checkpoints, and Publication Gates #### Customer and Admin Surfaces #### Evaluation Suites #### Ingestion Pipeline, Source Lifecycle, and Per-Type Adapters ##### Ingestion pipeline shape ##### Per-stage spec ##### Per-source-type adapters ##### Source lifecycle ##### Tests ### Isis Generation Control Isis is the governed-generation control plane of V1: every image, video, audio, voice, 3D, and Living Scene render the product produces must pass through an Isis-registered workflow class, an Isis-registered model, and the Isis release-gate machinery before it can reach a customer. Raw provider machinery — ComfyUI on RunPod, Stability, ElevenLabs, Suno, fal.ai-hosted video, Civitai model intake — is never customer-facing; **Isis is the only path**. This page is the substrate companion to the audience-facing surfaces: it specifies the registries, the promotion lifecycle, the fail-closed dispatch seam, provenance bundles, release gates, failover policy, and the operator surface. For how those capabilities are exposed to different customers, see Generation Audience Tiers and Surface Boundaries, External Model Intelligence and Execution Providers, and Output Gallery, Lineage, Branch, and Replay. 📄 **Full detail:** [Isis Generation Control](./features/isis-generation-control.md) #### Workflow, Model, and Provider Registries #### Environment Promotion and Release Gates #### Provenance Bundles #### Operator Surface ### Generation Audience Tiers and Surface Boundaries The same provider stack — Civitai intake, ComfyUI on RunPod, hosted image/voice/ music/video providers, and the 3D pipeline — serves **four canonical generation audience tiers** with non-overlapping exposure profiles. This page specifies the tier taxonomy as it actually exists in code, the canonical vocabulary of 28 named surfaces, the deterministic resolver that maps an entitlement bundle to a tier and a surface allowlist, and the deny-by-default boundary enforcement that keeps raw generation machinery off the contemplative product. It serves product, platform, and trust-and-safety readers who need to know _who can see what_ and _why the wrong customer cannot reach a surface even by typing its URL_. It sits on top of the Isis Generation Control substrate and is the front door for the External Model Intelligence and Execution Providers page. 📄 **Full detail:** [Generation Audience Tiers and Surface Boundaries](./features/generation-tiers-and-surfaces.md) ### Civitai and External Model Intelligence This page covers the two halves of V1's generation supply chain: the **external model intelligence** layer (governed intake of Civitai and other external model sources into Isis-owned records) and the **execution provider** layer (the adapter library, the BFF executors that drive live providers, the realtime streaming path, and the render-farm scheduler). It is written for operators, platform engineers, and anyone deciding what credentials a deployment needs. It serves the audience-facing tiers described in Generation Audience Tiers and Surface Boundaries and sits beneath the Isis Generation Control substrate that makes "Isis is the only path" structurally true. The honest summary up front: the intake policy, the adapter library, the executors, the release-gate wiring, and the realtime seam are **real and unit-tested**; every _live_ provider HTTP call is **env-gated and fail-closed by design** — with no key the resolver returns `null` and the job fails closed with `provider_not_configured`. 📄 **Full detail:** [External Model Intelligence and Execution Providers](./features/external-models-and-execution.md) ### ComfyUI, RunPod, and Execution Providers ↳ Detailed in [External Model Intelligence and Execution Providers](./features/external-models-and-execution.md). ### LoRA Training, Model Merging, and Tuning ↳ Detailed in [External Model Intelligence and Execution Providers](./features/external-models-and-execution.md). ### Curated Creator Generation Surfaces This page documents the creator-facing generation surfaces that sit on top of the V1 generation pipeline: the curated creator cards (illustration, narration, ambient audio, explainer, caption/dub, accessibility, Living Scene), the voice and music subsystems, and 3D generation and post-processing. It serves curated creators on the contemplative product and — for the heavier machinery — AAA-tier creators in Yemaya Studio, while the underlying execution providers stay operator-controlled. It is the surface layer above Isis Generation Control, Generation Audience Tiers and Surface Boundaries, and External Model Intelligence and Execution Providers; where every produced asset lands afterward is the Output Gallery, Lineage, Branch, and Replay. 📄 **Full detail:** [Creator Surfaces, Voice, Music, and 3D Generation](./features/creator-voice-music-3d.md) ### Atelier The Atelier (`/atelier`) is the customer-facing generative workshop — five rooms of making (Camera Obscura · image, Foundry of Voices · audio, Cinematheque · video, Forms · 3D, Stage of Motion · animated 3D) presented in the Lilith design register and governed by three house rules that front the platform's generation governance: only from a line, provenance shown, slow by default. Image casting is a real fail-closed provider seam (`POST /v1/atelier/cast`); member scenes are owner-scoped Postgres records; room presentation data is fixture-backed ahead of the planned per-room BFF contracts. 📄 **Full detail:** [The Atelier — Five Rooms of Making](./features/atelier.md) ### Voice Providers, Voice Cloning, and Audio Integrity ↳ Detailed in [Creator Surfaces, Voice, Music, and 3D Generation](./features/creator-voice-music-3d.md). ### Music and Audio Generation ↳ Detailed in [Creator Surfaces, Voice, Music, and 3D Generation](./features/creator-voice-music-3d.md). ### 3D Generation and Post-Processing ↳ Detailed in [Creator Surfaces, Voice, Music, and 3D Generation](./features/creator-voice-music-3d.md). ### Output Gallery, Lineage, Branch, and Replay The output gallery is the unified review-and-derive surface that sits at the _end_ of every Isis generation: once a workflow class has produced an image, video, narration, music track, 3D mesh, caption-dub, or accessibility pass, the artifact lands as an `OutputRecord` that the gallery can filter, trace through a lineage tree, branch, replay-with-tweak, compare side-by-side, and bulk-act on. It serves both the customer Studio (looking back over their own renders) and operators (governing the full corpus), and it is the join point where the generation pipeline meets the Editorial Calendar and Asset & Media Library, Living Scenes lineage, and the trust-&-safety takedown machinery. The whole subsystem is real, pure-function, and unit-tested in `libs/isis/output-gallery/` against §24.10. 📄 **Full detail:** [Output Gallery, Lineage, Branch, and Replay](./features/output-gallery-lineage.md) ### Search, Discovery, Recommendations, and Knowledge Graph Search and discovery are the cross-domain "find anything, then decide what to do next" surfaces of V1. They serve every member who opens the universal search sheet or scrolls a mixed-domain recommendation rail, and they sit one layer above the six customer domains — Tara, Veritas, Nyx, Arete, Nisaba, and Metis, of which V1.0 opens Tara, Nyx, Arete, and Nisaba — fanning a query or a request for recommendations out to each domain and blending the results back into one ranked list inside the BFF (`apps/oshun/bff`). This page is deliberately candid about a split the rest of the V1 docs glossed over: **there are two search-and-discovery stacks in this repository, and only the simpler one is on the live path.** The live `/v1/search` and `/v1/recommendations` routes do deterministic, lexical, domain-fan-out ranking over data the system actually holds; a much richer signal/candidate/ranker/experiment/concept-graph stack lives in `libs/oshun/search-discovery`, is fully tested, and is **explicitly retired from V1 scope**. Read everything below as a description of what runs today, with the aspirational library called out honestly wherever it appears. 📄 **Full detail:** [Search, Discovery, Recommendations, and Knowledge Graph](./features/search-discovery-recommendations.md) #### Searchable Object Catalog #### Signal Taxonomy #### Aggregation, Decay, and Freshness #### Candidate Generation #### Ranker Features and Coherence #### Online Experimentation #### Cold-Start Behavior #### Concept-Graph Substrate #### Evaluation ## Living Scenes Living Scenes is the V1 capability that lets a customer experience a continuous, visually responsive AI-generated video session — a contemplative arc whose underlying segments, transitions, narration, and grounding pins are governed and replayable, and which the user can shape live via voice, tap, or text. It serves the contemplative product (curated cards), the AAA-Creator and operator tier (authoring consoles in Yemaya Studio), and — for kept Living Offerings — the public web via a per-artifact viewer. In the V1 architecture it sits _on top of_ five substrates it does not own: the Yemaya generation substrate, the Psyche real-time runtime (Psyche Real-Time Runtime), the Isis governed control plane (Isis Generation Control), the Lilith policy substrate (Lilith Persona Policy), and Sophia grounding (Sophia Grounding). 📄 **Full detail:** [Living Scenes — Concept and Customer Promise](./features/living-scenes-overview.md) ### Concept and Customer Promise ↳ Detailed in [Living Scenes — Concept and Customer Promise](./features/living-scenes-overview.md). ### Scene Score Schema The Scene Score is the durable, portable contract at the heart of every Living Scene: an ordered list of Segments plus a Cue Plan plus a Render Envelope, which the Conductor runtime streams and from which a kept Living Offering is deterministically re-rendered. It serves the runtime (the schema the Conductor trusts), the BFF and queues (the schema that validates payloads crossing process boundaries), and persistence (the shape that is stored and replayed). It is the sibling contract to the Living Scenes — Concept and Customer Promise page and the input to Live Direction, Conductor Runtime, and Blend Kernel. 📄 **Full detail:** [Scene Score Schema](./features/scene-score-schema.md) ### Live Direction Channel This page documents the three runtime layers that turn a validated Scene Score into a streaming, continuous, viewer-steerable experience: the **Live Direction Channel** (how a viewer nudges a scene mid-flight), the **Conductor Runtime** (how segments are scheduled, pre-warmed, and handed off), and the **Blend Kernel** (how Segment N is stitched perceptually to Segment N+1). It serves the contemplative customer watching a Living Scene and the AAA creator authoring one in the Scene Score Editor; it sits between the Scene Score Schema that defines the artifact and the Composition Surface and Cinematographic Technique Catalog that decides which transition plays where. For the surrounding promise and concepts, start at Living Scenes — Concept and Customer Promise. 📄 **Full detail:** [Live Direction, Conductor Runtime, and Blend Kernel](./features/direction-conductor-blend.md) ### Conductor Runtime ↳ Detailed in [Live Direction, Conductor Runtime, and Blend Kernel](./features/direction-conductor-blend.md). ### Blend Kernel and Continuity Evals ↳ Detailed in [Live Direction, Conductor Runtime, and Blend Kernel](./features/direction-conductor-blend.md). ### Composition Surface and Cinematographic Technique Catalog The Composition Surface is the customer- and creator-facing affordance that arranges Segments into a Scene Score, and the Cinematographic Technique Catalog is the named layer that maps creator intent — "match cut," "L-cut," "smash cut" — onto the Blend Kernel's mechanical transition primitives, gated per Segment pair, per template, and per Lilith tone band. This page is part of the Living Scenes core (see Living Scenes — Concept and Customer Promise and Scene Score Schema); it sits one layer above the Blend Kernel's transition contracts and one layer below the rendered video that the Conductor streams. Everything documented here is **deterministic, pure decision logic** — the catalog, the compatibility scorer, the tone gates, and the compose-assist budgets are all real, contract-backed TypeScript with tests; the pixel-level work they govern (latent video generation, optical-flow warps, FVD computation, GPU determinism) lives downstream and is consumed only as **score inputs**, never computed in these modules. 📄 **Full detail:** [Composition Surface and Cinematographic Technique Catalog](./features/composition-cinematography.md) #### Customer-Tier Composition Surface #### Cinematographic Technique Catalog #### Segment-Pair Compatibility Matrix #### AI Compose Assist #### Per-Template Availability and Tone Gating #### Continuity-Eval Extensions for Named Techniques #### Tests ### Domain Templates Living Scenes ship at V1 as five authored **domain templates** — one per practising domain (Tara, Nyx, Veritas, Metis, Arete) — plus the authoring surfaces creators and operators use to build, rehearse, and promote new scores from those templates. A template is not a loose theme: it is a real workflow class with a machine ID, a locked cue-verb allowlist, a tone band, grounding and intent requirements, and a per-fixture eval gate that blocks promotion. This page sits in the living-scenes-core area alongside Scene Score Schema, Live Direction, Conductor Runtime, and Blend Kernel, and Composition Surface and Cinematographic Technique Catalog; it is where the abstract Score contract meets concrete, named, tested domain content. 📄 **Full detail:** [Domain Templates and the Scene Score Editor](./features/domain-templates-and-editor.md) #### Tara — Contemplative Arcs #### Nyx — Sky Briefings #### Veritas — Grounded Explainers #### Metis — Lesson Visualizers #### Arete — Living Offerings ### Authoring (AAA Scene Score Editor) ↳ Detailed in [Domain Templates and the Scene Score Editor](./features/domain-templates-and-editor.md). ### Safety, Tone, and Crisis Policy This page documents the governance spine of Living Scenes: the photosensitive-epilepsy (PSE) / strobe killer, the continuous tone-and-motion caps, the mid-stream crisis frame, the deterministic-render release gate, the four redundant provenance channels, and the two-layer (private / public-redacted) cue-privacy model. It serves the contemplative product, the AAA-Creator and operator authoring consoles, and trust-and-safety review; in the V1 stack it sits _on top of_ the Yemaya generation substrate and the Lilith policy substrate, and it is the most genuinely-implemented part of the Living Scenes story because governance is decision logic, not media rendering. Most of what follows is real, tested code in `libs/yemaya/living-scenes-runtime/src/` and `libs/oshun/trust-safety/src/`; where a piece is a fail-loud seam awaiting an upstream model or a real transcoder, this page says so plainly. See Living Scenes — Concept and Customer Promise for the customer framing and Lilith Persona Policy for the policy substrate this composes on. 📄 **Full detail:** [Scene Safety, Determinism, Provenance, and Cue Privacy](./features/scene-governance.md) ### Determinism, Render Envelope, and Re-Render-from-Score ↳ Detailed in [Scene Safety, Determinism, Provenance, and Cue Privacy](./features/scene-governance.md). ### Provenance, Watermarking, and C2PA Across Channels ↳ Detailed in [Scene Safety, Determinism, Provenance, and Cue Privacy](./features/scene-governance.md). ### Keep, Share, and Personal Artifacts This page documents what happens to a Living Scene _after_ it is rendered: how a user **keeps** a session as a personal artifact, how an explicit second consent turns it into a **share**, the per-component **shareability matrix** that decides how far an artifact can reach, the public-viewer and embed surface, the seven-disposition **takedown cascade**, tenant share policy, and reshare / lineage / remix attribution. It serves the contemplative product (users keeping and sharing offerings), the public web (a per-artifact viewer), and tenant and operator administration. In the V1 stack it sits between the renderer and the customer/public surfaces; the domain logic lives in `libs/yemaya/living-scenes-runtime/src/personal-artifacts/personal-artifacts.ts` and `…/shareability/matrix.ts` and `…/takedown/dispositions.ts`, and the HTTP surface is the 1871-line BFF route at `apps/oshun/bff/src/routes/living-scenes.ts`. The safety/provenance companion to this page is Scene Safety, Determinism, Provenance, and Cue Privacy. 📄 **Full detail:** [Keep, Share, Shareability, Takedown, and Lineage](./features/scene-sharing-distribution.md) ### Public Share Surface, Embed, and Off-Platform Distribution ↳ Detailed in [Keep, Share, Shareability, Takedown, and Lineage](./features/scene-sharing-distribution.md). ### Cue Privacy, Redaction, and Sensitive-Intention Handling ↳ Detailed in [Scene Safety, Determinism, Provenance, and Cue Privacy](./features/scene-governance.md). ### Shareability Matrix ↳ Detailed in [Keep, Share, Shareability, Takedown, and Lineage](./features/scene-sharing-distribution.md). ### Takedown Cascade Across Kept and Shared Artifacts ↳ Detailed in [Keep, Share, Shareability, Takedown, and Lineage](./features/scene-sharing-distribution.md). ### Tenant Entitlements and Share Policy ↳ Detailed in [Keep, Share, Shareability, Takedown, and Lineage](./features/scene-sharing-distribution.md). ### Reshare, Lineage, and Remix Attribution ↳ Detailed in [Keep, Share, Shareability, Takedown, and Lineage](./features/scene-sharing-distribution.md). ### Latency, Quality, and Backpressure Budgets This page documents the _quality spine_ of Living Scenes: the latency and backpressure budgets that keep a live scene responsive, the backend resolver that chooses between the chained-clip pipeline and the feature-flagged Phase 176 world-model, the reduced-motion and accessibility companions every Score ships with, and — most concretely — the per-template eval sets, release gates, and the deterministic test contracts that decide whether a workflow class is allowed to promote to the contemplative tier at all. It serves the AAA-Creator and operator authoring consoles (who watch these gates before they ship), trust-and-safety review (whose crisis and abuse signals feed the eval corpus), and the contemplative product (whose users feel the latency and accessibility budgets directly). In the V1 stack it sits _downstream_ of the Yemaya generation substrate and the governance spine documented in Scene Safety, Determinism, Provenance, and Cue Privacy: where governance decides _whether_ a frame is safe, this page decides _whether a whole workflow class renders well enough, fast enough, accessibly enough, and deterministically enough to ship_. Much of it is real, tested decision logic in `libs/yemaya/living-scenes-runtime/src/` (the published package `@yemaya/living-scenes-runtime`) and `libs/oshun/trust-safety/src/`; the latency numbers, the continuity-metric models (FVD, optical-flow morph), and the real pixel-level renders are upstream of these gates, and this page says so plainly wherever it matters. 📄 **Full detail:** [Latency, Accessibility, Eval Sets, and Tests](./features/scene-quality-and-eval.md) ### Backend Strategy and Phase 176 Bridge ↳ Detailed in [Latency, Accessibility, Eval Sets, and Tests](./features/scene-quality-and-eval.md). ### Reduced-Motion and Accessibility Renders ↳ Detailed in [Latency, Accessibility, Eval Sets, and Tests](./features/scene-quality-and-eval.md). ### Eval Sets, Release Gates, and Rollback ↳ Detailed in [Latency, Accessibility, Eval Sets, and Tests](./features/scene-quality-and-eval.md). ### Tests ↳ Detailed in [Latency, Accessibility, Eval Sets, and Tests](./features/scene-quality-and-eval.md). ## Agentic AI Studio The Agentic AI Studio is V1's first-class surface for autonomous content development, research, tutoring, curation, education, and operations. Agents here are not hidden orchestration: they are observable, governed, budgeted, attributable products consumed by customers, creators, operators, and Metis institutional partners across Oshun Web, Mobile, Studio, Admin, and the Tenant Console. This page is the foundational third of the Studio — the canonical **agent registry** (who exists and what authority they carry), the **job orchestration** layer that runs long-lived agent runs durably, and the **multi-agent plan / hand-off / approval-gate** machinery that keeps a research agent dispatching a Sophia retriever and an Isis generator from silently spinning into a runaway run. Its siblings cover the rest: Agent Invocation, Budgets, Memory, and Feedback Loops and Tool Catalog, Grant Semantics, and Multi-Agent Protocol. 📄 **Full detail:** [Agent Registry, Job Orchestration, and Multi-Agent Plans](./features/agentic-registry-jobs-plans.md) ### Agent Registry and Catalog ↳ Detailed in [Agent Registry, Job Orchestration, and Multi-Agent Plans](./features/agentic-registry-jobs-plans.md). ### Job Orchestration and Long-Running Runs ↳ Detailed in [Agent Registry, Job Orchestration, and Multi-Agent Plans](./features/agentic-registry-jobs-plans.md). ### Multi-Agent Plans, Hand-Offs, and Approval Gates ↳ Detailed in [Agent Registry, Job Orchestration, and Multi-Agent Plans](./features/agentic-registry-jobs-plans.md). ### Operator Job Dashboard, Replay, and Audit ↳ Detailed in [Agent Registry, Job Orchestration, and Multi-Agent Plans](./features/agentic-registry-jobs-plans.md). ### Customer- and Creator-Facing Agent Invocation This page specifies the _governance brain_ of the V1 Agentic AI Studio: how a customer or creator triggers an agent, how the platform proves a run is affordable and authorized before it starts, how budgets and kill switches stop a run mid-flight, how tool grants are resolved per call, and how new agent versions earn promotion through statistical readiness gates. It serves end customers (the assistant), creators (the authoring workspace), and operators (the console), and it is the substrate companion to Agent Registry, Job Orchestration, and Multi-Agent Plans and Tool Catalog, Grant Semantics, and Multi-Agent Protocol. Almost everything described here is implemented as value-tested pure TypeScript in `libs/oshun/agentic-studio` (`@oshun/agentic-studio` v0.1.0, 271 tests across 16 files); where the story is thinner than the prose — durable queues, a rich admin dashboard _page_, live provider tool execution — this page says so plainly. 📄 **Full detail:** [Agent Invocation, Budgets, Memory, and Feedback Loops](./features/agentic-invocation-budgets-grants.md) ### Budgets, Quotas, Throttles, and Kill Switches ↳ Detailed in [Agent Invocation, Budgets, Memory, and Feedback Loops](./features/agentic-invocation-budgets-grants.md). ### Agent Memory, Tool Grants, and Capability Audits ↳ Detailed in [Agent Invocation, Budgets, Memory, and Feedback Loops](./features/agentic-invocation-budgets-grants.md). ### Feedback Loops, Gold Sets, and Champion-Challenger Rollout ↳ Detailed in [Agent Invocation, Budgets, Memory, and Feedback Loops](./features/agentic-invocation-budgets-grants.md). ### Cost-Quality Controls and Mode Selection ↳ Detailed in [Agent Invocation, Budgets, Memory, and Feedback Loops](./features/agentic-invocation-budgets-grants.md). ### Cross-Domain Autonomous Pipelines ↳ Detailed in [Agent Invocation, Budgets, Memory, and Feedback Loops](./features/agentic-invocation-budgets-grants.md). ### Tool Catalog, Grant Semantics, and Multi-Agent Protocol This page specifies the _content_ of an agent's authority in the V1 Agentic Studio: the enumerated tool catalog, the per-tool grant scopes and revocation cascade, the multi-agent hand-off protocol, the runtime admission gate that makes those governance decisions act, and the concrete cross-domain pipeline patterns that compose them. It is the companion to Agent Registry, Job Orchestration, and Multi-Agent Plans (the families, lifecycle, and plan DAGs) and Agent Invocation, Budgets, Memory, and Feedback Loops (invocation surfaces, cost budgets, memory, and champion-challenger). Without the material here, an `AgentRun` is a black box — this is the layer that says exactly what a run is allowed to do, how that authority is granted and revoked, and how it is enforced when a tool is actually about to fire. 📄 **Full detail:** [Tool Catalog, Grant Semantics, and Multi-Agent Protocol](./features/agentic-tool-catalog.md) #### Tool catalog #### Grant scope and revocation cascade #### Multi-agent hand-off protocol #### Cross-domain pipeline pattern reference ##### Tests ## Admin Products The Admin products are the operator-facing control surfaces of Oshun V1: the Oshun Admin web console that platform operators use to run review, trust & safety, support, privacy, model ops, incidents, and readiness; and Oshun Admin mobile, an Expo app that puts urgent triage and step-up-protected approvals in an on-call operator's pocket. This page serves the operators who live in these surfaces, the engineers wiring the BFF route handlers, and reviewers who need to know which claims are backed by shipped code versus partially-covered UI. It sits beside the strictly-isolated Tenant, Institution, and Operator Toolkit: the operator-only Admin products described here are the platform-wide counterpart to the per-tenant console, and both draw on a shared domain library, `libs/oshun/tenant-console`. 📄 **Full detail:** [Admin Products — Web and Mobile](./features/admin-products.md) ### Admin Web ↳ Detailed in [Admin Products — Web and Mobile](./features/admin-products.md). ### Admin Mobile ↳ Detailed in [Admin Products — Web and Mobile](./features/admin-products.md). ## Tenant, Institution, and Operator Toolkit ↳ Detailed in [Admin Products — Web and Mobile](./features/admin-products.md). ### Tenant and Organization Admin The Tenant Toolkit is the per-tenant control plane of Oshun V1: the surfaces and domain logic an institution, school, research lab, partner organization, or managed cohort uses to run _its own slice_ of Oshun — members, content scopes, identity, custom roles, audit, bulk data, integrations, notifications, help, and status — strictly isolated from every other tenant and from Oshun's own platform-operator world. It serves tenant administrators (a district IT lead, a school's roster coordinator, a lab PI's delegate, a partner's integration engineer) and, in a more privileged read role, Oshun platform operators who investigate across tenants. Almost the entire toolkit is **shipped, real code**: the rendering app `apps/oshun/tenant-admin` is a thin Next.js layer, and the substance lives in the library `libs/oshun/tenant-console`, whose nine modules are deterministic, well-typed, and tested. Backlog tracking for the console substrate is §20 in ../TODOS.md. 📄 **Full detail:** [Tenant, Institution, and Operator Toolkit](./features/tenant-toolkit.md) ### Identity, SSO, SCIM, and Provisioning ↳ Detailed in [Tenant, Institution, and Operator Toolkit](./features/tenant-toolkit.md). ### Custom Roles and Permission Templates ↳ Detailed in [Tenant, Institution, and Operator Toolkit](./features/tenant-toolkit.md). ### Audit Log Explorer ↳ Detailed in [Tenant, Institution, and Operator Toolkit](./features/tenant-toolkit.md). ### Bulk Operations and Data Import/Export ↳ Detailed in [Tenant, Institution, and Operator Toolkit](./features/tenant-toolkit.md). ### API Keys, Webhooks, and Outbound Integrations ↳ Detailed in [Tenant, Institution, and Operator Toolkit](./features/tenant-toolkit.md). ### Notifications, Lifecycle Communications, and Template Authoring ↳ Detailed in [Tenant, Institution, and Operator Toolkit](./features/tenant-toolkit.md). ### Help Center and Knowledge Base Authoring ↳ Detailed in [Tenant, Institution, and Operator Toolkit](./features/tenant-toolkit.md). ### System Status, Maintenance, and Public Communications ↳ Detailed in [Tenant, Institution, and Operator Toolkit](./features/tenant-toolkit.md). ## Governance, Safety, Support, and Privacy ### Review, Audit, Compliance, Rights, and Provenance This page documents the governance spine that sits behind every Oshun V1 surface: the **review package** lifecycle that gates content and model releases, the **immutable audit and provenance** layer that records what happened, and the **Trust & Safety** subsystem that moderates content, assistant behavior, persona/voice/avatar usage, generated media, support contact, and educational integrity. It serves operators, reviewers, crisis-trained responders, and the compliance/legal functions; in the V1 stack the deterministic policy and state-machine cores live in `@oshun/trust-safety`, `@oshun/review-persistence`, and `@oshun/audit-platform`, while the runtime enforcement (real classifiers, live persistence, cross-domain fan-out) is the platform's job and is wired in at the application boundary. 📄 **Full detail:** [Review, Compliance, and Trust & Safety](./features/review-trust-safety.md) ### Trust and Safety ↳ Detailed in [Review, Compliance, and Trust & Safety](./features/review-trust-safety.md). #### Policy Taxonomy #### Severity Classes and SLAs #### Decision Classes and Appeals #### Crisis Handling Policy #### Abuse-Pattern Detection #### Appeal Evidence and Repeat-Offender Surfaces #### Evaluation Suites ### Support, Entitlements, Billing, and Customer Operations This page covers the customer-operations governance area of Oshun V1: how a customer's plan and feature access (**entitlements**) are defined, how money turns into entitlement (**billing**, settled crypto-first), how usage is metered and capped, how lapses and refunds are handled (**dunning** and **self-serve**), and how human help reaches the customer (**support cases**, SLAs, copilots). It serves paying customers, institutional contract owners, support agents, and the platform operators who run the billing and support machinery. In the V1 layering, the entitlement/billing/support core is real, shipped, deterministic domain code in `libs/oshun/billing-support` (package `@oshun/billing-support`, §23), composed by the product surfaces; the canonical crypto settlement that _funds_ those entitlements lives in the Aje domain (`libs/aje/`) and is documented on Crypto Payments — Non-Custodial Entitlement Settlement. Backlog tracking for this area is **§23** in ../features.md; the companion architecture page is Support, Billing, and Crypto. 📄 **Full detail:** [Support, Entitlements, Billing, and Customer Operations](./features/support-billing.md) ### Crypto Payments — Non-Custodial Entitlement Settlement V1 accepts payment for entitlements without custody, without KYC at the payment layer, and without routing funds through a centralized processor. Oshun never holds spending keys for customer-paid funds; every supported chain runs against a self-hosted full node and a watch-only (or view-only) wallet, so the hot path of the application server cannot move money even if fully compromised. This page documents both the **spec** (the operational and security posture V1 commits to) and the **shipped code** — and it is candid about where the two diverge, because several pieces of this subsystem are real, tested code while others are provider-gated or operational concerns that cannot be exercised inside the repo. It serves customers paying with crypto, operators running the settlement infrastructure, and the entitlement/billing machinery described in Support, Entitlements, Billing, and Customer Operations. 📄 **Full detail:** [Crypto Payments — Non-Custodial Entitlement Settlement](./features/crypto-payments.md) ### Privacy, Consent, Data Portability, and User Controls Privacy in Oshun V1 spans consent, retention, residency, deletion, export, operator access, and disclosure across the customer, creator, tenant, and institutional contexts. It is the user-facing half of the governance area: where Review, Compliance, and Trust & Safety governs what the product does _to_ content, this surface governs what the product may do _with_ a person's data — and gives that person the controls to grant, withdraw, inspect, export, and erase it. The deterministic core lives in `@oshun/privacy` (`libs/oshun/privacy/`); its modules are pure-function state machines and taxonomies, with the actual enforcement (live persistence, real fan-out across domains, immutable audit storage) supplied by the runtime that composes them. Backlog tracking for this area is **§22** in ../features.md; the architecture companion is Security, Privacy, and Compliance and Trust & Safety and Privacy. 📄 **Full detail:** [Privacy, Consent, Data Portability, and User Controls](./features/privacy-consent-portability.md) #### Consent Taxonomy #### Granularity, Default State, and Withdrawal #### Region, Residency, and Routing #### Export, Deletion, and Retention #### Customer-Facing Privacy Surface #### Admin DSAR and Operator-Access Workflow #### Compliance, Disclosure, and Audit ## Messaging Channels and Conversational Surfaces ↳ Detailed in [Privacy, Consent, Data Portability, and User Controls](./features/privacy-consent-portability.md). ### Channel Abstraction and Tier-Aware Routing This page documents the channel-abstraction layer that lets V1 deliver content over many messaging surfaces — Telegram, WhatsApp, email, push, SMS, Discord, Slack — through one common registry, one routing dispatcher, and one boundary contract, instead of bespoke glue per channel. It serves customers (delivery to their chosen channel) and tenants/operators (residency-aware allowlists and a full audit trail), and it sits beneath the per-surface pages Telegram Surfaces and WhatsApp, Email, Push, SMS, Discord, and Slack, which describe each transport in depth. The single rule that shapes everything here: **no AAA-creator or operator-admin intent ever reaches a messaging channel, and nothing is ever reported as "sent" unless a real provider transport actually sent it.** Almost all of this is implemented in `libs/oshun/messaging-channels/src`; the honest gaps are named explicitly at the end. 📄 **Full detail:** [Channel Abstraction, Routing, and Boundaries](./features/channel-abstraction-and-boundary.md) ### Telegram Bot — Delivery and Light Assistant Telegram is the first non-web surface Oshun ships, and it is the most fully realized one. It is not a thin proxy that re-renders the web app: it is a set of purpose-built surfaces — a conversational bot, embedded Mini Apps, operator publishing channels, inline-query cards, a binding/auth flow, and an optional fiat payment rail — each sitting on the same channel-policy core that governs every outbound message in V1. This page covers those surfaces, the real symbols that implement them in `libs/oshun/messaging-channels` and `apps/oshun/`, and the one honest gap: the live BFF outbound _send loop_ is still unimplemented even though the policy, grounding, auth, and rendering layers underneath it are real. For the cross-channel policy machinery shared with WhatsApp, email, push, SMS, Discord, and Slack, see WhatsApp, Email, Push, SMS, Discord, and Slack; for the architecture-level treatment see the companion doc Channel Abstraction, Routing, and Boundaries. 📄 **Full detail:** [Telegram Surfaces — Bot, Mini Apps, Channels, Inline, Auth, Payments](./features/telegram-surfaces.md) ### Telegram Mini Apps — Curated Studio Surfaces in Chat ↳ Detailed in [Telegram Surfaces — Bot, Mini Apps, Channels, Inline, Auth, Payments](./features/telegram-surfaces.md). ### Telegram Channels — Editorial Publishing Target ↳ Detailed in [Telegram Surfaces — Bot, Mini Apps, Channels, Inline, Auth, Payments](./features/telegram-surfaces.md). ### Telegram Inline Mode — Save, Share, Attribution ↳ Detailed in [Telegram Surfaces — Bot, Mini Apps, Channels, Inline, Auth, Payments](./features/telegram-surfaces.md). ### Telegram Authentication — Login Widget and Mini App initData ↳ Detailed in [Telegram Surfaces — Bot, Mini Apps, Channels, Inline, Auth, Payments](./features/telegram-surfaces.md). ### Telegram Payments — Entitlement Upgrade Flows (V1.x optional) ↳ Detailed in [Telegram Surfaces — Bot, Mini Apps, Channels, Inline, Auth, Payments](./features/telegram-surfaces.md). ### WhatsApp Business — Transactional Template Messaging This page documents every non-Telegram messaging surface V1 ships: WhatsApp Business, email, push (FCM, APNs, Expo, and W3C Web Push), SMS, Discord, and Slack. It serves customers (transactional and grounded delivery on whichever channel they have opted into), tenants and institutions (residency-aware allowlists, per-message cost ledgers, audit), and operators (deliverability monitoring and a credential→transport seam that fails loud instead of faking a send). All of it lives in one Nx library, `@oshun/messaging-channels` (`libs/oshun/messaging-channels/src`), and it sits beneath the shared routing spine described in Channel Abstraction, Routing, and Boundaries; its sibling surface page is Telegram Surfaces. 📄 **Full detail:** [WhatsApp, Email, Push, SMS, Discord, and Slack](./features/other-channels.md) ### Email, Push, and SMS Adapters ↳ Detailed in [WhatsApp, Email, Push, SMS, Discord, and Slack](./features/other-channels.md). ### Discord and Slack — Community and Institutional Surfaces ↳ Detailed in [WhatsApp, Email, Push, SMS, Discord, and Slack](./features/other-channels.md). ### Channel Boundary, Residency, Retention, Consent, Audit ↳ Detailed in [Channel Abstraction, Routing, and Boundaries](./features/channel-abstraction-and-boundary.md). ## Architecture and Platform Foundations ↳ Detailed in [Channel Abstraction, Routing, and Boundaries](./features/channel-abstraction-and-boundary.md). ### Security, Access Control, and Operational Hardening This page describes the load-bearing layer beneath every Oshun V1 domain: the canonical contracts, the persistence-alignment harness, the event and queue substrate, the inbound/outbound integration plumbing, the public-API authorization model, and the security controls that gate launch. It serves platform engineers, integrators, operators, and security reviewers — anyone who needs to know how a request travels from the shell to a domain service and back, what guarantees hold along the way, and which pieces are real versus spec-only. It sits "below" the customer-facing domain pages (Tara, Arete, Veritas, Nyx, Nisaba, Metis) and underneath the channel surfaces (Channel Abstraction); nearly all of it is implemented code with tests, not aspiration. Where a piece is contract-level or provider-gated, this page says so explicitly. 📄 **Full detail:** [Architecture, Platform Foundations, and Security](./features/platform-foundations-and-security.md) ## Design System and Experience Quality The Oshun V1 design system is the shared visual, behavioral, and copy foundation that every customer and admin surface is built on. It is not a style guide that lives in a deck — it ships as real, tested TypeScript: design tokens (`libs/oshun/design-tokens`), a reusable component library (`libs/oshun/ui`), the localization catalog (`libs/oshun/i18n`), and a suite of _auditable_ design-language modules (`libs/oshun/design-language`) that encode the rules an engineer or reviewer can query and a test can enforce. This page sits in the platform-quality area alongside Analytics, Observability, Testing, and Security; together they describe how Oshun makes the product feel calm, consistent, accessible, and honest about AI. The companion architecture page is Architecture, Platform Foundations, and Security. 📄 **Full detail:** [Design System and Experience Quality](./features/design-system.md) ## Analytics, Observability, Experimentation, and Evaluation This page covers the measurement, evaluation, quality, and security spine of Oshun V1 — the telemetry taxonomies and dashboards, the structured tracing/logging/metrics stack, the experimentation and unified-evaluation pipelines, and the testing/accessibility/performance/security matrices that gate merges and releases. It serves engineers, data, QA, trust-and-safety, and release owners. Most of it is real, machine-readable code in `libs/oshun/analytics` (with logging/metrics in `libs/shared`); the _operational_ launch drills it references are process gates, called out honestly below. It sits in the platform-quality area beside Design System and Experience Quality, and pairs with the companion page Architecture, Platform Foundations, and Security. 📄 **Full detail:** [Analytics, Observability, Testing, and Security](./features/analytics-and-testing.md) ## Testing, QA, Accessibility, Performance, and Security ↳ Detailed in [Analytics, Observability, Testing, and Security](./features/analytics-and-testing.md). ## Content, Localization, Documentation, and Launch This page describes the cross-cutting readiness layer that decides whether Oshun V1 is allowed to ship: launch-quality content per domain, a real localization catalog, the documentation and runbook corpus, the beta/GA launch gates, and the end-state exit criteria that define "feature-complete." It serves release captains, content and localization owners, quality and security leads, and anyone signing a go/no-go decision. Unlike the domain pages (which describe what a customer can do), this page describes what has to be true _across all of them_ before launch — and it is unusual in V1 in that much of it is encoded as machine-readable, test-locked manifests in `libs/oshun/analytics/` rather than living only in prose. The companion runtime doc is Architecture, Platform Foundations, and Security; the backlog of record is ../features.md and `V1/TODOS.md`. 📄 **Full detail:** [Content, Localization, Documentation, Launch, and Exit Criteria](./features/content-localization-launch-exit.md) ## V1 Exit Criteria ↳ Detailed in [Content, Localization, Documentation, Launch, and Exit Criteria](./features/content-localization-launch-exit.md).