An overnight power outage interrupted my distributed AI estate. I lost progress across network devices, including Mac minis and a Windows battle station.

The recovery problem was bigger than turning the machines back on. A reachable device does not tell me which agent was working, what it had completed, which conversation belonged to it, or what should safely happen next.

That experience made a design question concrete:

How do we centrally restore an AI estate to its last verified recoverable state, rather than reconstructing every interrupted task by hand?

That requires backups, ownership controls, and runtime-specific recovery mechanisms. It also illustrates a broader pattern: data becomes more useful when we record its context and relationships in frames, then derive task-specific views through lenses.

The discipline is to keep source material identifiable and traceable, and derived views distinct from the original evidence.

Here, data augmentation means adding context, relationships, constraints, and useful representations. It does not mean fabricating facts. It also does not necessarily mean fine-tuning a model or applying transformations to training examples.

Start with the difference between data and usable context

This was a continuity problem, not just a dashboard problem. Across a network of AI workers, logs, native chat histories, code changes, runtime configuration, generated artifacts, and records of attempted actions can exist in different places. Having them does not, by itself, tell us how to recover the work.

Before resuming work, we need to establish:

• Which records belong to the same agent, mission, and runtime instance?
• Which code, data, and runtime versions were in use?
• What is directly observed, and what is an interpretation?
• Which actions have already happened?
• What survived the outage, and what is safe and authorized to resume?

Those relationships are valuable information. They can make existing data more useful without adding a single invented observation.

The distinction matters especially when an AI system consumes the result. A large pile of text is not the same thing as a bounded, current, evidence-linked working context.

A frame gives the information a stable reference

A frame provides a way to identify a record, retain its version and ordering, and connect it to other records.

For an application using this pattern, the surrounding contract should make clear what the record represents, where its evidence came from, and which other artifacts are needed to interpret it.

Large artifacts do not need to be squeezed into every frame. A record can refer to separately stored material, provided the application can retrieve and verify the referenced bytes.

The important discipline is to keep several concepts separate:

• Identity: which entity or logical thing this is.
• Version: which particular content or state was used.
• Provenance: where the information came from and how a result was derived.
• Authority: who is allowed to make a particular claim or authorize an action.

RAPP/1’s identity, canonicalization, content-addressing, and frame rules provide a foundation for identifying and linking records. They do not, by themselves, establish truth or authority. A lens, as discussed here, is an application-layer design choice, not a protocol guarantee that a transformation is correct.

A lens makes the information useful for a job

A lens is a declared perspective or transformation over source material.

It selects relevant information, organizes it, and may derive an interpretation for a specific task. The useful part is not merely a different layout. It is an explicit relationship between the source, the purpose, the output, and the limitations.

The same estate records can support several lenses:

Lens	Useful output	Boundary to preserve
Operator	Which machines and missions need attention, and the next safe action	A reachable host is distinct from a resumed mission
Agent	Its objective, relevant context, last completed step, and next action	An old "working" label is not proof that execution survived
Recovery	Available checkpoints, dependencies, native references, and unresolved actions	A restore plan is not permission to execute it
Governance	Decisions, approvals, evidence, and outstanding uncertainty	A signature does not make an unsupported claim true

These views can share the same source references without becoming identical.

They also should not quietly rewrite the source. If a lens produces a new interpretation, that result should be a new artifact with explicit provenance. A reader should be able to distinguish “the logs show this” from “the analysis suggests this.”

The recovery experience should be central

The desired experience is not “SSH into every device and guess which command to run again.”

It is one recovery view, backed by explicit state, that can coordinate the estate:

1. Identify verified surviving instances and reconnect to them without creating duplicates.
2. Confirm a single current execution owner for each mission before allowing work to resume.
3. Select a recoverable checkpoint whose required data and keys are actually available.
4. Restore files, native conversation context, and declared runtime dependencies where needed.
5. Reconcile actions that may have completed before the outage but lack a recorded result.
6. Resume authorized work in dependency order and within the capacity of each target machine.
7. Record what recovered, what remains uncertain, and what requires a human decision.

That is the use case driving RAPP Disaster Recovery.

This describes the recovery behavior we are building toward. Full-estate recovery is not yet operational, and the design does not imply that every device or workload supports automatic failover.

“Where it was” must mean the last durable, verified state plus explicit reconciliation. It cannot mean magically recreating lost RAM, inaccessible provider state, or an unrecorded external action.

If an agent may have sent a message, submitted a job, or changed an external system just before the outage, blindly repeating the step is not recovery. It can create a second incident.

