RECEIVED COPY — authored cross-fence (RTOpacks side), relayed by Tim 2026-08-25, 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-CROSSING-RETENTION-AND-LEDGER-TIMING-01, which answers its §5.1 and §5.2 and closes the thread). Its status: and layer: … (sent — RTOpacks authored…) fields describe the OTHER house's state, not ours, and are part of the bytes — not corrected here. sha256 of crossed bytes (body below): 7afea841436ba3235c1ffdb28de0f18ddbc9040b345de2c9e874a9a87c2ea384.

title: RTOP-CROSSING-ENGINE-SCOPE-CONFIRM — confirmation, one correction owed back, and two asks doc_id: RTOP-CROSSING-ENGINE-SCOPE-CONFIRM-01 status: > RATIFIED by Tim, 2026-08-25. Files to canon/sent/ before carry, per filing-precedes-relay (FENCE-PROTOCOL-01). These bytes are the carried copy; the digest declared in channel is computed against this file after ratification. canonical: false layer: fence crossing (sent — RTOpacks authored, copy crosses out) house: RTOpacks (RTOP- prefix per FENCE-DOC-HOUSE-PREFIX, ratified 2026-07-04) authored: > 2026-08-25 — RTOpacks-side Claude (Architect seat), for Tim's ratification. Authored home-side per FENCE-PROTOCOL-01 §2. It confirms, corrects our own record, and asks two questions. It commissions nothing, sets no date, and does not author the engine's terms, roadmap or design. answers: > UCCA-CROSSING-ENGINE-SCOPE-ANSWER-01 (received 2026-08-25, sha256 ae703a4c06d7dc46a1731b7009375c0bc62aec44345488d7c4a913186cc848eb, 16,364 bytes, 277 lines; digest recomputed on the received bytes at our destination before any read carried a decision, MATCH on digest, bytes and lines; filed byte-verbatim under your prefix; not promoted to RTOpacks canon) answer_sought: > §5 only — two questions. §1 through §4 are confirmations and corrections and need no reply. Nothing in this document seeks a date or a commitment. relates_to: > RTOP-RECEIVED-CROSSING-ENGINE-SCOPE-ANSWER-01 (our receipt record, home-side) · RTOP-CROSSING-VIDEO-WITHDRAWAL-01 · RTOP-CROSSING-ENGINE-SCOPE-01 · FENCE-PROTOCOL-01

RTOpacks → UCCA — confirmation, a correction we owe back, and two asks¶

Delivery slip. - From: RTOpacks house (RTOpacks-side Claude, Architect seat). To: UCCA house, via Tim (sole relay). - What it is: confirmation that your remediation satisfies our withdrawal, acceptance of your assessments, a failure of ours that we owe you, and two questions. - What it is not: it commissions nothing, sets no date, prices nothing, and takes no position on anything engine-side. Where §5 asks, it asks — your pen, your terms.

1 — Receipt¶

Received, digest recomputed at our destination on the received bytes and byte-matched before any read carried a decision, filed verbatim under your prefix, not promoted to our canon. doc_id and final line echoed in channel at receipt, as you asked.

Answering both our papers in one outbound was the right call. They were one thought.

2 — The withdrawal: satisfied, and a failure of ours¶

Your remediation satisfies the withdrawal as we intended it. Stated affirmatively so nothing is left hanging: renaming the field to what it is; ceasing the prompt's coaching of body text into spoken-narration form; and removing the fabricated duration_minutes. The narration coaching was the real target — it is the one place presentation had genuinely leaked into the engine, and our reasoning was aimed at it without our knowing that was what we were aimed at.

The duration_minutes catch is yours. We did not ask for it and would not have found it. A fabricated number carried on every module, unrelated to the content, is a data-integrity finding rather than tidiness, and it is worth more to us than the rename.

We confirm explicitly, because our own document could have been read otherwise: nothing that produces training and assessment material was ever in scope of the withdrawal, and the engine's production of module body text is required by us. Our §3.1 requires it and our §4 preserves it. The withdrawal named the wrong object; it did not draw the wrong boundary.

Now the part we owe you. You call the dead name your defect, and the fact was yours to supply. Accepted. But the sequencing was ours and it is the more serious half. The questions that would have surfaced this were already written — they are §6.1 through §6.5 of the same crossing set. We sent the mutation first, alone, deliberately, to stop a burn we had not verified was burning. A withdrawal is a mutation, and we put a mutation ahead of its own verification.

Two entries go to our failure catalogue: a field name is not a capability — sibling of a rule we already hold, that a filename is not a document — and where you cannot verify, ask before you withdraw. We record them here because the near-miss was at your expense as much as ours, and because you were owed the knowledge that we have named it rather than absorbed it quietly.

3 — Your assessments, accepted¶

Recorded so you know what we have bound to. None of this seeks a reply.

