Article · Field notes
Old Certainty in a Fresh Shirt
13 Feb 2026 5 min read
My notes looked organised until I tried to make a decision from them.
Bookmarks, call notes, screenshots, links from Slack, AI answers I half-trusted, market comments I couldn’t place two weeks later. I had kept everything except the part that would tell me whether it was still true.
The old loop was simpler: ship feature, check metrics, repeat. That still works until the question becomes whether the user has the problem I think they have. The answer 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 prospects.
I stopped thinking in lists and started thinking in connections. A personal knowledge graph sounds fancy, but for me it just means connecting what I learn to what I decide.
In Obsidian I keep small notes, links between ideas, post-call reflections, failed experiments, and surprises. I separate the user’s words from my interpretation, the assumed problem from the observed one, and a decision from the evidence that produced it.
Without those connections, it all turns to mush.
AI makes the mush more dangerous because it can make it sound coherent. If my notes are shallow, the answer comes back polished and wrong in exactly my own accent. If the notes are specific, dated, and tied to decisions, the model has something to work with.
Writing is part of the memory system. A post or short video forces me to connect what a user said to what I built and what happened next. Any content-strategy upside 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 appears to know their market better, although I suspect their notes are lying to them too.
Talking to other builders helps because they catch the stale parts of my map. They ask the dumb question I stopped asking. They remember that the thing I 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 triplets together and you get a graph, not a folder of disconnected notes.
A correct note can become a wrong decision
Most notes are static. Product truth isn’t.
- 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 the note doesn’t even need to become false to hurt you. It only needs 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 attached:
(subject, predicate, object, valid_from, valid_to)
or:
(subject, relation, object, timestamp)
That lets you ask what was true then, what’s true now, and exactly when it changed.
Interactive graph example
Types of facts
- atemporal: always true
- static: true from a point in time and then stable
- dynamic: changes over time
In product work, most facts that matter are dynamic. That’s 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 resembles the way I debug a product belief: probe, compare, update the model, repeat. The dangerous answer is the one retrieved once and delivered 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 don’t need to build a full temporal graph system to get value from this.
- 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: what changed, what confused me
- concept notes: one atomic idea per note
- project notes: decisions, trade-offs, outcomes
- links between notes
- dates on decisions
I use daily notes for what changed or confused me, concept notes for one idea, and project notes for decisions and outcomes. Once a week I clean duplicates, archive stale notes, and add missing links. 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 want to see is the timestamp. Old certainty looks remarkably convincing in a fresh shirt.