kodyw.com

Kody Wildfeuer's blog

kodyw.com

Tag: rapp

When the Power Comes Back, the AI Estate Should Too

By

On September 6, 2026

In Technology

The power went out overnight, and it took down my whole home AI setup — several computers, each one in the middle of its own task.

Flipping the power back on didn’t actually fix anything. The machines came back, but I had no idea what each one had been doing, how far it had gotten, or what was safe to pick back up. A computer that turns back on isn’t the same as work that picks back up where it left off.

That’s the real problem with AI “helpers” running unattended: when something interrupts them, you can’t just reboot and hope. You need to know what each one was working on, what it had already finished, and what it’s safe to resume — because blindly repeating a step an AI already took (like sending a message or submitting a request) can cause a second problem instead of fixing the first one.

Think of it like coming home after a blackout

Imagine your dishwasher, DVR, and thermostat all lost power at once. The power comes back, but none of them remember what they were doing — the dishwasher doesn’t know if it finished the rinse cycle, the DVR doesn’t know if it recorded your show, and nobody wants to guess.

Now imagine dozens of AI assistants in that same spot at once, each one mid-task. That’s what I woke up to. The fix isn’t “turn it back on.” The fix is giving every task a paper trail — a record of what it was doing, what it had completed, and what it still needed — so recovery means picking up exactly where things left off, not guessing.

What “remembering” actually requires

To recover safely, you need answers to a few plain questions for every task in flight:

  • Which AI assistant was doing this, and as part of what job?
  • What had it actually finished, versus what it merely intended to do?
  • What survived the outage, and what needs to be checked before resuming?

That’s it. It’s less about fancier AI and more about good bookkeeping — a clear, trustworthy record that outlives the outage.

Why “just resume” is risky

If an assistant might have already sent a message or kicked off an action right before the power died, blindly re-running that step isn’t recovery — it’s a second, possibly duplicate action. The safe version of “pick up where you left off” always double-checks whether the last step actually happened before deciding what to do next.

This is the idea behind something I’m building called RAPP Disaster Recovery: a way to give an entire AI household a single, trustworthy view of what survived, what’s uncertain, and what’s safe to resume. It’s not finished — full automatic recovery across every device isn’t something I can promise yet — but it’s the direction I’m building toward.

The takeaway

The most useful thing an AI system can have isn’t more data or a longer memory. It’s a clear, honest record of what it was doing and what actually happened — so that when the power comes back, the work can come back with it.

If the idea of an AI helper that keeps working reliably on its own appeals to you, The Personless Harness goes deeper on what that actually looks like day to day.

This post describes an idea I’m actively building, not a finished product. If you want the deeper technical version of this, it lives on my GitHub.

The Personless Harness: Brainstem + Copilot

By

On August 4, 2026

In Technology

In 1895 you didn’t buy a car. You bought a horseless carriage — the new machine named for the animal it removed. The name is the whole lesson: the carriage didn’t change. The wheels, the seats, the cab — all still there. What changed was what pulled it. The horse went out, the engine went in, and the same carriage could suddenly run at a pace no stable could feed.

Here’s the same swap, happening right now, in software.

Copilot is the carriage. It’s the vehicle everyone already has — the chat window, the buttons, the place work actually happens. A genuinely good carriage.

You are the horse. Today, almost everything an AI assistant does, it does because a person is pulling: typing the prompt, clicking the button, checking the output, deciding what happens next, then pulling again. That works — beautifully, at the pace of one tired human — and it stops the moment that human needs to sleep, eat, or go to a meeting.

The Brainstem is the engine. Think of it as a second, tireless version of you: it knows your tools, remembers how you like things done, and can keep working after you’ve clocked out. It isn’t a smarter chat window — it’s the thing that can sit where you sit and keep going. Same carriage, different thing doing the pulling.

What the swap looks like in practice

This isn’t really a story about software testing. It’s a story about a new way of working — testing just happened to be the first job the engine took from me, because testing is the purest form of “a human clicks through an app after every change to see what broke.”

