The Case
Document A · Loop MMT Ecosystem
- Version
- v3
- Dated
- 27 May 2026
- Rendering
- walking skeleton (Slice 1) — Origin section only
- License
- CC BY-SA 4.0
The Origin
I built a computer inside Minecraft. Not a calculator — a computer. Redstone logic gates, loop-line memory, an ALU, value-catching circuitry. The memory was inspired by mercury delay lines from the 1940s — data stored as acoustic pulses circulating through a tube of mercury. Bits alive only in motion. I called it Loop 1.0. It took seven years to finish.
Loop 1.0 ran faster than one hertz. That doesn't mean anything to most people. It meant something to me: the thing I built was fast enough to be fun to use. The experience of operating it was the signal that the architecture had legs.
I designed Loop 2.0 — bigger, six-by-eight chunk display — and got seventy percent through the controls before confronting the arithmetic: at scale, one hertz would not be fun. The architecture had outgrown Minecraft. So I opened a conversation with Claude and typed something close to “Hey, you can code, right?” Three weeks and 331 builds later, working nights and weekends from a one-room RV on a $200 laptop, I had Loop 2.1 — an eighteen-thousand-line flow computer in a single HTML file, running in a browser, zero external dependencies.
Then a bill arrived. Large enough to change the arithmetic of the month. The bill didn't start the coding. The bill made the coding a career question. I have zero professional software experience. If you dropped me into a conventional CS job, I would drown. But I had spent three weeks directing an AI to build a system that was getting faster as it got more complex, and the bill made me ask: could this be a living?
The weekend of March 29–30, 2026, I extracted the pattern. Twenty-seven and a half hours across Saturday and Sunday, in the RV, on the $200 MacBook, while Jamie watched Bob's Burgers one foot from my right elbow. Twenty documents. Forty-five thousand words. Loop MMT — Multi-Module Theory. A methodology for building software with AI that compounds across sessions instead of resetting to zero every time.
Then I went back to work. Construction — framing and renovation, forty dollars an hour, my back hurts most days. Tuesday, Wednesday, Thursday. The methodology sat in a folder. On Friday I called out of work and started building. The specification for a deer processing management system passed structural analysis with zero orphans, zero undeclared cycles, and zero conflicting definitions across 131 routing entries, 15 nodes, and 188 edges. On the first pass. The methodology worked.
Then the CMS. Then Sieve, Relay, Vault — one tool after another, each a single file. Then the methodology itself grew: knowledge packs, protocols, a fictional advisory board reconstructed from documents each session. Two hundred sessions. Three hundred documents. The architecture scaled.
And then, one afternoon in May, eighty-seven tools existed. Not concepts. Running code. Single JavaScript files, each under three thousand lines, each following the same five rules. And the question changed. It wasn't “can I build a tool?” anymore. It was: “can I compose these tools into something that replaces an entire software stack?” The answer was the tree composition architecture — directed acyclic graphs of tools that execute business processes with proof chain receipts at every step. Not a toolkit. A business process IDE.
The road arrived before the destination was named. That's fine. The destination is personal data sovereignty, and this is why.