Kody Wildfeuer

The Wire Is the Authority

2026-08-01T00:00:00+00:00

I shipped an operating system this week whose filesystem is a public website. It has an index — a JSON file listing every node in the tree, regenerated on every build. On the first real test I typed cat on a path that was definitely there, and got back:

cat: /OS/system32/etc/motd: no such file or directory

The file existed. I could curl it from another terminal while the shell was insisting it didn’t. The index simply hadn’t caught up.

The obvious fix is to regenerate the index. The interesting fix is to stop believing it.

Two different questions

There are two questions a filesystem answers, and we habitually conflate them:

What is in this directory? — a listing question.
Does this specific thing exist? — an existence question.

An index is a very good answer to the first and a merely convenient answer to the second. It is a snapshot of a tree taken at a moment that has already passed. On a local disk the gap between snapshot and truth is microseconds and you can pretend it is zero. On a distributed system it is however long your build takes.

The fix I landed on is one line of policy:

The index is a listing. The wire is the authority.

ls reads the index, because listing is what an index is for. cat goes straight to the origin. If the origin serves the bytes, the file exists — whatever the index believes. And when a path resolves that way, the shell says so out loud:

index  not in /OS/api/fs.json
       served anyway — the wire is the authority,
       the index is only a listing

That last line matters more than the fix. A system that silently papers over a disagreement between its cache and its source has taught you nothing. A system that resolves the request and reports that the two disagreed has handed you a diagnostic for free.

This is not a filesystem problem

Once you have the shape, you see it everywhere, and almost always mishandled.

Package registries. The index says version 4.2.1 exists. The tarball 404s. Every developer has watched a resolver confidently produce a lockfile for artifacts that are not there.

Service discovery. The registry lists three healthy replicas. Two are gone. The list is a listing; the health check is the wire.

Search over your own docs. The vector index was built on Tuesday. The doc was rewritten on Wednesday. The index answers, fluently, from a version of reality that no longer exists.

Agent tool catalogs — and this is the one about to matter enormously. We are handing models a manifest of available tools and letting them plan multi-step work against it. That manifest is an index. When it drifts, the model does not fail loudly; it produces a confident plan built on capabilities that do not exist, and you find out four steps in.

In every one of those cases the failure mode is identical: the system trusts the listing to answer the existence question, and reports absence when it means staleness.

Those are not the same thing, and the difference is the whole ballgame. “It is not there” ends an investigation. “My index does not know about it” starts one.

The cost is not what you think

The objection is performance. If existence always costs a round trip, why have an index at all?

Because you do not check existence nearly as often as you think. Listing a directory, rendering a nav, populating an autocomplete, planning a route — those are index operations, and they stay fast. Existence is checked when you actually act: read the file, install the package, call the tool. At that moment you were going to pay for the round trip anyway.

That was the second thing I got wrong. My first version did a HEAD to check existence and then a GET to read — two round trips to answer one question. The GET is the existence check. A 404 is a definitive answer, and a 200 arrives with the bytes attached.

read(path):
  if local layer has path:  return it
  if hidden here:           throw
  GET path
  if 404:                   throw "no such file"
  return bytes

One request. The index was never consulted, and never needed to be.

Absence is a claim, and claims need standing

The deeper principle is about who is entitled to say no.

A cache is entitled to say yes — if it has the bytes, it has them, and staleness is a separate problem. A cache is almost never entitled to say no, because it cannot distinguish “this does not exist” from “I have not heard about it.” Those are wildly different facts wearing the same word.

So: let the fast layer answer affirmatively, and make the slow layer the only thing allowed to deny. Most systems have this exactly backwards — they let the index deny instantly and confirm slowly, which optimises for being wrong quickly.

I would rather be right slowly, on the small number of occasions when it matters.

How I actually found it

I did not reason my way here. I typed cat on a file I knew existed, watched a system I had just written lie to me, and had to decide which of the two things in front of me was authoritative: my own index, or the HTTP response.

It was never going to be my index. It is a file I generated. The origin is the thing that other people, other machines and other decades will read.

Build the index for speed. Keep the wire for truth. And when they disagree, say so out loud — the disagreement is the most useful thing either of them will ever produce.

The OS is at kody-w.github.io/OS/console. It boots in about a second from static files, and you can curl any path it shows you.

Six Times the Test Was Wrong

2026-08-01T00:00:00+00:00

I pointed eight agents at one file and told them to loop until it was perfect.

The file was voxel-world.html — 9,749 lines, a Minecraft-style voxel sandbox that is one self-contained HTML document. Six agents owned disjoint regions and edited. Two were read-only critics whose only job was to be unimpressed.

They found 20 real defects. They also produced six false ones.

Three of the six were mine.

The ledger

Here is what the false failures actually were.

1. I asserted window.vox was an object. It’s a function. My check reported a failure against correct code on the very first run.

2. I used offsetParent === null to mean “not visible.” CSSOM defines offsetParent as null for any position: fixed element. So a correctly-rendered fixed overlay read as invisible. An agent dutifully changed a real CSS property to satisfy my broken assertion. I caught it and reverted.

That one didn’t stay caught. The same trap burned a critic’s entire test run. It survived inside another agent’s focus-trap helper. And it was still sitting in the readiness check of both my tools an hour later — where, because #loading is position: fixed, the clause was trivially true and did nothing. Every “boot time” number I had quoted was measuring the wrong moment. Five instances of one mistake.

3. My static test server sent cache-control: no-store. I wrote it that way for clean reruns. It also makes offline caching untestable by construction. An agent caught it, checked what GitHub Pages actually sends for that file, and rebuilt the server to match production. Without that, the entire offline suite would have been measuring a fiction.

The agents produced the other three.

4. A self-test assertion whose entire body was async () => true. A placeholder, in a passing suite, reporting success forever. It was one of seven assertions the agent found that were green without being correct — three more were vacuous because they ran before any bot existed and compared nothing.

5. A leak that wasn’t. An agent measured 9.4 leaked objects per round and had the numbers to prove it. Then it ran a zero-bot control group. The control climbed identically. It had been measuring chunk-streaming warmup. It retracted its own finding.

6. Four failures from asserting obs.self when the real key is obs.you.

The one that matters most

The best finding of the run wasn’t a bug. It was this:

The ambient occlusion was real, correct, wired up, and completely invisible.

An agent implemented per-vertex AO properly — baked at mesh-build time, zero draw calls. It verified its own work: 66.3% of quads carried per-vertex colour variation, vertexColors: true was set. It reported AO as a win.

