RightMemory reconciliation

Type: agentic-system-analyses/types/agentic-system-reconciliation-report.md

Reconciliation

The four reports use the same frozen boundary, whose Source register supplies implementation, doctrine/design and reported operation only. Connections below concern source-supported architecture and instructions, not observed compliance, successful execution or benefit. No correction answers or refusal were supplied. No additional source reads were needed.

Duplicate supersessions

Amendment: EPI-OBJ-agent-corrections is superseded by MEM-OBJ-agent-corrections. Both identify the same two fixed Git-backed Agent Corrections collections and the same derived attempt/redirection/outcome cases. Their passages from SRC-1 rightmemory/reference/AGENT_CORRECTION_MEMORY_RULES.md identify the distinction between raw redirection and an admitted reusable case. The epistemic inventory and ledger continue to concern those cases, not Update control state. The memory report additionally retains positional selection and capacity-enforcement limits; this connection does not convert policy bounds into invariants.

Amendment: EPI-OBJ-corrections is superseded by MEM-OBJ-edit-feedback. Both name optional root corrections.md, with Candidate/Proposed edit/Accepted edit examples consumed after tentative Update judgment. Their identical load-bearing passage from SRC-1 rightmemory/reference/RIGHTMEMORY_EDIT_CORRECTION_RULES.md requires exact evidence rather than generalized lessons. Epistemic findings about curation feedback and memory findings about exclusion from ordinary retrieval refer to this one object. Unknown initial writing control remains unknown.

Amendment: EPI-OBJ-guidance-inbox is superseded by MEM-OBJ-guidance-inbox. Both identify AGENT_GUIDANCE_INBOX.md, holding evidence bodies plus entry/session/time metadata. SRC-1 rightmemory/guidance.py supplies the filename and construction passages in the two records. Capture retains pending evidence; it does not by itself admit formal guidance. Both capture and explicit review retain this object as their input/output boundary.