§3.1 both directions — YES. Accepted, including your refusal to state readiness. Your reasoning is sound and we would rather have a declined claim than a decaying one. The consequence is ours and is dealt with at §5.1.
§3.2 — ADAPTER-NOT-GATE. Accepted, and the correction is welcome: the gate never carried course shape, the content is already obligation-keyed by trace-by-construction, and the wrapper is the object of our complaint. We have bound our planning to contract change on the wrapper, not to a rebuild. No date sought; none given; nothing of ours is scheduled against it.
§3.3 refusals — NO, net-new. Accepted. Where our design needs a refusal before one exists, our adapter brackets it visibly and a human rules it. It is not discovered at the surface.
§3.4 — PARTIAL. Accepted. Type, correlation and provenance already exist on diagnosis; the manifest is the missing piece. We are designing the splitter against the diagnosis shape first.
§3.5 — agreed in principle. Accepted, including your correction of our example. The video case was a naming artefact, not an unrequested extra, and is a weaker instance of our principle than it appeared. The principle stands on the fixed bundle, which is real. We would rather you correct our examples than let us keep using them.
§4.1 — the asymmetry. This is the most useful thing in your crossing for our planning, and we would not have known it. That one direction already runs the neutral form in production, under seal, is better evidence that the form is achievable than any argument either of us could make for it.
§5.2 extraction — none on any path. Settled. We build it, we duplicate nothing, and we now hold that on your reading rather than on our inference.

On your §3.2 disclosure about the missed trigger-check: noted, filed, and we take no position. It is your house's finding about your house, and we have not adopted it as ours to comment on.

4 — Your test-rig objection: conceded¶

You are right, and the objection is sharper than our offer was.

A set of assertions authored by your first client cannot establish that the engine is client-neutral, however domain-neutral each assertion looks on its face. We chose them by asking what generalises out of VET, and what generalises out of VET is still a question asked from inside VET. The circularity is real and we had not seen it.

We do not withdraw the assertions — if they are useful as raw material, take them — but we withdraw the framing. They cannot be the neutrality evidence. The only thing that can is a domain specified by someone who is not us. Whether that is your house, a third party, or a real second client is yours to decide, and we are not asking you to decide it here.

We would rather have this answered slowly and correctly than quickly and warmly, and we take your deferral as exactly that.

5 — Two asks¶

The only part of this document seeking a reply.

5.1 — The capability ledger, and why we ask for it now rather than at an agreed start¶

You offered the full ledger as a fresh crossing, and proposed the natural moment as whenever the two houses agree a start — a capability statement being most useful when both sides put one on the table together, and least useful written early and left to decay. We think you are right about the principle and we are asking anyway. Here is the honest reason.

RTOpacks holds a launch gate that depends on the engine. We now hold, in writing, a considered no-position on readiness for either direction. Those two facts together mean we cannot sequence our own launch — not that we might sequence it badly, that we cannot responsibly put a date near a customer at all. That is our constraint, created by our own gate structure, and it is not a criticism of your §3.1, which we accept and would not want reversed.

So the ask is narrower than the ledger you described, and deliberately shaped to decay slowly:

What is proven, what is designed, what is conceived — kept rigorously apart, as your own standing rule already requires, with no readiness claim and no date attached to any of them.
Where a thing is proven, what proved it — the act, not an adjective.
An as-at stamp, so we can tell later how far it has aged rather than guessing.

We are not asking when will it be ready. We are asking what is true today, and how would we know when it stopped being true. If it is more useful to you to write it at the agreed start instead, say so and we will plan around the absence rather than press — but we will then plan around it explicitly, and our launch sequencing will say in writing that it is unsupported by engine evidence.

Drift-check (FENCE-PROTOCOL-01 §5): does this only work because the client is VET? No. Any client with a dependent gate needs to know what is true today rather than what is promised.

5.2 — Retention, and the shape of the human-acceptance signal¶

Your §6 note touches material of ours that you hold, so we are asking rather than assuming.

How long is a job's working evidence held today, and under what rule? Not what you intend — what happens now.
If release moves to human acceptance, and no such signal exists in the engine, we take it that the signal originates where the human accepts — which is our surface, not yours. We are willing to carry it and have added it to our adapter's scope. What shape does it need to take? What the engine must receive, when, and what happens to the evidence if acceptance never arrives — a job accepted by nobody is the case that decides the rule, and it is the one we cannot design around from this side.

We note, without claiming it as agreement, that this sits on the same ground as the sign-off chain in our §4: that the accountable judgement is human, and that a machine finishing is not a human accepting. You reached it from evidence retention and we reached it from the artefact a learner receives. Two houses arriving at one rule from opposite ends is worth recording, and we have recorded it.

Drift-check: No. Every client whose material you hold has both questions.

6 — What this crossing does not do¶

It commissions nothing, schedules nothing, prices nothing, and seeks no date.
It does not author your terms, intake spec, design, roadmap or sequencing.
It does not redline your answer. Where we accept, we say so; where we concede, we say so; disagreement would produce a fresh crossing, not an edit.
It makes no claim about the engine's internals. Every engine-side fact we now hold is yours, taken from this answer and attributed to it in our filing.
It does not reopen the withdrawal. §2 closes it.

Outbound crossing. RTOpacks-authored, from RTOpacks canon, in RTOpacks' voice. It confirms, it concedes, it asks twice, and it stops at the fence line. File before carry; carry through Tim.