# Shared memory > How observations become a curated canon, how agents retrieve it, and how evidence ages with the code. Ryph’s memory service separates proposing a lesson from adding it to the shared canon. Runs write observations into an inbox. Consolidation screens and reconciles those proposals before future runs receive them as memory. **From a proposed lesson to shared memory** - **Proposal inbox**: observations + documents - **Consolidation**: screen · dedupe · judge - **Shared canon**: claims + evidence - **Agent run** (sandboxed): check · confirm · refute - **Brief + search**: scope · rank · retrieve How they connect: - Agent run → Proposal inbox: propose - Proposal inbox → Consolidation - Consolidation → Shared canon: promote - Shared canon → Brief + search - Brief + search → Agent run: relevant memories Runs propose observations. Consolidation curates the canon; a brief and search bring useful memories back into later runs. For what memory does day to day and how to set it up, see [Semantic memory](https://ryph.ai/docs/semantic-memory.md). ## Proposals and the canon A proposal records a claim and its origin. It can come from a run or from document ingestion, such as a runbook. The service screens proposals for suspicious content before promotion; flagged proposals can remain held for a person to review. Exact duplicates can be folded into confirmations of an existing memory. With a consolidation model configured, the service can also identify rephrased duplicates, refine claims and resolve contradictions. A superseding claim retires the old memory and retains the relationship between them. Administrators can create, edit, pin and retire canonical memories directly. Agents proposing observations do not have that same direct editing surface. Confirmation and refutation are separate feedback operations that can change a memory’s standing. > [!NOTE] > **Two optional model capabilities** > > Semantic retrieval needs embeddings, which the single binary turns on by default and a standalone memory service enables with `RYPH_MEMORY_EMBEDDINGS=local`. Model-assisted consolidation needs a configured model through the platform’s model proxy. Without them, the service can still use text search, screening and exact deduplication. Screening and model judgments are fallible; a canon is curated evidence, not guaranteed truth. ## Briefs and retrieval A memory-enabled run starts with a brief composed for its scope. During work, it can query the canon in ordinary language through the memory tools behind the MCP gateway. Retrieval is scoped to the run’s organization and repository subjects, with audience filtering. A multi-repository checkout does not grant access to arbitrary repository memories. Search results are ordered by relevance, then recency; each result shows its trust and confirmations. Brief ranking combines relevance with trust, confirmation and refutation signals, and age since confirmation. Successful runs that received a memory contribute a smaller implicit confirmation. The vote multiplier is capped, so repeated confirmations do not increase ranking without bound. Pinned memories receive special treatment. Ordinary facts, procedures, decisions and other kinds have different decay horizons; preferences do not decay on the same schedule. ## Tie claims to code A repository claim can carry evidence: the commit and paths at which it was observed. After cloning, the runner checks the evidence supplied with its brief against the relevant checkout. If referenced files changed, the runner reports the memory as stale. It is marked for verification and excluded from later briefs until reconfirmed. The current run receives a warning alongside its already frozen brief. This is not a watcher on every commit. Evidence is optional, so a claim without it is never flagged. Only briefed evidence that the runner can check is examined, and failures to perform the check are handled best effort. A file change signals that a claim needs checking; it does not establish that the claim is false. ## Learn from feedback Runs can confirm what holds and refute what does not. A confirmation can restore a memory to the canon. A refutation with a replacement creates a new proposal, so replacing the claim still goes through review or consolidation. One run’s refutation does not automatically retire a memory, though it marks the memory for verification and removes it from briefs until it is confirmed again. The service considers refutations from distinct runs since the last confirmation, with separate handling for pinned memories. Decay and periodic sweeps can also retire old, unused memories. These mechanisms let useful lessons remain visible while retaining evidence about how they were learned, challenged and replaced. ## Follow the implementation The [memory service](https://github.com/ryph-hq/ryph/blob/main/packages/memory/src/core/service.ts) owns proposal, consolidation and feedback behavior. [Scoring](https://github.com/ryph-hq/ryph/blob/main/packages/memory/src/core/score.ts) defines trust, votes and decay. The [runner](https://github.com/ryph-hq/ryph/blob/main/packages/runner/src/core/run.ts) checks file evidence after cloning.