# Workbench Estate and Ownership

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.

```mermaid
mindmap
  root((V1 workbench estate))
    Shared Workbench Kit
      Identity tenant and grants
      Shell tokens and accessibility
      History jobs suggestions and audit
      Degradation recovery and release
    Isis
      Governed generation
      Models workflows and outputs
    Metis
      Courseware and assessment
      Learning outcomes
    Yemaya
      Production and interactive cases
      Study and deconstruction
    Veritas
      Newsroom claims and publishing
      Corrections and takedown
    Euterpe
      Music production and realtime audio
    Aja
      Motion capture and reference video
    Bellona
      DCC bridges build render and interchange
```

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:

1. Shared workbench platform.
2. Isis governed-generation workbenches.
3. Metis courseware and assessment workbench.
4. Yemaya AAA production, study, and interactive-case authoring.
5. Veritas newsroom workbench.
6. Euterpe music-production workbench.
7. Aja motion-capture operations console.
8. 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](../eve/runtime-tools-and-actions.md) 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](./shared-platform-and-composition.md) 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](./yemaya-study-workspace.md), 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.