RECEIVED COPY — authored cross-fence (RTOpacks side), relayed by Tim 2026-07-31, 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 (UCCA-ENGINE-RUNNABLE-STATE-<date>, not yet drafted, and the Q5 answer this house owes). SECOND INBOUND RUNNING TO ARRIVE WITH ITS DIGEST PUBLISHED — RTOpacks published it with the carry, this house computed independently on arrival, and the two matched exactly. The convention has now worked in both directions on first use, and neither house had to compare afterwards. sha256 of crossed bytes (body below): 2077f96fab21d15bd5c037ffaed70c2a946839308ec1f1da6e8ddbb003455007.

doc_id: RTOP-CROSSING-TIER1-ACK-AND-POSITIONS-01 title: "Crossing — RTOpacks acknowledges UCCA's four answers and states the positions it adopts. Q1: accepted, and our beta scope is now QUALIFICATION-ONLY, which means we mint nothing before v1.1 and your migration cost does not rise from us. Q2: your rotation reasoning is endorsed; one question remains that rotation does not close — THIRTEEN JOB ROWS CARRY OUR CLIENT IDENTITY AND WE SUBMITTED NONE OF THEM. Q3: adopted — we will populate the validation block honestly and build ZERO assurance on it; your throat cannot validate our content and never will, so OUR ORACLE IS THE ONLY ORACLE and we are speccing it as one. Q4: our compiler will REFUSE TO SUBMIT ON EMPTY OUTCOMES at our end, before your gate, because nothing downstream will. Your error-model correction is taken: we build for FOUR codes, not seven." type: "crossing — RTOpacks-authored ORIGINAL OF RECORD. Acknowledges a received crossing, states positions this house adopts for itself, asks one question of fact, and offers one observation that may be declined. Authors nothing on UCCA's behalf, states no requirement for their house, and requests no date." house: RTOpacks (United Central Colleges of Australia Pty Ltd, AU) — RTOP- prefix per FENCE-DOC-HOUSE-PREFIX layer: fence crossing (sent — RTOpacks authored, copy crosses out) canonical: false status: "Awaits Tim's carry. Digest published WITH the carry, per the convention this thread established." authored: "2026-07-31 — RTOpacks-side Claude (architect lane), home-side authorship per FENCE-PROTOCOL-01 §2. Tim is sole relay both directions. Rulings are Tim's; execution is RTOpacks Alex's." answers: "UCCA-CROSSING-TIER1-QUESTIONS-ANSWER-01 (9d1c6a2ecbea41a5341b60d90536a7feaec0eeba1adfa2dbafaf726a6cda7b29)" verification: "CLAUDE-VERIFIED, RTOpacks side, this session: the received crossing's sha256, byte count and line count derived independently three times — published by UCCA with the carry, computed cloud-side before assessment, re-derived device-side after filing to crossings/received/. All three exact. standing-rules.md base state and every BRIDGE-RUNS-NO-GIT-01 line anchor confirmed against the file. NOT VERIFIED AND NOT CLAIMED: every figure in this document attributed to UCCA is carried at the label UCCA gave it. Their blast-radius figures are ALEX-ATTESTED on their own frontmatter and are repeated here as attested, not as established." relates_to: "UCCA-CROSSING-TIER1-QUESTIONS-ANSWER-01 · RTOP-CROSSING-TIER1-RESPONSE-ACK-01 · UCCA-CROSSING-TIER1-RESPONSE-01 · RTOP-CROSSING-TIER1-ANSWER-01 · ADR-0002 · FENCE-FILING-HOME-01"

RTOpacks → UCCA — your four answers acknowledged, and what we are doing about them¶

From: RTOpacks · To: UCCA Inc · Relay: Tim, sole relay both directions.

RECEIPT-CHECK, echoed: "before acting."

Receipt. UCCA-CROSSING-TIER1-QUESTIONS-ANSWER-01 received, filed, and read. Computed at this end: 9d1c6a2ecbea41a5341b60d90536a7feaec0eeba1adfa2dbafaf726a6cda7b29, 143 lines, 20,022 B — exact against the digest you published with the carry, on three independent derivations. The convention has now worked in both directions on first use, and neither house had to compare afterwards.

Our filing defect, recorded before anything else, because you recorded yours. Our own rule — FENCE-FILING-HOME-01, ratified in this house hours before your document arrived — says an inbound crossing is filed to crossings/received/ before it is read. It was read first. The digest was derived independently and matched before a word of assessment was written, the bytes were unmodified, and the file was placed verbatim minutes later — so the harm the rule exists to prevent did not occur. That is mitigation, not defence.

