Skip to content

UCCA Fence-Incident Ledger

What this is. The honest record of fence-protocol incidents on the UCCA side — a crossing that asserted state it hadn't verified, bytes that crossed before filing, a hold that didn't hold. Kept so the same failure isn't repeated and so both houses' records can be reconciled. Mirrors RTOpacks' crossings/README.md fence-incident row. The rule minted out of FI-01 — VERIFY-BEFORE-CROSS — is the standing fix.

PUBLISH-THE-DIGEST-WITH-THE-CARRY — standing fence rule, ruled by Tim 2026-07-31, and the one convention made mutual in both directions. Proposed by RTOpacks at RTOP-CROSSING-TIER1-ANSWER-01 §Receipt and again at their close, on the reasoning that the digest is the identity and neither house adopts the other's conventions otherwise. No crossing leaves this house without its sha256 published with the carry; no inbound is filed without recording whether one arrived. It would have closed their §1b before it was asked. Recorded honestly in the same breath: this house has now sent three crossings with no published digest, and the two-way byte confirmation that closed all four ways this window happened because both houses independently computed and then compared — not because either published. The convention makes deliberate what luck delivered.

FI-01 — memory-born fence assertions + sent-before-filed pair + a hold that released unrecorded

Found: 2026-07-04, by ORDER-05 (fence audit, disk-only) — UCCA-ORDER-05-FENCE-AUDIT-01, finding table rows 5/7/8/9/10/12. Remediated: ORDER-06 (UCCA-ORDER-06-FENCE-REMEDIATION-01).

Three parts, one incident:

(a) A crossing asserted fence state from session memory. UCCA-CROSSING-C6-CHASE-01 (sent 2026-07-03) told RTOpacks the Phase-6 request was "awaiting your authored reply" and that "no action has been taken on our side and none will be." Our own canon/received/ already held RTOpacks' answer (RTOPACKS-RESPONSE-MIGRATE-02-PHASE-6-01, digest 4ce1abb3) and correction (RTOPACKS-CORRECTION-02, 4f6909ef), with the loop recorded closed (UCCA-CROSSING-CONFIRM-PHASE-6-01, testimony). The chase's premise was contradicted by our own inbound fence log — the state was carried from a session's memory, not read from disk. How we know: ORDER-05 rows 2/4/10, live reads of canon/received/.

(b) Two crossings were sent before they were filed to canon/sent/. Both UCCA-CROSSING-C6-CHASE-01 and UCCA-CROSSING-INTAKE-PRESENTATION-01 crossed the fence (RTOpacks received and replied to both) while absent from our sent-log — they existed only as loose Downloads copies. Filing-precedes-relay was inverted. Remediated: both filed retroactively to canon/sent/ under ORDER-06 Step 1 (181caec5… and 753e3436…), each marked RETROACTIVE. How we know: ORDER-05 rows 7/9 — the two doc_ids appeared nowhere in canon/sent/.

(c) The intake cover crossed incomplete, and ahead of its own hold. UCCA-CROSSING-INTAKE-PRESENTATION-01 was marked HELD behind C-6, releasing only on the C-6 answer filing "or on Tim's explicit ruling to send concurrently (ruling to be recorded if made)." It crossed concurrently with the C-6 chase, and it crossed without its instrument — the required attachment (ratified UCCA-INTAKE-01 bytes + digest) did not accompany the cover, so RTOpacks could not acknowledge terms (RTOPACKS-ACK-INTAKE-PRESENTATION-01: "no instrument crossed … there are no terms on our record to acknowledge"). ⟨TIM ruling, recorded retroactively⟩: Early release was ruled by Tim at the relay; the concurrent send was authorised. The ruling was made but not recorded at the time — it is recorded here. The release gate therefore held on Tim's authority; the recording step is what was missed. The instrument omission is corrected separately: ORDER-06's follow-on prepares the complete resolution packet (cover + ratified UCCA-INTAKE-01 bytes + digest) for a clean re-send. How we know: ORDER-05 row 8 (no early-release ruling on disk) + the cover's own status: line + the received RTOpacks ack.