I had just finished a feature I believed was done. Instead of opening the app myself, clicking the toggle, and watching what happened, I handed the job to an AI agent with a real browser and a checklist, and went to work on something else.

It came back with five problems. One was serious: the page was loading with zero working code behind it, so the whole feature was just a picture of itself. Another: a switch that could be turned on but never back off. A third: a checkbox that had quietly grown too wide and shoved its own label onto three lines. None of that showed up in my usual automated tests, because it all lived in the gap between “the code looks right” and “the thing actually works when a hand touches it.” Until that day, finding it had always meant me sitting there clicking around.

I fixed the five problems, sent the AI agent back in, and it came back clean: thirty-three checks, all passing, no human involved. My status update changed from “try it and tell me what breaks” to “it’s done, and here’s the proof.”

What makes an AI helper trustworthy at this job

A few things separate a helper you can actually trust from one that just looks impressive in a demo:

  1. It uses the real thing. Real clicks, real pop-ups, real downloads — not a shortcut that skips the part a real person would experience.
  2. It expects the annoying stuff. An unexpected confirmation pop-up is a failure to catch, not something to shrug off. And layout gets measured precisely, not eyeballed.
  3. It checks for things that should be missing, too. A feature that’s supposed to stay hidden until turned on, a panel that’s supposed to disappear — humans almost never double-check that something properly vanished. An AI helper can, every time.
  4. It never fakes success. If it couldn’t actually run the check, it says so loudly. A “looks fine” that never really ran is worse than an honest “this failed.”

How much faster, really?

To put a number on it: that 33-check run, done by hand by someone who knows the app well, takes roughly twenty minutes of full attention — and you have to redo the whole pass after every fix. The AI agent finished the same 33 checks in about 19 seconds. That’s roughly sixty times faster on the stopwatch. But the bigger difference is what it costs you: twenty minutes of a person’s full focus, versus zero. I ran it four times in one evening without noticing the cost at all.

The carriage stays; the horse retires

Notice what this swap does not ask of you. You don’t throw out the tools you already use. Copilot, the app, everything you’ve already built — all of it stays. That’s why the horseless carriage caught on so fast: it didn’t ask the world to reinvent the wheel, just to stop feeding the horse.

And notice where the person goes. The engine didn’t remove people from travel — it moved them from pulling to steering. This doesn’t remove you from the work; it moves you to the seat where you decide where things go and read the results. You stop being the horse. You were never at your best there anyway.

Curious how far this can go? The Buzzsaw pushes the same idea further — instead of one AI helper checking the work, I used eight of them, arguing with each other, to catch things a single reviewer never would.

For a while, this will feel like a strange new way to work. Then, like the horseless carriage before it, it’ll just be how work is done — and the idea that a person once had to manually click through every check will sound as old-fashioned as keeping a horse for your commute.

The Ark Pattern

By

On August 3, 2026

In Technology

Skills drift.

You teach an AI assistant how to do something, it works, you move on. Six months later, that same “skill” gives you a different answer — because someone edited a copy, or a dependency shifted underneath it, or four different people each tweaked their own version and never told each other. The name of the skill stays the same. What it actually does does not.

That’s not hypothetical. I watched one bad instruction produce five separate wrong answers, across different tools and different AI agents, before anyone realized it was the same mistake wearing different clothes each time. Nothing announced it. Every copy looked fine on its own.

The uncomfortable part: if AI assistants everywhere start relying on shared “skills” like this, quiet drift is the real risk — not some sci-fi AI takeover, just a slow loss of agreement about what a given instruction actually does, with no easy way to check.

So I wanted a way to catch it. A backup that works even if everything around it gets messy.

The idea

My approach treats a capability as one portable file with a clear job — drop it in a folder, it runs, no setup required.

This pattern goes one step further: it puts the working code inside the plain-English instructions themselves, so the document explaining what a skill does is also, literally, the thing that does it. It reads like a normal explanation to a person, and it can also run directly as working code. There’s no second, separate copy sitting somewhere else that could quietly drift out of sync — because there’s only one copy, period.

