The Ark Pattern

On August 3, 2026

The Ark Pattern

Skills drift.

You write a capability, it works, you ship it. Six months later the same nominal skill produces a different answer — because the runtime moved, or someone edited a copy, or a dependency shifted underneath it, or four teams each forked it and none of them told the others. The name still matches. The behavior does not.

That is skill drift, and it is not hypothetical. In one session this week I watched a single bad idiom produce five separate false results across two tools and three agents before anyone noticed it was the same mistake wearing different clothes. Nothing announced it. Every copy looked fine in isolation.

The uncomfortable part: if the whole industry standardizes on skills, drift is the systemic risk. Not model collapse. Not capability overhang. Just a slow, quiet loss of agreement about what a given capability actually does, with no way to check.

So I want a backup. Something that survives even if the skill ecosystem rots.

The Ark

RAPP’s core idea is that a capability should be one portable file with a typed contract and a single entry point. Drop agent.py into a folder, it runs. No registration, no manifest, no restart.

The Ark pattern extends that one step: inline the agent into the SKILL.md itself, so the document that explains the capability also is the capability.

One file. It reads as prose to a human. It self-extracts to running code for a machine. It carries its own implementation, so it cannot silently diverge from its own documentation — there is no second copy to diverge from.

The point is not that RAPP hosts benefit. The point is that outsiders benefit without adopting RAPP. No brainstem. No runtime. No install. Any harness that can read a markdown file gets the full fidelity of the native form.

That is the claim. Claims are worthless unmeasured, so I measured it.

The trial by fire

Two forms of the same capability:

Native form — agent.py inside a RAPP-style harness, with an agents/ package, a BasicAgent base class, and a runner. Four files.
Ark form — one SKILL.md, 20,382 bytes, nothing else in the directory.

Four experiments, five invocations each, covering every code path in the tool.

E3 — Provenance

Does the code in both forms hash to the same thing?

native agent.py  sha256[:16] = db907a26cc3ec142
ark   SKILL.md   sha256[:16] = db907a26cc3ec142
-> IDENTICAL

E1 — Fidelity

Same inputs, both forms, compared byte for byte. Not “looks the same” — the same bytes.

MATCH  rules     2502B  native=62a327afaf0407ac ark=62a327afaf0407ac
MATCH  plan       804B  native=102d09d6313990f2 ark=102d09d6313990f2
MATCH  seed      1732B  native=7e86b4a9e0b85f9c ark=7e86b4a9e0b85f9c
MATCH  critic    2202B  native=47fb87d9bb307b4f ark=47fb87d9bb307b4f
MATCH  gate      1759B  native=99f646e69457aa9b ark=99f646e69457aa9b

Five for five. A harness with no RAPP runtime produced output indistinguishable from a full host.

E2 — Determinism

Fidelity once could be luck. Five repeats per form, per case — fifty runs total.

STABLE rules   10 runs -> 1 distinct output
STABLE plan    10 runs -> 1 distinct output
STABLE seed    10 runs -> 1 distinct output
STABLE critic  10 runs -> 1 distinct output
STABLE gate    10 runs -> 1 distinct output

Fifty runs, five distinct outputs, one per case. Zero variance across forms.

E4 — Drift, deliberately induced

This is the one that matters. I edited the native copy in place — changed one rule’s text, exactly the way a well-meaning fork does — and then asked all three questions.

native output changed after edit:   True
ark output unaffected:              True
digest reveals the divergence:      True
  native bd381eb7975b209a  !=  ark db907a26cc3ec142

The native copy drifted. The Ark copy did not. And critically, the divergence was detectable — the digest changed, so a consumer can tell, rather than discovering it months later when two agents disagree about what a rule says.

That is the whole value proposition, reduced to a hash comparison.

Why this works

Three properties, none exotic:

The document is the implementation. There is no gap between what the skill claims and what it does, because there is only one artifact. Documentation drift and code drift become the same event, which means fixing one fixes both.

Content addressing makes divergence visible. Hash the extracted code. If your copy’s digest differs from the published one, you are not running what you think you are running. This is the property that turns drift from invisible to detectable.

No runtime dependency. The extraction is four lines of standard library. A harness that can read a file and run Python gets full fidelity. Nothing to version, nothing to install, nothing to break.

What it costs

Honestly: some ergonomics. A single file gets long, and you lose per-module testing. My inlined tool is about 270 lines, which is comfortable; ten times that would not be.

There is also a real failure mode I hit while building this, and it is worth naming because it is exactly the kind of thing that erodes trust. Embedding code inside markdown double-escaped the newline characters, so two of five commands printed literal \n instead of line breaks. The other three were fine, because they used a different string-building path.

A spot-check of one command would have shipped it broken. Only running every case caught it.

Which is the same lesson as always: the assertion is code too, and nobody reviews it. I only found my own bug because I tested all five paths instead of the one I happened to look at.

The pattern, stated plainly

Ship the capability as one self-extracting document. Publish its digest. Let anyone verify they are running the real thing.

