v31 · 27 May 2026

---

The Five Rules and What They Build

Five rules. One graph. Eighty-seven tools built, organized into fourteen trees. One sentence: the tool is a sovereign, portable, provable file.

Every tool in this ecosystem is a single JavaScript file. You run it with one command. It stores your data in SQLite — the most widely deployed database in the world, readable by thousands of applications, committed through 2050. Every change is recorded in an append-only hash chain that proves what happened, when, and in what order. No tool depends on any company's continued existence. Your data lives on your machine in a file you own.

Trees compose those tools into business processes. A constellation composes those trees into a complete operating environment for an organization. The tools are the instruction set. The tree is the program. The constellation is the deployment.

The architecture is AGPL — open, forkable, uncloseable. A person with zero dollars and a ten-year-old phone gets the same outcomes as anyone else.

---

About This Document

This plan is a hypothesis, not a specification. The architecture is validated — stress-tested through 30+ RCRs, four Panner campaigns, a full Red Team review, and three live constellation engagements. The build strategy is adaptive — it changes when reality contradicts it.

This is Document B of the Four-Basis set: The Case (conviction), The Argument (why it matters), The Walk-Through (experience), and this document (specification). For reading order: start with The Case (4 pages), then The Argument (5 pages), then The Walk-Through, then this.

Constitutional reference. This document carries the generating principles and architectural commitments that govern the ecosystem. Elaboration lives in factored documents:

---

Section 1 — The Five Rules

The recipe, given away: the Five Rules are published standalone and MIT-style on The Five Rules — everything a programmer needs to build sovereign, portable, provable tools, with no methodology required. This section is the same five rules read in the specification's context: how they define the product category and compose upward into trees and constellations. Recipe there; architecture here.

Every tool in the ecosystem obeys five architectural rules. These are not guidelines. They are constraints that define the product category. A tool that violates any of them is not a Loop MMT tool.

1. Single file. One file to download. One file to run. One file to read if you want to understand what it does. The entire application — server, logic, UI, and embedded dependencies — lives in a single JavaScript file.

2. One command. node tool.js starts it. No build step, no configuration wizard, no setup process. First run initializes everything it needs. The tool must be useful within sixty seconds of download.

3. No dependencies. No npm install. No package.json. No node_modules. Any external library the tool needs is bundled into the single file at build time. The only runtime requirement is Node.js 18+. Vendored source is permitted and documented.

4. SQLite storage. All structured data lives in a SQLite database. Binary assets are stored in a managed file directory alongside the database, referenced by content hash. The tool manages both as a unit. The user's data is always accessible, always portable, and never locked into a proprietary format.

5. Append-only proof chain. Every significant operation is recorded in a hash-chained append-only ledger. Each entry links to the previous entry's hash. SQLite triggers prevent modification or deletion. Content hashes use SHA-256, canonical across all tools — the same content produces the same hash regardless of which tool stores it.

These rules are a market position, not just a technical choice. They are the architectural equivalent of "we will never do this to you."

The Generating Principle

The Five Rules compile from one sentence: "The tool is a sovereign, portable, provable file." Sovereign → no dependencies, SQLite (you own it, you can read it). Portable → single file, one command (it travels). Provable → proof chain (it shows its work).

Shared constraints produce automatic interoperability. Any tool that follows the Five Rules reads any other tool's data — not because the tools were designed to work together, but because the constraints are the same. The fence is the phone line. The rules are the mesh.

The Three Sentences

The generating principle extends through three levels:

1. 1. "The tool is a sovereign, portable, provable file." — What a tool is.
2. 2. "Trees compose sovereign tools into business processes with proof chain receipts." — What the composition language does.
3. 3. "Constellations compose trees into complete operating environments for organizations." — What the product is.

Each sentence contains the one above it. A constellation is made of trees. A tree is made of tools. A tool is a sovereign, portable, provable file. The architecture is fractal — the same principles at every scale.

Handler Synthesis and the Derivation Principle

Handlers do not only display and index. A handler can emit new derived nodes from the data it processes. A photo handler extracts EXIF data and emits location nodes. A finance handler aggregates monthly totals and emits summary nodes. The graph gets richer from the system's own processing. Derived nodes are typed and deletable — the user curates what the handlers produce.

