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.
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.
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.
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.
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.
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.
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 links each
branch to its detailed feature, architecture, handbook, reference, and evidence
home.
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.
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.
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.