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.