# Epistemic Review Studio The Review Studio is Exomem's browser control plane for the daily epistemic loop: inspect the ranked Inbox, opt into corpus activation, understand why a signal surfaced, and make an explicit governed decision. It is packaged inside the Python distribution and served by the existing Exomem process. There is no CDN, Node runtime, frontend daemon, or separate database. ## Quickstart Start the HTTP service as usual, then print the Studio URL: ```sh exomem --transport http exomem studio ``` The default is `http://127.0.0.1:8765/studio/`. `exomem studio --open` opts into opening the system browser; the plain command only prints the URL and is safe on headless hosts. `EXOMEM_BASE_URL` or `--url https://kb.example.test` selects a remote origin. The shell is public but inert: it contains no vault titles, paths, counts, note text, graph data, or review state. Vault data crosses the boundary only through same-origin `/api/*` commands. Set `EXOMEM_REST_API_KEY`, enter that personal key in the connection screen, and the browser retains it in memory or `sessionStorage` for the current tab session. It is never placed in a URL, rendered HTML, persistent cookie, or `localStorage`. On a Cloudflare Access deployment, use the Access option; the edge assertion is checked by the existing REST authorization path. ## What the worklists mean Inbox is the default daily view. It displays `list_review_items(queue="due")` in exact server order, with recorded categories, reasons, state, summary counts, and every reported cap. The browser filters the returned view but does not recalculate rank, severity, confidence, or epistemic meaning. Activation is separate and opt-in. It displays `list_review_items(queue="activation")`, including denominator-backed structural coverage. It does not mix activation debt into the Inbox. Activation depends on the existing-corpus activation scanner; if that command is unavailable, the Inbox remains usable. Relations is the batched acceptance queue. It displays `list_review_items(queue="relation_suggestions")` — deterministic relation candidates grouped by page, already filtered against authored edges, placeholder targets, and unexpired dismissals — with the same capped-surfacing honesty as the other worklists. Its identities are namespaced (`exomem://review/relation/`) so triaging a relation candidate never resolves an Inbox or Activation item. Per-candidate Accept requires an audit reason and the reviewed fingerprint; Dismiss and Snooze record fingerprint-bound decisions that expire when the underlying signal materially changes. Selecting an item calls `inspect_memory` with `review.item_context` and its stable `exomem://review/` reference and current fingerprint. The bounded response contains the target body, exact reasons, related summaries, provenance/evidence, graph neighborhood, audit history, and pointer-ordered supersession evolution. Empty, unavailable, and truncated sections stay visibly distinct. The Studio does not fetch unrestricted related bodies to fill gaps. ## Writes are confirmation flows Dismiss, snooze, and reopen use `decide_review_item`. Before writing, the Studio rechecks the selected fingerprint; a changed signal refreshes the worklist and performs no action. Conclusion-changing work has a proposal step and a separate confirmation: - Relation suggestions come from read-only `inspect_memory` with `connections.suggest_relations`; single-candidate acceptance is an audited `edit_note` call, and queue acceptance is the governed `connect_memory(operation="accept-relation")`, which revalidates the candidate's fingerprint, the target page hash, and live eligibility before authoring exactly one canonical `## Relations` bullet. - Source compilation starts with read-only `create_note`; the editable draft becomes knowledge only through confirmed `create_note`. - Supersession previews the exact target, successor draft, reason, and consequence before confirmed `supersede_note` preserves the old version. Validation failures leave the dialog and draft intact. Proposal generation and cancellation never mutate the vault. Existing server validation, expected-hash guards, write logs, access policy, and audit behavior remain authoritative. ## Relation queue states The Relation worklist is graph-native and preserves server order. Its `status` is one of `available`, `warming`, `pending`, or `unavailable`; these states are not empty queue results. `warming`, `pending`, and `unavailable` are retryable and show no fabricated fallback candidates. `truncated` and coverage fields remain visible whenever a bounded response omitted work. An accept action sends the queue item's `source_path`, maps its `source_content_hash` to `expected_hash`, and maps its `fingerprint` to `expected_fingerprint`. A triage action sends `source_path` and `expected_fingerprint`; triage has no content-hash input. A changed signal produces `REVIEW_ITEM_CHANGED`; a legacy reference outside the bounded current prefix produces `REVIEW_REFRESH_REQUIRED`. The Studio refreshes instead of widening a search or re-ranking candidates client-side. ## Recorded evolution, not generated narrative The Evolution panel displays stored supersession pointers in order, with recorded dates, structural claims, transition reasons, paths, and canonical references. A single-version conclusion produces an honest empty state. The client does not invent an explanation, confidence score, authority score, or causal link from edit dates or semantic similarity. ## Local and remote deployment Local use needs only the existing HTTP service. Remote personal use should put the same service behind the documented Cloudflare Tunnel and Access boundary; see [remote-quickstart.md](remote-quickstart.md) and [deployment.md](deployment.md). Keep `/studio/` and `/api/*` on the same origin. The CSP rejects external scripts, styles, frames, and cross-origin API calls. Missing Studio assets return a bounded 503 diagnostic only on Studio routes. MCP, REST, CLI, favicon, retrieval, and service startup remain independent. ## Deliberate non-goals This is not a generic notes editor or Basic Memory clone. The first release has no rich Markdown editor, file manager, canvas, cloud sync, multi-user workspace, CRDT collaboration, billing, public sharing, background agent, or automatic cleanup. Its job is narrower and more valuable: make Exomem's governed review, provenance, activation, explicit decisions, and recorded belief evolution legible as one end-to-end product loop.