The real benefit isn’t for me. It’s that anyone can pick up that one file, with no special setup on their end, and get the exact same behavior I do.

That’s the claim. A claim is worth nothing until you test it, so I tested it.

Putting it to the test

I built the same capability two ways: the normal way (spread across several files) and the “one file” way described above. Then I ran both versions dozens of times, side by side, and compared the results byte for byte.

Every single time, both versions produced identical output. Not “close enough” — identical.

Then I deliberately broke it: I edited the normal, spread-out version in place, the way an innocent well-meaning edit usually happens. Its output changed, as expected. The single-file version’s output did not change at all — and, importantly, the mismatch between the two was easy to spot immediately, instead of surfacing months later when two AI agents quietly disagree about what a rule says.

That’s the whole value, proven rather than assumed: one copy stayed trustworthy, and when the other one drifted, it was obvious right away.

What it costs

Honestly, some convenience. A single file can get long, and you lose the ability to test small pieces of it separately. Mine landed at a comfortable size — ten times longer would start to hurt.

I also hit a real bug while building this, worth naming because it’s exactly the kind of thing that quietly erodes trust: embedding code inside a plain-text document accidentally mangled a couple of special characters, so two of five commands printed a broken symbol instead of a proper line break. The other three were fine, because they happened to be built slightly differently.

A quick spot-check of just one command would have missed it and shipped it broken. Only checking every single case caught it — which is the same lesson every time: the check itself can be wrong too, and nobody double-checks the checker.

The pattern, stated plainly

Ship a capability as one self-contained, readable document. If the surrounding ecosystem holds up over time, you’ve lost nothing. If it drifts, you have one clearly labeled, trustworthy copy that makes the drift obvious instead of invisible.

It’s a cheap insurance policy against a quiet, slow-moving risk — and so far, it’s the best way I’ve found to share something’s strengths with people who have no interest in adopting my whole system, just the one useful piece.

It’s the same lesson at the heart of The Buzzsaw: the thing meant to keep you honest can quietly become the thing you stop questioning.

Update: it holds up beyond one example

One capability working this way could be a fluke. So I automated the conversion process — turning a normal, spread-out capability into the “one file” version automatically, and refusing to finish if even a single byte comes out different — and tried it on two more capabilities.

All three matched perfectly, every time, without needing anyone to hand-check the conversion. That the conversion itself is automatic matters more than any individual result — if a person had to convert each one by hand, that manual step would become a brand-new place for drift to sneak back in, which defeats the whole point.

One test along the way even reported a false alarm — the two versions looked “different” only because of an unrelated quirk in how I’d named the test files, not because the actual code differed. Worth mentioning honestly: that’s now the eighth time in this stretch of work that a reported failure turned out to be a flaw in the test itself, not the thing being tested. I’ve started treating that as the normal rate, not a fluke — which is exactly why checking your checks matters as much as checking your code.

Every number in this post comes from a script anyone could re-run, and it fails loudly if the equivalence claim doesn’t hold. If it had failed, this post would say so.

What Is Our Moat?

By

On July 6, 2026

In Uncategorized

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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:

  1. Publish and timestamp the pattern (essay + spec) — locks the counter-position and the prior art. This week.
  2. Start the pulse on the public twin — the time-depth clock begins, even at n=1.
  3. 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.
  4. 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.
  5. 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:

  1. Published + timestamped ✅ — the essay · the spec · the patent pledge · the TWIN LICENSE
  2. The pulse is broadcasting ✅ — feed.xml · the signed genesis frame · verify it yourself · /twin lookup · the bones gallery
  3. The 90-second proof 🔨 — pieces live: the twin-in-training · the encounter surface; two-device recording next.
  4. The workshop 🔨 — fork the template · the one-liner hatch.
  5. 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

By

On July 6, 2026

In Uncategorized

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™.

Powered by WordPress & Theme by Anders Norén