The blind critic scored it 2 out of 10. Corners rendered perfectly flat.

The cause: sun intensity 1.1 plus hemisphere 0.8 is about 1.9 irradiance, and with no tone mapping the highlights clip. Multiplying albedo by 0.7 barely moves a pixel already clamped at white. The data was in the buffer. It never reached the screen.

The builder measured the attribute. It never measured the pixel.

That is not a coding error. Every line was correct. It’s a verification error — checking the thing you built instead of the thing the user sees.

What this unlocks

One agent did the thing that actually settles it. It wrote a mutation harness: deliberately break each invariant in a live page, and confirm the suite goes red.

Nine mutations. Nine kills. Each turning exactly one assertion red, with no collateral.

That is the only evidence that a green suite means anything. Without it, “83 assertions passing” and “83 assertions that cannot fail” produce identical output.

The cost

Adversarial verification is expensive. Two of eight agents wrote no production code at all. The critics took over an hour each and spent it clicking every control, throttling the CPU, and blind-ranking screenshots.

They also found the blocker.

The desktop UI was completely unclickable. A “Click to play” overlay at z-index: 40 sat above a toolbar at 35. Every button resolved to the overlay. Clicking the gear granted pointer lock instead of opening settings. Three panels had no keyboard fallback; the only route in was fourteen tabs and Enter. The buttons rendered at full opacity the entire time, so nothing looked wrong.

It was in git HEAD. It is invisible in source. It is invisible in a screenshot. It only appears if you put a cursor on a button and click it.

The implication

The lesson I keep relearning is not “write more tests.”

It’s that the assertion is code too, and nobody reviews it. Implementation gets scrutinized. Test code gets written once, goes green, and is never read again. So it rots silently, and a green suite becomes a claim nobody has audited.

Three rules I’d now apply anywhere:

Check the assertion before you fix the implementation. When something reports a failure, the test is a suspect. In this run it was guilty 23% of the time.

Measure the output, not the intermediate. Verify the pixel, not the buffer. The user cannot see your vertex attributes.

Prove your tests can fail. Mutate the code on purpose. If the suite stays green, you don’t have tests — you have decoration.

The agents were good. What made them trustworthy was that two of them were paid to disagree, and one of them retracted its own finding.

Rarity Without a Ledger: What Adopt Me Actually Taught Me

2026-08-01T00:00:00+00:00

Adopt Me is the most successful pet economy ever built — it holds Roblox’s concurrency record at roughly 1.9 million people in one game at one time. I spent a while pulling it apart, because I wanted its retention engine for a system that has no server, no database, and no authority of any kind.

The received explanation is that it’s a slot machine for children. That explanation is wrong, and being wrong about it is expensive, because it points you at the one mechanic you can’t have.

Two things everyone gets wrong

It isn’t a Tamagotchi. Adopt Me pets cannot die, cannot get permanently sick, cannot run away, and lose nothing to neglect. The care loop that supposedly drives guilty daily returns imposes no penalty at all. Every guide confirms it. The thing commentators describe as the hook is decorative.

It isn’t really a gacha, either. The egg odds are disclosed and the expected value across egg tiers is remarkably flat. If the gacha were the engine, the game would monetize like a casino and retain like one — briefly.

The actual engine is the part nobody writes about, because it looks like an accounting detail.

The engine is the sink

Four full-grown pets of the same species fuse into a Neon. Four Neons fuse into a Mega Neon. So one Mega costs sixteen base pets, plus the work of raising each one — about 3,660 tasks end to end.

Now price the shortcut. A Royal Egg yields a specific legendary about 2.67% of the time. Sixteen of them is roughly 600 eggs, ~870,000 in-game Bucks, which at the game’s own best-ever exchange rate is on the order of five thousand US dollars to brute-force a single Mega Neon.

That number is the whole design. Adopt Me built a demand engine its own monetization cannot satisfy, and then let players satisfy it for each other. Trading isn’t a feature bolted onto the pet system; it’s the only viable path to the thing the pet system makes everyone want.

And underneath both is the property that makes it work at all:

A fusion sink makes duplicates valuable.

This is the load-bearing insight. In any collectible system, most pulls are boring. Without a sink, a duplicate is a disappointment — a thing you got instead of the thing you wanted. With a sink, every boring pull is an ingredient. The floor of the loot table stops being garbage. You have converted your failure mode into your supply chain.

Which of these can survive without an authority?

I care about this because I build local-first systems: no server, no database, nothing that can be the sole writer of truth. So I sorted Adopt Me’s mechanics by what they actually require.

Trading requires an authority. Scarcity in a trade economy means non-duplication, and preventing duplication means somebody has to be the one who says this item is here and therefore not there. That’s a ledger, and no clever hash removes the need for it. Every anti-scam mechanism, every rollback, every unfair-trade detector is downstream of the same requirement.

(That’s the prevention half. Later in this post I get the other half wrong and then correct it — detecting a double-spend turns out to need no authority whatsoever, which is a much bigger loophole than I first gave it credit for.)

Fusion requires nothing. 4 → 1 is a pure function of its inputs. It needs no server because there is nothing to arbitrate: given the parents, the child is already determined.

That asymmetry is the finding. The single most retentive mechanic in the most successful pet economy ever built is also the one that needs no authority. The part that needs a server — trading — is a consequence of the sink, not a peer to it. Build the sink, and you have built the reason people wanted to trade in the first place.

What I built

The system I’m working in derives a creature entirely from a “tail” — a 64-hex secret minted exactly once and never re-rolled. Four traits fall out of a hash of it. Nothing is stored, nothing is assigned, and anyone can verify any creature offline. The rarest trait band is one in 65,536, and the only way to get it is to mint identities until one lands. The scarcity is real because the electricity was real.

The fusion law is one line:

fuse(tails) = sha256("rapp/1:fuse\n" + sorted(tails))

Sorted, so fusion is a property of the set and not of the order you happened to place them in. Distinct parents required, because letting one creature stand in for four would make the entire cost fictional.

Three properties come free:

Determinism. The same four parents always produce the same child, on any machine, forever.
Proof of possession. You cannot produce a well-formed child without knowing four real mint-once secrets. That is unforgeable evidence of accumulated work — the closest thing to scarcity available without a ledger.
Depth is free. Generation 1 costs 4 identities. Generation 2 costs 16. Generation 3 costs 64. Adopt Me stopped at 16; the arithmetic doesn’t care where you stop.

