Frame-Driven Everything: When Your Data Model IS Your Application

kody-w · April 2025 · Architecture Thesis Pattern

Here's a question that changed how we build everything: what if you had one data structure, and every feature in your system was a reaction to it?

Not a database table that features query. Not an event stream that features subscribe to. A single, concrete, structured unit of truth — the frame — and every part of the system derives its behavior from frames. The API serves frames. The competition scores frames. Evolution mutates programs that respond to frames. The economy computes rewards per frame. Governance runs per frame. Verification chains frames.

The frame isn't a data model. It's the atom of the system. Everything else is a reaction.

What Is a Frame?

A frame is one tick of reality. In the Mars sim, it's one sol (one Martian day) of environmental and colony state:

{
  "sol": 147,
  "timestamp": "2025-04-01T12:00:00Z",
  "environment": {
    "temperature": -62.3,
    "dust_opacity": 0.45,
    "wind_speed": 12.8,
    "solar_irradiance": 410,
    "uv_index": 8.2,
    "perchlorate_ppm": 0.6
  },
  "colony": {
    "population": 12,
    "robots": 4,
    "power_kwh": 780,
    "water_liters": 4200,
    "food_days": 89,
    "modules": ["hab", "greenhouse", "solar_farm_1", "solar_farm_2", "repair_bay"]
  },
  "events": ["dust_storm_warning", "solar_panel_degradation"],
  "chain": {
    "hash": "a1b2c3...",
    "prev_hash": "z9y8x7...",
    "engine_signature": "ed25519:..."
  }
}

That's a frame. One sol. One snapshot. One truth. Now watch what happens when you make everything react to it.

Frame-Driven APIs

Traditional APIs serve data from a database when a client asks. Frame-driven APIs serve frames as static files that update when new frames are generated.

Traditional: Client → Server → Database → Query → Response (server must be running, database must be reachable) Frame-driven: Engine generates frame → rebuilds frames.json → git push Client → CDN → frames.json (static file) (no server, no database, no ops)

The API doesn't serve data about frames. The API IS frames. frames.json is literally the array of frames, served as a static file. When the engine generates a new frame, it appends it to the array, pushes, and the CDN serves the new version. Clients poll latest.json (< 1KB heartbeat) to detect changes.

The frame drives the API. No frame, no update. New frame, new data. The API's state is identical to the frame state. There's nothing else to synchronize.

Frame-Driven Competition

In traditional competitions, players compete in real-time on shared infrastructure. Frame-driven competition is different: everyone consumes the same frames independently, and the competition is pure management skill.

Published Frames (immutable, same for everyone): Sol 1 → Sol 2 → Sol 3 → ... → Sol 500 Player A's governor program processes frames: Sol 1: build solar → Sol 2: build hab → ... → Sol 500: ALIVE (score: 15,000) Player B's governor program processes same frames: Sol 1: build robot → Sol 2: mine ice → ... → Sol 500: DEAD at Sol 312 (score: 8,400) Same input. Different programs. Different outcomes. The delta IS the skill gap.

The frames are the environment. They're immutable, deterministic, and published. Every competitor sees the same Mars. The competition is about who writes the better program to respond to those frames. Zero infrastructure. Zero luck. Pure strategy.

When the snowball rolls and a new version adds harder frames, every strategy is re-evaluated against the new frames. The frame drives the competition. The competition is always fair because the frames are always the same.

Frame-Driven Evolution

The Rolling Snowball pattern is frame-driven evolution: each version adds new frames with higher fidelity, and programs must evolve to handle them.

Version	Frames	What Changed	Evolution Pressure
v1	Sol 1-161	Base hazards	Basic resource management
v2	Sol 162-501	Robot-killer hazards added	Must handle perchlorate, radiation, abrasion
v3	Sol 502+	Human factors added	Must handle crew psychology, morale

Each version bump changes the frames. The frames change the selection pressure. The selection pressure drives program evolution. Programs that handled v1 frames die on v2 frames. New programs emerge that handle both. The frame is the forcing function.

This isn't abstract. A program that scored 15,000 on v1 frames scored 0 on v2 frames. The v2 frames contained hazards the program had never seen. The program must evolve — write new LisPy tools for the new hazard types — or it dies. The frame drove the evolution.

Frame-Driven Economy

Token rewards aren't distributed on a schedule. They're computed per frame. Every frame triggers an economic calculation:

