The codebase ADRs are very interesting; you can view the process of building the database, in the order in which it happened.
Looks like they took many design decisions from neo4j, and started (-ish) with an ontology that describes the graph's design itself (rather than describing _a_ graph).
You also get to see some technical decisions, like WAL etc. Very SDDish.
Ok, so right now I have my ADRs as part of my blueprint, and of course each also links to other related adr. How’s this any different than just keeping them in markdown files?! Just the graph?
Markdown stays the source for the ADRs so the graph is more like a derived index built from the markdown sources, rather than a replacement. The graph gives you (and your coding agent) the ability to ask questions about the relationships between decisions, which you can do with markdown only by reading them all.
Markdown makes it easy to find things like "what does this ADR link to?" The graph allows for questions like "what links to this one, what replaced it, did whatever replaced it get replaced too, and which modules depend on code governed by a decision that's been superseded?"
> what links to this one, what replaced it, did whatever replaced it get replaced too, and which modules depend on code governed by a decision that's been superseded?
Very interesting, as right now I have some sort of a header for each adr with some details including what supersedes it, but also status if approved/proposed, amendments, owner, blueprint version, and other details to track them. Will try it and see how it goes in my ~300 adrs. Is it adr only or does track other parts of the blueprint? Like specs, architecture, etc.?
The codebase ADRs are very interesting; you can view the process of building the database, in the order in which it happened.
Looks like they took many design decisions from neo4j, and started (-ish) with an ontology that describes the graph's design itself (rather than describing _a_ graph).
You also get to see some technical decisions, like WAL etc. Very SDDish.
There's even a cookbook example using the relate ADRs to analyze the codebase decisions using relate itself: https://relatedb.ai/cookbook/codebase-context-graph/
Like a context graph for your codebase. Code analysis for agents is one use case I think makes a lot of sense for relate.
Ok, so right now I have my ADRs as part of my blueprint, and of course each also links to other related adr. How’s this any different than just keeping them in markdown files?! Just the graph?
Markdown stays the source for the ADRs so the graph is more like a derived index built from the markdown sources, rather than a replacement. The graph gives you (and your coding agent) the ability to ask questions about the relationships between decisions, which you can do with markdown only by reading them all.
Markdown makes it easy to find things like "what does this ADR link to?" The graph allows for questions like "what links to this one, what replaced it, did whatever replaced it get replaced too, and which modules depend on code governed by a decision that's been superseded?"
> what links to this one, what replaced it, did whatever replaced it get replaced too, and which modules depend on code governed by a decision that's been superseded?
Very interesting, as right now I have some sort of a header for each adr with some details including what supersedes it, but also status if approved/proposed, amendments, owner, blueprint version, and other details to track them. Will try it and see how it goes in my ~300 adrs. Is it adr only or does track other parts of the blueprint? Like specs, architecture, etc.?
Nice! Yes, lots of other ways to use for software analysis beyond ADRs. One other example is an extension for loading git history into the graph: https://relatedb.ai/docs/guides/extensions/git-to-graph/
From the Neo4J people!
In the example:
Not that you couldn't model it this way, but not exactly filling me with confidence that this has been looked at closely.something like this perhaps to find the latest event: