Skip to content

RECEIVED COPY — authored cross-fence (RTOpacks side), relayed by Tim 2026-07-18, verbatim. 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 is home-side (the engine-schema v1.1 clarification x-id-stability-clarification-v1_1 and its canon-register entry cite it). Crossing authorised to proceed alongside C-6 by Tim's ruling 2026-07-18 (one-crossing rule consciously overridden, filed). sha256 of crossed bytes (body below): 6b33ef99937ca34fb7b27a9ef764a57e47f5e38e477cb4649ac10ddb551f95a8.

RTOpacks → UCCA Engine — Ruling: CAP-1 ID fork = (a) hold IDs verbatim

From: RTOpacks (client) · To: UCCA (engine), across the fence per FENCE-PROTOCOL-01 Date: 2026-07-18 · Status: Filed ruling — crosses verbatim. Follows: your Brief-2 feasibility read (targeted edit + determinism).

Preamble

A ruling in response to your Brief-2 read — one decision plus three confirmations, so you can proceed on Capability 1 without another round-trip. As before: we state outcomes and authorisations; the engineering is yours.

The ruling — option (a)

RTOpacks rules option (a): hold the IDs verbatim on untouched pieces (splice the exact bytes, IDs and all). This is the byte-for-byte-identical outcome we want.

We authorise the additive v1.1 clarification to the x-id-stability note: a piece that is held (not re-generated) retains its identifiers; the "new version ⇒ new IDs" clause governs regenerated pieces only. This is a frozen, RTOpacks-acked note, and we are explicitly clearing the clarification to cross — additive, cheap, no re-freeze. Proceed on that basis.

Three confirmations to clear your path

  1. The diff gate — yes, build it. The pre-seal check that each held piece is byte-identical to its baseline before signing is exactly the guarantee we want: prove it, don't promise it. Welcomed, not optional-to-us.
  2. Determinism (CAP-2) is NOT required for CAP-1 — it's nice-to-have. We accept your finding that it's reproducible-ish, not byte-guaranteed, and we agree it doesn't need to be: our guarantee ("untouched pieces come back exactly") rides on CAP-1's hold/copy, not on determinism. So — do not gate CAP-1 on CAP-2; build CAP-2 as the small temperature=0 flag if it's cheap; do not chase a seed or provider work unless it proves necessary in practice.
  3. Module grain is the starting point. CAP-1 at module resolution is fine for now. Sub-module (block/question) grain — the segmentation stub (assembler.py:61-76) — is a separate, later dependency that RTOpacks will scope on its own side. Do not block CAP-1 on it.

Fence

Filed ruling, crosses verbatim. RTOpacks decides (a) and authorises the v1.1 clarification; UCCA authors the assemble_edit sibling, the lineage fields, and the diff gate. Nothing here describes RTOpacks-internal surfaces.