I have been thinking more about Living Architecture Nodes, and I think I am only now starting to understand what the second half of the idea actually is.
The first half came from a fairly simple problem. Software changes much faster than our understanding of it gets documented. A file changes, then another one changes because of it, a regression appears, somebody finds a workaround, a dependency turns out to be more fragile than expected, and eventually all of that becomes part of the system even though very little of the reasoning survives in a form that another person can easily use.
That is already expensive when humans maintain software. With AI-assisted development it becomes even more obvious, because an AI can move through a codebase very quickly while still having surprisingly little persistent understanding of why that codebase is shaped the way it is.
Living Architecture Nodes was my attempt to give a software system some memory of itself. Not just documentation in the traditional sense, but a maintained trail of architectural intent, dependencies, fragile areas, previous failures, changes, and the relationships between components.
The more I work with that idea, though, the more I think that preserving the past is only half of what architectural memory is useful for.
Once a system has enough structured memory about what it is and how it got there, a much more interesting question becomes possible.
What can it become from here?
That sounds obvious when written down, but I do not think most development tools really operate that way. We are getting extremely good at generating implementations. Ask an AI coding system to add a feature and it will often produce code almost immediately. What it is much less equipped to do is show you the actual design space around that change.
There is rarely only one reasonable way to implement something.
You might extend an existing abstraction because it already owns most of the relevant behaviour. You might introduce a separate component because the existing abstraction is becoming overloaded. You might change an interface first because the requested feature exposes a limitation in the current design. You might deliberately accept a larger change now because it removes something that has repeatedly caused problems in the past.
All of those can be legitimate answers.
The problem is that we often see only the first implementation that appears plausible.
That is where I think the second half of Living Architecture Nodes begins.
If the architecture already knows which components are involved, what their responsibilities are, what depends on them, what contracts they expose, what regressions have happened before, where hidden coupling has been found, and which changes previously created problems, then that knowledge should be able to help construct several viable implementation paths.
Not choose one.
Not declare one of them “the correct architecture.”
Just make the real options visible.
That distinction is becoming increasingly important to me.
I do not want Living Architecture Nodes to become another system that reduces architectural judgment to a score. Architecture is too contextual for that. A solution that fits the current architecture perfectly may also reinforce a design that should have been replaced two years ago. A more disruptive option may be much healthier in the long term. A lower-compatibility option may exist precisely because someone is trying to move the system somewhere new.
So instead of saying that one option is 92% good and another is 81% good, I think the system should expose the dimensions that matter.
How compatible is this option with existing contracts? How many components are likely to be affected? Does it reuse an existing pattern or introduce a new one? Does the proposed change cross a security boundary? How reversible is it if it turns out to be wrong? Has a similar dependency path caused regressions before? How much of this analysis is actually supported by evidence, and how much remains uncertain?
Those are much more useful questions than simply asking which option wins.
The idea of diversity also becomes important here.
If I ask for several implementation options and receive five variations of the same basic pattern, I have not really been given five choices. I have been given one architectural idea expressed five different ways.
A useful system should be able to recognize that.
Two options may differ in code but preserve exactly the same dependency structure, ownership model, failure boundary, and state flow. A third option might reorganize those things completely. That third option is architecturally different even if it initially looks more expensive.
I think Living Architecture Nodes should preserve that difference rather than optimizing it away.
That is probably one of the most important things I have realized about the design.
The purpose is not to make software converge toward whatever it already is.
The purpose is to make the consequences of different directions easier to understand.
There is also something useful about having the architectural history tied directly to those choices.
Suppose an option touches a dependency edge that has already caused three regressions. That should be visible. Suppose another option introduces a new boundary and reduces coupling, but requires migration work across six modules. That should also be visible. Suppose a third option looks elegant but the repository simply does not contain enough evidence to say what its operational impact will be. The system should be comfortable saying that too.
I would rather see NOT VERIFIED than false confidence.
What starts to emerge from this is a different development loop from the one we normally have.
Today the loop is often something like: requirement, implementation, testing, release.
What I am imagining is closer to this: intent, architectural context, possible designs, comparison of consequences, human decision, implementation, observed result, then that result goes back into the architectural memory.
That last part matters because the system should also be able to compare what was expected with what actually happened.
If the expected blast radius was three modules but five were affected, that is useful evidence.
If an implementation was expected to preserve an interface but required a schema migration, that is useful evidence.
If an option looked low risk but reproduced exactly the kind of regression recorded six months earlier, that is extremely useful evidence.
The architecture becomes more informative because the consequences of decisions become part of its memory.
And that is where this starts becoming much more interesting to me than documentation.
The repository begins carrying not only a record of what exists, but a record of how design decisions behaved in reality.
Over time, that could make future architectural reasoning much less dependent on rediscovery.
A new developer would not have to learn everything through trial and error.
An AI system would not have to infer every architectural constraint from source code alone.
And a team could compare possible changes with some understanding of how similar decisions actually behaved in that particular system.
I am still thinking through exactly how far this should go, but I am becoming convinced that the boundary is important.
Living Architecture Nodes should not decide architecture for people.
It should make architectural possibilities legible.
It should show the options, show the consequences that can be supported by evidence, show where the evidence is weak, and preserve genuinely different directions rather than collapsing everything into the safest continuation of the status quo.
The human decision remains the human decision.
What changes is the amount of architectural context available when that decision is made.
That is the part I had not fully understood when I first started building Living Architecture Nodes.
At first I thought the important thing was giving software memory.
Now I think the more interesting idea is what becomes possible after that memory exists.
A codebase that remembers enough of its own history may eventually be able to show us more clearly what its possible futures look like.
And that may be where this becomes genuinely useful for AI-assisted development, because faster code generation is only one part of faster software development.
The harder problem has always been deciding what should be built, where it should fit, what it might break, and what other choices were available before the code was written.
That is the second half I want to build next.
Living Architecture Nodes:
https://altru.dev/living-architecture-nodes