The Five Rules

The recipe, given away

What: The five architectural constraints that define a Loop MMT tool.
For: Any programmer who wants to build tools this way — no permission, no license fee, no dependency on us.
License: The rules are free. Adopt them, fork them, teach them. That is the entire point.

Loop MMT builds small tools. Eighty-seven of them so far, each a single file you run with one command. They interoperate without ever having been designed to, they outlive the company that made them, and they prove their own history. None of that is magic. It is five rules.

This page gives away the whole recipe. Not a summary, not a teaser — everything a programmer needs to build tools that obey the Five Rules, and the reasoning behind each one so you can defend it in your own codebase. We are giving it away on purpose. A rule set only becomes a platform if enough people build on it, and the only way that happens is if it is free.

The one sentence

The Five Rules compile from a single sentence: “The tool is a sovereign, portable, provable file.” Sovereign → no dependencies, SQLite; you own it, you can read it. Portable → one file, one command; it travels. Provable → an append-only proof chain; it shows its work. If you remember nothing else, remember the sentence — the five rules are just its parts made precise.

The category test

These are not guidelines. They are constraints that define a product category. A tool that violates any of them is not a Loop MMT tool — the same way a dish without the load-bearing ingredient is a different dish. Read each rule as a line you do not cross, and the interoperability, longevity, and auditability come for free, as consequences rather than features you have to build.

Single file

Rule 1

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 source file.

Why it is a rule, not a preference. A single file is the smallest unit a human can fully hold, move, back up, diff, and reason about. The moment an application is a directory of files with an implied assembly order, you have introduced a build artifact that can drift from its source, a layout someone has to learn, and a hundred small places for state to hide. One file removes that entire class of problem by construction. It is also the unit that survives being emailed, pasted into a chat, dropped on a USB stick, or committed to a repo you will read in ten years.

How to hold the line. Keep the server, the request handlers, the data layer, and the UI in the same file. Inline your templates and your CSS. When you reach for a helper library, vendor its source into the file (see Rule 3) rather than adding an import. If the file grows large, that is a signal to simplify the tool, not to split it — a tool that cannot fit in one file is usually trying to be two tools.

One command

Rule 2

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

Why it is a rule, not a preference. Every step between “I have the file” and “it is doing something useful” is a place a person quits. A build step is a second program you have to keep working. A configuration wizard is a form standing between the user and the value. Sixty seconds is not a marketing number — it is the budget for the whole distance from download to first use, and it forces every setup decision to justify its cost against that budget. A tool that initializes itself on first run carries its own setup inside it, so there is nothing to get wrong on someone else’s machine.

How to hold the line. On first run, create the database, run the schema, and start the server — in that order, idempotently, so the second run is a no-op. Choose sensible defaults for everything and let the user override later, in the running tool, rather than up front in a config file. Treat “works on a clean machine with only the runtime installed” as a test you actually run.

No dependencies

Rule 3

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 22.13+ (the version where the built-in node:sqlite module ships unflagged). Vendored source is permitted and documented.

Why it is a rule, not a preference. A dependency is a bet that someone else’s code, and the registry that serves it, will still exist and still behave the same way when your user runs the tool. Most tools lose to bit rot not because their own code broke but because a dependency moved, a registry went down, or an install step failed on a machine slightly unlike the author’s. Vendoring the source you actually use — and only the source you actually use — converts a runtime bet into a fact that ships inside the file. The tool becomes something you can run from an archive with no network at all.

How to hold the line. Prefer the runtime’s standard library; it is the one dependency you are allowed. When you genuinely need outside code, copy the specific source you use into the file and note where it came from and under what license. Resist the transitive-dependency reflex — if a library drags in twenty others, that is a reason to write the twenty lines you need by hand instead.

SQLite storage

Rule 4

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.

Why it is a rule, not a preference. SQLite is the most widely deployed database in the world, its file format is a committed public standard, and it is readable by thousands of other applications. Storing data in SQLite means the user can open their own data with tools you did not write, decades after you stop maintaining yours. A proprietary format — even a well-documented one — makes the user a hostage to your tool’s continued existence. Keeping binary assets on disk by content hash keeps the database small and makes deduplication and integrity checking fall out for free.