The derivation engine creates edges based on temporal proximity, shared metadata, and content correlation. Every derived edge carries a human-readable reason string. The system observes. The user interprets.

The Access Test

A permanent design gate: Can a person with limited bandwidth, an old device, and no technical training use this tool? Not just "can they achieve the same outcome" — can they achieve it on hardware that costs $50 and a connection that drops every ten minutes? The admin UI is server-rendered HTML. Relay output is under 100KB per page. WCAG 2.2 AA contrast ratios. Keyboard-only navigation. Functional at 200% zoom.

Two Modes — Sovereign and Shadow

The Five Rules assume an adversary that is a platform, not a state. For users whose threat is a government, the proof chain becomes a prosecution tool. The ecosystem operates in two modes, chosen at database creation. Sovereign Mode (default): full proof chain, filesystem presence, network checks. Shadow Mode: encrypted at rest, zero host footprint, disguise interface, no unprompted network calls, self-bootstrapping. The modes do not convert. Shadow Mode documentation is honest about what it protects against and what it doesn't. See the Threat Model for full security boundaries.

Scale Invariance

The generating functions carry no personal-scale constraint. A constellation of one is a personal archive. A constellation of ten thousand is a knowledge graph. The architecture does not distinguish between them. The proof chain provenance is the differentiator from institutional knowledge graphs. Personal deployment is a strategy choice, not an architectural ceiling.

---

Section 2 — Tree Composition Architecture

The Composition Language

[Ada Lovelace lens] "The apps aren't the invention. The composition language is."

Eighty-seven tools following the Five Rules is a toolkit. What makes it a product is the ability to wire those tools together into directed acyclic graphs that execute business processes with proof chain receipts at every step. Saved composition trees are programs. The tree executor is the runtime. Users build custom business processes by composing tools — not by writing code.

The Tree Model

Every tool exists at one of three levels:

Fourteen trees organize the ecosystem: eight Office trees (Treasury, Crew, Workshop, Library, Pipeline, Wire, Table, Helm), three Floor trees (Stockroom, Floor, Roster), and three Domain trees (Municipal, Cannabis, Academy). See the Tree Catalog for the full inventory.

STNI — The Interface Contract

Every tool declares twelve properties — the Standardized Tree Node Interface — that define how it participates in tree composition: input format, output format, value proposition, resource profile, degradation behavior, proof chain policy, taxonomy position, execution mode, character type, yield points, view declarations, and priority class. The STNI is the tool's contract with the tree executor. 85 of 87 tools are tree-compatible without structural changes.

The Tree Executor

The tree executor takes a validated tree specification (YAML) and runs it. Architecture: SpecLoader → PreflightGate (validator) → TopologySolver (execution order) → ExecutionEngine (node runner, edge transporter, merge engine, fan-out dispatcher) → ProofChainManager → ResourceMonitor → DegradationRouter → CrossTreeBridge. Batch mode: one trigger → one pass → results. The executor, validator, and full module suite are built.

Constellation Reports

The constellation report is the product document — the customer-facing assembly of trees that shows an organization how Loop replaces their software stack. Three reports exist: Kris Lotlikar (executive coaching), MAPS (psychedelic research nonprofit), and Loop MMT Inc. (internal operations). The Constellation Specification Format defines the repeatable production process.

---

Section 3 — The Adoption Funnel

Four layers. Each independently useful. Each creates conditions for the next.

Layer 0 — The Methodology. Loop MMT manages its own 300+ file corpus using the same architecture it sells. The methodology is User Zero — the acceptance test for tool readiness. If the tools can't manage 87 tools, 68 protocols, 200+ knowledge packs, and per-session mesh production, they aren't ready for customers.

Layer 1 — Cadence. A free personal operating standard for AI-assisted work. Four documents, five practices, five minutes a day. Published openly. No product dependency. Creates the friction that the tools resolve.

Layer 2 — Constellation Deployment. The consultative engagement where we map a customer's operations to trees, produce a constellation report, deploy the system, seed data, and train users. This is the primary commercial offering. Kris Lotlikar's coaching practice is the first deployment.