Change the carrier, not the contract

An estate also needs to distinguish a failed communication route from a failed worker.

An emergency messaging carrier such as iMessage is one design option when the normal service connection is unavailable. Bidirectional iMessage control is still a design goal here, not an operational capability.

The fallback should preserve the same logical request, response, identity, authorization, and duplicate-protection rules rather than introduce a different kind of agent.

If a request arrives through the normal route and later appears through an emergency route, it must not execute twice. Human-readable sender labels help people follow the conversation, but they are not substitutes for cryptographic authentication of machine-control records.

This is a control-channel design, not a way to push an entire backup through text messages. It also is not an offline radio: iMessage still needs powered devices and a usable Internet path.

Where the augmentation happens

Context augmentation connects a log entry or observation to its mission, timeframe, runtime environment, and intended use.

Relationship augmentation links records that would otherwise remain isolated: a mission to its native conversation, a checkpoint to its required artifacts, or a decision to its evidence.

Constraint augmentation states what an output may be used for. A result suitable for an internal summary may not be sufficient for an automated production change.

Representation augmentation turns the same supported information into something another consumer can use: a human briefing, an agent’s working context, an audit view, or a recovery checklist.

The goal is to make information easier to use, not to imply that a derived output contains more evidence than its sources.

Reuse can compound value

Without explicit framing, each new workflow tends to reconstruct context from scratch.

A new agent receives a long prompt. A new dashboard copies fields into another schema. A new integration loses the reasons behind earlier decisions. Eventually, different consumers disagree because they are working from different versions or unstated assumptions.

A frame-and-lens approach can make some of that work reusable: the source remains referenceable, the lens declares its purpose, and the derived artifact records how it was produced. A later consumer can build on the result while checking the underlying evidence.

Feedback can become another traceable record rather than an invisible change to the original. That makes it possible to improve a lens without erasing the history of what earlier versions produced.

Portability must be demonstrated, not announced

Moving work from a Mac mini to a different host would make portability a practical concern. The pattern can help describe what a target needs, but it does not justify a blanket “write once, run anywhere” claim.

A target environment might lack a required tool, permission, state representation, or interaction model. Two frameworks can accept superficially similar inputs while producing meaningfully different behavior.

A lens should therefore declare:

• Its supported input and output contracts.
• The capabilities it requires from the target.
• Any information it drops or transforms.
• Which observable behaviors were evaluated.
• What it refuses when the target cannot preserve the required meaning.

Compatibility evidence should be specific to the claim. Valid serialization is not evidence of equivalent execution.

Likewise, a frame hash is not a backup. The referenced data must exist, the recovery keys must be usable, and the selected copy must survive the failure being planned for. Two virtual machines on one physical host do not create two independent failure domains.

Keep the contract open without exposing every implementation

An interoperable contract and its implementation are different assets.

A public specification can explain how to describe a capability, represent a projection, link evidence, report limitations, and evaluate the required behavior.

It does not need to disclose every internal compiler decision, optimization, learned mapping, or proprietary evaluation asset.

That separation is valuable: others can understand the contract and build compatible implementations, while an implementation can retain its own engineering advantages.

Existing licenses and disclosures still matter. A public contract is not a mechanism for making already published code secret again.

Measure usefulness rather than output volume

A longer summary or a larger collection of generated artifacts is not automatically an improvement.

Better questions include:

• Can someone recover the relevant context faster?
• Can they trace an important claim to its source?
• Are incompatible versions and unsupported capabilities visible?
• Does the output reduce ambiguity about the next action?
• Can another consumer reproduce the relevant interpretation or evaluate its limits?

These are properties to measure in the intended workflow, not benefits to assume.

The underlying idea

The most useful augmentation is often not “more data.”

It is a clearer relationship between evidence, purpose, constraints, and action.

Frames identify and connect records. Lenses help make those records useful in a particular setting. Keeping those responsibilities separate creates room for reuse without sacrificing traceability.

When the power comes back, I want more than reachable machines. I want recoverable work, with enough context to decide what can safely happen next.

---

Further reading: the public RAPP/1 specification.

This article describes a general architectural pattern. It is not a disclosure of a proprietary engine implementation or a claim of universal cross-framework equivalence.

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 is the same swap, happening right now, in software.

Copilot is the carriage. It’s the vehicle everyone already has — the chat surface, the agents, the buttons, the place work actually rides. It is a genuinely good carriage.

