Codex
82e2c91f42
Add PostgreSQL-backed memory, editable evidence with source review and activation, and human-approved archive repairs across the harness, API, and UI. Include migrations, deployment support, regression coverage, and validation documentation. Refresh permissions from validated session roles so existing administrator logins can access newly deployed archive management features.
3.0 KiB
status, date
| status | date |
|---|---|
| accepted | 2026-09-08 |
Use PostgreSQL for Memory and Qdrant for retrieval
The new Memory module uses the installation's existing PostgreSQL service as the authority for Memory Cards, their links, and structured schema dependencies. Qdrant holds a rebuildable search projection. This replaces the JSONL registry and allows related administrative changes to be coordinated in one database transaction. The owner accepted this direction in Q9 of the Memory design interview; implementation is pending.
Memory uses its own tables and remains a separate module from the Metadata Catalog. Sharing the PostgreSQL service does not transfer Memory ownership to Database management or make Evidence and Memory one canonical domain.
Retrieval and graph
The owner also accepted hybrid semantic/lexical Qdrant retrieval with scope filters and explicit card links traversed in core. Both belong to the planned first version; there is no dedicated graph database or external Memory framework.
This extends ADR 0017: the separate reference and memory collections remain, while Memory gains sparse lexical indexing in addition to dense vectors. Memory projections become rebuildable from the module's PostgreSQL authority. Preprocessing Clear still preserves Memory; this decision does not add it to the preprocessing cleanup scope.
Links support discovery. Finding a card through a link does not approve its use. The core proposes links with the cards for the same final review; Administration provides manual creation, editing, and deletion. Deleting a card removes its incident links without deleting the other linked cards.
Considered options
- Retaining JSONL preserves the current storage format, but leaves coordinated card/link/dependency mutations and concurrent administrative writes to application code.
- Using Qdrant as the sole authority is a viable alternative for record storage and retrieval. PostgreSQL is preferred for the coordinated mutations of the new module, with Qdrant reserved for its search projection.
- Adding a dedicated graph database would introduce another service; the selected bounded traversal can be implemented in core over persisted links.
Consequences
The module needs a persistence contract, PostgreSQL schema, and explicit propagation of additions, updates, and deletions to Qdrant. Choosing PostgreSQL does not make this propagation atomic across both systems: failures, retries, and invalidation of stale search content must be handled and tested. An index rebuild uses the original card content and cannot resurrect deleted cards.
The decision does not introduce Memory revision history or require compatibility with existing development sessions. Evidence authoring and publication remain governed by their own contract until the Evidence management project defines its evolution.
The Memory management project records the approved behavior, scope, and integration work.