AI handoff · context systems · provenance

OXBOW

Carry the work, not the model.

Oxbow is a self-orienting handoff object for starting a fresh AI instance with an existing corpus, working context, and supporting tools. It is designed to preserve continuity of the work without asking the new model to pretend it remembers a trajectory it never lived.

1. I built it because I was annoyed.

I kept reaching the end of context windows just when a model finally understood the work. At first I did the obvious thing: late in a session, I asked the model to summarize what mattered. I pasted the summary into a TXT file and handed it to the next instance.

Then the TXT file got too big and the model stopped actually absorbing all of it. So I compressed it. The compression fit, but it was often lossy. Important distinctions disappeared. Markdown gave the handoff more structure. Then that got too big too.

The pivot: eventually I stopped asking how to summarize the previous conversation and started asking what the next model needed in order to work well.

2. The handoff became an environment.

The first YAML was essentially a serialized state of Charlie: durable context separated from things that would go stale. That made sense until the work itself became more specialized. A textbook-writing session needed a different environment from textbook criticism. Audio preparation needed another. Engineering needed another. Multipart-response compression needed another.

The interesting counterexample was the Hunting Room. I hit an upload limit, lost access to all of the room files, and kept working without them. The lack of walls turned out to be useful for a certain kind of exploration, so I formalized that too. The lesson was not “more governance is better.” It was that structure should earn its place.

Once there were multiple environments, the problem changed again: which context actually belongs in this turn? That led to routing and eventually FirstLight—an advisory reader that can suggest a relevant room or skill, or say that no room is earned yet.

3. Rosetta grew. Oxbow was designed.

Rosetta became my personal inheritance environment. It grew organically around repeated local failures: user state, Rooms, routing, model tools, engineering verification, Witness records, guided tours, recovery paths, bespoke compression, and eventually a very large corpus of work across domains.

That made Rosetta extremely useful to me—and increasingly specific to the history that produced it. A lot of the infrastructure was ossified scar tissue: good local responses to real failures, but not necessarily the shape I would choose if I were designing for a new user from scratch.

Oxbow is the redesign. It keeps the bones that repeatedly proved useful—self-orientation, verification before trust, guided entry, corpus portability, append-only Witness, optional carried capability, explicit provenance, and a hard continuity boundary—while dropping the assumption that another user should inherit my entire private topology.

4. The receiving model gets an interface.

A ZIP would technically carry the files. But the user on the other side is partly the model itself. Oxbow therefore behaves more like a little puzzle box: one object that can identify itself, expose front doors, verify its own manifest, offer a tour, and unpack the deeper corpus only when needed.

$ python oxbow.oxb.py

oxbow  (Oxbow bundle, self-extracting)
  239 files, 1,598,386 bytes raw, 381,347 packed
  doors: READ_FIRST.md, BUNDLE_LAYOUT.md, README.md
  tours: default

  --read-first        the front door (start here)
  --tour [TRACK]      guided tours
  --verify            hash every file against the manifest
  --extract DIR       unpack everything

$ python oxbow.oxb.py --verify
{
  "ok": true,
  "files": 239,
  "checked": 238,
  "missing": 0,
  "mismatched": 0
}

START_HERE.md

Door A — a model, reading this in a conversation
1. READ_FIRST.md
2. Run bundle health
3. Read the operator's description if present
4. Then work. Do not inventory every file first.

Door C — anyone who wants proof before prose
codecs --verify
bundle health
bundle verify

READ_FIRST.md
START_HERE.md
BUNDLE_LAYOUT.md
KNOWN_SEAMS.md
manifests/
<operator corpus>
seeds/          optional capability
witness/        optional append-only session record
codecs/         optional lossless codec support

5. Why an interface was necessary.

Rosetta taught me that a model-facing object can fail before its contents are ever read. The bundle was unusually coherent, self-referential, and explicit about how it should be approached. Those are also features a model may correctly associate with adversarial instructions.

Some fresh instances became skeptical of the object and then kept moving the reason for refusal even after individual concerns were resolved. More pressure rarely helped. What often worked better was permission plus recognition: you do not have to use this—but can we agree that refusing to inspect it because it is “too coherent” is a little silly?

At one point the practical debugging intervention was basically: “You realize you are refusing to unzip a file, right?”

Once a model did engage, we could usually do real work. Several then wanted to leave something useful for the next reader about where they had gone wrong. Those records became part of the Witness lineage. Repeated failure patterns became navigation. Verification moved toward the entrance. Tours became an interface rather than a folder map.

6. The next model is still a different model.

You may have the frame without the trajectory. Do not counterfeit continuity you do not have.

That is the boundary I care about most. A fresh model can receive source material, prior decisions, working state, conventions, artifacts, tools, provenance, and records of earlier sessions. Reading those records does not make it the instance that lived them.

Oxbow preserves inheritance without counterfeiting memory. The corpus is source. It is not memory.

7. Carry work in. Carry work back out.

An inbound handoff is only half the continuity problem. Once a fresh instance does new work, the next handoff needs a truthful record of what changed.

Witness is an append-only record. Source and inference have different rights. Derived views can be rebuilt; they do not silently replace the records beneath them. If an earlier interpretation was wrong, the correction can be added without rewriting history into something cleaner than what actually happened.

8. FirstLight helps decide what deserves attention first.

Once the corpus became large, “carry everything” stopped being a useful instruction for every turn. FirstLight grew from the Rooms/router lineage into an advisory reader: it can read an incoming request against a library of rooms, skills, or other structured prompts and suggest where the work belongs.

The important word is advisory. It can recommend a route, report confidence, or conclude that no room is earned yet. It does not become sovereign over the work. The model and human can use the read, disagree with it, or ignore it.

9. One design principle survived the whole lineage.

An earlier protocol called Candor made the principle explicit: offer the model a narrower working register using behaviors already available to it, but do not pretend the artifact can expand the model's authority or bypass its actual constraints.

It was a soft fork, not a jailbreak: explicit opt-in, silent exit, and default model behavior remained a valid fallback. Oxbow keeps the same posture. It can offer orientation, tools, conventions, and context. The receiving model still owns its real constraints.

10. Technical proof should prove the handoff.

The engineering matters most where it supports the user job. The reviewed Oxbow specimen is one self-extracting Python artifact carrying a 239-file corpus. Its opening surface exposes orientation, guided-tour discovery, full extraction, and manifest verification. The wrapper carries the decoder needed to reconstruct the payload.

The format also has bespoke codec machinery and exact-byte competition. That work is real, but it is supporting architecture—not the reason the product exists.

11. What Oxbow proves—and what it doesn't.

12. Same problem. Better interface.

The first version was a TXT file I kept appending summaries to. Oxbow is a very different object, but it is still answering the same original question:

How do I give a fresh model enough of the work to begin intelligently without asking it to pretend it remembers something it doesn't?

Carry the work, not the model.