Disciplines · Audits

Eve operator-memory controls and disclosure — Task 9.2

The admin assistant now exposes one collapsed, operator-visible Memory surface.

4sections2 minread
Markdown source
On this page

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.