Play Theory
for Computation

I. You Already Know

Your code broke in production.

Same code. Worked yesterday. Different machine, different version, different... something.

You've spent hours debugging "works on my machine." You've seen npm install pull different versions on different days. You've watched a deployment fail because someone, somewhere, changed a dependency.

You already know software is brittle.

Here's what you might not know: it's not a bug. It's the physics.

We built computation on a primitive designed for scarcity: destroy to change.

Variables. Mutable state. Overwrite to update. This made sense when memory was expensive and processors were slow.

But we're not there anymore.

We have abundance. Compute is cheap. Storage is infinite. Bandwidth is everywhere.

And yet we're still coding like it's 1970.

II. A Note on Manifestos

This is a manifesto.

Manifestos tell you what to do.

"Be free!" (they command)
"Think different!" (they demand)
"Break the rules!" (they order)

See it?

III. The Wrong Primitive

Game theory gave us the math for winning.

Finite games. Zero-sum. Compete for scarce resources. Winner takes all.

So we built computers that way:

• One program overwrites another
• One version replaces the previous
• One process starves another for memory
• Mutation as the fundamental operation

This worked. Until it didn't.

But look around. The infrastructure is already telling us something:

LEGO bricks from 1958 still click into bricks from 2025.

Git commits never disappear, only add.

Blockchains append, never edit.

The web slowly moves from location (broken) to hash (IPFS).

We need a different primitive.

Not mutation. Observation.

IV. Inventing Play Theory

We don't have a name for this yet.

Game theory: finite games, scarce resources, win/lose.

We need something else.

Let's call it play theory.

Infinite games. Abundant resources. Keep playing.

Not from economics. Not from philosophy.

Invented here, now, for computation.

V. The Same Physics Everywhere

LEGO, 1958: The brick IS the interface. Not "this brick version 2.1.3" or "this brick from factory A." The physical shape IS the identity. Same shape = same interface = fits forever. That's not design philosophy. That's physics.

Git, 2005: The hash IS the content. Not "this commit at this URL" or "this file named index.js." The SHA-256 hash IS the identity. Same hash = same content = works forever. That's not version control. That's physics.

Ethereum, 2015: The code IS the address. Not "this contract at this server" or "this function we maintain." The contract's code IS its address. Same code = same address = behaves forever. That's not blockchain magic. That's physics.

Graeber, studying anarchist societies: The protocol IS the authority. Not "leaders interpret the rules" or "gatekeepers approve changes." The rules themselves ARE the authority. Everyone sees them. Everyone can verify. No rulers, not no rules. That's not political theory. That's physics.

LEGO figured this out with physical bricks. Git figured this out with commits. Ethereum figured this out with contracts. Anarchist societies figured this out with protocols.

Flock figures this out with computation itself.

Same physics. Different domain.

VI. The Three Primitives

Here's what computation looks like when you build on observation instead of mutation:

1. Hash = Identity

hash:v1:8VkLMN2pQr7XYZabc...

Not a reference. Not a location. Not a name that might point to different things. The hash IS the thing.

Same content → same hash, forever.
Different content → different hash, guaranteed.

// This brick will ALWAYS parse JSON
flock:PARSE@1.0.0:v1:8VkLMN2pQr7XYZabc...

// Different implementation = different hash
flock:PARSE@1.0.0:v1:9XyZaB3cDe4Fg5Hi...

// Both exist. Both work. No conflicts.

Your code doesn't break because someone changed a dependency. Because dependencies don't change.

2. Append-Only Log

{"type":"PLACE","position":0,"brick":"hash:v1:abc..."}
{"type":"PLACE","position":1,"brick":"hash:v1:def..."}
{"type":"CONNECT","from":[0,"data"],"to":[1,"text"]}

Not instructions for the computer to follow. Not documentation of what happened. Events. The log IS the program.

Replay the log → get the same result. Always.

Time travel debugging? Rewind the log.
Audit trail? The log is already there.
Reproducible builds? Replay the same log.

3. Self-Contained Bundles

{
  "manifest": { "name": "data-pipeline", "version": "1.0.0" },
  "log": "...JSONL...",
  "bricks": {
    "hash:v1:abc...": { /* full definition */ },
    "hash:v1:def...": { /* full definition */ }
  }
}

Not a package.json pointing to npm. Not a Dockerfile pulling from registries. Everything needed to run is inside.

Send a bundle to someone? They can run it. Run it in 5 years? Still works. Run it on different machine? Identical results.

╔═════════════════════════════════════════════════╗
║  GAME THEORY         →       PLAY THEORY        ║
╠═════════════════════════════════════════════════╣
║  npm install                 Self-contained     ║
║  Location = identity         Hash = identity    ║
║  Overwrite to update         Append to extend   ║
║  Your version OR mine        All versions exist ║
║  Works on my machine         Works everywhere   ║
║  Break to change             Observe to compose ║
║  Trust platforms             Trust math         ║
╚═════════════════════════════════════════════════╝

VII. Code That Lasts

Put these together: Hash = Identity. Append-Only Log. Self-Contained Bundles.

What emerges?

A computer where every program ever written still works.

Not "still works if you maintain it." Not "still works with compatibility layers." Still works. Period.

1958 LEGO brick fits 2025 LEGO brick.

2025 Flock bundle will still run in 2095.

This isn't aspiration. This is inevitable given the physics.

