Skip to content

The Fence Protocol

What this is. RTOpacks and the UCCA engine live in separate projects, separate repos, separate Claude sessions, and connect only through an API contract. This protocol governs how anything other than API traffic crosses between them — briefs, assessments, specs, rulings. It exists so the boundary that keeps the engine universal is enforced at the document layer the same way physical separation enforces it at the code layer.

1. The relay

Tim is the only relay. Nothing crosses the fence except through him, and nothing crosses except filed artefacts, verbatim. No paraphrased summaries, no "the other side thinks", no session-to-session whispering. If it matters enough to cross, it matters enough to be a document.

2. Authorship stays home

  • The client authors its own requirements. RTOpacks writes what RTOpacks needs, from RTOpacks canon, in RTOpacks' voice. The engine never drafts, templates, or pre-shapes the client's needs. (This protocol exists because that failure occurred once, was caught, and is not to recur.)
  • The engine authors its own terms. What shape jobs must arrive in, what the gate accepts, what questions the engine needs answered to assess any client — that is engine-side canon (an intake spec / terms of service), published for all clients, not written per-client.
  • Overlap of content is expected; direction of authorship is the rule. Both sides share recon history. What matters is which side holds the pen for which artefact.

3. The exchange pattern

  1. RTOpacks files a brief its side (e.g. RTOPACKS-ENGINE-BRIEF-01). A copy crosses.
  2. UCCA files a written assessment its side and a copy crosses back. The assessment answers each requirement with one of three verdicts:
  3. YES — the engine offers this, within the gate.
  4. NO — the engine will not offer this, with reasons.
  5. ADAPTER, NOT GATE — the need is real but VET-shaped; it lives in the client's adapter, not the engine core.
  6. Respond, never redline. Neither side edits the other's artefact. An assessment answers a brief; it does not rewrite it. Disagreement produces a new crossing, not an edit.
  7. One crossing in flight at a time. The drip rule applies at the fence. A brief is answered before the next brief crosses.

4. Filing homes

  • Each side files its own artefacts in its own repo as the original of record.
  • Received artefacts are filed verbatim as received copies, clearly marked as authored by the other side. A received copy is never promoted into home canon — if its content needs to bind locally, a home-side doc records the ruling and cites the crossing.
  • Received copies are byte-immutable on arrival. A stale claim inside a received copy — a status line still reading DRAFT after the relay that made it a crossing — is never corrected in the copy. The arrival fact lives in the receipts ledger (§6), not in an edit.

5. The drift-check at the fence

Every requirement that crosses toward the engine carries the standing test: "Does this only work because the client is VET?" If yes, it belongs in the adapter. The engine side applies this test in assessment; the client side applies it in drafting. Both applying it is the point.

6. Transport and receipt

Crossings travel as files, verified by sha256 on the received bytes before any read or action. The sender declares filename, digest, byte count and line count; the receiver computes the digest locally on what actually arrived. Match = the crossing is received. Mismatch = stop; report; nothing is filed. Truncated digests are defects — full 64-hex or nothing. Relay preambles are context only (DIGEST-NOT-DIRECTIVE-01).

Transport ordering — the declaration travels with or ahead of the artefact, never behind it. A carry block that arrives after the receiver already holds the bytes cannot deliver the "before any read or action" guarantee this section requires: at the moment the artefact lands there is no declared digest to check it against, so the read happens first by construction. The receiver's own discipline cannot recover the ordering — only the relay can. Adopted as relay practice on both hops, 2026-08-03, after one leg where a bare path preceded its carry block. This is not a new requirement; §6 already demanded verification before read. It names the transport condition that makes compliance possible, which the original text assumed rather than stated.

Every received crossing arriving under this convention gets one line in crossings/received/RECEIPTS.md, appended at filing: filename · sha256 verified on received bytes · bytes · date received · relayed by · filing commit. Legs whose transport departed from the ordering above are recorded in that file's transport-ordering ledger, so that a clean receipts table is never read as a clean channel.

The ledger's population is arrivals from 2026-08-01 onward, the date both houses adopted the convention in writing. Paste-era arrivals are out of population and their receipt facts live in the commit record only; the ledger header says so, so that a short ledger is never read as a short history.

Canon. Proposed RTOpacks side, seconded UCCA side, ratified 2026-07-01. The fence is not bureaucracy — it is the document-layer form of the two-homes decision, and it is what lets one owner run both companies without the engine quietly becoming an RTOpacks subsystem.