# Workspace, Conversation, And Governance Boundary

## Aggregate Role

`Workspace` is the current collaboration and access boundary.

It owns:

- workspace identity
- name
- visibility
- lifecycle status
- membership and member roles

It currently supports:

- create
- rename
- change visibility
- add member
- remove member
- change member role
- archive

It enforces:

- non-empty workspace name
- no duplicate membership for one user
- at least one owner at all times
- no mutable changes once archived

## Workspace Lifecycle Meaning

### `active`

- the workspace may accept document, conversation, and chat operations
- active membership checks use the shared access filter

### `archived`

- the workspace remains persisted
- membership can still be inspected through backend state
- active document and conversation creation flows are rejected
- destructive delete remains a separate governance action

## Conversation Role

`ConversationRecord` is intentionally lightweight in this phase.

It owns:

- conversation identity
- workspace binding
- title
- created/updated timestamps

It currently supports:

- create
- get
- list within one workspace
- rename
- delete

It does not yet own:

- persisted transcript history
- message blocks
- citations as durable conversation artifacts

That later history layer should attach to `conversation_id` and `workspace_id`
without bloating the workspace aggregate.

## Access And Identity Boundary

The current identity seam is the Compass auth boundary:

- OpenSearch-backed login at `/api/aibs/auth/login`
- HTTP-only browser session cookie
- session inspection at `/api/aibs/auth/session`
- logout at `/api/aibs/auth/logout`
- conversion from authenticated principal into a minimal `UserContext`

The legacy `X-AIBS-User-Id` header is accepted only when
`AIBS_AUTH_DEV_MODE=true`, and is retained as an explicit local development
compatibility path rather than a production identity mechanism.

The current shared access seam is:

- `WorkspaceAccessFilter.require_member(...)`
- `WorkspaceAccessFilter.require_active_member(...)`
- `WorkspaceAccessFilter.require_owner(...)`

This keeps workspace truth in the backend and avoids trusting raw client-owned
workspace ids.

The Phase 1 session store is fixed-TTL and process-local. Multi-worker and
restart-surviving deployments should replace it behind the session-store port
before production scale-out.

## Governance Boundary

Archive and delete are not treated as the same operation.

### Archive

- handled through governance
- applies the workspace lifecycle transition
- persists the archived workspace
- keeps the record available for later inspection

### Destructive Delete

- handled through governance
- first closes the in-process workspace boundary at the interface layer
- rejects delete if any bounded document or workspace conversation is still in
  an in-flight ingestion or planning state
- enumerates all workspace-bound documents and conversations up front so the
  cascade does not depend on per-conversation discovery
- drops the workspace's chunk index in OpenSearch in one call rather than
  walking the chunks per document
- per document: removes the document record and parsed artifacts (raw files
  and ingestion jobs are handled by the workspace-level cleanup below to avoid
  redundant per-document work)
- removes raw files via the file store's workspace-level deletion path
- per conversation: deletes the conversation record and any associated lineage
- sweeps remaining workspace-scoped artifacts in OpenSearch by `workspace_id`:
  conversation memory, answer artifacts, query records, and ingestion job
  records, each sweep uses `refresh=True` so subsequent reads observe a
  consistent post-delete state
- removes the workspace record last

This is truthful for the current single-process wiring phase.
It is not yet a durable distributed lock model.

## Current Bounded Resource Shape

Today the workspace boundary owns these persisted resource relationships:

- workspace -> memberships
- workspace -> documents by `workspace_id`
- workspace -> conversations by `workspace_id`

The current chat path already resolves a real workspace-bound conversation
before answering.

## Future Follow-Up

The next layers that can build on this source of truth are:

- persisted transcript history per conversation
- retrieval rebased onto workspace-scoped access filtering
- a durable session store to replace the current process-local store