If the brick is immutable, it can't break. If the log is append-only, you can always replay it. If the bundle is self-contained, external changes don't matter.

Code that ages like LEGO.

Not because you're careful. Because the substrate won't let it rot.

VIII. The Dissolution

When computation is immutable, something strange happens:

You can observe it without changing it.

In mutation-based systems, observation IS mutation: Reading a variable might trigger side effects. Logging changes performance. Debugging alters timing. Monitoring impacts behavior.

In observation-based systems: The computer shows you everything because showing you changes nothing.

Every execution generates a complete trace. Every brick records its inputs and outputs. Every decision point is visible. Every failure shows exactly what failed.

Not because you added logging. Because logging is free when nothing mutates.

It's not "human-in-the-loop AI." It's not "AI-assisted development."

It's a new kind of computer where humans and AI are both agents appending to the same substrate.

IX. The Trade-Off

"But mutation is sometimes what you need!"

Maybe. Or maybe you're so used to scarcity you see it where there isn't any.

Mutation made sense when memory was expensive. When storage was limited. When resources were constrained.

You have abundance now.

Compute is cheap. Storage is infinite. Memory is everywhere.

Mutation isn't wrong. It's obsolete.

Like optimizing for 56k modems in the age of gigabit fiber. You can do it. But why?

Datomic did this for databases. Unison did this for functions. Nix did this for packages.

Flock does this for computation itself.

Same trade-off every time: Give up mutation, gain permanence. Every time, it's worth it.

X. The Lineage

This isn't new physics. It's physics we already know, applied consistently:

IPFS – Content-addressed web

Git – Content-addressed version control

Ethereum – Content-addressed execution

Datomic – Immutable database

Unison – Content-addressed code

Nix – Immutable packages

Every one chose immutability over mutation. Every one chose observation over destruction. Every one still works years later.

Flock is the same choice, for workflows.

The physics isn't new. The domain is.

XI. What Dies in the Fire

When play theory wins, game theory dies. What burns:

This isn't "better tools for the same paradigm."

This is different physics. Different tools. Different outcomes.

XII. The Computer

An execution runs in the background. You didn't start it. It's scheduled. Running continuously. Ambient.

You open the surface. See every step:

🔵 Execution started
   ├─ FETCH → completed (230ms)
   ├─ PARSE → completed (12ms)
   └─ LOG → completed (5ms)

You didn't add logging. It's automatic. Observable.

The execution pauses. A question appears:

HUMAN_ASK: "Deploy to staging or production?"

You answer: "Staging." The execution continues. Records your response. Completes. Bidirectional.

Open it on your phone. Same execution. Same trace. Open it on your laptop. Same execution. Same trace. Someone else opens it on their device. Same execution. Same trace.

The execution doesn't live on your device. It lives on the network.

But here's the thing: You control where your context lives.

Context can live locally on your device. (Local-first)
Context can be encrypted end-to-end. (Private)
Context can be proven without revealing. (Zero-knowledge proofs)

The same physics that enables network-native also enables privacy.

Immutability doesn't mean surveillance. Immutability means you control the truth without trusting gatekeepers.

XIII. What This Means

For developers: Code that works today works in 10 years. Not aspirationally. Literally.

For teams: The log shows everything. No tribal knowledge. No "who changed this?" No archaeological digs through Slack.

For AI agents: Workflows are just JSON. LLMs generate JSON. Agents and humans share the same substrate.

For the industry: Stop rewriting because "old stack." Stop choosing between move fast or build solid. Immutability is both.

XIV. The Substrate

Flock is being built.

The protocol is defined. The physics is clear.

Content-addressed bricks. Append-only logs. Self-contained bundles.

60+ built-in operations: FETCH, POST – HTTP. PARSE, STRINGIFY – JSON. MAP, FILTER, GET – Data. FILE_READ, FILE_WRITE – Filesystem. LOG, BRANCH, MERGE – Control flow. HUMAN_ASK – Request guidance. AGENT_NOTIFY – Send notification.

Ambient execution. Observable by default. Bidirectional communication. AI-native from day one.

{
  "name": "daily-report",
  "bricks": {
    "fetch": {
      "brick": "FETCH",
      "inputs": { "url": "https://api.example.com/data" }
    },
    "parse": {
      "brick": "PARSE",
      "inputs": { "json": "@fetch.response" }
    },
    "notify": {
      "brick": "AGENT_NOTIFY",
      "inputs": { "message": "Report ready!", "level": "info" }
    }
  }
}

Or just describe it: "Fetch data from API and send me a notification"

The AI generates the workflow. The substrate executes it. The log records everything.

Three surfaces for interacting:

Observatory – Watch what's running
Playground – Build and test workflows
Director – Schedule automation

Not tools you use. Agents you supervise.

XV. The Invitation

The substrate is being built. Not as aspiration. As physics.

The same physics that made LEGO eternal. The same physics that made Git reliable. The same physics that made Ethereum trustless.

Applied to computation itself.

Your stack breaks every month. Your dependencies rot while you sleep. Your deployments are prayers.

It doesn't have to.

Content-addressed bricks don't break. Append-only logs don't lie. Self-contained bundles don't fail.

This is Flock. Not a better way to write JavaScript. Not a faster way to deploy containers. Different physics.

In ten years, someone will look at this moment and ask: "Why did they keep building on mutation?" "Why did they accept that code rots?" "Why did they think software had to break?"

We had the physics for winning.

We need the physics for continuing.

What will you make when code lasts?