How to hold the line. Put every structured record in the database, not in ad-hoc JSON files beside it. Reference each binary asset by its SHA-256 content hash so the same bytes are stored once and any tampering is detectable. Treat the database file and its asset directory as one movable unit — copy them together, and the user’s whole world moves with them.

Append-only proof chain

Rule 5

Every significant operation is recorded in a hash-chained, append-only ledger. Each entry links to the previous entry’s hash. Database 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 stored it.

Why it is a rule, not a preference. A tool that can silently rewrite its own past is a tool you have to trust. A tool whose past is a hash chain — where each entry commits to the one before it, and the database itself refuses edits and deletes — is a tool you can verify. This is the difference between “the log says X happened” and “X happened, and here is the chain that proves nothing was inserted, removed, or reordered since.” Making the content hash canonical across every tool is what turns a pile of separate tools into a mesh: two tools that never knew about each other still agree on the identity of a piece of content, because the same bytes hash the same way.

How to hold the line. Record each significant operation as a ledger entry that includes the hash of the previous entry, so the chain is self-verifying. Enforce append-only at the database level with triggers that reject UPDATE and DELETE on the ledger table — do not rely on your application code to be disciplined. Use SHA-256 for every content hash, computed over the canonical bytes, so your hashes mean the same thing as everyone else’s.

What the rules buy you

The payoff

Automatic interoperability. Shared constraints produce interoperability nobody designed. Any tool that follows the Five Rules can read any other tool’s data — not because the tools were built to work together, but because the constraints are the same: the same SQLite format, the same content-hash convention, the same proof-chain shape. The fence is the phone line. The rules are the mesh.

Composition into programs. A single tool is useful. What makes a toolkit a system is the ability to wire tools together into directed graphs that run real processes, with a proof-chain receipt at every step. A saved composition is a program; the thing that runs it is a runtime; and the person building the process is composing tools rather than writing code.

A market position, stated plainly. These rules are not only a technical choice. They are the architectural equivalent of a promise: we will never do this to you — never lock your data in a format you cannot read, never make the tool stop working because a service went away, never ask you to trust a history you cannot check.

How the tools get built

The method behind the recipe

The Five Rules are the shape of the artifact; they say nothing about how one gets made. In practice each tool starts as a short specification — a blueprint naming what the tool does and the seams it exposes — which a fresh AI instance reads, builds against, and commits back to the repo, one deterministic byte-truth floor checking the work at every step. The result is an app that obeys the five rules, and the record of how it got there is itself in the repo. That loop — blueprint, build, check, commit, and the next session picking up where the last left off — is the whole engine; the rules above are just the standard every pass has to meet.

None of that is required to use the rules — you can build a Five-Rules tool by hand in any language, and it will still interoperate with every other one. The method is simply how these particular tools were made, and it is written down: the full architecture lives in The Plan, and the Walk-Through traces a single tool from first blueprint to shipped file. The apps are the worked specimens — each one links its own source, so the recipe and a tool that follows it are never more than a click apart.

Start here

The rules as a code shape

The five rules are architectural constraints, not a framework, so there is nothing to install and no starter to clone — a compliant tool is one you can write from an empty file. What follows is the smallest shape that satisfies all five at once: a single Node file, run with one command, no dependencies beyond the runtime, its data in SQLite, its history in an append-only hash chain. Copy it, rename it, and grow your tool inside it — every line you add lands under a rule that is already being held.