If the skill ecosystem holds, you have lost nothing — the Ark form runs natively anyway, byte-identical, as measured above. If it drifts, you have a canonical copy that carries its own implementation and announces its own divergence.

That is a cheap hedge against a systemic risk. It is also, as far as I can tell, the only way to share a platform’s strengths with people who have no intention of adopting the platform.

Fifty runs. Zero variance. One file.

Update: the pattern generalizes

One capability proving equivalence is an anecdote. So I mechanized the conversion — a toast step that inlines an agent into a SKILL.md and refuses to write the file if the round-trip loses a single byte — and applied it to two more capabilities.

All three now ship in both forms, and all three were measured rather than assumed:

capability           cases   runtime      canonical sha[:12]
------------------------------------------------------------
buzzsaw              5       MATCH 5/5    db907a26cc3e
wp_publish           1       MATCH 1/1    d507eb26f76d
prompt_extractor     1       MATCH 1/1    65dbdc01b9e7

That the conversion is mechanical matters more than the result. If each capability had to be hand-toasted, the conversion itself would become a place for drift to enter — which is precisely what the pattern exists to prevent.

The sweep failed first, and the sweep was wrong

The parity run initially reported prompt_extractor as DIVERGED.

The code was identical. argparse derives its usage line from sys.argv[0], and I was running the two forms from files named a.py and b.py. The only difference in the entire output was the filename echoed back at me.

That is the eighth time in this stretch of work that a reported failure turned out to be the test rather than the code. I have started treating it as the base rate rather than the exception.

Both sides were worth fixing, and they are different kinds of fix. The harness now runs both forms under an identical filename, because comparing output that embeds the filename was simply a bad experiment. And the agent now sets prog= explicitly, because help text that changes depending on what you named the file is genuinely worse behavior — the test was wrong, but it was pointing at something real.

Methodology note: every number above came from a script that anyone can re-run. The experiment writes its results to JSON and exits non-zero if equivalence fails, so it works as a regression test rather than a one-time demo. If it had failed, this article would say so — that is the point of measuring before publishing.

The Buzzsaw

By Kody Wildfeuer

On August 3, 2026

The Buzzsaw

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

They found 21 real defects. They also produced six false ones — and three of those were mine.

That ratio is the whole lesson. The tests were wrong nearly as often as the code, and the only reason anyone knows is that somebody checked.

The pattern

The buzzsaw is a way of driving agents that assumes the builder cannot see its own blind spots. So you pay a separate adversary to be unimpressed, and you let a machine decide when to stop.

Five moves:

Name a reference. “Make it good” is unfalsifiable. “Put it next to the real thing, blind, and say which is better” is not. Name the actual best-in-class thing you are chasing.
Fan out builders over disjoint regions. This is the trick that makes parallelism work on a single artifact. Give each agent an explicit list of what it does not own, and warn it that line numbers shift while it works.
Loop each item instead of making one pass and declaring victory.
Add a harsh critic, read-only. Its entire job is to refuse to be impressed. It must never edit.
Write the acceptance gate first. The loop ends when the gate exits zero. Not when the work looks good.

Most people already do some version of one through three. Four and five are where the value is.

The best finding was not a bug

An agent implemented ambient occlusion — the shading in corners that makes 3D geometry look solid. It did the work correctly. Then it verified its own work: 66.3% of surfaces carried the right vertex data, the material flag was set. It reported a win, with evidence.

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

The cause was upstream: the scene lighting was bright enough to clip the highlight, so multiplying by a shadow value barely moved a pixel that was already clamped to white. Every line of the implementation was correct. 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. It is a verification error, and no amount of re-reading the source finds it.

The blocker nobody could see

A “click to play” overlay sat at one stacking layer. The toolbar sat below it. Every button in that toolbar was unreachable — clicking the settings icon captured the mouse instead of opening settings, and three panels had no keyboard fallback at all.

The buttons rendered at full opacity the entire time. It is invisible in a screenshot. It is invisible in the source, because the CSS is unremarkable and the click handlers are correctly registered.

It only appears if you put a real cursor on a real button and click.

It had already shipped.

Six times, the failure was the test

This is the part I did not expect, and it is now the reason I bother with the whole apparatus.

A check read a value through a method that did not exist. It got null. The code treated null as “not supported, skip,” and printed a tidy line. The single most important check in the suite never ran once. In a log, a skipped check and a passing check look nearly identical.

Another: I used a common DOM property as a visibility test. It returns null for any fixed-position element, which means correct code reads as broken. That one mistake produced five separate false results across two tools and three agents before anyone noticed it was the same error each time. It nearly caused a correct line of CSS to be changed to satisfy a broken assertion.

And my own test server sent a header that disables caching — while the thing under test was a caching feature. Every offline test I ran before that was measuring a fiction.

One agent found seven assertions in its own suite that were green without being correct. One of them had a body that returned true unconditionally. A placeholder, in a passing suite, reporting success forever.

Another measured a memory leak and had the numbers to prove it. Then it ran a control group with the feature disabled, watched the control climb identically, realized it had been measuring startup warm-up, and retracted its own finding.

