Skip to content

RECEIVED COPY — authored cross-fence (RTOpacks side), relayed by Tim 2026-07-01. Original of record lives in the RTOpacks repo. Per FENCE-PROTOCOL-01 §4 this copy is never edited and never promoted into home canon; local force comes from UCCA-FENCE-ADOPTION-01.

title: FENCE-PROTOCOL — how RTOpacks and the UCCA engine exchange artefacts doc_id: FENCE-PROTOCOL-01 status: CANON (proposed RTOpacks side, seconded UCCA side, ratified by Tim 2026-07-01) layer: standing rules (cross-project ops) canonical: true authored: 2026-07-01 NYC voice: the rules of the fence — terse, operational relates_to: ENGINE-BENCH-CONTRACT-01 §5 (two homes, symbiosis, no tangle — this protocol is that principle's operational form); WS-PRODUCT-01 (the anchor); UCCA-FOUNDATION-01 §3 and ADR-0002 (the engine side's matching commitments, held in the UCCA project) supersedes: nothing — first canon in this space

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.

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.

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.