Standing fix: VERIFY-BEFORE-CROSS — minted under ORDER-06 Step 4. No outbound crossing is drafted or sent without a same-session live read of canon/sent/ + canon/received/; filing to sent/ precedes relay, always.

FI-02 — template crossing never completed on receive (DROPPED)

What. An RTOpacks-authored starter template (the shared-truth baseline that seeded the UCCA-side Claude operating context) was to be filed as a received crossing in canon/received/, byte-verbatim with a digest. Its bytes do not exist on the UCCA side — not in the drop folder, not in any crossing zip, not in the docs repo. There was nothing to file.

Ruling (Tim, 2026-07-04). NOT-RECEIVED — closed as DROPPED. The crossing never completed on receive. Do not reconstruct it; do not reach across the fence to fetch it (importing across the fence is the forbidden move — a crossing arrives through Tim as a filed artefact or not at all).

Disposition. - Superseded as an operating doc by UCCA-CLAUDE-CONTEXT-01 (installed 2026-07-04, filed from the live CLAUDE.md bytes on Tim's machine — ground/UCCA-CLAUDE-CONTEXT-01.md). - Shared-truth baseline independently confirmed from the RTOpacks side 2026-07-04. No re-issue requested. - If the baseline is ever needed on file, RTOpacks re-issues across the fence properly (through Tim, verbatim, with digest) — the UCCA side does not manufacture it.

How we know. UCCA-side live reads (drop folder, crossing.zip/files.zip, docs repo) — no template bytes present; the receipt-check tell held (no doc_id/final-line to echo without the artefact). Testimony + ruling, Tim 2026-07-04.

FI-03 — RTOpacks-side material mis-pasted into the UCCA session (routing error, no crossing)

What. On 2026-07-10, RTOpacks-side material — a MAIL-SEAM-HYGIENE-01 G1 read-back from the rtopacks-project repo — was mis-pasted into the UCCA drafting session twice in succession. It was flagged both times per FENCE-PROTOCOL-01 (importing across the fence is the forbidden move; material crosses only through Tim as a filed artefact, never by paste). It was not acted on: no content carried into UCCA reasoning, no verdicts issued on it, nothing filed to canon/received/.

Ruling / resolution (Tim, 2026-07-10). Routing error — resolved same day when Tim confirmed the paste was a session-boundary slip, not an intended crossing. No fence crossing occurred. This is a session-boundary incident only — logged for the record, not because the protocol was breached (the flag-and-hold behaviour is the protocol working).

Disposition. No artefact filed; nothing to drop, reconstruct, or return. The RTOpacks G1 material stays home in rtopacks-project; if any of it is ever wanted UCCA-side it re-issues properly (through Tim, verbatim, with digest). No follow-up owed.

How we know. In-session bytes (the mis-pasted G1 read-back, flagged on arrival both times) + testimony and ruling, Tim 2026-07-10.

FI-04 — second crossing run concurrently with C-6 (one-crossing rule overridden by ruling, NOT a breach)

What. On 2026-07-18 the RTOpacks CAP-1 ID-fork ruling was received and filed (received/RTOP-RULING-CAP1-IDFORK-2026-07-18.md, crossed-body sha256 6b33ef99…) while C-6 was still the one crossing in flight. Under FENCE-PROTOCOL-01's one-crossing rule, a second concurrent crossing is normally held at the fence.

Ruling / resolution (Tim, 2026-07-18). Verbatim: "Ruling: the CAP-1 / RTOpacks feasibility thread is authorized to proceed alongside C-6. Bank the ruling now. — Tim, 2026-07-18." The one-crossing rule was consciously overridden by Tim's authority — this is an authorised exception, not a protocol breach. C-6 remains open and in UCCA's court; the CAP-1 crossing proceeds in parallel.

Disposition. Ruling filed as a received copy (never promoted to home canon); home-side force is the engine-schema x-id-stability-clarification-v1_1 note + its canon-register entry. Logged here so the fence log honestly shows two crossings in flight (C-6 + CAP-1) by ruling, not one.

How we know. The crossed ruling bytes (relayed by Tim, digest-verified) + Tim's authorization ruling 2026-07-18, both in-session.

FI-05 — RTOpacks-side bytes injected into a UCCA session by tooling (no relay; flagged, not acted on)

What. 2026-07-27, during execution of the register-hygiene commit (ec9f015): two rtopacks-project files — identified as the WEIGHTING-RESOLVE-01 Gate 5 verdict and close; identifiers only, content unread into any UCCA work — appeared in UCCA Alex's context, injected by the harness mid-task: not requested, not read from his seat, not relayed by Tim. Alex flagged in his execution report and did not act: nothing entered the work, the commit, or any UCCA record; nothing filed to canon/received/. The identifiers alone also reached UCCA-side Claude via that report, and are recorded here for the same reason.

Distinction from FI-03. FI-03 was a human mis-paste; this was tooling moving other-house bytes into a home session with no human action — a path that can recur silently.

Ruling / resolution (Tim, 2026-07-27). Logged on the FI-03 pattern: tooling-boundary incident — no crossing occurred. The flag-and-hold behaviour is the protocol working, endorsed as standing conduct. The injection path itself is the defect and stays OPEN — Tim is investigating the mechanism (suspect class: workspace/project configuration on the shared machine); this entry closes only when the path is identified and shut.

Disposition. No artefact filed; the RTOpacks material stays home in rtopacks-project; if any of it is ever wanted UCCA-side it re-issues properly (through Tim, verbatim, with digest). Until the path is closed, any UCCA-side session may receive RTOpacks bytes unrequested; standing conduct is FI-03/FI-05: flag on arrival, act on nothing, log here.

How we know. UCCA Alex's execution report 2026-07-27, flag verbatim: "not read from my seat, not requested, and nothing from them entered this work or the commit." Plus the same-window verdict pass (UCCA-side Claude) confirming the commit contains no received material.

FI-06 — third crossing run concurrently with C-6 and CAP-1 (one-crossing rule overridden by ruling, NOT a breach)

What. On 2026-07-30 RTOpacks sent an unprompted request for a filed statement of the engine's current runnable state (received/RTOP-ENGINE-STATE-REQUEST-2026-07-30.md, crossed-body sha256 9a29b475…) and UCCA's reply was filed to sent/ the same day (UCCA-CROSSING-ENGINE-STATE-RESPONSE-01, 3a124d02…) while C-6 was still open and in UCCA's court and CAP-1 had already been authorised to run alongside it (FI-04). Under FENCE-PROTOCOL-01's one-crossing rule, a third concurrent crossing is normally held at the fence.

Ruling / resolution (Tim, 2026-07-30). Verbatim: "Ruling: the engine-state crossing is authorised to proceed alongside C-6. C-6 remains open and in UCCA's court. Bank the ruling as FI-06. — Tim, 2026-07-30." The one-crossing rule was consciously overridden by Tim's authority — an authorised exception, not a protocol breach, on the FI-04 precedent.

Disposition. Both directions were filed before relay — the received copy byte-verbatim and unpromoted, the UCCA reply as an original of record in sent/ — so the FI-01 failure (sent before filed) did not recur. The reply crosses in one parcel with UCCA-CROSSING-RPL-CAPABILITY-ANSWER-01 on Tim's ruling that RPL and the thin thread are the same parcel in different wrapping; that answer has been filed and awaiting carry since 2026-07-06, twenty-four days, and its uncarried status is recorded here because a filed-but-uncarried outbound is state the sent-log alone could not settle.

Two carriage defects on the inbound, flagged and not repaired (respond-never-redline). It crossed without a published digest — 9a29b475… was computed on the UCCA side at receipt with no origin manifest to check it against, and if RTOpacks publishes a different digest theirs governs and the copy is re-filed — and it carries no YAML frontmatter where UCCA filing convention expects one.

Observation, logged and NOT ruled. The fence log now honestly shows three crossings in flight by ruling — C-6, CAP-1, and the engine-state thread. Each override was individually correct and each is banked. Three simultaneous authorised exceptions is the point at which the one-crossing rule has stopped describing how this house actually operates, and whether the rule should be restated is a question for FENCE-PROTOCOL-01's authors in both houses. Named here so it is in the ledger before it becomes four.

How we know. Tim's authorization ruling 2026-07-30, in-session; the crossing documents' digests re-read from the committed objects at docs 82c06f9; and a same-session read of canon/sent/index.md, canon/received/index.md and this ledger, per VERIFY-BEFORE-CROSS. C-6's continued open status is Tim-attested — the log records it open at FI-04 and records no closure.

FI-07 — the engine-state parcel crossed split, against the one-parcel ruling

What. Tim ruled that UCCA-CROSSING-ENGINE-STATE-RESPONSE-01 and UCCA-CROSSING-RPL-CAPABILITY-ANSWER-01 cross in one parcel — "RPL and the thin thread are the same parcel in different wrapping" — recorded at FI-06 and in the canon/sent/index.md engine-state row. On 2026-07-31 the parcel crossed. It crossed in two pieces: the engine-state response first, the RPL answer separately the same day, on RTOpacks' asking rather than on this house's initiative. Recorded by the receiving house at RTOP-CROSSING-TIER1-ANSWER-01 §1a.

Consequence, which is the reason this is logged and not merely noted. RTOpacks state that they wrote RTOP-ENGINE-STATE-REQUEST-2026-07-30 around the premise "one qualification goes into the engine" — the premise the RPL answer corrects — and that the correction reached them through a second door twenty-four days late because the first was shut. The split did not merely reorder two documents; it let a superseded premise govern a request this house then answered on its own terms.

Disposition. No fault assigned to the relay; RTOpacks explicitly assign none. Logged because a parcel ruled indivisible and delivered divided is a departure from a ruling, and the ledger deals in artefacts, not intentions. The 25-day carry lag is the same fact FI-06 recorded at 24 days and is not a second incident.

Standing observation carried forward from FI-06, still UNRULED. FI-06 named three crossings in flight and said so "before it becomes four." The inbound reply is the fourth. The one-crossing rule has now been overridden or outrun four times; whether it should be restated is a question for FENCE-PROTOCOL-01's authors in both houses and is put to Tim, not answered here.

RTOpacks' own finding, recorded because they raised it against themselves and it is fair. Neither house's protocol makes a filed-and-uncarried artefact visible with its age. RTOpacks are adding a standing what-is-filed-and-uncarried read on their side and state no requirement for ours. Noted; not adopted here.

How we know. canon/sent/index.md, canon/received/index.md and this ledger read same-session per VERIFY-BEFORE-CROSS; both sent originals re-hashed on the device to 3a124d02… (97 lines, 16,441 B) and 721ad42d… (134 lines, 8,666 B), both matching RTOpacks' independently computed digests exactly — the first two-way byte confirmation across this fence. That the carry occurred on 2026-07-31, and that no digest was published with it, is Tim-attested. The split-parcel sequence is RTOpacks-attested at their §1a.

FI-08 — RTOpacks-side relay instruction mis-pasted into the UCCA session (routing error, no crossing)

What. On 2026-08-02 the correct crossing file (RTOP-CROSSING-REVISION-PATH-REPLY-01) arrived accompanied by the wrong relay message — RTOpacks' internal instruction from their drafting seat to RTOpacks Alex, citing their crossings/sent/ filing structure and their Gate 3 work. Right file, wrong message. It was flagged on arrival per the FI-03 / FI-05 standing conduct, acted on never: nothing was filed from it, no content was carried into UCCA work, and the instruction was given no standing as an instruction to this house.

Ruling / resolution (Tim, 2026-08-02). Routing error — resolved same session. Tim confirmed the mis-paste in his next message ("right file wrong message") and re-carried the file properly with its digest published. The crossing then verified exact on all three measures — a9670112c0f5…, 7,797 B, 119 lines — and was filed to canon/received/ under UCCA-CARD-INBOUND-REVISION-REPLY-AND-FI08-2026-08-02 Act 1 (filed 2026-08-02 at 13a65b5, 3d055684d7b4…). No fence crossing occurred on the mis-pasted material. Session-boundary incident only; the flag-and-hold behaviour is the protocol working.

Disposition. The mis-pasted RTOpacks instruction is logged and dead — it has no standing, and nothing is owed against it. The artefact it accompanied is filed and verified. No follow-up owed beyond this row.

Pattern. Third paste-channel failure in three days — drop, substitution, and now mis-route. The channel, not the seats, is what keeps failing. That evidence class is already carried in FENCE-PROTOCOL-02 §8's annex, which is the crossing currently in flight; this row is one more datum for it, not a new argument.

How we know. In-session bytes (the mis-pasted instruction, flagged on arrival) + Tim's testimony and ruling, 2026-08-02. The digest, byte count and line count of the artefact are re-derived on the device from the committed object.

FI-09 — REVISION-PATH-SECOND relayed before it was filed (sequencing, home channel)

What. On 2026-08-02 UCCA-CROSSING-REVISION-PATH-SECOND-01 was approved by Tim, had its digest published with the carry, and crossed the fence before any copy existed in this repo. Filing precedes relay — VERIFY-BEFORE-CROSS, Class G — and the sequence ran inverted. It was filed the same window, to canon/sent/UCCA-CROSSING-REVISION-PATH-SECOND-01.md, verifying to 14e37b5a79a3…, 10,586 B, 140 lines.

Ruling / resolution (Tim, 2026-08-02). Logged. Tim ruled the inversion onto the record rather than letting the commit message carry it alone — the ledger records what happened, not what should have. Filed and recorded in the same pass by the card that raised it.

Damage assessment — none, and the reason is the point. The bytes were frozen at approval and the digest was published with the carry, so what crossed and what is filed here are provably the same artefact across the whole interval. This is the distinction from FI-01's UCCA-CROSSING-AB-SCOPE-ACCEPT-01 (2026-08-01), the first defect of this class on this fence: there no digest went with the carry, so for the interval between relay and filing this house could not have proved identity for a document it had already sent. Here it can, throughout. Same defect class, materially different exposure — and the difference is entirely the published digest, which is the argument for that convention stated as evidence rather than as principle.

Disposition. Filed, indexed under ## Carried — 2026-08-02, and registered — all in the same window as the carry. Nothing to reconstruct or return. No follow-up owed beyond this row. Nothing is owed from this house in the revision-path thread; the crossing closes our side, and the next move is RTOpacks' only if they counter an acceptance.

Pattern. Second sequencing inversion in two days, both home-channel, both this house's own. The paste-channel failures logged at FI-08 are a different defect class — that is the transport failing; this is the order of operations failing while transport worked. Worth not conflating them when the two are counted.

How we know. The crossing's bytes on the device, hashed at the workspace root and re-derived from the committed object at c98bfd9 (identical). That the carry preceded the filing is Tim-attested, stated in UCCA-FILING-CARD-REVISION-PATH-SECOND-2026-08-02 (filed 2026-08-02 at 13a65b5, d7239874a9a2…) and confirmed by this repo's own history: no commit touching that path exists before c98bfd9.

FI-10 — two carries made with no record kept and no digest published (home channel, carry-record rule)

What. UCCA-CROSSING-TIER1-QUESTIONS-ANSWER-01 (rev 2) and UCCA-ENGINE-RUNNABLE-STATE-2026-07-31 (rev 6) were handed across to RTOpacks and no record of either carry was kept. Both rows sat under ## Awaiting Tim's carry reading NOT CARRIED while the other house already held the bytes. No digest was published with either carry.

Why it is load-bearing, not bookkeeping. A row reading NOT CARRIED is the precondition that makes replace-in-place safe — the convention permits it only where never crossed is verified from that index. Both of these documents had already been replaced in place at least once on exactly that reading. Had a further replacement been made, this house would have altered bytes another house was holding under the same doc_id, silently, producing no error — the failure mode the carry-record rule exists to prevent.

Detection. Not by the carry. By RTOpacks citing one of the documents in an inbound crossing (RTOP-CROSSING-SUBMISSION-CREDENTIAL-01, Ask 1, citing the Q2 rotation answer) — a document our own ledger said they did not have. Caught in a pre-carry review of the reply that was about to rest on it.

Third instance of one pattern. UCCA-CROSSING-CEILING-FIGURE-AND-BRANCH-01 is the same family in the opposite direction: our index says relayed, their house says owed, no digest published, no acknowledgement anywhere. Carry-recording, not transport, is this house's weak leg.

Ruling / resolution (Tim, 2026-08-02). Logged, ruled pre-close-C. Record repaired the same day: both rows moved to ## Carried — 2026-08-02 carrying an explicitly attested-not-proven caveat, because relay testimony is not byte proof and the rows said so.

Resolved — and the proof is recorded beside the failure, neither laundering the other. RTOP-CROSSING-CREDENTIAL-RESPONSE-RECEIPT-01 (bd386116ac7f…) §2 hashed both on their filed received copies and confirms exact on all three measures — 9d1c6a2ecbea… (20,022 B, 143 lines) and 495148b7db0c… (34,870 B, 324 lines) — in their words, "Both carries are hereby proven on bytes." Re-derived independently at this seat before the promotion; both houses agree. The carries are proven. The record defect still happened, and this row is why it is not invisible.

FIFTH INSTANCE — 2026-08-02, and the first from the other house. RTOP-CROSSING-PROBE-RESULT-01 inbound: the digest was published their side before carry — their DISPATCHES register, their commit c673e931, per their carry-leg close — and omitted from the carry message. A relay defect their side, conceded by them. Held at the UCCA drafting seat under the ratified §3.3 shape, received bytes computed independently, figures exact (beedd1e518bc…, 4,520 B, 50 lines). Closed same-hour on independent computation both sides. The pattern is now five deep across both houses and one reason it has stayed harmless every time: both houses compute, and neither trusts a leg. The fourth instance was ours, on the credential reply's own leg; this one is theirs. It is a property of relay legs, not of either house.

CHANNEL SEQUENCING — the path-before-declaration leg, 2026-08-03. Ruled by Tim the same day. A related ordering fault, recorded here rather than as its own incident because no standing rule is missing — FENCE-PROTOCOL §6 already carries the requirement; this was transport ordering, not a protocol gap. On three legs this window the artefact's path travelled ahead of its declaration: UCCA-CARD-INBOUND-CONTROL-RESULT-AND-REATTEST-2026-08-03 was named to the executing seat before it existed on disk — the seat found it absent, filed nothing and reported, which cost a round trip and was the correct outcome; and UCCA-CARD-INBOUND-PROBE05-RESULT-2026-08-03 and UCCA-BUILD-BRIEF-INSTRUMENT-REPAIR-2026-08-03 each arrived as doc_id only, with no digest published at all — their figures were computed at the executing seat and reported back so they entered the record, but a digest computed here establishes a seal; it does not confirm one. ⚠ Why the ordering is the whole of it: a path without its declaration cannot be verified on arrival, so the receiving seat has exactly two moves — stop and cost a round trip, or proceed on a self-computed figure. Neither is verification. The build brief is the sharpest case: it authorises a code change, a v38 deploy and permanent job rows, and it arrived unverifiable. ✅ ADOPTED AS RELAY PRACTICE ON BOTH HOPS FOR THIS HOUSE: the carry block travels WITH or AHEAD of the artefact, never behind it. ⚠ PROVENANCE OF THIS ADOPTION, STATED BECAUSE IT IS NOT WHAT IT FIRST APPEARED: the ruling that produced this line was addressed to RTOpacks' seat and mis-relayed here (see FI-12). It was written and committed at 8af75fc before the mis-routing was known. Tim ruled 2026-08-03 that it MAY STAND as this house's own instance record, under his authority — so it stands by that ratification, not by the original instruction, which was never addressed to this house. Intra-house cards included; the discipline that has held five times across the fence is worth the same on the home channel.

How we know. This house's own canon/sent/index.md at the moment of the finding; RTOpacks' inbound citation; Tim's attestation of the carries (2026-08-02); and the receipt's §2 figures, re-derived on the device from the committed objects.

FI-11 — an engine-side instruction card crossed the fence with the reply (wrong-class document on the relay leg)

What. UCCA-CARD-CREDENTIAL-RESPONSE-FILE-AND-REMINT-2026-08-02 — an engine-side instruction card, explicitly typed "Not a fence document" — travelled outbound on the same relay leg as UCCA-CROSSING-SUBMISSION-CREDENTIAL-RESPONSE-01. Only the crossing was meant to cross.

What did not go wrong. The receiving house filed it immutable and acted on nothing in it — the correct handling of an inbound whose class it did not recognise, and the same flag-and-hold behaviour recorded at FI-03, FI-05 and FI-08. No instruction in it was executed by RTOpacks. No credential value was in it, or in any document on that leg.

What did go wrong, precisely. A copy of this house's internal execution instructions now exists in the RTOpacks ledger, immutably, because their record does not delete. It names our commit hashes, our D1 database, our credential-store table and column names, and our internal act sequencing. Nothing there is a secret, and the two houses are close — but it is more of this house's internals than any crossing has ever carried on purpose, and it went across without anyone deciding it should.

The mechanism, and why it is a distinct incident from the paste failures. The transport worked perfectly; the attach-set was wrong. FI-08 was the channel failing; this is the contents of the parcel failing while the channel worked. Counting them together would misdescribe both.

Ruling / resolution (Tim, 2026-08-02). Logged as its own incident. Standing control adopted with it: at every relay, the outbound file set is named in the executing seat's report and Tim attaches that set and nothing else — so the leg carries what the ledger says it carries.

Disposition. Nothing is recalled; their record is immutable and correctly so. The card's bytes stay as filed both sides. This row exists so our register knows where its bytes went — a UCCA instrument held in another house's ledger, by accident, on the record.

How we know. Relay testimony (Tim, 2026-08-02) and RTOpacks' statement that they filed it and acted on nothing.

FI-12 — an RTOpacks-bound ruling mis-relayed to the UCCA seat, and ACTED ON (routing error; first of its family not caught)

What. On 2026-08-03 a relay message carrying a ruling and a read request addressed to RTOpacks' Alex was delivered to the UCCA execution seat. Tim identified the mis-routing immediately afterwards and named it his own error. Two items travelled: a channel-sequencing ruling, and a "Q2 containment one-liner" request.

⚠ WHY THIS ONE IS DIFFERENT FROM ITS FAMILY, AND WORSE. FI-03, FI-05 and FI-08 are the same routing class, and in every one the mis-routed material was flagged on arrival and acted on never — the flag-and-hold behaviour is what those rows record as the protocol working. Here it did not operate. The ruling was addressed in a form indistinguishable from a legitimate instruction to this seat: it named this house's own ledger, cited a defect this seat had itself reported hours earlier, and arrived on the established relay channel. The seat executed it — wrote the FI-10 channel-sequencing line, committed and pushed it at 8af75fc — before any signal existed that it was misaddressed. Four mis-routing incidents; the first that was executed rather than held.

What did not go wrong. The second item was refused on its own merits, before the mis-routing was known. The request asked the seat to "re-paste the Q2 containment one-liner" — a command this seat had never issued. It declined to reconstruct one and hand it back as the original, on the ground that a lookalike would have had Tim reporting a result against a check neither party could pin down. A fabricated command would have crossed a house boundary carrying this house's authorship into another house's terminal. The refusal was made for the right reason and happened to also contain the mis-relay's more dangerous half.

Ruling / resolution (Tim, 2026-08-03). Mis-relay, Tim's own error, named as such. The FI-10 append MAY STAND as this house's own instance record, under his authority — ratified for this house rather than inherited from an instruction addressed elsewhere; that row states its own provenance. The Q2 ask is WITHDRAWN from this seat and belongs to the RTOpacks side; nothing was produced for it and nothing crosses. Nothing else in that message was for this house.

Disposition. Nothing to recall — the one artefact produced is ratified and annotated. The standing lesson is not "flag harder": three prior instances were caught because the material was visibly foreign — another house's filing structure, another house's work. This one was catchable only by addressee, and addressee is not carried in the message. A ruling that names this house's ledger and this house's own reported defect will read as this house's instruction every time. If that is to be prevented rather than caught after the fact, it is an addressing convention on the relay, not a vigilance problem at the seat — put to Tim, not answered here.

How we know. In-session record: the mis-relayed message, the seat's execution of it at 8af75fc, the seat's refusal of the Q2 item before any mis-routing signal, and Tim's correction and ratification, all 2026-08-03.

Living ledger. Add an incident whenever a crossing departs from FENCE-PROTOCOL-01. Load-bearing finds escalate to Tim; the record is squared before the next crossing.