UCCA — Fence Adoption¶
What this is. The home-side doc that gives local force to FENCE-PROTOCOL-01. The received copy of the protocol (
canon/received/FENCE-PROTOCOL-01.md) is never edited and never promoted into home canon; its binding effect on UCCA comes from this document. Proposed RTOpacks-side, seconded UCCA-side, ratified by Tim on 2026-07-01 (crossing #1).
UCCA operates under FENCE-PROTOCOL-01¶
UCCA and RTOpacks are separate houses (separate projects, repos, jurisdictions — see ADR-0003). Artefacts cross between them only under FENCE-PROTOCOL-01. This document records that UCCA is bound by it and states the engine-side consequences.
The two engine-side consequences¶
1. Published, client-agnostic intake — the engine never shapes a client's requirements. The engine authors a published intake spec (UCCA-INTAKE-01, to be written) stating what the gate accepts and what any client's brief must answer. The engine never drafts, templates, or pre-shapes a client's requirements. That failure occurred once — the retracted NEEDS-01 draft of this session, in which the engine began authoring the client's needs on the client's behalf. It was caught and retracted. FENCE-PROTOCOL-01 §2 (authorship-stays-home) exists so it cannot recur. Consequently UCCA-RTOPACKS-NEEDS-01 is dead — retracted, never filed, never registered.
2. The engine's assessment vocabulary is the protocol's three verdicts. The engine reports against a client's material using exactly three verdicts, and no others:
| Verdict | Meaning |
|---|---|
| YES | The gate accepts / coverage is traceable. |
| NO | The gate rejects / coverage cannot be traced. |
| ADAPTER, NOT GATE | The mismatch is a domain-translation concern — it belongs in the client's adapter, not in the gate. The gate does not narrow to accommodate it (see ADR-0002). |
The operating rules UCCA is bound by¶
- Relay through Tim only. Nothing crosses between the repos except through Tim, as filed artefacts, verbatim. No paraphrasing the other side; no reaching into the RTOpacks repo to import content for UCCA decisions. (Reading for verification when Tim asks is fine; importing is not.)
- Filed verbatim. Received copies are filed exactly, not one character changed.
- Respond-never-redline. Nothing under
canon/received/is ever edited. If a received doc needs local force, that force lives in a home-side doc (like this one) that cites it. - One crossing in flight at a time.
- VERIFY-BEFORE-CROSS (minted 2026-07-04, UCCA-RULING-VERIFY-BEFORE-CROSS-01; earned by fence-incident FI-01). No outbound crossing is drafted or sent without a same-session live read of
canon/sent/+canon/received/attached to the draft. A TM, a register line, or memory is not a source for fence state — only the fence log is. Filing tosent/precedes relay, always; where a TM or the register contradicts the crossings, the crossings win and the ledger is corrected (dated erratum). - The two drift-checks — asked of every build decision, not just fence crossings. A pair of tests that keep the engine both domain-neutral and purpose-true:
- Domain drift (catches narrowing to VET). "Does this only work because the client is VET?" If yes, it belongs in the adapter, not the gate/engine. Applied at the fence to anything arriving from the RTOpacks side before it influences engine work.
- Purpose drift (catches narrowing to course-creation). "Does this serve the reasoner, or is it a fossil of the course-creation engine (AU units → US-biased courses)?" Applied to everything a build touches. A fossil found gets yellow-tape + a fossil-ledger row, not silent deletion, and nothing course-shaped enters the spine's contracts — the envelope, the job rows, the R2 keys. (Standing test, Tim 2026-07-03.)
Home-side adoption. The protocol's text lives in the received copy, unedited; its force on UCCA lives here. The engine publishes what it accepts and never authors a client's needs; it speaks in three verdicts; it crosses the fence only through the one relay.