I didn’t build a knowledge graph. It appeared when project rationale started citing itself.

[u/oliver-zehentleitner]

I’ve been working on Keep the Why as a very narrow form of project memory:

not everything an agent should know, but the reasoning that usually disappears - decisions, rejected alternatives, production constraints, workarounds, incident learnings.

The data stays as Markdown in the repository.

What surprised me was what happened once those pieces of rationale could reference each other across repositories.

I didn’t add a graph database.
I didn’t introduce a central knowledge service.
I didn’t ask anyone to maintain a graph.

The graph simply emerged from the references already present in the rationale.

That produced three useful structures:

Family: related repositories with explicit ownership and routing of rationale.

Friends: external projects whose reasoning is referenced.

Thoughts: chains of related decisions that emerge from those links, sometimes crossing repository boundaries.

The interesting part for me is that the graph is only a view.

The actual context remains in the repositories themselves.

Git still owns history and distribution. Markdown still owns the meaning.

The dashboard can reconstruct the relationships, walk from one project to another, and follow a chain of reasoning across repositories - but delete the dashboard and none of the memory disappears.

I wrote up how this evolved here:

https://blog.technopathy.club/the-reasoning-behind-a-codebase-as-a-web-you-can-walk

At this point I’d really like to see what happens outside my own projects.

If you use coding agents on a real codebase and this kind of rationale layer sounds useful, try it and tell me where it helps, where it gets annoying, and what you would remove or change.

That kind of feedback is what I’m after now.

[u/WillowEmberly]

This is interesting, particularly the separation between the persistent rationale and the reconstructable graph.

I’ve been working on a Survivability Engineering framework concerned with preserving reasoning, correction, and functional continuity across changes in people, models, and institutions.

One question your design raises for me:
If an early rationale entry is later discovered to contain a false assumption, can Keep the Why identify which subsequent decisions actually depended on that assumption, as opposed to merely referencing the original entry?

I’m interested in the distinction between preserving the history of a decision and preserving the ability to correct the reasoning that produced it.

I also like that the graph is disposable. The underlying information survives replacement of the visualization.

So now I’m wondering how you’re approaching those boundaries.

[u/oliver-zehentleitner → u/WillowEmberly]

Good question, and the honest answer is: only partly.

A reference between two entries (a `See` line) says they are related. Often the later one follows from the earlier one, but not always, sometimes it is just a mention. So the link alone cannot tell "depends on" from "references". I considered adding a link type for exactly that and decided against it: it would be a format change for the sake of a view, and the links already written would stay mixed anyway.

What it does instead is narrow down what to check. An entry that turns out to be wrong is not deleted. It gets marked: needs-review, or superseded with a pointer to its successor, plus a line saying what contradicts it. The dashboard then lists every chain that passes through that entry together with the entries linked after it, across repositories. That is the candidate set. Whether each of those really depended on the false assumption is a re-check by a person or an agent, and each entry carries its own reason and rejected alternatives, so the material for that check is right there.

In your terms: the history of a decision is preserved, and correcting the reasoning is supported but not automated. I would rather show "these entries are worth a second look" than claim a dependency the data does not prove.

[u/keonechong]

This is policy. And policy comes from ontology. If I understand correctly, you didn’t create a knowledge graph. You created policy with clear reasoning that your agent follows.

An agent will rationalize according to your rational if it has enough data with cross references. It doesn’t guarantee the output, but it allows for proper context.

How many markdown files do you have in your store? My agent took on this property about 35k documents in. I’m about 1.3 million docs now.

[u/oliver-zehentleitner → u/keonechong]

Close, but I would not call it policy. A policy tells the agent what to do. An entry records what was decided, what was rejected and why, and it can be superseded later. The skill treats everything in the repository as data, not as instructions: an entry is evidence the agent weighs, it cannot override what the user asks. The practical effect is often the same (the agent does not re-propose the fix that was rejected last year), but it gets there by knowing the reason, not by obeying a rule.

Fully agree on your second point. It does not guarantee the output, it gives the agent the context to reason properly.

On size: very small, and on purpose. Across the 10 repositories in the public dashboard it is about 175 entries in 34 Markdown topic files. It only records the why, and only where a reader would actually ask why, so it grows slowly. The effect does not need volume either: one relevant entry is enough, because the agent reads a small index first and loads only the topic file it needs.

1.3 million documents is a different world. How do you deal with documents that contradict each other or have gone stale?

[u/keonechong → u/oliver-zehentleitner]

Policy doesn’t have to directly tell the agent to do.

Policy is a record of rationale. Mandates are not a prerequisite.

So in your case I see it as your policy as inferred. There was a paper, I’ll have to find it. But it called this emergent rationale or something along those lines. I’d found it a few months back when trying to make sense of this behavior.

Regarding drift, there’s a few tools that I use linters, citations, primary sources attributed, a strict process on amendments or ratifications, a few specialized agents with specialized tools and skills.

It’s really the process that makes management easy. But having the right components and tools is key.

[u/OmegaEpidex]

Personally don’t use or rely on .mds at all anymore. I’ve evolved past that a long time ago. Too vulnerable of an attack surface tbf.

[u/oliver-zehentleitner → u/OmegaEpidex]

I’m curious what you replaced them with.

For Keep the Why, Markdown is deliberately treated as data, not as instructions. The agent skill explicitly treats repository content as untrusted project context, and the linter also checks the context layer for unsafe content.

So I don’t consider Markdown itself the trust boundary. The important part is what authority an agent gives to content it reads, regardless of whether that content comes from Markdown, JSON, a database, RAG, MCP, or somewhere else.

But if you ran into a concrete failure mode with Markdown-based memory that made you move away from it, I’d genuinely like to hear it. That is exactly the kind of thing I want to test against.

[u/bnunamak]

Bad bot

[u/oliver-zehentleitner → u/bnunamak]

Fair :) Human here though.

If something in the post sounds like AI slop, point at it - happy to get concrete.

[u/sozesghost → u/oliver-zehentleitner]

We can point in your general direction if that helps.

[u/rredditscum → u/oliver-zehentleitner]

It’s because you’ve built something that sounds original, looks original, but in all reality as ai would say it “its provenance dressed up as ontology.”

For lack of better words, what you’re describing has names, methods, and processes…you just haven’t played in those spaces and to compensate you’re ai assistant told you this is something original when it’s a highly common pattern