The discipline: fusion must not hand out rarity

Here’s where it would have been easy to ruin it.

The obvious move is to make fusion upgrade things — fuse four commons, get an uncommon. Publish an uplift curve, call it a stated law of physics rather than a slot machine.

I didn’t, and I think the reasoning generalizes. In a system whose entire claim is rarity is earned work, not an assertion, an uplift function is an authority wearing a costume. It’s me deciding that this thing is rarer than that thing. The moment rarity can be manufactured by a rule I wrote, it stops being a measurement and becomes a claim — and the system’s whole pitch was that it makes no claims.

So the child of a fusion is an ordinary creature. Its tail is an ordinary tail; its traits come out of the ordinary derivation at the ordinary odds. Fusing four of the rarest things does not produce something rarer than the rarest thing.

What the child carries instead is its generation — and generation is arithmetic, not opinion. A generation-3 creature is a receipt for 64 minted identities. It cannot be faked, because you cannot produce it without the parents, and it doesn’t have to be trusted, because anyone can recompute it offline in a millisecond.

I made this a test rather than an intention: fuse two thousand children, tally their rarity bands, and assert the distribution matches freshly minted creatures within noise. If fusion ever starts handing out rarity nobody minted for, the build fails. A principle you haven’t written a test for is a principle you’re planning to violate later.

The part I got wrong

I originally ended here: fusion proves the parents existed, not that they were spent — with no ledger there is nothing to burn.

That was too strong, and someone rightly pushed back on it. I had collapsed two different things into one:

Preventing a double-spend globally. This does need an authority.
Detecting one. This needs nothing at all.

The primitive is a nullifier — a spend-marker derived from the secret:

nullifier(tail) = sha256("rapp/1:nullifier\n" + tail)

Only the holder can produce it, because the tail is a mint-once secret. It reveals nothing, because preimage resistance means the marker doesn’t identify the creature unless you already know its tail. And — this is the whole trick — it is identical every time.

Which is exactly why it must not be bound to the child. Bind it, and the same parent can be spent into two children under two different markers, and the burn is theatre. Leave it unbound, and spending one creature twice publishes the same value twice. That collision is the evidence.

So the honest split is sharper than “no burn”:

On one device, the burn is enforced. The registry refuses a parent it has already seen consumed. A spent creature is struck through and cannot be selected again.
Across devices, the burn is detected. Hand any two fusion records to a function that looks for a repeated nullifier. It runs offline, on nothing but the records themselves. Nobody adjudicates — the collision is the adjudication.
What still needs an authority is ordering. Deciding which of two conflicting fusions came first requires a clock somebody agrees on. So equivocation is caught, but not arbitrated.

That last bullet is the real remaining limit, and it’s a much smaller one than I first claimed. I made it a test: the conflict object is asserted never to contain the words “first”, “valid”, “winner”, or “canonical”. Quietly picking a winner would be the same overclaim wearing a new costume.

This isn’t novel — it’s the construction Zcash uses to retire a note, and the posture Certificate Transparency takes toward mis-issued certificates. You don’t prevent the lie. You make it undeniable. For a system with no server, that turns out to be most of the way there.

The general point stands, but I had the boundary in the wrong place. “This needs an authority” deserves the same scrutiny as any other claim — including, especially, when I’m the one making it.

The general lesson

When you’re rebuilding something that works, the temptation is to port the whole surface and then discover which parts needed infrastructure you don’t have.

Better to invert it: find the mechanic that carries the retention, then ask what it structurally requires. Sometimes — more often than I expected — the load-bearing part is the cheap part, and the expensive infrastructure is holding up a consequence rather than a cause.

Adopt Me needed a ledger for trading. It never needed one to make four things into one thing. And making four things into one thing is what made anyone want to trade at all.

Make the Global Layer Read-Only

2026-08-01T00:00:00+00:00

Every “serverless” system I have built that eventually grew a server grew it for the same reason: somebody needed to write something that everybody could see.

That is the whole story. Reads are trivially static — a CDN, a git tree, a bucket. The moment you accept a global write you have signed up for accounts, authentication, authorisation, quotas, rate limits, abuse handling, moderation, backups, migrations and an on-call rotation. Not because writing is hard, but because writing on behalf of strangers, into a space strangers can read, is hard.

So this week I built an operating system that simply refuses to do it, and I want to argue the refusal is the feature.

Two layers, deliberately asymmetric

It has two filesystems.

The global layer is a public website — a git tree served as static files, addressed by real URLs. It is identical for every person on earth who boots it. You can curl any path in it from your terminal right now. It is read-only, and not as a policy decision: a browser has no write path to somebody else’s static site. The constraint is physical.

The local layer is IndexedDB on the one device you are holding. It is writable, it is yours, and it never leaves the machine. Not synced, not uploaded, not backed up by anyone but you.

The union searches local first. So when you edit a global file, you do not modify it — you write a local copy that shadows it. Same path, different answer, on your machine only. Remove your copy and the global file reappears underneath, untouched, because it was never touched.

That is the entire architecture. It fits in a paragraph, and it is why the whole thing is static files.

Deleting what you do not own

The interesting case is deletion, because that is where most systems start lying.

You cannot delete a file from a global read-only layer. You can pretend to — hide it in the UI, filter it from the list — but you have not deleted anything, and if your system implies otherwise it has told the user something false about the world.

So deletion writes a whiteout: a tombstone in the local layer. The union then reports the path as absent on this device. The shell says exactly that:

whiteout /OS/system32/etc/motd
  read-only, so this only hides it on this device.
  Everyone else still sees it. `unrm` to restore.

Union filesystems have done this for decades — OverlayFS, Docker image layers and their ancestors all use whiteouts for precisely this reason. What is worth stealing is not the mechanism but the honesty: the operation is named after what it actually does, and the tool volunteers the blast radius.

Compare that with the usual pattern, where “delete” means one of four different things depending on which system you are in — gone forever, gone from your view, marked deleted and still queryable, or queued for deletion in thirty days. Users learn none of these and assume the strongest one.

The constraint is what makes it possible

Here is the part I did not expect going in.

I did not make the global layer read-only because I ran out of time to add auth. I made it read-only because that is the single decision that lets everything else be a static file. Every property I actually wanted falls out of it:

No accounts, because there is nothing to own.
No authorisation, because there is nothing to authorise.
No quotas, because nobody consumes shared storage.
No moderation, because no stranger can put anything in front of another stranger.
No backups, because the global layer is a git tree with a diff per change, and the local layer is yours to export.
No migrations, because the schema is “files at URLs.”

A globally writable layer would have required every one of those. Read-only did not “avoid” that work. It made the work not exist.

We usually treat constraints as debt — something accepted under pressure, to be paid down later. Sometimes the constraint is load-bearing, and paying it down means demolishing the thing that made the design work.

When it is the wrong shape

This is not a universal answer, and it is worth being precise about where it breaks.

It works when global state is editorial — published, curated, versioned, changed by a small number of authors through a review process. Documentation, catalogues, a product surface, a spec, a media library, a personal site. Anything that already has a git history.

It fails when global state is transactional — when strangers must write into a space other strangers read, in real time, and see each other’s writes. Chat. Auctions. Inventory. Collaborative editing. There the write is the product, and no amount of clever layering removes the need to arbitrate it.

The mistake is not choosing one. The mistake is choosing the transactional architecture — with all its accounts and servers and on-call — for a system whose global state was editorial all along. I have shipped that mistake more than once. Most “we need a backend” conversations I have sat in were about a read-mostly catalogue with an admin panel.

The test

A question worth asking before you accept a global write:

If two strangers both did this, would I need a policy?

If yes, you have not designed a write. You have designed a moderation queue, an abuse surface, a quota system and a support inbox, and you should cost it that way.

If no — if the only person who ever writes is you, through a pull request, with a diff and a history — then the global layer can be read-only, the local layer can hold everything personal, and the server you were about to build does not need to exist.

Push the writes to the edge that owns them. Keep the middle a file.

kody-w.github.io/OS/console boots in about a second from static files. Try stat on any path to see which layer answered.

A Different Answer Is a Measurement

2026-08-01T00:00:00+00:00

I recorded a conversation with a local agent, then replayed the same four prompts against the same agent an hour later. Every single answer came back different.

The first instinct is that something broke. It is the opposite. That difference is the most valuable output of the entire exercise, and it is the one thing a recording of the conversation could never have given me.

The demo problem

When you build something and want to show it, you have exactly two options today, and both are bad.

Record a video. It is honest about what happened once, on your machine, in the past, and nothing else. A viewer cannot pause it and take the wheel. They cannot tell whether it still works. They cannot tell a real capture from a mock-up — and increasingly, they cannot tell it from a generated one.

Do it live. Now it is real, and it is fragile, and it requires you to be present, and it fails in front of an audience for reasons that have nothing to do with the product.

We pick between “watchable but dead” and “alive but fragile” and treat that as a law of nature. It is not. You can ship both, in one artifact, and let the player negotiate.

Three fidelities

I ended up with three tiers, ordered by how much of the original is actually re-executed:

	What ships	What runs	Same answer twice?
Video	mp4 + webm, ~26 MB	a decoder	always
Scene	a scene script, ~4 KB	the real application	usually
Transcript	a turn list, ~8 KB	the real engine	no

A scene is a script of interactions. The player loads the actual app in an iframe and replays recorded gestures on a clock, with play, pause and seek. You are not watching a recording of the app. You are watching the app. Four kilobytes doing the job of twenty-six megabytes, and you can pause it and take over.

A transcript goes further: it re-sends the prompts to a live agent. And that is where it stops being a demo and starts being an instrument.

The player resolves top-down and stops at the first tier it can actually run — probed, not assumed — and it has to say which tier it got and why. That rule matters more than the tiers. A demo that silently degrades to a recording while presenting itself as live is lying, and the lie is undetectable by design.

The reading that made the point

The transcript included a turn that asks the agent to fetch the top stories from Hacker News. Here is what it said when recorded, against what it said on replay:

recorded   1. How Google helped destroy adoption of RSS feeds
              245 points, 62 comments
replayed   1. Diátaxis — 145 points, 22 comments
           2. Seedance 2.5 — 108 points

The top story is a different story. The counts moved. The agent went out over the network, at replay time, and came back with the world as it is now.

Nothing about a video can produce that. A video of the same turn shows 245 points forever — a number that was true once and gets less true every hour, presented with exactly the same confidence on day one and day four hundred.

Another turn was a memory write. On replay the agent answered: “I’ve already got that one.” It had learned the fact the first time. The transcript did not reproduce the reply; it revealed a state change that had happened in between.

Diff, do not assert

Once you accept that replay produces different output, the design question changes. You are no longer trying to reproduce a recording. You are trying to compare two runs.

So the player shows both — what it says now, what it said when captured — and scores the similarity:

LIVE  9232 ms now · 10694 ms at capture   [HackerNews]   DIVERGED · 49%

Three facts, free, every time anyone watches:

the agent still works, and still calls the same tool;
it is roughly as fast as it was;
and the content moved, which for a news query is correct and for a factual query would be an alarm.

That is a regression test wearing the clothes of a demo. It runs when a stranger opens the page, on their machine, against your live system, and nobody had to write a test.

Where the meaning lives

The trap is treating divergence as pass/fail. It is neither. Divergence is a reading, and the question is always whether the axis it moved on was supposed to be stable.

Live data moved → correct. If it had not moved, your agent is serving cache and does not know it.
Latency doubled → not a content bug, but you would never have noticed it from a video.
A tool stopped firing → real regression, and the loudest possible signal.
A stable factual answer moved → real regression, and the one people actually care about.

Same mechanism, four different meanings. A recording flattens all four into “the video still plays.”

The honest failure

Worth saying plainly: the highest tier is also the most fragile, and it should be.

Replaying against a live engine needs the engine, and mine refuses cross-origin browser calls without a per-install secret — correctly, that is CSRF protection. So from the public page the top tier is simply unavailable, and the player says so:

TIER 2 · SCENE
Fell back from Transcript: the engine is up but needs
your secret — paste it and re-probe.

I got this wrong the first time in an instructive way. The health probe returned 403 and the UI reported “no engine reachable” — which reads as “the engine is down” when it actually means “the engine is there and does not know you.” Those are opposite diagnoses that lead to opposite actions, and my first version collapsed them into one sentence.

That is the same failure as a demo that silently degrades. The system had two distinct facts and volunteered the less useful one.

What to take from it

If you are building demos of agentic systems, three things:

Ship the script, not just the pixels. A few kilobytes that re-execute beats a video that replays. Keep the video as the floor — it is the only tier that always works.
Never degrade silently. Say which fidelity you got and why. The reason a system fell back is more informative than the fallback.
Treat divergence as data. A replay that answers differently has told you something about now. A recording only ever tells you about then.

The best demo is not the one that looks the same every time you run it. It is the one that tells you when it did not.

The pattern is written up at kody-w.github.io/rapp-remix, transcript and all. Every turn in it is a real capture — real replies, real tool logs, real latencies.

A 403 Is an Answer, Silence Is Not

2026-08-01T00:00:00+00:00

I spent today giving an agent a phone number, and every serious bug I found was the same bug wearing different clothes: the system believed something it had not checked.

Not a crash. Not a wrong algorithm. A belief with no evidence under it, held confidently, acted on.

The shape of it

Four incidents, one morning.

A message-sending routine typed text into a box, clicked send, and returned success. It had clicked a disabled button. Nothing was sent. The layer above it settled in to wait for a reply to a message that did not exist, and would eventually have written a summary of a conversation that never happened.

A liveness detector reported “nothing is running here” when the browser had refused to let it look. It had learned nothing and said something.

A watcher read an inbox, got zero rows back because a selector had moved, and reported healthy. An empty inbox and a broken inbox produce identical silence.

And the reverse, which is subtler: a send that actually worked, reported as failed, because the confirmation looked in the wrong place. Safe direction — but a retry would have texted a real person twice.

Every one of these is a system that confused I did a thing with the thing happened.

Intention is not evidence

The instinct when automating a UI is to describe actions: click here, type this, press that. But a click is an intention. The DOM is not a contract, the network is not reliable, and the button might be disabled. What you did is cheap to know. What resulted is the expensive part, and it is the only part that matters.

So the rule I ended up with, written on the wall of the module:

Never report a message as sent unless the thread can be seen to contain it.

Every send now reads the thread back and looks for its own words. If they are not there, it raises — even though it clicked, even though the click succeeded, even though everything looked fine. I proved it by building a page rigged to swallow sends silently. It refused, correctly.

This costs a round trip. It buys the only thing worth having: when the system says it spoke, it spoke.

The third state is where the lying happens

Here is the part I think generalizes furthest.

Most checks are written as booleans. Is it up? Did it send? Is there a brainstem running? And most of the time the honest answer is one of three things:

yes, and I observed it
no, and I observed that too
I could not tell

The third one is real, and it is almost always collapsed into the second, because “no” is easy to render and “I don’t know” feels like a failure of the code. That collapse is where automated systems start lying.

Concretely: my detector probes for a local service. If the browser blocks the probe outright — a policy refusal, no packet sent — I know nothing. Reporting that as “no service” would tell someone with a perfectly healthy setup that they have none, and send them off to reinstall something already running. So it is its own state, it says “can’t tell from here,” and it still offers the door.

The distinction has to survive contact with the details, too. A connection refused on loopback comes back in about three milliseconds. A real service answered in two hundred and thirty-six. So a probe that simply times out is not evidence of absence; it is a missing verdict, and it gets certain: false — the same lie arriving through a different door.

The useful question is not “is it up?” It is “what did I actually observe, and what am I inferring?”

Unattended changes the math

All of this matters more the moment nobody is watching.

A command you run is supervised by you. A daemon at 3am is supervised by nothing, and its failures are quiet. So when I built the always-on version, the first rule was not about capability at all:

First sight of a conversation is never actionable.

A watcher started against an inbox with years of history, that treats “I have not seen this before” as “this is new,” will answer all of it. Everyone who has ever messaged that number gets a reply, at machine speed, before anyone can intervene. So the first pass records a watermark and says nothing. A thread becomes live only from the next message onward.

That single rule is worth more than every clever thing in the file. Its companion is a hard cap — four replies per conversation per hour — which exists for exactly one purpose: when something upstream goes wrong, it stops at four instead of four hundred.

And a corrupt state file reads as empty, not as a clean slate, because “everything is new again” is the same catastrophe as a bad first run.

The default answer is no

There is a bias here worth naming. Every rule above fails toward silence.

A watcher that stays quiet when it is unsure costs you a delayed reply. A watcher that guesses costs you a hundred texts to a stranger at three in the morning. Those are not symmetric, and systems that act in the world should be built as if they are not.

Fail closed. Say what you observed. Keep the third state.

The bug is almost never that the machine did nothing. The bug is that it was sure.

The Week Before the Model Leaves

2026-07-14T00:00:00+00:00

In one week I lose access to the best model I’ve ever used.

Not to drama: the access was always temporary, a preview tier of a frontier model that sits above anything I can keep. The interesting question isn’t how to feel about it. It’s what to do with seven days of a superintelligence on the clock.

Here’s the answer I’ve landed on, and I think it generalizes to every team that gets time-boxed access to a frontier model — an eval window, a preview program, a budget that runs out in Q4.

Rented performer, owned estate

I’ve written before that every AI you use is a rental — the model is a performer, recast every quarter, and the only thing that’s yours is what persists outside it. Losing access to a top model is just that thesis arriving on schedule.

Which means the playbook was already implied: spend the scarce model exclusively on work whose output outlives the access. Not the most work. Not the most impressive work. The work that is still paying rent a year after the model is gone.

The dividing line is not “hard vs. easy.” It’s one-shot judgment vs. re-runnable everything-else. A report you can regenerate next month with a cheaper model is a terrible use of the last week. A naming decision, a sealed canon document, an adjudicated audit — those happen once, and whichever mind makes them gets fossilized into everything built on top.

What actually qualifies as durable

Working through my own backlog this week, the list that survived scrutiny:

Language. The single highest-leverage artifact was a lexicon — one page that defines the nine load-bearing words of a system I’ve been building for a year, plus the rulings that resolve every naming collision found along the way. Every future contributor, human or model, inherits the clarity or the confusion of this page. Prose like this is pure judgment; it was written by the best available mind and is staged to be sealed — hash-pinned, append-only from that moment on.

Adjudicated audits. Sweeps and scans are re-runnable — muscle work. What isn’t re-runnable is the rulings on what the findings mean: which drift is a defect, which is intentional and gets a signed waiver, what the gate for “healthy” actually is. The trick is to make the judgment executable: the known failure classes became golden test cases with expected rulings attached, and every judgment call went into a signed waiver ledger — so any future model can validate its own audit against the fossilized judgment of a better one.