Amendment: EPI-OBJ-insight-logs is superseded by MEM-OBJ-insight-logs. Both name timestamped insight_logs/*.md, with prior logs available to later Insight cycles. Both quote SRC-1 rightmemory/prompts/insight.md; neither establishes automatic promotion into active Memory. The affected epistemic content-transformation row and memory maintenance account therefore concern one retained product, separate from its execution container.

Amendment: EPI-OBJ-shared-view is superseded by MEM-OBJ-shared-view. These are two accounts of the provider/shared-import artifact container: distribution Markdown, recipe metadata and question-view configuration/policy. SRC-1 rightmemory/prompts/shared-view-builder.md in the epistemic record identifies provider-owned artifacts, while rightmemory/reference/SHARED_VIEW_RULES.md and the builder/question paths in the memory record identify their distinct consumption surfaces. The memory account also discusses feedback notes; that added surface does not replace the container's content and permission parts. The declared parts EPI-OBJ-view-document, EPI-OBJ-retriever-policy and EPI-OBJ-view-permission remain separate, with their original parent declaration and IDs intact. Container identity neither merges their authority nor supersedes them by one undifferentiated object.

Amendment: EPI-RTE-provider-question is superseded by MEM-RTE-question-view. Both trace explicit consumer question and connection through provider approval/policy/runtime invocation to an answered/unavailable return. SRC-1 rightmemory/shared_view_questions.py supplies the approval gate and view-specific runtime-session passages. Their wired implementation and uninspected operation findings agree. Memory describes possible provider-session continuity; epistemic says the wrapper does not itself persist the answer and leaves that later answer read-back uninspected. Those statements concern different persistence surfaces and do not conflict. EPI-OBJ-question-answer remains the returned product, not another declaration of the route.

Overlaps that are not record identities

EPI-OBJ-memory explicitly includes linked Markdown and skill assets as well as the Memory tree. MEM-OBJ-memory instead distinguishes that tree from MEM-OBJ-markdown-evidence and MEM-OBJ-memory-skill. The schema/renderer passages in the memory records distinguish graph continuation, retrievable non-graph evidence and complete instruction assets. The epistemic record is a broader semantic-state container; it is not identical to any single one of these records. Its findings do not require replacement once those parts are distinguished, so no split supersession is made. Its ledger does not establish that every route consumes every contained part. Package RT-OBJ-role-instructions is a further distinct object: shipped role policy, not mutable user-root memory.

MEM-RTE-guidance-review covers capture followed by explicit user-reviewed curation. EPI-RTE-guidance-capture and EPI-RTE-guidance-review separately describe those stages. Neither epistemic route is identical to the complete memory route. The combined account remains valid: memory explicitly distinguishes wired capture from an afforded review protocol; epistemic assigns implemented retention to capture and doctrine-only acceptance/integration to the skill. These are different status vocabularies and stage boundaries, not rival findings. All distinguish this inbox-specific workflow from RT-RTE-manual-maintenance and ordinary RT-RTE-isolated-update. No supersession of the valid combined route is required.

EPI-RTE-view-build covers initial construction and refresh, including file distributions and generated question instructions. MEM-RTE-view-refresh concerns file-view refresh. They overlap in the refresh branch but are not identical routes. Their shared SRC-1 rightmemory/shared_view_builder.py passage preserves old approval. EPI-RTE-view-approval is the separate permission transition; RT-RTE-file-import is downstream acquisition, not provider construction or approval. The approval principal and universal withdrawal propagation remain unresolved rather than contradictory.

MEM-RTE-opening-context selects a retained Pursuit neighborhood for host context; RT-RTE-pursuit-editor mutates and checkpoints map state. The caller relationship does not make them identical. MEM-OBJ-pursuits is their retained map, not either route. Likewise, MEM-OBJ-update-evidence, MEM-OBJ-retrieve-context and MEM-OBJ-vectors name retained payload/bookkeeping/cache objects rather than runtime route identities, model parameters or RT-OBJ-semantic-operation phase state.

Independent convergence and integration dispositions

The workflow report declares no additional records. Its annotation on RT-RTE-native-assistant traces the same route's main-agent scheduling, native-child handoffs, task claims, completion retry and program receipt. The memory annotation independently describes live sources and lack of internal delivery-history state. Both agree with the runtime distinction from RT-RTE-agent-retrieval: native retrieval is host-selected, not protected by the internal terminal selector's renderer or output budget. RT-CLM-native-publication concerns publication, not successful enclosing-task delivery or truthful semantic content.

Memory's embedding corpus elaboration extends rather than contradicts RT-RTE-embedding-retrieval: imported/backing/correction/pending entries are included, and count/ranking limits do not detect answer absence. EPI-CLM-retrieval-coverage retains the source's small agent-labelled benchmark as reported operation, consistent with the boundary's lack of raw traces. No stronger observed or causal status is selected.

Memory's separate effectively unbounded include-returned input renderer qualifies the scope of the final-output size check without contradicting the runtime record, which bounds terminal return rather than the complete model window. Provider/host compaction remains uninspected. No universal token-budget or context-removal guarantee follows from either report.

The reports converge on the separation between requested semantic judgment and deterministic publication checks. EPI-CLM-memory-admission and EPI-CLM-correction-cases concern scoped semantic policy; RT-RTE-isolated-update establishes publication controls, including capacity exceptions, not factual truth. RT-RTE-sync-admission, file import, direct maintenance and the Pursuit editor have independent admission authority. No report requires all retained state to have passed local Update or per-content human approval.

The memory integration issues concerning real input provenance, feedback initialization, exact deployed models, host compliance, completed-batch read-back, provider-note adoption and remote withdrawal remain local limits. None contradicts a supported positive in another report. RT-BAP-role-policy and RT-BAP-host-context establish guidance channels, not observed activation or improvement. The epistemic conclusion independently withholds concrete accepted ampliative production, exercised theory-building and causal self-improvement findings without turning those limits into repository-wide absences.

No unresolved cross-report disagreement was found in the supplied versions. This is a reconciliation of their findings, not a judgment that their source support or completeness passes verification.