Layer 3 — Loop Home. Managed hosting for customers who want sovereign infrastructure without the infrastructure. The same open-source tools on a server someone else maintains. Storage-tier pricing, all features included. The sovereignty guarantee — stated intent, not a shipped capability — is to export everything in one command, self-host in an hour, with no loss in either direction. The mechanism it names (loop export --full) is unbuilt; owed loop-export-tool-cited-but-unbuilt. See [internal source] §2, The Sovereignty Guarantee, for the build state and the four surfaces that do ship.

---

Section 4 — Coordination Architecture

The Three-Part Alternative

Nineteen independent tools need coordination without a central dependency. A Coordinator App was rejected — it becomes a platform.

Part 1 — Registry Convention. Every tool writes a JSON registration file to ~/.loop/tools/ on startup. Removed on shutdown. Crash-orphan detection via PID check. The Inter-Module Contract Specification defines the full schema.

Part 2 — Status Command. loop status reads all registration files, pings health endpoints, checks compatibility, reports compliance, and prints a one-page health report. The constellation hash — a Merkle tree of all proof chain heads — gives the whole system's state in one value.

Part 3 — The Tree Executor. For Phase 0 (before Flare), tools communicate via structured stdout events and CMS webhooks. The tree executor provides the production coordination layer — reading STNI declarations, resolving topology, routing data between nodes, and enforcing resource budgets. Flare (event router) replaces shell-level composition when it ships.

The Tick

Every data event is a tick. Each tick fires the derivation engine, updates the constellation hash, and potentially propagates through the event bus. The rules don't know about the patterns they produce. The patterns emerge from rules meeting the data.

Packaging

Loop CLI starts all tools with one command. Loop Helm serves a web dashboard at localhost:1300. Platform doorknobs put an icon in the system tray. Together: open Loop. These are packaging, not dependencies. Delete them and every tool still runs with node tool.js.

---

Section 5 — Commercial Strategy

The Pricing Promise

Every Loop MMT tool is free. Every feature in every tool is free. Paid services make things easier, not possible. If you can do it yourself, you never have to pay us. This commitment is permanent, visible, and absolute.

The North Korea Test

Every commercial decision passes this gate: Can a person with zero dollars and no internet achieve the same outcome as a paying customer with gigabit fiber? Not the same experience — the same outcome. If any outcome is gated, the model fails.

Revenue Streams

1. Constellation Design & Deployment. The high-value consultative engagement. Map the customer's operations to trees, produce the constellation report, deploy, seed, train. Build time per tool is ~2 minutes; the value is in the architecture, not the construction. This is the primary revenue driver.

2. Loop Home — Managed Hosting. Constellation hosting with storage-tier pricing. CMS-only tier ($5/month) as entry. Full constellation tier ($10–20/month). All tools, all features, exportable on demand (the export mechanism is unbuilt — see §3 and loop-home-architecture-v2 §2).

3. The Unified Relay. Always-on cloud endpoint for publishing, sync, messaging, and backup. Open protocol — anyone can run a relay. Revenue from being the easiest, not the only.

4. Loop Notary — Trust Amplification. External proof chain anchoring via OpenTimestamps and RFC 3161. The gap between "I can prove it" and "a court can verify it."

5. The Bazaar — Community Handler Marketplace (Phase 3+). Federated discovery and payment for community-built handlers. First-party tools covering any data type in this plan are free forever. The Bazaar serves the long tail — homebrew recipes, bird watching logs, genealogy trees.

6. Labor — Migration & Consulting. Doesn't scale. Starts fastest. Funds the build.

---

Section 6 — Where We Are

Current State (May 2026)

Path to Revenue

1. 1. Complete tree executor production hardening. Remaining phases: PoC validation, view layer, first constellation deployment. ~10 sessions.
2. 2. Deploy Kris's constellation. First paying customer. Tree specs, readiness reports, and seed data exist. The Generosity Graph — philanthropic intelligence as a tree — is the first product.
3. 3. Demo for Jamie. Working app she can see and use. The threshold.
4. 4. Price constellation deployments. The constellation report is the sales document. The design engagement is the revenue model.

What the Plan Does Not Carry

The following content has been factored to purpose-built documents. This document does not grow.

---

Changelog

---

The Plan v31 · Loop MMT Ecosystem · Constitutional Reference 87 tools · 14 trees · 3 constellations · One generating principle Document B of the Four-Basis set. Specification. What the system is, how it's built, how the pieces connect. © 2026 Shea Gunther · New Gloucester, Maine · CC BY-NC 4.0