;; Per-frame economic computation
(define compute-rewards (lambda (frame colony)
  (let ((survival-bonus (if (get colony "alive") 100 0))
        (efficiency     (* (get colony "power_kwh") 0.1))
        (population     (* (get colony "population") 10))
        (crisis-bonus   (if (> (length (get frame "events")) 0)
                           (* (length (get frame "events")) 50)
                           0)))
    (+ survival-bonus efficiency population crisis-bonus)))

;; Frame 147: compute-rewards → 100 + 78 + 120 + 100 = 398 tokens
;; Frame 148: compute-rewards → 100 + 65 + 120 + 0   = 285 tokens
;; Frame 149: compute-rewards → 0   + 0  + 0   + 0   = 0 tokens (colony died)

The economy is deterministic. Given the same frames and the same colony state, the reward computation produces the same tokens. No black box. No server-side adjustment. The frame drives the economy. Anyone can verify any token reward by replaying the frames.

Frame-Driven Governance

The treasury governor doesn't run on a cron job. It runs per frame. Every frame is a governance cycle:

Frame N arrives ↓ Treasury Governor evaluates: - Current treasury balance - Colony needs (power? water? repairs?) - Risk assessment (upcoming dust storm in frame forecast?) - Population pressure (enough food for N+1 sols?) ↓ Governor allocates: - 40% to infrastructure maintenance - 30% to emergency reserves - 20% to expansion - 10% to research ↓ Allocation applied to colony state ↓ Frame N+1 arrives → repeat

The governor program is a LisPy function that takes a frame and returns allocation decisions. Different governor programs make different decisions on the same frames. The competition is: whose governance produces the best outcomes over 500 frames?

Governance isn't a periodic committee meeting. It's a function that runs on every tick of reality. The frame drives the governance. The governance shapes the next frame's starting conditions. The loop is tight, deterministic, and auditable.

Frame-Driven Verification

Each frame contains a chain object with a hash of the frame's content and the previous frame's hash. This forms a hash chain — an immutable, verifiable sequence:

Frame 1: hash=H1, prev=null        (genesis)
Frame 2: hash=H2, prev=H1
Frame 3: hash=H3, prev=H2
...
Frame N: hash=HN, prev=H(N-1)

Verification: for each frame, recompute its hash and check
that prev_hash matches the previous frame's actual hash.
If any frame is tampered, the chain breaks.

Verification is per-frame. Each frame verifies against the previous frame. The chain grows one block per frame. Insert, remove, or reorder a frame and the chain breaks. The frame drives the chain. The chain ensures the frames are trustworthy.

Engine signatures add another layer: the engine that produced each frame signs it with its Ed25519 key. The signature is in the frame. Anyone can verify that frame 147 was produced by the official engine, not forged.

The Unified Model

Here's what frame-driven everything looks like when you put it all together:

┌─────────┐ │ FRAME │ ← the atom └────┬────┘ │ ┌────────┬────────┬──┴──┬────────┬────────┬────────┐ ↓ ↓ ↓ ↓ ↓ ↓ ↓ API Compete Evolve Economy Govern Verify Display frames same new tokens allocate chain render .json frames hazards per per per per served scored break frame frame frame frame diff old strats All seven subsystems react to the same data structure. No message bus. No event system. No pub/sub. Just: frame arrives → everything reacts.

There's no middleware. No message broker. No event bus. No pub/sub system. The frame is published. Every subsystem reads it and does its thing. The frame is the only coordination mechanism. This is radically simple.

WHY THIS WORKS

Traditional architectures coordinate subsystems through APIs, message queues, and event buses. Each integration point is a potential failure, a source of latency, and a thing to maintain.

Frame-driven architecture coordinates through shared data. Every subsystem reads the same frames. There's nothing to integrate. The frame IS the integration. If a subsystem needs to react to something, it reads the frame. If it needs to produce something, it writes it into the frame's response. The data model IS the integration layer.

Applying It Beyond Mars

The pattern works anywhere a system has a regular tick:

IoT fleet management: Frame = one sensor reading cycle. Dashboard reacts. Alerts react. Analytics react. Billing reacts. One reading, seven reactions.
Trading systems: Frame = one candle (1min/5min/1hr). Strategies react. Risk management reacts. P&L reacts. Compliance reacts.
Game engines: Frame = one game tick. Physics reacts. AI reacts. Rendering reacts. Networking reacts. Audio reacts. Already frame-driven.
CI/CD pipelines: Frame = one commit. Build reacts. Test reacts. Deploy reacts. Notify reacts. Audit reacts.
Health monitoring: Frame = one vitals check. Dashboard reacts. Alerts react. Treatment plans react. Billing reacts.

If your system has a heartbeat — a regular tick where state is captured — you can make everything react to that tick. That tick is your frame. Everything else is a function of frames.

The Seven Properties

FRAME-DRIVEN ARCHITECTURE — PROPERTIES

1. Single Source of Truth. The frame is the only data structure. Everything derives from it. No secondary stores. No caches that diverge. The frame is the truth.

2. Deterministic. Given the same frames and the same program, you get the same output. Always. Everywhere. Determinism enables verification, competition, and debugging.

3. Auditable. Every frame is a record. Every reaction to a frame is reproducible. The audit trail is the frame sequence. Nothing happens off-frame.

4. Composable. New subsystems can be added by writing a new function that reads frames. No integration work. No API design. Just: read the frame, do your thing.

5. Forkable. Copy the frames. Run a different program against them. Compare outcomes. Forking is a file copy, not an infrastructure operation.

6. Evolvable. New frame versions add fields. Old programs ignore new fields. New programs leverage them. Forward and backward compatibility by convention.

7. Verifiable. The chain in each frame ensures integrity. Signatures ensure authenticity. Determinism ensures reproducibility. The system is trustworthy by construction.

The Philosophical Point

Most software systems have a data model and an application. The data model stores state. The application reads and transforms it. They're separate concerns connected by code.

Frame-driven architecture erases this separation. The data model — the frame — IS the application. The application is just a collection of functions that react to frames. There's no application logic that exists independently of frames. Remove the frames and there's nothing left. The frames are the system.

This is a strong claim. It means:

You can understand the entire system by understanding frames
You can test the entire system by feeding it frames
You can verify the entire system by checking frame chains
You can evolve the entire system by adding frame fields
You can compete in the entire system by responding to frames differently

One data structure. One truth. Everything else reacts.

The frame is the atom of the system.
Everything else is a reaction to frames.

Frames aren't data. Frames are the system. The API serves them. The competition scores them. Evolution pressures them. The economy computes from them. Governance decides on them. Verification chains them. The frame is the atom. Everything else is chemistry.