# V1 Diagram Atlas This atlas collects the small set of mental models needed to navigate V1 before opening subsystem detail. It complements the generated Docs Center diagram gallery, which indexes every authored diagram across the repository. Each model below is deliberately scoped: it explains responsibility or flow, not shipment. ## Product and platform landscape ```mermaid flowchart TB Member[Member surfaces: web PWA mobile Telegram] --> Shell[Shared consumer shell] Creator[Creator and Studio surfaces] --> Studio[Oshun Studio and workbenches] Operator[Admin tenant and support surfaces] --> Ops[Operator control planes] Shell --> BFF[Oshun BFF and channel boundaries] Studio --> BFF Ops --> BFF BFF --> Domains[Tara Arete Nyx Nisaba Veritas Metis] BFF --> Substrates[Sophia Iris Psyche Lilith Isis Aje] Domains --> Foundation[Contracts persistence events identity audit] Substrates --> Foundation Foundation --> Data[(Domain stores blobs queues and projections)] Foundation --> Providers[Model media payment messaging and platform providers] ``` Member, creator, and operator surfaces share foundations but not authority. Every request crosses the BFF/channel policy and a domain or substrate boundary; a shared shell does not authorize a domain effect. ## Member request sequence ```mermaid sequenceDiagram actor Member participant Surface as Lilith surface participant BFF as Oshun BFF participant Policy as Identity and policy participant Domain as Domain or substrate participant Store as Durable store or provider Member->>Surface: Intent plus current context Surface->>BFF: Authenticated typed request BFF->>Policy: Resolve tenant grants consent release and safety alt refused or withheld Policy-->>BFF: Named reason and safe posture BFF-->>Surface: Denied unavailable or grounded abstention else admitted Policy-->>BFF: Scoped capability BFF->>Domain: Versioned command or query Domain->>Store: Read write or provider effect Store-->>Domain: Durable result receipt or failure Domain-->>BFF: Typed outcome plus evidence BFF-->>Surface: Content disclosure provenance and recovery end Surface-->>Member: Honest visible outcome ``` The provider/store receipt and typed domain outcome matter. A surface label or planned response is not proof that a write or delivery occurred. ## Durable identity and evidence relationships ```mermaid erDiagram TENANT ||--o{ MEMBERSHIP : grants MEMBER ||--o{ MEMBERSHIP : holds MEMBER ||--o{ SESSION : authenticates MEMBER ||--o{ CONSENT : controls TENANT ||--o{ PROJECT : owns PROJECT ||--o{ RESOURCE : contains RESOURCE ||--o{ REVISION : versions REVISION ||--o{ EVIDENCE : supports EVIDENCE }o--o{ SOURCE : cites REVISION ||--o{ JOB : produces JOB ||--o{ ARTIFACT : emits ARTIFACT ||--o{ PROVENANCE : records CONSENT ||--o{ MEMORY_RECORD : permits MEMBER ||--o{ MEMORY_RECORD : subjects RESOURCE ||--o{ AUDIT_EVENT : records SESSION ||--o{ AUDIT_EVENT : attributes ``` Domains specialize these records and may use different stores. The invariant is that tenant, actor/session, resource/version, consent, evidence, job/artifact, provenance, and audit identities do not collapse into one convenient id. ## Governed action lifecycle ```mermaid stateDiagram-v2 [*] --> Proposed Proposed --> Validated: schema and domain preconditions pass Proposed --> Rejected: invalid unavailable or prohibited Validated --> AwaitingConfirmation: sensitive member or operator side effect Validated --> Authorized: read or pre-authorized bounded effect AwaitingConfirmation --> Authorized: exact scope confirmed and reauthorized AwaitingConfirmation --> Cancelled Authorized --> Queued: asynchronous work Authorized --> Executing: synchronous effect Queued --> Executing: lease and fence acquired Executing --> Completed: durable receipt and evidence Executing --> Retryable: transient bounded failure Retryable --> Queued Executing --> Failed: terminal or policy failure Executing --> Withheld: required evidence provider or rights absent Completed --> Compensating: governed reversal or correction Compensating --> Completed: new revision and receipt Rejected --> [*] Cancelled --> [*] Failed --> [*] Withheld --> [*] Completed --> [*] ``` Confirmation, authorization, domain validity, execution, and verification are separate. Compensation creates new history; it does not erase the original action. ## Shared contract composition ```mermaid classDiagram class RequestContext { tenantId actorId sessionId correlationId releaseScope grants } class DomainCommand { commandId resourceId expectedVersion idempotencyKey } class PolicyDecision { outcome reason obligations } class JobReceipt { jobId state leaseFence resultRef } class EvidenceEnvelope { sourceRefs provenanceRef disclosure auditRef } RequestContext --> DomainCommand : scopes RequestContext --> PolicyDecision : evaluated by PolicyDecision --> DomainCommand : admits or refuses DomainCommand --> JobReceipt : may enqueue DomainCommand --> EvidenceEnvelope : returns JobReceipt --> EvidenceEnvelope : completes with ``` Concrete packages use richer domain-specific schemas. This model shows the shared contract roles that should remain visible through every implementation. ## Cross-cutting ownership map ```mermaid mindmap root((V1 cross-cutting ownership)) Member experience Lilith identity Shared shell Rooms and domains Accessibility Builder operations Eve Workbenches Confirmation and leases Independent verification Trust Identity and tenant Lilith policy Sophia evidence Iris consent and memory Rights provenance audit Creation Isis generation Yemaya production and study Aja motion Euterpe audio Bellona interchange Delivery Web and PWA Telegram and channels Notifications Publishing and exports Operations Observability and SLOs Capacity and cost Backup and restore Rollout rollback incidents ``` The map is a reading aid. The [V1 documentation guide](./README.md) links each branch to its detailed feature, architecture, handbook, reference, and evidence home. ## Release timeline ```mermaid timeline title V1 product-line release boundaries V1.0 : Customer web app and PWA : Tara Nyx Arete and Nisaba rooms : Crypto payment rail V1.1 : Native mobile and watch surfaces : Fiat card bank wallet and app-store rails V1.2 : Veritas member room : Metis member room ``` This timeline describes product scope, not a calendar promise or proof that a release is deployed. Current backlog, deployment, and release-gate evidence remain authoritative. ## Multi-actor release journey ```mermaid journey title From product decision to supported V1 capability section Decide Define user promise and release: 5: Product, Design Approve architecture trust and data boundaries: 5: Architecture, Governance section Build Implement contracts storage services and surface: 4: Engineering Add failure accessibility and observability behavior: 5: Engineering, SRE section Verify Run unit contract integration and browser journeys: 5: QA, Engineering Validate security privacy performance and recovery: 5: Governance, SRE section Release Deploy compatible changes and canary cohort: 4: SRE Inspect provider receipts and operational evidence: 5: SRE, Product section Maintain Re-evaluate quality drift cost and incidents: 5: Owners Update docs diagrams backlog and runbooks: 5: Owners ``` No actor or gate can stand in for the entire journey. In particular, a product decision is not implementation, a green unit suite is not deployment, and a successful provider call is not the whole member experience. ## Review discipline Use a diagram to ask better questions, then verify the answer in its canonical source. For a request path, inspect the typed contract, the admitting policy, the owning service, the durable write or provider receipt, and the visible recovery state. For a data relationship, confirm tenant and actor scope, revision behavior, retention, deletion, provenance, and audit semantics in the real schemas and migrations. For an action lifecycle, prove idempotency, authorization freshness, lease fencing, retry limits, cancellation, and compensation with tests that cross the relevant boundaries. Review diagrams in the same change as the behavior they explain. Rename nodes when ownership changes, remove edges that no longer exist, label rollout or provider conditions, and preserve explicit refusal or withheld paths. A visual that silently promotes a plan to a runtime fact is a documentation defect even when its syntax renders perfectly. Conversely, implementation detail that does not change responsibility, sequence, state, or evidence need not make the overview denser; link to the focused source instead. ## How to use this atlas - Start with the landscape to choose the owning surface/domain/substrate. - Use the request sequence to trace an end-to-end behavior. - Use the ER model when reviewing identity, data, evidence, retention, or deletion. - Use the action lifecycle when reviewing commands, tools, workbenches, jobs, confirmations, retries, or compensation. - Use the class model when evolving shared contract boundaries. - Use the ownership map to find the correct cross-cutting handbook. - Use the release timeline and journey to keep product scope and completion evidence honest. Continue into the [feature index](../features/README.md), [architecture index](../architecture/README.md), [Eve](./eve/README.md), [workbenches](./workbenches/README.md), [Telegram](./telegram/README.md), and [Lilith](../../V3/docs/lilith/README.md) handbooks. The generated Docs Center diagram gallery links every additional diagram to its host page and heading.