Why knowledge systems need to think beyond timestamps and updates.
The expensive part of old knowledge isn't always updating it. Sometimes it's figuring out whether it still needs updating.
Imagine opening a note you wrote two years ago:
Library X doesn't support Y.
At the time, the statement was correct. You had checked the documentation, perhaps tested the library yourself, and recorded the conclusion so you wouldn't have to repeat the investigation.
Now, two years later, you're working on a project that requires Y.
You find your old note. The information is exactly where you left it. Your knowledge management system has done its job: it preserved something you once learned and made it retrievable.
But can you trust it?
You open the library's documentation. You search the changelog. You check the release history, look through relevant issues, and perhaps run a small experiment against the current version.
Twenty minutes later, you reach a conclusion:
Library X still doesn't support Y.
Nothing has changed.
Your original note was correct. It required no modification. Yet recovering confidence in that statement consumed twenty minutes of work.
This is a peculiar kind of maintenance cost: you paid to verify that no maintenance was necessary.
And most knowledge management systems have remarkably little to say about it.
1. The Difference Between Updating Knowledge and Revalidating It
When we discuss knowledge maintenance, we usually think about updates.
A fact becomes outdated. A dependency changes. A previously accurate statement no longer describes reality. We discover the discrepancy and correct our records.
This is an update cost.
But there is another cost that exists independently of whether the underlying information has changed: revalidation cost.
Revalidation cost is the effort required to determine whether an existing claim remains valid under the conditions in which we intend to use it.
The distinction matters because verification and correction are separate operations with separate outcomes.
Consider three possibilities:
- A claim is outdated, and verification reveals that it needs correction.
- A claim remains accurate, and verification confirms that no correction is needed.
- A claim is used without verification, leaving its current validity uncertain.
Only the first scenario necessarily produces an update. Both the first and second incur verification costs. The third avoids immediate verification costs but introduces the possibility of relying on an invalid assumption.
This suggests that the total cost of maintaining usable knowledge cannot be measured solely by how often information changes.
A more useful conceptual model might be:
Knowledge maintenance cost = Revalidation cost + Update cost + Expected cost of undetected invalidity
These components are not necessarily additive in every real-world workflow, and their relative importance depends on context. But distinguishing them exposes something that conventional note-taking systems tend to obscure.
A knowledge base can contain perfectly accurate information and still be expensive to use.
The problem is not necessarily the quality of its contents. It may be the cost of establishing that quality at the moment it matters.
2. A Timestamp Is Not a Measure of Truth
Most digital knowledge systems understand time primarily through timestamps.
A document was created on a particular date. A note was last modified six months ago. A page hasn't been edited in three years.
These are useful properties, but they tell us about the history of the record, not necessarily the validity of the knowledge it contains.
Consider two notes written on the same day, two years ago.
Note A:
API endpoint X returns a specific response structure.
Note B:
The derivative of x² is 2x.
Both notes are equally old in chronological terms.
But treating them as equally susceptible to obsolescence would be absurd.
The API may have undergone multiple revisions. Its response schema could have changed, its authentication requirements could have evolved, or the endpoint might have been deprecated entirely.
The mathematical statement, by contrast, remains valid under its original assumptions.
The passage of two years does not have the same epistemic significance for both claims.
Staleness isn't just about age. It's about how likely reality was to change underneath the note.
This distinction becomes especially important when a knowledge system attempts to automate maintenance.
A simple rule such as "flag notes that haven't been updated in twelve months" confuses chronological age with epistemic uncertainty.
It might repeatedly flag stable mathematical definitions while overlooking a pricing note that became inaccurate three days after it was written.
The relevant question is not merely:
How long has this information existed?
It is:
What could have changed since this information was last verified, and how much would that change matter now?
3. Knowledge Has Different Rates of Change
Not all claims have the same relationship with time.
Some describe relatively stable structures. Others describe contingent states of the world that can change rapidly.
A mathematical identity, a historical date, a software pricing tier, and a cloud provider's API behavior are all pieces of information. Yet their expected rates of change differ dramatically.
We can think of this as a claim's change susceptibility: how likely the conditions supporting a statement are to change over a given period.
For example:
| Knowledge category | Typical change susceptibility |
|---|---|
| Mathematical definitions and established theorems | Very low |
| Historical events and dates | Low |
| Programming language specifications | Low to moderate |
| Software library capabilities | Moderate to high |
| API behavior and service policies | High |
| Pricing, availability, and regulatory requirements | Often high |
These categories are only heuristics, not universal rules. Even stable facts can be recorded incorrectly, and a historical interpretation can change as new evidence emerges. A supposedly volatile API may also remain unchanged for years.
The point is not to assign permanent expiration dates to entire categories of knowledge.
It is to recognize that the probability of a claim becoming invalid depends on the system or reality that the claim describes.
A more sophisticated knowledge system could use that distinction to estimate when verification is worth performing.
Crucially, this would be an estimate of verification priority, not an automatic declaration that an old statement is false.
4. Revalidation Should Be Triggered by Use, Not Just by Time
The obvious response to stale knowledge is periodic verification.
Every thirty days, check the API notes. Every six months, review technical documentation. Once a year, revisit old research.
But this approach introduces another inefficiency: it spends resources maintaining information that may never be used again.
Suppose you have 10,000 notes.
Some are accessed every week. Others have not been opened in years. Many describe systems you no longer depend on.
Revalidating all of them on a fixed schedule could consume substantial time or computational resources without producing corresponding value.
Instead, consider a different principle:
Verification should be prioritized when a claim becomes relevant to a decision.
Returning to the original example, your two-year-old library note does not necessarily need attention while it sits unused in your knowledge base.
But the moment you retrieve it to make an architectural decision, its validity becomes consequential.
That is when a knowledge system could surface contextual information:
- The claim was last verified two years ago.
- It describes the behavior of an externally maintained library.
- The library has released several versions since verification.
- The claim is about to influence a technical decision.
None of these observations proves that the claim is outdated.
Together, however, they provide a reason to verify it before relying on it.
A system could express this through a verification priority rather than a simplistic expired/not-expired classification.
Conceptually, that priority might depend on four factors:
Verification priority = f(elapsed time, change susceptibility, dependency changes, consequence of error)
Elapsed time describes how long uncertainty has had to accumulate.
Change susceptibility estimates how volatile the underlying subject is.
Dependency changes capture whether relevant external systems have evolved since the last verification.
Consequence of error measures the cost of relying on an incorrect claim.
The final factor is particularly important.
An outdated note about a minor UI preference and an outdated note about a payment API's security requirements should not receive equal attention, even if both have the same probability of being wrong.
Verification is an allocation problem. The objective is not to eliminate all uncertainty, which is generally impossible, but to spend verification effort where it has the greatest expected value.
5. The Missing Relationship Between Claims and Their Dependencies
There is a deeper architectural problem here.
Traditional notes tend to store statements as text, with little explicit representation of what makes those statements true.
Consider:
Library X doesn't support Y.
This claim implicitly depends on several things.
It depends on which version of Library X is being discussed. It depends on what "support" means. It may depend on the operating environment, configuration, or the availability of third-party extensions.
Most note-taking applications store the sentence but not those dependencies.
As a result, when something changes, the system has no reliable way to identify which claims might be affected.
This is where a graph-oriented representation becomes interesting.
Imagine representing the statement as a claim connected to its supporting context:
Claim: Library X does not support Y.
Dependencies: Library X, version range, feature Y, relevant platform constraints.
Evidence: Documentation, issue discussion, or test result.
Verification metadata: Last checked date, tested version, verification method.
Now suppose Library X releases a major update.
That event does not automatically invalidate the claim. But it may change the claim's verification priority because one of its dependencies has changed.
A knowledge system could potentially identify the relationship and surface the claim when it becomes relevant again.
The important distinction is between detecting a possible reason for revalidation and establishing that the claim is false.
A release event is evidence that the environment may have changed. It is not evidence that every claim about the library has become invalid.
This distinction is essential if automated knowledge maintenance is to avoid producing more noise than value.
6. From Storing Information to Managing Confidence
Knowledge management has historically focused on capture, organization, and retrieval.
How do we save information?
How do we connect related ideas?
How do we find something we previously learned?
These remain fundamental problems. But retrieval alone is insufficient when the information describes a changing world.
Finding a claim is not the same as knowing whether it remains safe to use.
A system that retrieves an old note without communicating its verification context effectively leaves the user to reconstruct that context manually.
This suggests an additional responsibility for knowledge infrastructure: helping users manage confidence in their existing information.
Such a system would not need to assign an absolute truth score to every statement. In fact, doing so would risk introducing false precision.
Instead, it could preserve the distinction between several questions:
Was this claim supported when it was recorded?
When was it last verified?
What conditions did that verification cover?
Have relevant dependencies changed?
How important is verification before the claim is used again?
These questions describe different dimensions of knowledge quality.
A claim may have strong historical evidence but uncertain current applicability. Another may be recently recorded but poorly substantiated. A third may be old, well-established, and entirely appropriate to reuse without further investigation.
A single timestamp cannot capture these differences.
Neither can a single confidence score unless its meaning and limitations are carefully defined.
The more promising approach is to preserve the provenance and verification context of claims so that users can make informed decisions about when additional investigation is warranted.
7. The Paradox of a Growing Knowledge Base
The more knowledge we accumulate, the more useful our personal knowledge base should become.
But growth introduces a subtle problem.
Every additional claim is another piece of information that may eventually require verification.
A sufficiently large knowledge base can therefore become a repository of unresolved uncertainty.
This does not mean storing more knowledge is inherently counterproductive. It means that the value of accumulated information depends partly on the cost of determining whether it remains applicable.
A note that takes thirty seconds to retrieve but twenty minutes to revalidate is not necessarily saving twenty minutes of work.
Sometimes it is only saving the initial discovery process while leaving the verification process intact.
And in some cases, the old note may be actively misleading because its apparent completeness discourages further investigation.
This creates an interesting design challenge:
How can a knowledge system preserve the benefits of accumulated information without forcing users to repeatedly audit everything they have ever learned?
My hypothesis is that the answer lies partly in treating verification as a first-class operation.
Not every claim needs constant monitoring.
Not every change requires an update.
Not every old note deserves a warning.
But when a claim becomes relevant again, the system should be able to help determine whether its existing evidence is sufficient for the intended use.
The goal is not a knowledge base that continuously rewrites itself.
It is a knowledge base that understands the difference between remembering something and having good reason to trust it now.
8. Toward Knowledge Systems That Understand Change
This is one of the problems I'm interested in exploring through Infinite Graph, a project focused on connected personal knowledge.
A graph is useful not merely because it can visualize relationships between ideas, but because relationships can provide context for evaluating how information remains applicable over time.
If a claim depends on a software version, a policy, an external service, or another claim, those dependencies may help determine when revalidation deserves attention.
That doesn't mean an AI should silently rewrite notes whenever it detects a possible change.
Verification requires evidence. Updates require judgment. And a system that mistakes plausible AI-generated answers for verified facts would only replace one maintenance problem with another.
I think a better design principle is to make uncertainty visible and verification more deliberate, while keeping the user responsible for deciding what belongs in their knowledge base.
The long-term ambition is not simply to make old information easier to find.
It is to reduce the work required to determine whether that information can still be trusted.
Because the most expensive knowledge isn't always the knowledge that becomes wrong.
Sometimes it's the knowledge that remains right, but makes us prove it again.
Should a two-year-old API note and a two-year-old math note look equally "old" to a knowledge system?
And if not, what should a knowledge system understand about the world before it decides which one deserves another look?