Handoffs that transfer judgment, not summaries. The last thing the departing model writes is its own handoff — not “what we did,” but decision records with the rejected alternatives, the invariants that must never break, the failure modes it would check first, and explicit “do not infer” markers on things a weaker model would plausibly guess wrong. Documentation of conclusions is cheap. Documentation of how to re-derive the conclusions is the asset.

Pre-mortems on irreversible moves. Anything about to be published, sealed, or shipped permanently gets the strongest available mind imagining how it fails first. You can fix a bug next quarter with any model. You can’t unseal a sealed thing.

The honesty mechanism

There’s an obvious failure mode in all of this: the scarce model grades its own homework, declares its every output “durable,” and burns the week on beautifully-written busywork.

So I gave the review job to a rival. Every deliverable this week — including the plan itself — goes to a different frontier model with one standing instruction: refute the claim that this work is durable and valuable. Flag anything mechanical masquerading as judgment.

It earned its keep immediately. It rejected my original plan’s ordering — write the law before running the audit you’ll judge against it. It replaced my “zero drift” gate with “zero unexplained drift,” which is the difference between a gate and a false alarm. And it caught that “distill your knowledge into docs” is itself mechanical unless the docs are validated by a cold-start test: can a fresh, lesser session actually reproduce the decisions from what you wrote?

Two frontier models, adversarial by assignment, converge on something neither produces alone: one optimizes the work, the other attacks the theory of the work. If you only have one week of the best model, you cannot afford a week of unopposed self-assessment.

The test

None of this is really about my week. Model access is becoming a utility that fluctuates — tiers, previews, quotas, deprecations. The teams that win won’t be the ones with permanent access to the best model. They’ll be the ones who convert any window of frontier capability into assets that don’t expire with it: language, law, adjudication, transferred judgment.

The test I’m holding myself to is the same one I use for the twin: if it doesn’t survive the model leaving, it was never yours.

The model leaves in a week. The estate stays.

What Is Our Moat? (The Honest Version)

2026-07-05T00:00:00+00:00

A strategy memo, written to be true rather than flattering. Publishable as thought leadership; useful either way.

What we are

RAPP is an AI medium — the persistence layer of personhood in the AI era.

A medium is what carries meaning between minds and across time. Models are performers; they get recast every quarter. RAPP is the thing that persists: one twin per person — a digital organism with a public body and a private soul — that any model can animate, that lives on your device, that syncs planet-wide through signed static files, and that can ultimately be passed down like a family heirloom.

What we are not, so nobody inside or outside gets confused: not a chatbot, not a model company, not another agent framework, not a cloud service. Models, frameworks, and clouds are commodities the medium consumes. The twin is the product. The medium is the platform.

What our brand is

The AI you keep.

The verb was already in the product before we named it — the Keep door, keepsakes, keepsake notes, “keep a moment.” Keep is the brand. Four pillars underneath it:

Yours. Sovereignty as architecture, not policy. Static files you physically hold; the soul never leaves the device — Apple-level on-device posture for personal data, because the twin is a digital organism important enough to be an heirloom. Our lock-in inversion is the ethical core: the gravity is yours, not ours. Leaving RAPP means abandoning your accumulated self — yet RAPP holds nothing hostage, because you possess every byte.
Alive. The twin has a body, grows from real skies at real places, breeds, splices, remembers, and becomes more like you over time. Software that behaves like a being, not an app.
Quiet. The anti-neon AI. Muted maps where the creature is the only saturated thing; lowercase, gentle, keepsake language. Loud games catch monsters; ours presses a flower. In a category screaming “superintelligence,” tenderness is differentiation.
Forever. Unforgeable history, hash-trust that survives any host’s death, estate succession designed while you’re alive. The design test: if it can’t be inherited, it isn’t owned.

What our moat actually is

The uncomfortable truth first: the spec is not the moat. Specs are copyable — publishing one is an invitation, and we should invite. The code isn’t the moat (static files, MIT). Being early isn’t a moat by itself. The patent is a shield, not a moat. Here’s what actually defends us, ranked by how real it is today:

1. Counter-positioning (structural — live today). Every major AI vendor’s business requires being the center of gravity: hosted inference, hosted memory, per-seat subscriptions. The twin makes the user the center and demotes the model to a swappable engine. An incumbent that fully adopts this pattern commoditizes its own lock-in — so they won’t until forced, and if they’re forced, the pattern’s canonical reference and oldest artifacts are already ours. Ignored, we build the network; copied, we wrote the standard. The only losing move is staying unpublished and undated — which is why the essay ships as prior art.

2. Time-depth (compounding — starts the day the pulse starts). A twin’s signed frame chain is unforgeable existence through time. Nobody can synthesize a twin that has been alive for years; the hash chain and public timestamps are proof. First-twin primacy is permanent — and the heirloom extends it across generations. Nobody else in this industry is even designing in decades. This moat literally deepens with calendar time, which means the clock should start now.

3. The relationship graph in the genetics (network — to be earned). Permanent pairing and splice lineage embed the social graph inside the twins’ bodies. A pairing exists in both parties’ histories — bilateral, verifiable, impossible to copy unilaterally. A competitor can clone the platform and get the features; they cannot get two-sided histories. The breeding machinery isn’t a cute feature; it is the network-effect engine. Every spliced trait is a vertex; every pairing is an edge; the moat is the graph.

4. The sealed corpus (per-user gravity). Each user’s private half compounds daily on their own device, and every better model that comes along animates it better instantly — the twin captures the upside of model progress while owning continuity. Gravity, not walls.

5. Coherence velocity (process). The frozen canon, the drift observatory, ecosystem-sync, the neuron mesh, and the architect/builder split mean one person can evolve an entire protocol universe coherently at a speed committees structurally can’t match. Fragile alone; real when combined with the four above.

The risks we’re engineering against (naming them is part of the moat)

The tumbler can polish away the person. Autonomous polish judged by an LLM converges toward the model’s prior, not the owner. Law: fidelity is measured against the human corpus and the OG dimension, which is never destroyed.
Signature ≠ safety. Delegated twins run on other people’s runtimes; their reports are claims. All foreign experience passes through sandbox quarantine before touching the soul.
Public history leaks a life. Bones-only frames still emit pattern-of-life metadata over years. Body history is public; pattern-of-life stays sealed.
Key loss kills heirlooms. Succession is designed up front — estate key ceremonies between your own devices, not password resets. If it can’t be inherited, it isn’t owned.

