# Eve operator-memory controls and disclosure — Task 9.2

Date: 2026-09-12

Status: complete for Task 9.2; Phase 9 and G11 remain open

## Result

The admin assistant now exposes one collapsed, operator-visible `Memory`
surface. It inspects only the authenticated operator's rows and shows the exact
stored category, slot, and value together with:

- source (`Confirmed in assistant chat` or `Saved in memory controls`);
- explicit-confirmation time;
- last update time;
- last use in prompt assembly, or an honest `Not used in a prompt yet`;
- server-authoritative operator-profile or session-only scope;
- until-forgotten retention and operator-account erasure behavior; and
- the exact in-product erasure location, `Admin assistant → Memory`.

The surface remains collapsed by default so the conversation owns the drawer. If
durable memory is unavailable, the same read endpoint returns session-only scope
and no mutation control is shown.

## Control semantics

All routes require verified admin authority and derive the memory subject from
the authenticated token. There is no operator-subject field in any request.
Corrections require the exact `save-correction` confirmation marker and reset
last-use because the corrected value has not yet crossed a prompt boundary.
One-row deletion requires the exact category and slot plus the `forget-entry`
marker. Forget-all has a separate two-step UI and requires `forget-all`; the
server never widens a slot-only, category-only, or unconfirmed request.

Every direct correction and deletion enters the canonical admin audit feed
without copying the note value into the audit payload. The existing assistant
write tools remain separately confirmation-gated.

## Persistence and isolation

The table adds `source`, `confirmed_at`, and nullable `last_used_at` columns.
Historical rows default truthfully to `assistant-confirmation`, since the
assistant confirmation bridge was the only production writer before these direct
controls. Opening the manager performs a read-only list. Prompt assembly uses a
distinct atomic recall function that advances `last_used_at` only for the
authenticated operator's rows.

The composite primary key remains `(operator_sub, category, slot)`. Exact
deletion predicates on all three values; forget-all predicates on
`operator_sub`. The live database route suite proves that correcting and
deleting one operator's rows neither reveals nor removes an adjacent operator's
row.

## Evidence boundary

The Task 9.2 manifest is `docs/audits/eve-sota-evidence/phase-09/task-9-2.json`.
Retained evidence covers source inspection, component and parser behavior, real
Fastify routes over PostgreSQL, persistence reconstruction, admin/member
authorization isolation, exact data-rights deletion, a real Chromium journey
through inspect, correct, exact forget, and forget-all, and a scoped
serious-impact axe scan.

The Chromium test controls its same-origin API responses so UI state transitions
are deterministic; the separate Fastify/PostgreSQL integration executes the real
authorization and persistence boundary. The database is local development
PostgreSQL rather than staging or production. Task 9.2 does not claim measured
recall quality, supersession history, salience/expiry policy, poisoning
resistance, semantic retrieval, or rollout evidence; those remain Tasks 9.3–9.7.
Accordingly Phase 9 and G11 remain open.