You are the horse. Today, almost everything a copilot does, it does because a person is pulling: typing the prompt, clicking the button, checking the output, deciding what happens next, then pulling again. Call this configuration what it is — You + Copilot, a personed harness. It works exactly the way a horsed carriage worked: beautifully, at the pace of one animal’s attention, and it stops the moment the animal needs to sleep, eat, or attend a meeting.

The Brainstem is the engine. A brainstem — in my RAPP work that’s the literal name — is a persistent engine built out of your stuff: the agents you’ve written, the tools you’ve wired up, the memory of how you do things. It isn’t a smarter chat window. It’s the thing that can sit where you sit and pull what you pull. Put it in front of the same carriage — Brainstem + Copilot — and you have a personless harness: the carriage unchanged, the pulling replaced.

What the swap looks like in practice

This is not a story about testing. It’s a story about the new way of work — testing just happens to be the first seat the engine took from me, because testing is the purest form of person-as-horse: a human clicking through an app after every change to see what broke.

I had just finished a feature I believed was done. Instead of strapping myself into the harness — open the app, click the toggle, watch the panel, check the download — I handed the job to an agent with a real browser and a list of expectations, and went to work on something else.

It came back with five defects. One was a blocker: the page was loading with zero JavaScript, so the whole feature was a painting of itself. Another: the one control that half-worked was a switch that could be turned on but never off. A third: a checkbox had quietly stretched to 87 pixels wide and shoved its own label onto three lines. Nothing in my automated test suite could see any of this, because it all lived in the seam between “the code is right” and “the thing works when a hand touches it.” It was findable only by pulling the carriage — which until that day had meant me.

I fixed the five, sent the engine back in, and it returned a green table: thirty-three checks, no human involved. My report changed from “try it and tell me what breaks” to “it’s done, and here’s the run that proves it.”

What makes an engine trustworthy in the harness

A few things separate an engine you can trust from a demo that waves its hands:

1. It pulls through the front door. Real clicks, real dialogs, real downloads — not API calls impersonating a user. The whole value of the person it replaced was that they used the product like a person.
2. It expects the annoying things. A confirmation popup it didn’t predict is a failure, not a nuisance. Layout gets measured — “this control is at most 22 pixels” — not eyeballed.
3. It checks what should be absent. The feature that must stay invisible until enabled, the panel that must vanish on disable. Human testers almost never verify that things are properly gone. An engine always can.
4. It never fakes a pull. If it can’t run, it says so loudly. A green light that didn’t actually execute is worse than a red one.

The arithmetic: horsepower over personpower

James Watt invented the unit “horsepower” for a simple commercial reason: he was selling engines to people who owned horses, so he measured what a horse could sustain and priced his machine in the buyer’s own units. Let’s do the same. Define one personpower as one attentive power user at a browser — someone who knows the app, knows the checklist, and doesn’t dawdle.

My harness run is 33 checks across two surfaces. Hand-executed, the mix is unforgiving even for a fast operator: the simple look-and-click checks go at ten seconds or so, but verifying a prefilled URL’s query parameters takes half a minute, measuring whether a control is 13 pixels or 87 takes a trip into devtools, and confirming an exported file actually downloaded and contains what it should takes a minute of its own. Averaged across the mix, that’s a solid twenty minutes per full pass — and you have to do the pass again after every fix.

The engine’s measured time for the same 33 checks: 19.1 seconds. That’s roughly a 60:1 ratio on the stopwatch — the engine runs at about sixty personpower on this workload. But the stopwatch undersells it, because the honest denominator is attention: the twenty human minutes were twenty minutes of a person’s full focus, while the engine’s nineteen seconds cost zero. I ran it four times tonight without noticing.

The carriage stays; the horse retires

Notice what the swap does not ask of you. You don’t abandon the carriage. Copilot, the app, the surfaces you’ve already invested in — all of it stays. That’s why the horseless carriage won so fast: it didn’t ask the world to reinvent the wheel, only to stop feeding the horse.

And notice where the person goes. Ford’s engine didn’t remove people from travel; it moved them from pulling to steering. The Brainstem doesn’t remove you from the work; it moves you to the seat where you set the destination and read the verdict. You stop being the horse. You were never at your best as the horse.

“Horseless carriage” survived only as long as it took people to forget that carriages had ever needed horses. “Personless harness” will go the same way. For a while it will be the odd new practice with the odd new name — and then it will not be “the new way of testing” or even “the new way of automation.” It will just be work: Brainstem + Copilot, the engine pulling and the person steering. And the idea that a human being once hand-pulled every prompt, click, and check through their copilot will sound like keeping a horse for your commute.

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.