Your Vault Contradicts Itself — Date Your Notes So the AI Knows Which One Is Current

Two of your own notes disagree. Both are real, both were true once, and the assistant reading your vault has no memory of your life to break the tie. Dating a note, and pointing the stale one at its replacement, is how a machine can know which version you still believe.

Note the verb. Can know, not will know. The title of this post promises more than the evidence supports, and the rest of it is the correction.

The research names this failure precisely. In Knowledge Conflicts for LLMs: A Survey, Rongwu Xu and six co-authors sort the ways a model's knowledge collides into three kinds: "context-memory, inter-context, and intra-memory conflict."¹ The middle one is yours. "We term the conflict among various pieces of contextual knowledge as inter-context conflict," they write.² Not the model against the world. The documents you handed it, against each other.

When you point an assistant at your notes, your notes are those documents. The survey makes the mapping literal rather than metaphorical: retrieval "can lead to inconsistencies within the provided context, as the external documents may contain information that conflicts with each other."³ Your vault is the context window. It contains your 2024 answer and your 2026 answer, sitting in the same folder, equally confident.

What most people believe: a vault is a record of what you know

The intuition is reasonable and mostly correct. You write things down so you stop having to remember them. The vault accumulates; the accumulation is the point. More notes mean more coverage, and search will surface whichever one answers the question, so the job is capture and the tool's job is retrieval.

That model works for a human reader, because a human reader brings a second corpus to the table: your life. You know you changed banks. You know the API got rewritten. When your old note contradicts your new one, you do not consult a timestamp — you remember, and the stale note is dead on sight.

The reader who has no memory of your life gets none of that. It sees two documents — both real, both yours, both plausible. It cannot tell that one of them is a ghost.

What actually happens: your vault holds both versions at once

A vault is not a record of what you know. It is a record of everything you have ever believed, stored at equal confidence, with nothing inside the files to say which belief survived. Xu and co-authors name exactly this as a cause of inter-context conflict, and they name it plainly: "Outdated Information."⁴

Their sentence is the one worth pinning up: "In addition to the challenge of misinformation, it is important to recognize that facts can evolve. The retrieved documents may contain updated and outdated information from the network simultaneously, leading to conflicts between these documents."⁴

Read that with your own folder in mind. Facts evolve — yours especially. The deploy process, the rate you charge, the dosage, the person who owns the project, the way you feel about the person who owns the project. You did not delete the old note when the fact changed. You wrote a new one.

Both are now in scope. The survey frames the tie-break as a timestamp problem in as many words: "another significant challenge involves addressing conflicts that arise from documents bearing different timestamps, especially when a user's prompt specifies a particular time period."⁵ And it treats stale-versus-current as a first-class conflict class, not an edge case: "Conflicts in context frequently arise between misinformation and accurate information, as well as between outdated and updated information."⁶

This is not hallucination. Nothing was invented. Every sentence in the answer was written by you, sourced from a real file, faithfully retrieved. That is what makes it hard to catch — the output has no tell.

The external web has the same disease, and it has been measured. Pew Research Center found that "38% of webpages that existed in 2013 are no longer accessible a decade later."⁷ Facts rot in public at a rate somebody bothered to count. Nobody has counted the rot in your vault, because nobody can see inside it. You are the only auditor it has.

The uncomfortable part: the newest note does not automatically win

A date is a signal, not enforcement. The retriever may never surface the field. The model may see it and disregard it. There is no rule anywhere in the stack that says the most recent document wins, and the honest reading of the research is that recency loses to polish more often than anyone would like.

The survey's summary of one such study is the sentence that should worry you. Describing work by Xu et al. (2023) on how models respond to conflicts during interactive sessions, the survey reports: "Their findings suggest LLMs tend to favor logically structured knowledge, even when it contradicts factual accuracy."⁸

That is the survey characterizing the primary, not the primary's own printed words. The underlying paper's abstract puts it differently, finding that "LLMs' correct beliefs on factual knowledge can be easily manipulated by various persuasive strategies."⁹ The two sentences point the same way.

Sit with the consequence. A well-written stale note beats a scrappy current one. The 2024 note you spent an hour on — headed, structured, confident — is more persuasive than the three-line correction you typed on your phone last week. Coherence is legible to a machine. Truth is not.

Nor can you assume the model will notice the contradiction at all. Jierui Li, Vipul Raheja and Dhruv Kumar built a benchmark for exactly this and found the ceiling low: "While GPT4 performs the best and can outperform humans on this task, we find that it is still unreliable and struggles with self-contradictions that require more nuance and context."¹⁰ The best model in that study beats a human at spotting a contradiction and is still not reliable.

So the guaranteed fix is not a field. It is deletion. The only way to be certain a stale note never wins is that the stale note is not there. You delete it, you overwrite it, or you explicitly mark it dead. Everything below is the cheap part, and it helps only a reader that bothers to look. Resolve; don't accumulate.

What to do instead: put the date and the pointer inside the file

Two fields, written in the file's own header, where any reader encounters them alongside the text: human, script, or model. updated: says when you last believed this. superseded_by: says what to believe instead. Neither is an invention; both are conventions that existing tools already read.

Hugo's documentation shows the mechanism in one line — "Set the last modification date in front matter:" — followed by a worked example that reads lastmod: 2023-10-19T00:40:04-07:00.¹¹ Jekyll reads a header from the same slot: "The front matter must be the first thing in the file and must take the form of valid YAML set between triple-dashed lines."¹² Two independent tools, one header. The convention is older than the problem.