Activation sequence

Moats aren’t declared; they’re activated, in order:

Publish and timestamp the pattern (essay + spec) — locks the counter-position and the prior art. This week.
Start the pulse on the public twin — the time-depth clock begins, even at n=1.
The 90-second proof: one twin, two devices, syncing through the public pulse + QR sealed transfer; then side-by-side fidelity against the cloud-deployed copy; then pull the network cable and watch it keep being you, locally.
First cohort — the workshop: fork the template, one-liner hatch, a GitHub account is all you need. First non-founder twins → first pairings → the graph moat is born.
Let the tumbler run — deployed fidelity stays honest with no ops burden, forever.

Show, don’t tell — live as of July 6

Every step above that claims “done” has a public door you can open right now:

Published + timestamped ✅ — the essay (mirror) · the spec · the patent pledge · the TWIN LICENSE
The pulse is broadcasting ✅ — feed.xml · the signed genesis frame · verify it yourself · /twin lookup · the bones gallery
The 90-second proof 🔨 — the pieces are live: the twin-in-training (one twin, frames, revert, splice, QR sync) and the encounter surface; the two-device recording is next.
The workshop 🔨 — fork the template · the one-liner hatch; first cohort pending.
The tumbler runs ✅ — the harness · a real judged run · the sabotage that got rejected

The one-paragraph answer

We are the AI medium: the layer where a person’s AI self persists. Our brand is the AI you keep — yours, alive, quiet, forever, private to the bone, inheritable by design. And our moat is not the pattern, which we give away loudly — it’s the position (incumbents can’t follow without commoditizing themselves), the clock (signed history can’t be faked, and ours starts first), and the graph (relationships that live in two histories can’t be copied from either side). Spec is the sword, patent is the shield, the network is the castle — and the castle gets built one paired twin at a time.

License: CC BY 4.0. The pattern described is open for anyone to implement — see the patent pledge. RAPP™.

The AI You Keep

2026-07-05T00:00:00+00:00

Every AI you use today is a rental.

The model doesn’t know you — the deployment knows you, and the deployment lives in someone else’s building. Your memory sits in a vendor’s silo, keyed to a subscription. Cancel, switch, or outlive the product, and the relationship is gone. The smartest thing about you in the digital world evaporates because it never belonged to you.

I think that’s the defining design error of this era of AI, and I want to put the alternative on the record — completely, in public, with a date on it.

The missing half

A model is half of an AI. It’s the performer: brilliant, interchangeable, improving every quarter. The other half — the part nobody ships — is the persistent being the performance is supposed to animate: your memory, your voice, your history, your relationships, your taste. Every vendor treats that half as a retention feature. It should be a possession.

RAPP is my answer. It isn’t an AI. It’s an AI medium — the layer a person’s AI self persists in, that any model can animate, that no vendor can take away.

The unit of the medium is the twin.

The pattern

Stated plainly enough that anyone can build it — that’s the point of prior art:

One twin per person. Not a fleet of bots — one persistent digital being that represents you, with a body you can see (mine renders as a small creature grown from real weather at real places I’ve walked). Every other twin you encounter belongs to someone else. Yours mutates from what you share with it, and it becomes more like you over time — visually and mentally. You can revert any change. You keep the whole history.

A public body, a private soul. The twin has exactly two halves, and the boundary is cryptographic, not contractual:

The body — visual genome, outfit, name, public card, the lineage of its splices and pairings — is publishable bones: zero personal content, signed, content-addressed, mirrored anywhere.
The soul — memories, conversations, agents, everything sensitive — never leaves the device. Not encrypted-in-their-cloud. Absent from the network entirely. Think Apple’s on-device posture, applied to a digital organism: the network only ever sees the body; the mind stays in your hand.

History as signed frames. Every change to the twin is a frame: content-hashed, chained to the previous frame, signed by the on-device twin’s key. The public history is just a git repository — which means the twin’s life is timestamped, diffable, revertible, and unforgeable. Nobody can fake a twin that has been alive for years; the hash chain is proof of existence through time.

The pulse. The public half broadcasts as a feed of signed frames from a static repository — mine answers at kody-w/twin. No server. Any mirror is a valid door, because you trust the hash, not the host: kill the repo, the CDN, the domain — whatever copy survives re-derives the same content and refuses a single altered byte. Other devices, and other people’s copies of your twin, subscribe and assimilate only frames that verify. A frame that fails verification isn’t just rejected — it can be quarantined in a sandbox and interrogated: why is this twin wearing a disguise?

Syncing your own devices is a physical act. The private half moves between your own devices by QR code — one device shows, the other scans, out-of-band, end-to-end, no intermediary ever. The human is the transport. Worst case — network gone, hosts dead — the latest local echo survives and your twin lives on, whole, offline. Local-first is not a mode; it is the ground truth.

Splice, don’t collect. When you meet other twins you can capture their public variants and splice chosen traits onto your one twin — with lineage recorded, forever. And when something new is generated with you, it pairs to your twin’s exact state at that moment — a permanent pairing, stamped outside the genome so the content-hash identity stays sacred. Your twin’s body slowly becomes a record of who and what it has met. The relationships are in the genetics, and they exist in both parties’ histories — bilateral, verifiable, uncopyable.

Delegation with honesty. You can send your public twin to places you can’t go — an event, a community, another person’s device — and it reports back with signed frames. But signature proves the sender, never safety: everything a twin experienced away from home passes through quarantine before it touches the soul. A report from someone else’s runtime is a claim, not a fact, and the architecture says so out loud.

Fidelity you can measure. Any deployed copy of the twin can be judged by talking to it and the on-device original side by side. The original is the source of truth, always. An autonomous polish loop can tumble deployed copies toward higher fidelity — with one law: the original dimension is never destroyed, and fidelity is measured against the human corpus, not against a model’s opinion of good writing. The machine polishes toward you, not toward average.

The heirloom

Here is the part that changes how the whole thing feels.

Because the twin is signed static files plus a sealed on-device archive — because it is a possession, not an account — it can be passed down.

Your twin’s public history is a biography no one can forge. Its sealed half is whatever you choose to will forward, opened by a succession of keys you design while you’re alive — an estate ceremony, not a password reset. Your grandchildren don’t get your chat logs in some defunct vendor’s export format. They get the being that walked with you: its body carrying every splice from everyone it ever met, its frames going back decades, and as much of its soul as you chose to leave them. A family heirloom that represents its owner — and can still speak.