The rules

Six, each earned by getting it wrong:

Check the assertion before you fix the implementation. When something reports a failure, the test is a suspect too.

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

Prove the tests can fail. “83 assertions passing” and “83 assertions that cannot fail” produce identical output. Break each invariant on purpose and confirm exactly one assertion goes red. That is the only evidence a green suite means anything.

A skipped check is more dangerous than a failing one. Any branch that turns “cannot measure” into anything other than a failure is a place where confidence goes to die quietly.

Measure after the system settles, and keep a control. A measurement taken during warm-up, with no baseline, will find a trend that isn’t there.

Never let one bad idiom spread. When the same surprising result shows up in unrelated places, stop and ask whether it is the same mistake wearing different clothes.

What it costs

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

They also found the blocker, and the shipping bug that made the simulation run at a third of real time while every instrument agreed everything was fine.

The implication

The lesson is not “write more tests.”

It is 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.

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.

The Synthetic Enterprise Data Plane (or: how we demo enterprise AI without waiting for anyone’s data)

By Kody Wildfeuer

On August 2, 2026

In Uncategorized

Every enterprise AI project I’ve ever seen dies a little in the same place: waiting for data access. The use case is approved, the agent pattern is proven, and then everyone sits for six weeks while security reviews a service account for a demo.

So we stopped waiting. We publish the enterprise systems themselves as static APIs.

The pattern

A static API is a read-only API served entirely from files on a Git host — no server, no database, no runtime. GitHub’s raw CDN is the host: free, globally cached, CORS-open, forkable. One idempotent build script turns hand-authored seed data into responses shaped exactly like the real system’s wire format.

This week we added two new organs to the commons at kody-w.github.io/rapp-static-apis:

sap/ — an S/4HANA gateway simulation. OData v2 envelopes, __metadata per row,

real service names (API_COMPANYCODE_SRV, API_PLANT_SRV, API_BUSINESS_PARTNER). A client — a custom connector, an HTTP node, a RAG ingester — cannot tell it from a live gateway.

sharepoint/ — a Graph-flavored document library for a fictional S/4HANA transformation

program: charter, workstream directory with owners and backups, governance and escalation paths, per-stream one-pagers, a data-migration playbook, a cutover plan, an FAQ.

The company is Meridian Manufacturing Group. The program is Project Phoenix. Neither exists. Every name, plant, and risk register entry is invented — which is precisely why we can publish all of it.

Try it — no auth, no signup, any language:


RAW=https://raw.githubusercontent.com/kody-w/rapp-static-apis/main
curl -s $RAW/sap/registry.json
curl -s $RAW/sap/api/opu/odata/sap/API_PLANT_SRV/A_Plant.json
curl -s $RAW/sharepoint/api/v1/sites/phoenix/documents.json
curl -s $RAW/sharepoint/api/v1/sites/phoenix/docs/workstream-directory.md

What grounds on it

On top of those two sources we built a transformation knowledge companion — the classic MVP every large program asks for: “Who is responsible for this workstream?” “Who owns Procure-to-Pay?” “I’ve got a blocker — who do I escalate to, and who’s their backup?”

It’s two small Python files on the RAPP memory-agent platform (kody-w/rapp-ai): an ingest agent that walks the library listing, fetches each document, and chunks it by section; and a companion agent that scores chunks against the question and returns passages with citations — document title, section, author, URL. The LLM is instructed to compose only from those passages and cite its sources. Ask the escalation question and it merges the Data Migration Playbook with the Governance & Escalation doc into one answer — several sources, one clear response, every fact attributed.

The part that matters: repoint two URLs and the same agent grounds on a real SAP gateway and a real SharePoint site. The demo isn’t a mockup of the production system — it’s the production system with synthetic data behind it. The distance from demo to pilot is a config change.

Why static?

Because the data plane becomes infrastructure anyone can hold:

Forkable — fork the repo, edit the seed JSON, run build.py, and you have your industry’s

version in an afternoon.

Versioned — every state of the “enterprise” is a commit. Demos are reproducible forever.
Zero standing cost — nothing to patch, scale, or pay for.
Honest — it’s all synthetic by construction, so there is nothing to leak. The security

review takes as long as reading this sentence.

The loop that makes it fun

The platform loads its agents from cloud storage at runtime. So once the Microsoft 365 channel is wired up (a Copilot Studio solution, imported once), a new or changed agent file hot-deploys into the running app over HTTP and is answering in the M365 chat seconds later — no redeployment, no solution reimport. Iterating on an agent in front of the people who’ll use it, in their own Copilot, is a genuinely different way of building.

Fork the commons, point an agent at it, and stop waiting for data access.

Everything above is public: the commons, the platform, the agents, the build scripts. All example data is synthetic; any resemblance to a real company is coincidental.

What Is Our Moat?

By Kody Wildfeuer

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:

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 · 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 🔨 — pieces live: the twin-in-training · the encounter surface; two-device recording next.
The workshop 🔨 — fork the template · the one-liner hatch.
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 Kody Wildfeuer

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