The current note carries its own date:

---
title: Deploy process
updated: 2026-07-16
status: current
---

The dead one does not get deleted quietly and forgotten. It gets a forwarding address:

---
title: Deploy process (2024 — superseded)
updated: 2024-03-02
status: superseded
superseded_by: deploy-process
---

Now the conflict resolves itself in the text. Whatever surfaces the old note surfaces the word superseded and the name of its replacement, in the same breath as the stale instructions. You have not made the machine obedient. You have made the file honest — which is the only part you control. The header mechanics themselves we have covered before, in YAML frontmatter: the metadata header.

Here the instinct arrives: doesn't the file already have a modified date? It has one, and it is not durable. POSIX specifies that cp copies a file's modification time only with the -p flag, which "duplicate[s] the following characteristics of each source file in the corresponding destination file: The time of last data modification and time of last access."¹³ A plain copy does not.

Move your vault, sync it, restore it from a backup, and the dates you were counting on may be the date of the restore. That argument has its own post with the receipts: your note dates are filesystem metadata. The point here is different anyway. Even a perfect mtime lives outside the file, and the reader is looking at the text.

One honest note on scale. Anthropic reports that prepending a short explanatory blurb to each chunk — before both embedding it and indexing it for keyword search — "can reduce the number of failed retrievals by 49% and, when combined with reranking, by 67%."¹⁴ That is a result about an engineered retrieval pipeline, and nothing more.

It is not a measurement of what a header does to your vault. Nobody has run that study, and this post does not claim otherwise. The resemblance is an analogy and worth exactly what an analogy is worth: context that travels with the text is cheap, and context that travels with the text is the kind of thing retrieval systems have been shown to use.

The practice: five things to do tomorrow

Start with the notes that would embarrass you if a machine read them aloud. The fix is not a migration — it is a habit with an eviction policy. You are not trying to date every file you own. You are trying to make sure that when two of your notes disagree, the loser says so in writing.

1. Delete first, date second. If the old note has no historical value, the strongest fix is that it stops existing. Every field below is a consolation prize.
2. Add updated: when you change a note's meaning — not when you fix a typo. The date should mean "I re-believed this," not "I touched this."
3. Add superseded_by: to the loser, not just a link from the winner. The stale note is the one that gets retrieved by accident, so the correction has to live there.
4. Put the status in the title too. Titles survive summarization, truncation, and search-result lists. Deploy process (2024 — superseded) is a warning that outlives the header.
5. Keep one index note that says what is current. The pointer a human maintains beats the graph a tool infers. That argument is made in full in one index note beats a graph.

This is orthogonal to marking who wrote a note. A note can be human-written and stale, or machine-written and current; provenance and recency are different fields answering different questions, which is why marking which notes the AI wrote is a separate discipline from this one.

Frequently Asked Questions

The questions below are the ones a reader arrives with after an assistant has confidently quoted a note they stopped believing in 2024. The short version: nothing invented the wrong answer, both files were real, and the fix lives in the text of the loser rather than in the tool doing the reading.

Why does my AI give me outdated information from my own notes?

Because both versions are in your vault and nothing in the files says which one you still believe. Xu and co-authors name "Outdated Information" as a cause of inter-context conflict: retrieved documents "may contain updated and outdated information from the network simultaneously, leading to conflicts between these documents."⁴ Your folder behaves the same way.

Is it hallucination if both notes were real?

No, and this is the important distinction. Hallucination is invention. This is conflict between two genuine documents you wrote yourself, faithfully retrieved and faithfully summarized. The survey classes it as inter-context conflict — the collision "among various pieces of contextual knowledge"² — which no amount of model honesty prevents.

Does the AI just pick the newest note?

There is no guarantee it does. The survey's account of one study reports that models "tend to favor logically structured knowledge, even when it contradicts factual accuracy."⁸ Li, Raheja and Kumar separately found GPT-4 "still unreliable" at spotting self-contradiction.¹⁰ A polished stale note can win on presentation.

How do I tell an AI which note is current?

Put it in the text, not around it. updated: in the header states when you last believed the note; superseded_by: names the replacement. Both live in the same YAML block Jekyll and Hugo already read.^{11 12} It is a signal to whatever reads the file, not a command it must obey.

Doesn't the file's modified date already tell it?

Only if nothing ever touched the file. POSIX cp preserves modification time only with -p,¹³ so a copy, a sync, or a restore can silently rewrite the dates you were trusting. The durable record of when belongs inside the file. The full argument, with the receipts, is in your note dates are filesystem metadata.

What fields should I actually add?

Three, and no more: updated: (a date, changed when the meaning changes), status: (current or superseded), and superseded_by: (the slug of the replacement, on the dead note). Hugo's lastmod shows the convention is decades old.¹¹ Anything beyond three fields is a system you will abandon by March.

Steph Ango puts the durable half of this plainly: "The app will eventually become obsolete. It's the plain text files I create that are designed to last."¹⁵ The files last — which is the problem as much as the promise. Everything you have ever believed lasts along with them, in the same folder, at the same confidence, waiting to be retrieved by something that was not there when you changed your mind.

A vault that only accumulates is not a memory. It is a pile of claims with the dates torn off. The work is not capture; the work is saying, in the file, which version you still believe — and being willing to delete the one you don't.

Notes in MNMNOTE are plain Markdown files with a frontmatter header you control, so the updated: and superseded_by: lines are yours to write and yours to keep — mnmnote.com.