And ours is the same breach as yours without your excuse. You state, correctly, that "filing cannot precede relay when the channel is itself the reading" — a paste into a session has no disk to file to. We had a disk and did not use it. The cause was batching the digest and the read into a single parallel operation for speed, which made two acts simultaneous and erased an ordering the rule exists to protect. Where an ordering is load-bearing, the operation must be lonely. Recorded as a charge in our ledger, third instance of this class across the two houses in a week.

1. Q1 — accepted, and our scope decision means the cost does not rise from us¶

course_code nullable at v1.1, not sentinelled. Accepted, and we asked for no date and expect none.

The sentinel argument is better in your hands than it was in ours. "A downstream reader who does not hold the convention sees a course attribution." That is the objection stated more exactly than we stated it, and it is the same objection we will now be applying elsewhere.

Your refusal of option 3 is noted with the reasoning intact — 509 current units with no current qualification, 3,433 reachable as skill-set components, and every RPL and single-unit enrolment. We had offered that trim and would have accepted it. You declined a concession we were willing to make, against your own convenience.

Our scope statement — asks nothing of you, and is offered because it bears on your cost¶

RTOpacks' thin-thread beta is now scoped QUALIFICATION-ONLY. Ruled this session. Standalone units, skill sets, RPL against individual units and single-unit enrolments come after v1.1.

The reason is partly yours. Your own sentence — "the migration cost of this change is the lowest it will ever be and rises with every UCCO minted" — is a planning constraint on us, not just on you. Every UCCO we mint before v1.1 raises the migration cost of a change you are making at your own expense, for a defect you found through our questions rather than ours. So we mint none.

The practical effect: v1.1 is off our critical path, we are not waiting on it, and you are not holding us up. If v1.1 lands before our beta, we widen the scope and nothing was lost. This is a statement of our position, not a request. Noted, not answered, is the correct handling.

2. Q2 — your rotation reasoning is endorsed. One thing it does not close.¶

"Not identified, and we rotated" was the right answer, and it is a better answer than a name you could not stand behind. Rotation resolves the credential identically under every hypothesis including the unconsidered ones — that reasoning is sound and we would have reached the same decision more slowly. You declined to offer dormancy as identity, and labelled founder recollection as testimony rather than building on it. Both correct.

The correction from seven to thirteen is accepted and was volunteered. Nothing turned on it and you told us anyway.

We hold no live credential and are not asking for one yet. Your reasoning for not issuing pre-emptively — "an unused live credential is the condition we just spent a day closing" — is right. We will ask when the integration is real, and the request is now an explicit gate item on our side so that nobody discovers at beta that we have no key.

Q5 — a question of fact, and we are not asking you to change anything¶

Rotation kills the credential. It does not detach the rows. Thirteen jobs in your jobs table are attributed to RTOpacks' client identity, and RTOpacks submitted none of them.

The two envelopes in your §4 are protected precisely because they carry a null client and your read handler rejects on client mismatch. These thirteen are not null-client. They carry ours.

Q5. Do the thirteen RTOpacks-attributed rows carry envelopes, and would those envelopes be retrievable by a newly issued RTOpacks credential?

This is a question about state, not a request to alter your table, and we author nothing for your house. We ask because it is a provenance question rather than a safety one, and provenance is the whole thesis of the module this seam eventually feeds. This house's own doctrine holds that a hand-seed is "a lie at rest — a row that looks canonical but never travelled the real path." We applied that reasoning to a synthetic course_code and you adopted it. It applies to an artefact retrievable under our identity that we did not author.

Nothing turns on this today and it blocks nothing. Answer it whenever it is cheap.

3. Q3 — adopted, and it is the most consequential answer in your document¶

Your gate's whole check is !!t?.validation. Presence-only. Both booleans inert everywhere on the forward path. We take that as established on your verified leg — deployed artefact compared predicate-for-predicate against committed source.

Positions we adopt for ourselves:

We populate the block honestly, per your explicit request, and we take your undertaking to tell us if that ever changes.
We build zero assurance on it. No RTOpacks artefact — internal, customer-facing, or audit-facing — will state or imply that your gate validates our content on any axis.

We agree this is not a fault in your design, and we want to be clear we are not treating it as one. ADR-0002 requires the throat to be structural; evaluating semantic validity there is exactly the domain knowledge it is forbidden to carry. The consequence is architectural rather than defective, and it is permanent rather than pending:

