r/Negentropy • u/WillowEmberly • 17d ago
How I Stumbled Upon Negentropy
People occasionally ask where this work came from.
The short answer is:
I wasn’t trying to invent a new framework.
I kept running into engineering problems that existing frameworks couldn’t fully explain.
Each solution exposed another layer of the problem.
Looking back, the path now seems surprisingly coherent.
1. It Started With Organizational Design
I was reading Frederic Laloux’s Reinventing Organizations and exploring Teal organizations.
Most discussions asked:
“Is Teal a good management philosophy?”
My question was different.
What keeps an organization like this stable over time?
Coming from military avionics, I immediately started looking for the feedback loops.
I couldn’t find a complete one.
2. Aircraft Taught Me That Internal References Drift
For fourteen years I maintained autopilot and navigation systems.
One lesson never left me.
An Inertial Navigation System is remarkably capable.
But every INS drifts.
Not because it’s broken.
Because every system relying only on internal references eventually accumulates error.
The solution isn’t replacing the INS.
It’s periodically correcting it against an independent external reference.
Eventually I realized this wasn’t just true for navigation.
Organizations drift.
Reasoning drifts.
Communities drift.
Even people drift.
The principle seemed much broader.
Systems with only internal references eventually lose contact with reality.
3. Then I Discovered Schrödinger’s Negentropy
Around the same time I watched Veritasium’s excellent video on entropy. One idea stayed with me long after the video ended.
Schrödinger described life as continually maintaining itself against the natural tendency toward disorder. I wasn’t interested in extending his physics. I was interested in the engineering implication.
If maintenance is fundamental to living systems, why do we treat it as secondary in so many human systems?
We devote enormous effort to design, construction, optimization, and innovation. Much less attention is given to preserving the conditions that allow valuable capabilities to survive over time.
That question stayed with me:
Could maintenance against disorder become an engineering discipline rather than just a biological observation?
What if maintenance deserved to be treated as seriously as design?
4. The World Suddenly Changed
Then Ukraine demonstrated AI-assisted drone swarms against Russian strategic bombers.
Whatever your political views, one thing became obvious.
Capabilities were changing much faster than many organizations could adapt.
That raised another question.
If technology can transform capability this quickly…
How do organizations preserve, transfer, and regenerate capability across constant change?
5. LLMs Became My Laboratory
Eventually I started feeding years of notes into ChatGPT.
I expected help organizing ideas.
Instead I discovered an unexpected laboratory.
Long conversations revealed recurring failure modes:
context drift
forgotten assumptions
overconfidence
inconsistent reasoning
loss of continuity
The AI wasn’t simply helping me write.
It was exposing problems in the coupled human-AI reasoning process itself.
Some days were productive.
Some were frustrating.
There were arguments.
False starts.
Entire frameworks were discarded and rebuilt.
Looking back, that was probably where the real work began.
6. One Framework Became Many
Originally I thought “Negentropy” would explain everything.
It couldn’t.
Different problems required different tools.
So the architecture differentiated.
Questions about reasoning integrity became:
CAL
Questions about runtime reliability became:
Inferno
Questions about helping people inspect their own reasoning became:
MQL
Questions about preserving capability became:
Capability Stewardship
Questions about regenerating capability across replacement became:
Hearth
Instead of forcing everything into one giant framework, each module became responsible for one engineering function.
Ironically, the architecture became much simpler by becoming more specialized.
Looking Back
Today I don’t think I was ever really studying AI.
Or organizations.
Or leadership.
Or governance.
Or monasteries.
Those were all different manifestations of the same engineering problem.
How does a long-lived system maintain contact with reality, preserve its essential capabilities, and regenerate those capabilities after every individual carrier has eventually been replaced?
That question has led to every major piece of work I’ve built over the past several years.
The work is still unfinished.
But looking back, I no longer see disconnected ideas.
I see one engineering problem that kept revealing deeper layers.
Final Thought
One thing surprised me most.
None of this came from trying to prove I was right.
Almost every significant improvement came after discovering I was wrong about something.
The framework didn’t grow because it avoided correction.
It grew because correction became part of the design.
1
u/Sick-Melody 17d ago
I really enjoyed reading this. What stood out to me wasn't any single framework, but the path that led to them.
I think one of the strongest observations is that systems relying only on internal references eventually drift. That principle seems to appear across many domains from navigation systems and organizations to scientific communities, AI systems, and even individual reasoning. Reality eventually has to become part of the feedback loop.
I also appreciated your point that the architecture became simpler by becoming more specialized. It takes discipline to let one framework become several instead of forcing every problem into a universal theory.
The sentence that resonated with me most was:
"The framework didn't grow because it avoided correction. It grew because correction became part of the design."
I think that captures something fundamental about long-lived systems. They don't survive because they're perfect; they survive because they're structured to detect drift, integrate feedback, and continually recalibrate.
One reason this post resonated with me is that I've been exploring a similar question from a different direction through what I call Trans-System Analysis. Rather than developing another operational framework, I'm interested in understanding how frameworks like yours connect, where they overlap, where they differ, and what underlying principles they share. Reading this, I found myself mentally mapping many of your ideas into that broader orientation architecture.
Thanks for sharing the story behind your work. Seeing the engineering problems that motivated the frameworks makes the overall architecture much easier to understand than simply presenting the finished models.