When Correct Memories Become Wrong Decisions: Building Context-Aware Manufacturing Memory with Hindsight Team ThinkMates (Amrutha K, Kammar Akshay, Rashmika K) built Validrift, a change-aware manufacturing memory system that pairs persistent Hindsight memory with a deterministic context-validity engine to decide whether learned fixes should still be trusted. The system was motivated by a heat-sealing machine, Sealer-02, where a fix of increasing temperature +5°C succeeded 4/4 times under Film-A/R10 but failed 2/2 times after production switched to Film-B/R11, showing that a memory can remain historically true while its validity drifts. Validrift records process changes as first-class events and issues Fix Passports that display both the validated and drifted states of the same corrective action. By Team ThinkMates — Amrutha K, Kammar Akshay, Rashmika K Sealer-02 is a heat-sealing machine on a packaging line. For months it ran Film-A from supplier PackCo under recipe R10, and the fix for any Weak Seal defect was reliable: Increase Temperature +5°C — four successes, zero failures. Then production changed to Film-B from FlexPack under recipe R11. The Weak Seal defect returned — and the remembered fix, four successes and zero failures behind it, failed twice. Most AI memory answers one question well: what worked before? They store experiences, retrieve them by similarity, and surface the past fix. That works until the world moves. "Temperature +5°C worked 4 out of 4 times" is technically correct — and operationally dangerous — when those times happened under a context that no longer exists. A fix is never valid in the abstract. It is valid for a defect, under a context : Change the film and the seal physics change with it. The old memory is still true — the fix really did work under Film-A/R10. But truth and current validity differ, and a system that cannot tell them apart may recommend a fix that the new reality has already contradicted. The fix did not become false. Its validity boundary changed. Validrift is change-aware manufacturing memory: persistent Hindsight memory plus a deterministic context-validity engine deciding whether learned knowledge should still be trusted. Hindsight remembers the manufacturing history. The Validrift engine decides whether that knowledge remains valid under the current production context. Its main ideas are: Nothing is deleted or globally overwritten just because the production context changed. Under: the corrective action Increase Temperature +5°C had: 4 successes / 0 failures Status: VALIDATED Validrift preserves this as historical evidence. It happened, it worked, and that historical fact remains true. Production later changed: Film-A → Film-B PackCo → FlexPack R10 → R11 Validrift records process changes as first-class events in its structured ledger and in Hindsight. A process change tells the system that previously learned knowledge may need to be re-evaluated. Under Film-B/R11, the same fix failed twice: 0 successes / 2 failures DRIFTED The old record is not erased. The Fix Passport can show both facts at the same time: Film-A/R10 Temperature +5°C 4 successes / 0 failures VALIDATED Film-B/R11 Temperature +5°C 0 successes / 2 failures DRIFTED The memory wasn't wrong. Its validity drifted. Validrift's central idea is that validity is a function of: fix, defect, context —not of the fix alone. Every intervention record carries the production context. For a new incident, the deterministic engine separates evidence into: It then evaluates each fix using one of these statuses: This lets the same corrective action have different validity states under different production conditions. A Fix Passport is the biography of one corrective action. It contains: If a quality engineer asks: "Why not Temperature +5°C?" Validrift can answer with both halves of the truth: Film-A/R10: 4/0 — VALIDATED Film-B/R11: 0/2 — DRIFTED There is no global overwrite and no silent forgetting. A process change can trigger a Memory Validity Audit . Known fixes are re-evaluated against the current context. For example: Instead of treating every remembered fix as permanently trustworthy, Validrift continuously asks: Does this knowledge still apply here? Manufacturing events are retained into the Hindsight memory bank. These can include: HindsightService.retain uses stable document IDs and records a MemoryTrace row in SQLite. This makes memory operations auditable with: When a new Weak Seal incident occurs on Sealer-02 under Film-B/R11, Validrift recalls relevant manufacturing experience from Hindsight. This can include: During the verified live run, the recommendation flow received 49 real recalled memory IDs . The important distinction is: Recall supplies evidence. It does not supply the final validity verdict. That decision belongs to Validrift's deterministic validity engine. Hindsight REFLECT is used to generate higher-level understanding from accumulated experience. For example, Validrift can ask: How did the effectiveness of Temperature +5°C change between Film-A/R10 and Film-B/R11? Reflection helps explain how knowledge evolved across contexts. However, REFLECT does not determine the validity status. The deterministic engine remains responsible for: VALIDATED, SUPPORTED, DRIFTED, and the other validity states. The heart of Validrift is deliberately not an LLM . A simplified part of the real logic is: if hs 0 and cf = settings.drift min failures and cs == 0: status = ValidityStatus.DRIFTED reason = f"Historically successful evidence exists, " f"but {cf} repeated failure s occurred in the current context." elif cs = settings.validated min successes and ratio = 0.75: status = ValidityStatus.VALIDATED reason = f"{cs} successful current-context outcomes " f"support repeated validation." There are no language-model probabilities deciding whether a fix is valid. The thresholds are deterministic configuration, and every status is backed by evidence and a reason. A recommendation is only a hypothesis until its outcome is recorded. The recommendation flow writes its reasoning back into memory: retain text = f"Validrift recommended '{best.fix name}' for incident " f"{incident.id} {incident.defect} under " f"machine {incident.machine}, " f"material {incident.material}, " f"supplier {incident.supplier}, " f"recipe {incident.recipe}, " f"firmware {incident.firmware}. " f"Validity status: {best.status}. " f"Current-context evidence: " f"{best.current successes} success es , " f"{best.current failures} failure s ." await memory service.retain db, request id=request id, content=retain text, context="Validrift recommendation", document id=f"recommendation:{rec id}", timestamp=rec.created at, metadata={ "recommendation id": rec id, "incident id": incident.id, "fix": best.fix name }, tags= "validrift", "recommendation", f"defect:{incident.defect.lower .replace ' ', '-' }" In the verified end-to-end flow: Pressure +8% started with: 2 successes / 0 failures SUPPORTED One additional successful recorded outcome changed the evidence to: 3 successes / 0 failures The loop becomes: Recommend → Record Outcome → Retain → Re-evaluate → Improve Future Recommendations Quality Engineer │ ▼ Validrift Frontend │ ▼ FastAPI Backend │ ├────────► SQLite │ Incidents │ Interventions │ Process Changes │ Recommendations │ Outcomes │ Memory Traces │ ├────────► Hindsight Cloud │ RETAIN │ RECALL │ REFLECT │ └────────► Deterministic Validity Engine │ ▼ Context-Scoped Validity │ ▼ Recommendation │ ▼ Recorded Outcome │ ▼ Hindsight RETAIN │ ▼ Better Future Recommendation Nothing in this architecture automatically controls manufacturing equipment. Validrift is a decision-support system , not autonomous machine control. The system defines the production context using five core fields: CORE CONTEXT FIELDS = "machine", "material", "supplier", "recipe", "firmware" Evidence is represented explicitly: @dataclass class EvidenceItem: incident id: str intervention id: str date: datetime defect: str fix name: str outcome: str context: dict notes: str def to dict self : d = asdict self d "date" = self.date.isoformat return d Each evaluated fix keeps current and historical evidence separately: @dataclass class FixEvaluation: fix name: str defect: str status: str current successes: int current failures: int current partial: int historical successes: int historical failures: int current evidence: list EvidenceItem historical evidence: list EvidenceItem relevant process change: dict | None reason: str score: float And context equality is deterministic: php def context of incident: Incident - dict: return { k: getattr incident, k for k in CORE CONTEXT FIELDS } def contexts match a: dict, b: dict - bool: return all a.get k or "" == b.get k or "" for k in CORE CONTEXT FIELDS Every Hindsight operation also leaves an auditable memory trace: python def trace self, db: Session, request id: str, operation: str, summary: str, started: float, memory ids: list str | None = None, status: str = "SUCCESS", details: dict | None = None : db.add MemoryTrace id=new id "MT" , request id=request id, operation=operation, query summary=summary, memory ids=memory ids or , latency ms=round time.perf counter - started 1000, 2 , status=status, details=details or {}, db.commit | Check | Result | |---|---| | Backend test suite | 13/13 passed | | Frontend pages | 5/5 hydrated, zero JS errors | | Hindsight RETAIN / RECALL / REFLECT | PASS / PASS / PASS | | /api/health | hindsight: {mode: live, ok: true} | | Temperature +5°C, Film-A/R10 | 4/0, VALIDATED | | Temperature +5°C, Film-B/R11 | 0/2, DRIFTED — history preserved | | Pressure +8%, Film-B/R11 | 2/0 SUPPORTED → 3/0 VALIDATED after recorded outcome | Validrift is designed to fail honestly. If Hindsight becomes unavailable, the deterministic engine can still compute validity statuses from the structured SQLite ledger. The UI reports: Memory service temporarily unavailable. If natural-language explanation is unavailable, the system reports: Evidence is available, but natural-language explanation is temporarily unavailable. It does not fabricate recalled memories, successful memory events, or reflection output. Validrift still has important limitations. The instinct — in manufacturing and in AI memory design — is to treat the past as a promise. Validrift treats the past as evidence: kept forever, trusted conditionally, and re-examined whenever the context changes. A corrective action can deserve: VALIDATED under Film-A/R10 and: DRIFTED under Film-B/R11 at the same time. That distinction is the core of change-aware memory. The memory wasn't wrong. Its validity drifted.