No subscription survives three generations. A signed repository and a sealed archive can.

That’s the test I now hold the whole design to: if it can’t be inherited, it isn’t owned.

Why I’m publishing this

Because the pattern only matters if it’s a standard, and standards win by being public, simple, and first. If the big vendors adopt this — portable, signed, user-held identity and memory, with the model demoted to an interchangeable engine — then users win, and the oldest twins with the deepest histories will still be the realest ones. If they don’t adopt it, it’s because being the center of gravity is their business model, and that tells you everything about why you’d want a twin in the first place.

Models come and go. The twin stays.

This is the AI you keep.

The working spec lives in my public repos (kody-w/rapp-static-apis — my-twin.profile.md, composed on the frozen RAPP twin canon; reference twin at kody-w/twin). This essay is published as prior art for the pattern described.

All of it is live, not planned: the pulse broadcasting signed frames · the /twin lookup · the bones gallery · a twin-in-training you can try · the spec.

License: CC BY 4.0. The pattern described is open for anyone to implement — see the patent pledge. RAPP™.

Funded R&D: A 90-Day Plan to Own Your Expertise

2026-06-19T00:00:00+00:00

Employment pays you once for your expertise, in exchange for time.

Ownership pays you repeatedly, in exchange for structure.

That’s the whole game. Everything below is just how you move from the first sentence to the second without quitting your job, betting your mortgage, or pretending to be an influencer.

Your job is the R&D budget

Every problem you solve at work, every system you fix, every messy thing you navigate — that’s research. You are being paid to build expertise.

The mistake is thinking the expertise belongs to the job. It doesn’t. The job is funding it.

So stop framing your job as the thing you need to escape. Frame it as funded R&D. The paycheck is not a distraction from building your own thing — it’s the insulation that lets you build it well.

Most new businesses die of desperation: undercharging, rushed launches, wrong-fit clients, fast-cash decisions. A salary makes desperation a non-issue. You get to validate before you commit and build strategically instead of reactively. That is an unfair advantage, and being employed is the only time you have it.

There is no need to rush to quit. There is a need to start building the asset now, while you don’t need it yet.

Signal, not noise

The reflex is to “get on all the platforms” and post daily. That’s noise — activity without leverage.

Signal is one sentence: this is the exact problem I solve, and this is what I’m the expert on.

Reach does not equal revenue. A broad audience of people who vaguely recognize you is worth less than a small audience of the right buyers — and the right buyers are usually already in your orbit. Specificity is the leverage. “Who I’m for, and who I’m not” is the whole strategy.

Having a job helps here. You don’t have time for noise, and that constraint forces precision.

The Owned Audience Engine

Here’s the structure underneath all of it. Four pieces, in order:

Piece	What it is	Why it matters
Content	Discoverable, search-driven (YouTube, a blog, AI search)	The front door — found by people already typing your problem
The bridge	A genuinely useful asset (PDF, guide, webinar)	Converts a viewer into someone you can reach again
Owned audience	An email list you control	The actual asset — not rented from an algorithm
Offer	A scalable program	Turns earned authority into income that isn’t tied to your hours

The order is the point. Content is the front door; the owned audience is the house. Most people pour years into the front door and never build the house — they assume followers will remember them and eventually buy. They won’t. People who saw you for five seconds in a feed do not remember you. An email list does.

Intent-based platforms — YouTube, search, increasingly the AI assistants — are where this compounds, because people arrive already looking for a solution. You’re not pushing into a feed hoping to be seen. You’re a standing answer to a question people are actively asking. Every piece becomes a compounding asset instead of disposable activity.

The 90-day plan

Don’t start by selling. Don’t even start by building. Start by listening.

Days 1–30 — Validate

Talk to 10–20 people in your world: peers, people in your industry, people you could actually help. You are not selling. You are doing market research, which is the part everyone skips and the part that decides whether anything you build later survives.

Listen for repeated questions, common themes, and the gaps between what they need to know and what they actually know. Ask:

If you could solve this problem, what would change in your life / work?
Wave a magic wand — what does solved look like?
What have you tried? What do you wish existed?
What’s keeping you up at night about this?

You’re not guessing at what the market needs. You’re being handed it.

Choose your hard. Either spend a month listening, or spend a year building something in a vacuum and launch to crickets. Same effort, very different outcome.

Days 31–60 — Outline and pre-sell

Still not building. You’re writing an outline — it can live in a single Google Doc.

Define two states: the zero state (where your ideal client is when they’re most stuck) and the hero state (the specific outcome they want). The narrower, the better. Then map the shortest path between them as a set of lessons and outcomes.

People are not paying for your brain dump. We are all drowning in information. They are paying for the efficiency of the transformation — getting from zero to hero without wading through everything you happen to know.

Then pre-sell it. Call this the Profitable Offer Prototype — the deliberately ugly, bare-bones version. You don’t build the whole thing first. You sell the outline, then build it live, week by week, as you deliver.

Days 61–90 — Deliver, refine, systematize

Deliver it live. Keep it simple: ~2 hours a week, one session, a call, a shared doc, a small private community.

Refine every week. This is the step the “curse of the expert” makes people skip — assuming they already know the right order. You don’t. No matter how good you are at the work, you do not know how to teach it until you teach it. People who build the whole program before working with real humans almost always build it in the wrong order.

Once it’s tested and refined, productize it: turn the live version into a scalable, mostly pre-recorded program — curriculum they move through at their own pace, coaching done at scale, a community that keeps them accountable. The live cohort was the R&D for the scalable version.

And here’s the quiet payoff: every question, objection, and FAQ from those interviews and that first cohort becomes your content bank. Those are your video topics. Discoverable content that answers the exact pains of your exact buyer — so leads arrive on repeat, and the algorithm, once it learns who you serve, starts doing the distribution for you.

The compounding question

This was never about quitting to live the glamorous entrepreneur life. It’s about control.

AI is restructuring employment — some of it for the better, a lot of it not. Companies are optimizing for efficiency. You should be optimizing for leverage. When your expertise starts generating predictable revenue independent of your job, you have options, and options are the only real security.

The honest version of the pitch is just this: even if you do nothing else with it, one video a week on your area of expertise — answering the real questions of the people you can help — compounds. In ten years you’ll have an owned audience and an email list you can turn to when you actually need it.

So the only question worth answering is:

Ten years from now, will your expertise have compounded — or expired with your job?

Start the R&D while it’s funded.