This is the complete domain map for the V1 workbench program. It accounts for the shared platform and all seven named initiatives in the program ledger. It is an orientation and ownership map; generated inventories remain authoritative for exact files, routes, applications, and tests.
The shared branch owns reusable mechanics; each domain branch owns its business records, effects, policy extensions, and operational truth.
What counts as a workbench#
A workbench is a domain-owned environment for sustained, reviewable work. It is more than a page and less than a new platform: it combines a task model, domain-specific commands and evidence, persistence, asynchronous jobs, history, review, and operational controls inside a consistent Oshun shell.
The complete program scope is:
- Shared workbench platform.
- Isis governed-generation workbenches.
- Metis courseware and assessment workbench.
- Yemaya AAA production, study, and interactive-case authoring.
- Veritas newsroom workbench.
- Euterpe music-production workbench.
- Aja motion-capture operations console.
- Bellona DCC bridge and interchange console.
Tara and Hathor appear in Studio and media workflows, but they are not separate initiatives in this V1 workbench ledger. Likewise, Eve is an actor across builder workbenches, not another domain workbench. See the Eve runtime handbook for her governed write and confirmation boundary.
Shared platform#
The shared program owns mechanics that should behave consistently across domains: shell and layout primitives, navigation, tokens, accessibility, identity/tenant context, grants, revisions and history, jobs, suggestions, notifications, provenance, audit envelopes, storage abstractions, degradation plans, recovery objectives, and verification helpers.
The package home is libs/oshun/workbench-kit; the governance and evidence home
is evidence/v1-workbenches. Shared code does not own Isis generations, Metis
assessments, Yemaya studies, Veritas stories, Euterpe sessions, Aja captures, or
Bellona builds. It provides the safe grammar in which those domains implement
them.
Read Shared platform and composition for the extension and dependency contract.
Isis — governed generation#
Purpose. Isis owns governed generative production: workflow and model selection, execution, output inspection, provenance, consistency, approval, and operational parity across providers and runtimes.
Surface families. The estate inventory covers the Isis web application, Studio routes, generation API, GPU worker, CLI, mobile surface, and supporting libraries. Product work spans jobs, workflows, templates, providers, models, outputs, audit logs, feature flags, and dedicated consistency/parity views.
Critical boundaries. A prompt or workflow declaration is not permission to run a model. Tenant grants, model/workflow policy, safety checks, budget and capacity, provenance, output review, and provider failure behavior remain separate gates. AAA-only Studio routes fail closed unless explicitly allowed by the canonical boundary module.
Canonical evidence. Use
evidence/v1-workbenches/isis-package-inventory.json,
isis-page-inventory.json, isis-curated-surface-inventory.json,
isis-workload-catalog.json, and the model/template/asset-kind registries.
Metis — courseware and assessment#
Purpose. Metis owns structured learning: programs, courses, lessons, cohorts, classrooms, assessments, adaptive sequencing, credentials, outcomes, and the authoring and reporting work around them.
Surface families. Its estate includes learner and authoring web routes, service and API packages, mobile/CLI surfaces, assessment and adaptive-learning libraries, analytics, and cross-domain learning adapters. The generated route, contract, package, API, and persistence inventories are the fastest exact map.
Critical boundaries. Learning recommendations must preserve the difference between observed progress and inferred proficiency. Assessment mutations, rubric or evaluator changes, credentials, exports, and learner data require versioned contracts, attributable authorship, and tenant/role enforcement.
Canonical evidence. Use metis-route-inventory.json,
metis-api-inventory.json, metis-contract-inventory.json,
metis-package-inventory.json, and metis-persistence-inventory.json under
evidence/v1-workbenches.
Yemaya — production, study, and interactive cases#
Purpose. Yemaya owns film, animation, and production work and is the primary owner of the Study & Deconstruction Workspace. Study turns owned or authorized source material into evidence-linked observations, comparisons, practice, and original creative decisions; it does not turn reference into untraceable imitation.
Surface families. Yemaya spans Studio web and Electron desktop surfaces, creative-agent and production libraries, the Study Workspace service, media and project schemas, and cross-domain adapters to Nisaba, Sophia, Hathor, Aja, Euterpe, Aglaea, Bellona, Metis, Isis, Oshun, Iris, Neith, and Maya.
Critical boundaries. Source rights and expiry, tenant/project sharing, untrusted media parsing, evidence identity, model/provider lineage, derived artifact deletion, export signing, and honest partial/offline states are part of the product contract, not optional infrastructure.
Canonical evidence. Begin with
Study Workspace overview, then use
yemaya-route-inventory.json, yemaya-data-inventory.json,
yemaya-storage-inventory.json, yemaya-case-inventory.json, and
yemaya-ipc-registry.json under evidence/v1-workbenches.
Veritas — newsroom#
Purpose. Veritas owns the evidence-bearing editorial lifecycle: source and claim work, research, drafting, review, approval, scheduling, publishing, correction, takedown, and distribution automation.
Surface families. The estate covers newsroom web/control surfaces, API and worker processes, publishing and social services, CLI/agent runtimes, and libraries for research, claims, state, storage, and provider integrations.
Critical boundaries. A generated draft is not a verified claim; a verified claim is not publication approval; and publication is not immutable. Source provenance, counterclaims, corrections, embargoes, roles, review state, delivery receipts, and takedown remain explicit throughout the history.
Canonical evidence. Use veritas-route-inventory.json,
veritas-data-catalog.json, veritas-state-inventory.json, and
veritas-storage-inventory.json under evidence/v1-workbenches.
Euterpe — music production#
Purpose. Euterpe owns music creation and production: composition, recording, arrangement, editing, mixing, realtime collaboration, performance, and the audio-specific engine and session state behind those jobs.
Surface families. The canonical inventory separates a small route shell from the much larger DAW module and component surface. It also records realtime, identity/billing, shell/runtime, telemetry/launch, native bridge, worklet, and worker signals so a route count is never mistaken for product depth.
Critical boundaries. Audio-thread safety, deterministic session history, plugin and asset compatibility, latency, offline recovery, collaboration conflicts, metering, rights, export fidelity, and native/browser divergence must be tested in their actual runtime lanes.
Canonical evidence. Use euterpe-inventory.json,
euterpe-host-inventory.json, and euterpe-storage-inventory.json under
evidence/v1-workbenches.
Aja — motion capture and reference video#
Purpose. Aja owns capture and motion operations: source/reference intake, format inspection, skeleton and pose processing, cleanup, retargeting, comparison, metrics, and motion pipeline delivery.
Surface families. Aja is intentionally a Studio-route, service, and CLI estate rather than a standalone web application. The inventory accounts for the Studio surface, motion-AI and motion-pipeline HTTP services, the reference-video package, and CLI commands for comparison, formats, metrics, skeletons, and operational inspection.
Critical boundaries. Rights and consent for captured people, biometric and body data, source-to-derived lineage, coordinate and skeleton conventions, model/version drift, idempotent jobs, review, and deletion propagation are first-class.
Canonical evidence. Use aja-inventory.json, aja-storage-inventory.json,
aja-format-registry.json, and the target/model/ modifier registries under
evidence/v1-workbenches.
Bellona — DCC bridges and interchange#
Purpose. Bellona owns managed interchange between Oshun and creation engines/tools: build and render orchestration, Blender/Godot/Unity/Unreal bridges, remote hosts, approvals, artifact transfer, and operational control.
Surface families. Its estate spans Studio pages, a React control room, mobile approvals, build/render API and worker processes, remote gateway/host/ extension, four DCC bridge hosts, and a CLI. Inventory classifies WebSocket, IPC/process, gRPC, and HTTP protocols so non-HTTP bridges do not disappear.
Critical boundaries. Remote command authorization, host identity, project and artifact scoping, version/interchange compatibility, retries and fencing, path and archive safety, engine-specific capability negotiation, approval, and audit are mandatory.
Canonical evidence. Use bellona-inventory.json and the engine-bridge,
remote, build, render, and interchange evidence under evidence/v1-workbenches.
Cross-domain interaction rules#
| Boundary | Rule |
|---|---|
| Identity and tenant | Resolve once at the trusted edge; propagate typed tenant, actor, grants, and correlation context. Do not accept a tenant id merely because a client supplied it. |
| Reads | Domain queries expose versioned, permission-filtered projections. A shared shell must not reach around them into another domain's tables. |
| Writes | Use domain commands or governed events. Mutations expose preconditions, idempotency, review/confirmation, audit, and an honest failure state. |
| Long work | Jobs carry owner, tenant, inputs, model/tool versions, progress, cancellation, retry/fencing, result identity, and lineage. |
| Evidence | Preserve source, claim/observation, anchor, method/model, author, time, version, confidence/status, and derived-artifact relationships. |
| History | Revisions are immutable records linked by explicit ancestry. Undo creates a new revision or compensation; it does not erase history. |
| Suggestions | Suggestions are attributable proposals. Accepting one produces a governed domain command; displaying one does not mutate state. |
| Export and deletion | Export proves contents and provenance. Deletion follows the reference graph, tombstones/audit requirements, rights state, backups, and external copies. |
How to read the inventories#
The deterministic generator at scripts/v1-workbenches/generate-inventory.mjs
discovers tracked source with git ls-files and emits packages, applications,
routes, tests, library graph, public symbols, reconciliation, and manifest
summaries. Domain generators add semantics the generic inventory cannot infer,
such as Studio routes, desktop IPC, DAW modules, DCC protocols, persistence, and
registries.
Counts are diagnostic, not scorecards. A domain with few filesystem routes may have a large embedded engine; a domain with many generated Studio pages may still lack supported journeys. Use the inventory to find the implementation, then use route, contract, integration, browser, accessibility, performance, security, and operational evidence to decide whether the journey is complete.
Change checklist#
- Update the domain-owned contract and implementation.
- Regenerate the relevant generic and domain inventories.
- Reconcile new routes, packages, protocols, schemas, and public symbols.
- Add or update the smallest test that proves each affected success, refusal, partial, offline, retry, and recovery behavior.
- Update the domain handbook section when ownership, scope, or a critical boundary changes.
- Run the Docs Center freshness and integrity gates so every canonical link and search entry remains reachable.