#!/usr/bin/env node // tool.js — a Five-Rules skeleton. One file. Run: node tool.js // Rule 3: standard library only. No package.json, no node_modules. const http = require('node:http'); const crypto = require('node:crypto'); const { DatabaseSync } = require('node:sqlite'); // Rule 4: structured data in SQLite. Rule 2: first run initializes it. const db = new DatabaseSync('tool.db'); db.exec(` CREATE TABLE IF NOT EXISTS item (id TEXT PRIMARY KEY, body TEXT, ts TEXT); CREATE TABLE IF NOT EXISTS ledger ( seq INTEGER PRIMARY KEY AUTOINCREMENT, prev TEXT, hash TEXT, event TEXT, ts TEXT); -- Rule 5: the ledger is append-only. Enforce it in the database, -- not in application code you have to remember to be careful in. CREATE TRIGGER IF NOT EXISTS ledger_no_update BEFORE UPDATE ON ledger BEGIN SELECT RAISE(ABORT,'append-only'); END; CREATE TRIGGER IF NOT EXISTS ledger_no_delete BEFORE DELETE ON ledger BEGIN SELECT RAISE(ABORT,'append-only'); END; `); // Rule 5: each entry commits to the one before it — a self-verifying chain. function record(event) { const prev = db.prepare('SELECT hash FROM ledger ORDER BY seq DESC LIMIT 1').get(); const prevHash = prev ? prev.hash : ''; const ts = new Date().toISOString(); const hash = crypto.createHash('sha256').update(prevHash + event + ts).digest('hex'); db.prepare('INSERT INTO ledger (prev,hash,event,ts) VALUES (?,?,?,?)') .run(prevHash, hash, event, ts); } // Rule 5, held structurally: no state change happens WITHOUT its receipt. // Route every write through mutate() — one atomic transaction that does the // change and records it. A future programmer cannot forget the ledger line, // because there is no path to the state that goes around this wrapper. function mutate(event, change) { db.exec('BEGIN'); try { const r = change(); record(event); db.exec('COMMIT'); return r; } catch (e) { db.exec('ROLLBACK'); throw e; } } const esc = s => String(s).replace(/[&<>"]/g, c => ({ '&':'&','<':'<','>':'>','"':'"' }[c])); // Rule 1: server, logic, and (inline) UI live in this same file. http.createServer((req, res) => { if (req.method === 'POST' && req.url === '/item') { let body = ''; req.on('data', c => body += c); req.on('end', () => { const id = crypto.randomUUID(), ts = new Date().toISOString(); mutate('item.create:' + id, () => // state + receipt: one transaction db.prepare('INSERT INTO item (id,body,ts) VALUES (?,?,?)').run(id, body, ts)); res.writeHead(201).end(id); }); return; } const rows = db.prepare('SELECT id,body,ts FROM item ORDER BY ts DESC').all(); res.writeHead(200, { 'content-type': 'text/html' }) .end('<h1>Items</h1>' + rows.map(r => `<p>${esc(r.body)}</p>`).join('')); // Rule 2: one command, useful in sixty seconds — no build step, no config. }).listen(3000, '127.0.0.1', () => console.log('http://localhost:3000'));

That is roughly forty lines and it already holds all five rules: it is one file (Rule 1), it starts with node tool.js and initializes itself (Rule 2), it imports only node:* (Rule 3), it keeps its data in SQLite (Rule 4), and it writes an append-only, hash-chained ledger the database itself refuses to edit (Rule 5). Grow a real tool by adding routes and tables — route every write through mutate(…) and the receipt is taken in the same transaction as the change, so a new operation cannot land its state without its proof. That is the difference between a rule you remember and a rule the design holds: there is no path to the data that goes around the ledger. When you want the fully worked versions rather than the skeleton, the apps each link their own complete source, and the Walk-Through follows one from its first blueprint to the shipped file.

One honest boundary

The Five Rules assume the adversary is a platform, not a state. The proof chain that protects your data’s integrity also records what you did — and for someone whose threat is a government, that record becomes evidence. For that case the ecosystem defines a second mode: encrypted at rest, no unprompted network calls, minimal host footprint. The two modes do not convert into each other, and the documentation is honest about exactly what each one protects against and what it does not. Choose the mode that matches your actual threat, not the one that sounds strongest. The two-mode security posture is set out in The Plan.

Take it

Adopt the rules

There is no sign-up. The rules above are the whole specification — hold all five and you are building Loop-MMT-class tools, whether or not you ever use the name. Build one for yourself, teach the five constraints to someone else, or fork the idea into your own house style. The recipe is given away because a rule set only becomes a platform when it is free, and a platform is what we are after. If you build something that follows the Five Rules, it will already speak the same language as everything else that does.

The Five Rules are locked as a standing decision (29 Mar 2026): single file · one command · no dependencies · SQLite storage · append-only proof chain. Everything on this page is the recipe, given away MIT-style so it can become a platform. Full architecture: The Plan · the tree-composition runtime is the reference implementation. See also the Discoveries register — the findings the methodology surfaced while building tools to these rules.