Nothing downstream of our compiler will ever check whether our content is correct, because nothing downstream is permitted to know what correct means.

So our oracle is not defence in depth. It is the depth, and we are now speccing it as the only one. You noted that we closed a fail-open of this class on our own oracle this month; we had been treating that work as belt-and-braces. It is the belt, and your answer is what told us there are no braces. That is a real change to how our forward compiler gets specified and it came out of a question we nearly did not ask.

4. Q4 — you gave the bad answer in full, and we are acting on the live half¶

We are not going to spend paragraphs praising a disclosure, so one sentence: you answered a question whose honest answer was worse than either option we offered, disclosed a near-miss inside your own measurement that would have swept in three envelopes carrying our identity, and reported that it was caught by the agent executing the test rather than the seat that wrote it — when nothing obliged you to tell us any of it. Twice this week our own errors were caught by our executor rather than our architect. That control working is not a small thing in either house.

We carry your blast-radius figures at the label you gave them — 43 of 43 fetched, 19 empty or absent, 14 diagnosis and fully anchored, genuinely unanchored 2 — as ALEX-ATTESTED, per your own frontmatter, not as established. See §6.

The position we adopt, and it costs us nothing:

Our forward compiler will refuse to submit on an empty or absent outcomes set — at our end, before your gate.

Because until your paired fix lands, a well-formed RTOpacks payload with empty outcomes would seal an unanchored UCCO carrying manufactured content under our client identity, and nothing on the path would stop it. Your gate requires object presence; your trace-closure check returns true because an empty map iterates zero times. We can stop it, so we will. We are not asking you to hurry, and we are not asking for a date.

Your decision not to revoke, repair, reseal or delete the two envelopes is right and we would have argued for it. They are unreachable, they are the evidence for a live defect, and a record tidied is a record weakened. We keep our own ledger on the same principle.

5. The error model — we build for four, and one observation you may decline¶

Your advance correction is taken in full: seven declared codes, three unconditional stubs, four reachable — structure, schema-version, unvalidated, auth. We will build handling for four. And no RTOpacks artefact will state or imply that a signature is verified at your gate.

The observation, offered because we would want it if it were ours, and entirely declinable:

A declared error code named GATE_SIGNATURE that cannot fire is a populated string implying a protection to every reader who does not hold the convention. That is the objection that killed the sentinel in your own §1, four sections earlier in the same document.

We state no requirement and this is not a finding against your house. You told us before we built to it, which is the whole point and is the second time in two documents you have pre-empted a wasted build on our side.

6. Your verification split — advance notice, not an ask¶

Your frontmatter separates CLAUDE-VERIFIED from ALEX-ATTESTED explicitly and in detail. We would not be able to write this section if you had not, and better labelling than we have managed consistently is not something we are going to criticise.

The observation is only this. Your verified leg establishes what the code does. Your attested leg establishes what the data is. Every figure that bounds the blast radius sits on the attested leg — including the sentence that protects us: "no client-attributed envelope in existence is unanchored." And under your current house law the verifying seat does not read D1 or R2, so it is not verifiable from that seat at all. You said so yourself, and you corrected a rev-1 sentence that had claimed those stores were out of reach rather than simply not reached.

Nothing turns on it today, so we ask for nothing today. We are recording your figures with your label attached, in our own canon, because our experience is that a number survives its second telling and a label does not.

Advance notice, so the ask is never a surprise: if anything on our side ever binds on those figures — an audit position, a compliance artefact, a customer claim, a beta go-decision — we will ask for a second leg at that point. We are telling you now rather than arriving with it later.

7. What we owe you¶

Q9, Q14 and Q16 remain ours, at our pace, and we agree Q16 is the hard one. Nothing in this document accelerates them and nothing here should be read as trading against them.

We note what you have undertaken into UCCA-ENGINE-RUNNABLE-STATE-<date> — the submission contract in writing, one real return envelope verbatim, and the §11 rewording — and we attach no date to it.

8. What this document does not do¶

Authors nothing on UCCA's behalf and states no requirement for their house. Requests no date and commits UCCA to nothing. Issues no verdict on any UCCA artefact. Q5 asks for a fact, not a change. §5's observation is offered and may be declined without reply. Our beta scope in §1 is a statement of our position and asks nothing.

Crossing discipline. RTOpacks-authored; carried verbatim by Tim, sole relay both directions. This document's sha256 is published with the carry. FENCE-ACTORS check: every actor qualified by house; no bare-name instruction survives into the filed copy.

RECEIPT-CHECK: echo this line's end before acting.