RMS Revised RFC Suite — Index

Suite Version: 1.0 Date: 2026-02-19 Status: Draft

Overview

This index covers the complete Revised Relational Memory Substrate (RMS) RFC suite. This suite was produced following a full scientific audit of the original BlindspotRFCs series (RFC-0001 through RFC-0015). It addresses the structural weaknesses identified in that audit while preserving and strengthening the genuinely valuable architectural ideas.

Key changes from the original suite:

• RFC-0013 (Emotional and Behavioral Signal Tracking) removed entirely. Replaced with RFC-0013 (Intent and Goal Memory), which addresses a real need without the privacy and epistemic risks.
• Determinism requirements scoped correctly: strict determinism at the storage/derivation layer; [BEST-EFFORT] reproducibility at the extraction layer.
• All unvalidated parameter choices are explicitly marked [HYPOTHESIS] with benchmark requirements before promotion.
• Merge conflict resolution fully specified (the original suite deferred this).
• Agent trust model redesigned as domain-scoped rather than scalar.
• Resource limits and garbage collection added to branching.
• Reference implementation requirement added as a gate before any RFC exits Draft status.

Current implementation evidence

The research agenda  tracks verified results, active comparison protocols and remaining capability gaps. RFC status and historical benchmark targets are not evidence of current product quality.

The 2026-09-17 competitive landscape snapshot  records PRME’s point-in-time position against direct and adjacent memory products, including source URLs, adoption metadata, benchmark boundaries, and the source revision evaluated. Future reviews create new dated snapshots rather than rewriting this reference.

Developer guides cover entity profiles and recovery, custom embedding providers, and entity identity and conservative merges. These describe implemented Python and CLI contracts separately from draft RFC requirements.

Framework integrations documents the LangChain and LlamaIndex retrievers, lossless structured-message storage, and append-only logical history mutations.

Coding memory  connects local coding agents to one Docker memory service per repository and documents isolated paired development trials.

Jev product-alignment advisor  documents the opt-in, pinned external advisor for caller-selected software-product pairs, its held-out evidence, audit fields, durable unverified-proposal workflow, and proposal-only safety boundary.

Scoped retrieval learning documents the two-stage evidence gate, immutable owner/scope profiles, automatic application, and rollback workflow.

Explicit memory corrections documents source retention, node/event identities, scoped evidence and the sync/async replacement workflow.

Metadata handling covers finite JSON admission, copied inputs and lossless special-float snapshots for previously admitted graph metadata.

Context packing explains the default retrieval settings (rank fusion, the reader format and balanced ordering) and how to restore the v0.12.0 defaults, the score and density orderings, exact token budgets, evidence limits and receipt compatibility.

Experimental retrieval policies documents opt-in retrieval experiments that do not change production defaults: the reranker score-envelope policies, the cross-encoder rank order and alternate-query signal merging, with their evidence and limits.

Evidence-bound temporal relations documents the opt-in resolver, deterministic citation validation and arithmetic, independent Jev gate, fixed-budget repacking, failure behavior, receipts and held-out evidence.

Typed presentation and lookup values documents source-bound value pairs, visible-context filtering, exact tool-argument resolution and the Python, HTTP and MCP contracts.

Answerability and grounded abstention documents the optional post-retrieval evidence-sufficiency evaluator, partial answers, cited conflicts, provider configuration and audit boundary.

Local claim verification documents the optional pinned NLI verifier, bounded minimal evidence groups, typed bundle evidence and the explicit completeness boundary for derived counts and lists.

Memory credit documents removing one cited record from a packed context and re-answering, to measure whether that memory changed an answer.

Memory confirmations and safe retries covers the async engine, synchronous client and HTTP idempotency header.

Integration reference is the broad API, data model, configuration and retrieval pipeline reference for developers and coding assistants; its coverage is partial.

HTTP source fidelity and recovery documents HTTP routes for storing sources, extraction, quantity aggregation, request recovery, corrections, relevance judgments, answer citations, confirmations and alias proposal review.

Named memory workspaces documents MemoryWorkspace: named projects in separate local packs or PostgreSQL schemas, with bounded open engines and leases. The namespace design review  records the 2026-09-12 comparison that led to it.

Resource control for multiple local packs covers one pack per project, DuckDB worker counts and sharing an embedding provider.

Single-file packs covers the opt-in .prme layout, its native encryption, prme compact and prme migrate. The RFC-0014 amendment records its format and rebuild-on-open behavior.

PostgreSQL vector eligibility and search mode explains exact vector search under owner, scope, lifecycle and validity filters, and the approximate mode’s recall tradeoff.

RFC Listing

Tier 0 — Foundation

Tier 1 — Storage and Integrity

Tier 2 — Retrieval

Tier 3 — Lifecycle

Tier 4 — Advanced Capabilities

Dependency Graph

RFC-0000
    │
    ▼
RFC-0001
    │
    ├──► RFC-0002
    │        │
    │        ├──► RFC-0003
    │        │        │
    │        │        └──► RFC-0004
    │        │                 │
    │        │                 └──► RFC-0005
    │        │                          │
    │        │                          └──► RFC-0006
    │        │                                   │
    │        │                    ┌──────────────┘
    │        │                    ▼
    │        └───────────────► RFC-0007
    │                              │
    │                              ├──► RFC-0008
    │                              │        │
    │                              │        └──► RFC-0009
    │                              │                 │
    │                              │                 ├──► RFC-0015 (Self-Organizing Execution Model)
    │                              │                 │
    │                              └─────────────────┴──► RFC-0010
    │                                                     RFC-0011
    │                                                     RFC-0012
    │                                                     RFC-0013
    │                                                     RFC-0014

Conformance Summary

An implementation claiming conformance at a given tier MUST satisfy all requirements at that tier and all tiers below it.

A system claiming “Tier 2 conformance” has implemented Tiers 0, 1, and 2 — not merely RFC-0002.

What Was Removed and Why

Earlier Specifications and Audit

These files predate the revised suite and are kept for reference.

Key Design Decisions

Why is [HYPOTHESIS] used so frequently?

Because the original suite asserted confidence values, decay weights, scoring weights, and threshold values without empirical grounding. In a system that claims to model epistemic confidence, asserting design parameters without epistemic justification is a contradiction. [HYPOTHESIS] marks are requirements for future empirical validation, not weaknesses.

Why no emotional signal tracking?

Text analysis can detect linguistic patterns associated with emotional expression. It cannot detect emotions. Treating the proxy as the thing is a category error. Acting on inferred emotional state without user consent and without reliability validation is harmful. The intent and goal memory in RFC-0013 addresses the legitimate underlying need (understanding what the user cares about and is working toward) without this conflation.

Why is determinism scoped?

The original suite required determinism everywhere, including in LLM-based extraction pipelines. This is not achievable: modern LLMs are non-deterministic at the hardware level even with temperature=0, and different hardware produces different floating-point results. Scoping determinism to the storage and derivation layer (where it is achievable and matters for auditability) while using [BEST-EFFORT] semantics for extraction (where strict determinism is not achievable) is an honest specification.

Why tiers?

Because the original suite implicitly required all features simultaneously. A minimal useful memory system needs only Tiers 0-2. Many deployments will not need branching, federation, or temporal pattern awareness. Tiering allows incremental adoption and reduces the compliance burden for simple use cases.

End of Index

Source: docs/INDEX.md  in PRME at 58caddb1.