Article · Field notes
Old Certainty in a Fresh Shirt
13 Feb 2026 5 min read
My notes looked beautifully organised right up until I tried to make a decision with them.
Bookmarks, call notes, screenshots, links from Slack, AI answers I half-trusted, market comments I couldn’t place two weeks later. I’d kept everything except the one thing that would tell me whether any of it was still true.
The old loop was simple: ship a feature, check the metrics, repeat. It still works, right until the question becomes whether the user even has the problem I think they have. That answer never shows up in one piece. It arrives in fragments: a sentence from a customer call, a failed onboarding experiment, a competitor changing its pricing page, the same confused question from three different prospects.
So I stopped collecting lists and started connecting things. “Personal knowledge graph” sounds fancy. For me it just means linking what I learn to what I decide.
In Obsidian I keep small notes, links between ideas, reflections after calls, failed experiments and surprises. I separate the user’s words from my interpretation of them, the problem I assumed from the one I actually saw, and a decision from the evidence behind it.
Skip the connections and it all turns to mush.
AI makes the mush more dangerous, because it can make mush sound coherent. Feed it shallow notes and the answer comes back polished and wrong, in exactly my own accent. Feed it notes that are specific, dated and tied to decisions, and it has something to work with.
Writing is part of the memory system too. A post or a short video forces me to connect what a user said to what I built and what happened next. Whatever it does for content strategy is a bonus that comes later.
It still gets overwhelming. I don’t know if users want the thing. I don’t know if we’re solving the right problem. Everyone else seems to know their market better than I know mine, although I suspect their notes are lying to them too.
Other builders help, mostly by spotting the stale bits of my map. They ask the dumb question I stopped asking. They remember that the thing I now treat as obvious was only true for one customer segment, in March.
I don’t need a perfect map. I need one that tells me which notes are old.
The missing field was time
A knowledge graph is entities connected by relationships. The basic unit is a triplet:
(subject, predicate, object)
Triplet examples
(User-segment-A, struggles-with, onboarding-flow)(Feature-X, solves, Problem-Y)(Project-Z, uses, Postgres)(Decision-123, was-driven-by, user-feedback)
Link enough triplets together and you get a graph, instead of a folder full of notes that have never heard of each other.
A correct note can become a wrong decision
Notes sit still. Product truth moves:
- we targeted enterprise, then pivoted to SMB in Q3
- a pricing model worked until we hit a certain scale
- competitor X mattered a lot, now competitor Y does
Drop the time dimension and a note doesn’t even have to become false to hurt you. It just has to outlive the conditions that made it useful.
A fact with no date attached quietly goes stale, and you keep trusting it long after it stopped being true.
Temporal knowledge graphs
A temporal fact is a triplet with time stapled on:
(subject, predicate, object, valid_from, valid_to)
or:
(subject, relation, object, timestamp)
Now you can ask what was true then, what’s true now, and exactly when it changed.
A big graph to poke at
Types of facts
Facts come in three kinds. Atemporal ones are always true. Static ones become true at some point and then stay put. Dynamic ones keep changing.
In product work, most of the facts that matter are dynamic, which is exactly why they go stale so fast.
One search is too confident
Research on temporal knowledge graphs suggests single-pass retrieval breaks easily. Agentic flows do better by:
- breaking a question into sub-queries
- retrieving with temporal constraints
- checking whether facts are still valid
- iterating when context is missing
That’s more or less how I debug a product belief: probe, compare, update the model, repeat. The dangerous answer is the one fetched once and handed over without its age showing.
Typical temporal operators:
Search_time(query)Search_specific(query, t)Search_before(query, t)Search_after(query, t)Search_between(query, t1, t2)
The version I can maintain
You don't need a full system
You can skip building a full temporal graph system and still get value from the idea. These four habits are the part I actually keep up.
- Track when things change.
- Link facts to the call, test, customer, or decision that created them.
- Invalidate stale notes instead of letting them sit there looking wise.
- Connect notes instead of collecting them.
My weekly cleanup
Daily notes get what changed and what confused me. Concept notes get one atomic idea each. Project notes get decisions, trade-offs and outcomes. Notes link to each other, and decisions get dates.
Once a week I clean up duplicates, archive the stale ones and add the links I missed. It’s not glamorous. The dates matter more than the diagram.
Sources
I used to open Obsidian and feel reassured by how much I’d saved. Now the first thing I look for is the timestamp, because old certainty looks remarkably convincing in a fresh shirt.