Temporal Validity on Real Software Histories: Eliminating Stale-Fact Errors in Code-Assistant Memory over GitHub Fixes

AuthorsNeeraj Yadav

arXiv 20262026

TL;DR

MemStrata uses deterministic supersession over a bi temporal ledger to cut RAG’s stale fact errors from 36–38% to ≈0 on real GitHub fixes.

SharePost on XLinkedIn

Read our summary here, or open the publisher PDF on the next tab.

THE PROBLEM

RAG serves superseded values 36–38 percent of the time

RAG retrieves both old and new code facts with near identical similarity, so it cannot tell which value is current and often serves stale answers.

On SWE bench GitHub buggy to fixed histories, naive_rag and advanced_rag commit the superseded value in 36.1–37.7 percent of forced answers, breaking coding assistants’ reliability.

HOW IT WORKS

Deterministic supersession memory over a bi temporal ledger

MemStrata routes each value bearing turn through a deterministic assertion path backed by a production triple extractor and a bi temporal ledger of assertions.

Like a card catalog that always files the latest card on top, MemStrata closes old validity intervals and opens new ones whenever a clean subject relation object triple changes.

This strict_object_supersede rule lets MemStrata retire stale values and surface only currently valid rows, something a plain similarity based context window cannot guarantee.

DIAGRAM

From SWE bench patch to atomic temporal scenario

This diagram shows how MemStrata constructs marker free longitudinal scenarios from SWE bench buggy to fixed GitHub issues.

DIAGRAM

Paired evaluation pipeline for MemStrata and RAG

This diagram shows how MemStrata and RAG are evaluated in paired allowed and forced regimes on the same 130 cached scenarios.

PROCESS

How MemStrata Handles a SWE bench atomic state transition

  1. 01

    Constructing real longitudinal scenarios

    MemStrata uses a local LLM patch reader and the production triple extractor to emit a single atomic subject state_a state_b question tuple from a SWE bench issue.

  2. 02

    Deterministic guard

    MemStrata applies a deterministic guard that rejects scenarios unless the two values differ, are atomic, and carry no recency tells, ensuring clean supersession engagement.

  3. 03

    Self validation selection criterion

    MemStrata keeps a scenario only if the production triple extractor keys the state A and state B sentences identically with objects equal to the two values.

  4. 04

    Deterministic supersession and retrieval

    MemStrata ingests state A then state B into the bi temporal ledger via the deterministic assertion path and strict_object_supersede, then answers the question by retrieving only currently valid rows.

KEY CONTRIBUTIONS

Key Contributions

  • 01

    A real data longitudinal benchmark

    MemStrata mines 130 clean atomic state transitions from 707 SWE bench Lite plus Verified GitHub issues, with a marker free invariant and explicit selection via the production triple extractor.

  • 02

    An end to end win on real history

    MemStrata achieves 0.908 allowed and 0.985 forced accuracy, while naive_rag and advanced_rag reach only 0.569–0.615, and MemStrata drives stale fact error from 0.361–0.377 down to ≈0.

  • 03

    Moat preserving bug fix in strict_object_supersede

    MemStrata identifies a case and punctuation insensitive comparison bug in the assertion path, fixes it with strict_object_supersede, and verifies synthetic accuracy at 1.000 and stale fact error at 0.000.

RESULTS

By the Numbers

accuracy — allowed

0.908

+0.339 over naive_rag

accuracy — forced

0.985

+0.370 over naive_rag

stale-fact-error — forced

≈0.00

36.1–37.7 points lower than naive_rag and advanced_rag

mean retrieval latency

2.13 s

similar to naive_rag’s 2.16 s and 8.5 times faster than advanced_rag’s 18.1 s

On 130 SWE bench Lite plus Verified atomic transitions, MemStrata is evaluated against naive_rag and advanced_rag in paired allowed and forced regimes. The MAIN_RESULT shows MemStrata maintains current code facts with near zero stale commitments while matching RAG latency and compressing active memory by 48 percent.

BENCHMARK

By the Numbers

On 130 SWE bench Lite plus Verified atomic transitions, MemStrata is evaluated against naive_rag and advanced_rag in paired allowed and forced regimes. The MAIN_RESULT shows MemStrata maintains current code facts with near zero stale commitments while matching RAG latency and compressing active memory by 48 percent.

BENCHMARK

Paper 2 result on 130 real GitHub scenarios

Accuracy — allowed on SWE bench Lite plus Verified atomic transitions.

KEY INSIGHT

The Counterintuitive Finding

advanced_rag, which adds an LLM reranker, has stale fact error 0.377 when forced, slightly worse than naive_rag’s 0.361 on the same scenarios.

Designers often expect smarter reranking to help, but without a temporal signal advanced_rag simply reshuffles chunks and cannot distinguish stale from current values, sometimes amplifying stale commitments.

WHY IT MATTERS

What this unlocks for the field

MemStrata shows that deterministic supersession over a bi temporal ledger can keep current code facts across evolving GitHub histories at RAG latency.

Builders can now ship coding assistants whose session memory has a moat like guarantee against stale fact errors on clean code mutations, rather than hoping embedding similarity and reranking will suffice.

~10 min read← Back to papers

Related papers

RAG

A Dynamic Retrieval-Augmented Generation System with Selective Memory and Remembrance

Okan Bursa

· 2026

Adaptive RAG Memory (ARM) augments a standard retriever–generator stack with a Dynamic Embedding Layer and Remembrance Engine that track usage statistics and apply selective remembrance and decay to embeddings. On a lightweight retrieval benchmark, ARM achieves NDCG@5 ≈ 0.9401 and Recall@5 = 1.000 with 22M parameters, matching larger baselines like gte-small while providing the best efficiency among ultra-efficient models.

Questions about this paper?

Paper: Temporal Validity on Real Software Histories: Eliminating Stale-Fact Errors in Code-Assistant Memory over GitHub Fixes

Answers use this explainer on Memory Papers.

Checking…