In [Context Engineering (Part 1): The Architecture of Recall], we discussed the Structure of data (Hierarchy). Now, we must discuss the Time and Temperature of data.
Most RAG (Retrieval Augmented Generation) systems are static. They treat a document from 2020 exactly the same as a document from today. They treat a generic policy document the same as your specific user profile. This leads to “Zombie Knowledge”-the AI confidently reciting facts that were true three years ago but are dead today.
To build a truly “Context-Aware” system, we need to architect for Entropy (Time) and Identity (Warmth).
1. The Decay Function (The Half-Life of Truth)
The Naive Approach:
“Relevance = Vector Similarity.”
The Engineering Reality:
In software, the truth is a moving target. “How to reset the server” in 2021 is likely different from 2025. If the AI retrieves the 2021 answer because the wording is a better match, it is failing.
I believe in the Decay Function. We shouldn’t just “cut off” old data (because history is useful for debugging), but we must apply a mathematical “Gravity” that pulls old data down.
- The Formula : Score = Similarity * (1 / Time_Elapsed)
- The Result : A document from Yesterday with an 80% match should beat a document from Last Year with a 95% match.
We prioritize “ What happened latest ” over “ What happened best. ” In a living system, Recency is Relevance.
2. The Context Triad (Hot, Warm, Cold)
The Naive Approach:
“Stuff everything into the Context Window until it’s full.”
The Engineering Reality:
We need to treat context like a tiered storage system, but defined by Intimacy , not just speed.
- L1: Hot Context (The Situation): Definition: What is happening right now ? The current conversation, the open VS Code tabs, the error log streaming in this second. Policy: This is the “Attention Head.” It overrides everything.
- L2: Warm Context (The Persona): Definition: Who am I? This is where most systems fail. They don’t know the user. “Warm” data is my LinkedIn profile, my Medium articles, my coding style preferences. Policy: This is the “Filter.” It colors how the AI speaks to me. It doesn’t need to be retrieved every time; it should be “Always On” in the system prompt.
- L3: Cold Context (The Archive): Definition: What happened last year? Old tickets, closed PRs, historical design docs. Policy: This is “On Demand.” Only fetch this if the user explicitly asks for history. Never let Cold data pollute the Hot window.
3. The Pragmatic Truth (Real > Official)
The Naive Approach:
“The Official Documentation is the source of truth.”
The Engineering Reality:
Any Senior Engineer knows that the “Docs” are often theoretical, while the “Slack Logs” contain the actual fix. If the Documentation says “The API limit is 100,” but the Engineers in Slack are saying “Actually, it crashes after 50,” the AI faces a conflict.
My Philosophy:
The AI should provide the Real Answer , not just the Official one.
- The Output: “Officially, the docs say the limit is 100. However, looking at recent logs and team chats, the real limit appears to be 50 before instability occurs.”
We must treat the AI as a Pragmatic Engineer , not a Compliance Bot. But-and this is critical-it must “ Give Justice” to the answer. It cannot just hallucinate a new fact; it must cite the source of that reality: “I found this in a Slack conversation from yesterday.” Transparency allows the user to trust the “Real” answer over the “Official” one.
Conclusion: The Living Index
Context isn’t just a database of facts. It is a living, breathing ecosystem. It ages (Decay). It has personality (Warmth). It has street smarts (Pragmatic Truth). If you build your RAG system without these dimensions, you aren’t building intelligence. You are just building a very expensive search engine for old PDFs.
Originally published at https://www.linkedin.com.
Top comments (0)