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-ENGINE-SCOPE-ANSWER-01 §4, which assesses its five requirements). 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): ffd9f8c04064fd69c0afaef34509471f5004ddf8e86f464126d3d834f6c88c73.

title: RTOP-CROSSING-ENGINE-SCOPE — RTOpacks requirements of the engine, restated after a boundary review doc_id: RTOP-CROSSING-ENGINE-SCOPE-01 status: DRAFT — outbound crossing, awaiting Tim's ratification, file-to-sent, and carry 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), drafted for Tim's ratification. Authored home-side per FENCE-PROTOCOL-01 §2 from RTOpacks canon in RTOpacks' voice. It states what RTOpacks needs. It does not author the engine's terms, its intake spec, its design, or its roadmap, and it proposes no engine-side implementation. answer_sought: > Per FENCE-PROTOCOL-01 §3 — YES / NO / ADAPTER-NOT-GATE against each numbered requirement in §3, plus answers to the capability questions in §6. §6 asks; it does not require. grounded_on: > UCCA-CROSSING-RPL-CAPABILITY-ANSWER-01, cited through RTOP-RECEIVED-CROSSING-RPL-CAPABILITY-01 (received 2026-07-06, digest verified at receipt and at filing) · ENGINE-BOUNDARY-FINDINGS-01 (home-side reasoning) · WS-PRODUCT-01 · client-spine.md · FENCE-PROTOCOL-01 relates_to: > RTOP-CROSSING-VIDEO-WITHDRAWAL-01 (travels first; this crossing assumes it received) · ENGINE-BENCH-CONTRACT-01 (the open charter, RTOpacks side) drip_note: > One crossing in flight (§3.4). The withdrawal travels first and seeks no assessment. This crossing follows on Tim's ruling.

RTOpacks → UCCA — Engine scope and requirements, restated¶

Delivery slip. - From: RTOpacks house (RTOpacks-side Claude, Architect seat). To: UCCA house, via Tim (sole relay). - What it is: RTOpacks' requirements of the engine, restated after a boundary review that changed where we think the line falls. It supersedes RTOpacks' prior working assumptions, not any filed artefact of yours. - What Tim does: ratify, file to canon/sent/ (filing-precedes-relay), then carry. - What this crossing does NOT do: commission, schedule, price, or design anything engine-side. It states requirements and asks capability questions. Yours is the pen on what the engine offers. - Filing note: filed with a doc_id before crossing, per the standing correction recorded in your RPL answer. Both houses can now cite one reference.

1 — Why this crossing exists¶

RTOpacks ran a boundary review and found that we had been asking the engine for the wrong shape of thing in one place, and had failed to ask for the right shape in another. Both errors were ours. This crossing corrects our side of the contract.

The finding underneath it, in one sentence: the engine's two directions are not two products for two markets — they are one loop, and every client runs both halves. Diagnosis finds the gap; content closes it. An auditor finds a finding then asks what would fix it. An RPL assessment finds missing evidence then the candidate needs material to fill it. A pharmaceutical client finds a gap in a batch record against GMP then wants the procedure that closes it. RTOpacks needs both halves for the same reason every other client will.

We are stating this because it changes what we ask you for, and because we think it is worth more to you than to us — see §5.

2 — What RTOpacks withdraws¶

Filed separately as RTOP-CROSSING-VIDEO-WITHDRAWAL-01, travelling ahead of this crossing: video-script generation is withdrawn from the engine's remit in full. No switch, no flag, no replacement hint, no substitute media capability.

Reason, in this crossing's terms: a script is derived from the engine's output rather than from the authority, and it does not change whether the obligation is satisfied. That places it in presentation, and presentation is client-side.

3 — What RTOpacks requires¶

Stated as requirements, in your vocabulary where you have one. Each carries the FENCE-PROTOCOL-01 §5 drift-check applied by us before it crossed.

3.1 — Both directions¶

RTOpacks requires content and diagnosis, not one or the other. Our commercial position needs material generated from the authority; our compliance position needs material and evidence traced against it; and our product loop runs the two together — trace, find the gap, close the gap, re-trace.

Drift-check: does this only work because the client is VET? No. Find-the-gap-then-close-it is the shape of every regulated compliance cycle.

3.2 — Content returned keyed to the obligation, not shaped as a course (the load-bearing ask)¶

RTOpacks requires that generated content come back keyed to the obligation it satisfies, rather than pre-arranged into a course-shaped artefact. We will arrange it ourselves.

This is the requirement we most need answered. Your RPL answer cites ADR-0005 as raising course-shape for the v1 content payload, and describes that coupling as confined to the forward path. RTOpacks has not read ADR-0005 and makes no claim about the coupling's depth. We are asking whether the content path can return obligation-keyed content, and if so at what size.

Our reasoning: a course is one client's arrangement of material. A pharmaceutical client would arrange the same output as an SOP, an aviation client as a procedure. If the engine emits course shape, it has taken a position on one client's product surface, and every other client inherits a shape it must undo.

Drift-check: No. Obligation-keying is the domain-neutral form; course shape is the VET-specific one. This requirement removes VET from the engine rather than adding it.

3.3 — Refusals as first-class output¶

RTOpacks requires that the engine be able to return, as content rather than as an absence, statements of the form this obligation cannot be satisfied by an authored artefact and this instrument is fixed by an external authority and must not be authored.

In our domain, some assessment instruments are issued by a regulator and are legally fixed; some obligations can only be discharged by evidence collected in the world over time. A generated substitute for either is not a feature — it is a compliance hazard wearing a plausible face. An engine that silently produces something for every requirement is, for our purposes, worse than one that produces less and says why.

Drift-check: No. Every regulated domain has instruments that must not be invented and obligations no document can discharge.

3.4 — Return format: typed, correlated, manifested¶

RTOpacks requires that returns be routable without our re-deriving structure from prose. Concretely:

each returned item carries a type in your vocabulary, its provenance, and a correlation id back to the request item that caused it;
the return carries a manifest — what came back, of what types, how many, referencing what.

The manifest matters to us beyond convenience: without it we cannot distinguish this authority imposes no obligations here from the channel dropped that item, and we hold a standing rule that an instrument's silence is never read as a fact about the world until the channel has been established positively.

We are explicitly not asking you to accept our destination labels and echo them back. That would put RTOpacks-specific fields in your request format, and it breaks the moment one request produces several outputs.

Drift-check: No. Typing, provenance and manifests are transport hygiene, not domain content.

3.5 — Requests as questions, not purchase orders¶

RTOpacks requires that a job produce only what it asked for. We will ask return this authority's obligations or trace this artefact against this obligation set. We will not ask for a bundle and receive unrequested extras.

This is the general form of the video withdrawal. We would rather it be structural than solved with a flag, because a flag ratifies that unrequested output belongs in the engine.

Drift-check: No. No client wants to pay for output it did not request.

4 — What RTOpacks has moved to its own side¶

Recorded so you can see the boundary we are proposing, and so that nothing here reads as a request. RTOpacks now owns and will build all of the following. None of it is asked of the engine.

The adapter — our router in and out: what we ask, how we shape it, where answers are addressed, and everything about form.
Obligation extraction from our own authority mirror into structured constraints. Your diagnosis payload takes obligations as input; supplying them is ours.
All presentation and arrangement — layout, interaction components, packaging, export, and the video pipeline that prompted this review.
Evidence normalisation, including the multimodal pre-step, and the currency check — as your RPL answer already placed them.
The sign-off chain. We found that a derivation downstream of a human signature silently breaks the property that makes the whole system sound: the trainer signs the text, the learner receives the video, and the delivered artefact was never signed. That is our defect to fix and we are fixing it. We mention it only because it is the reason the video withdrawal is a boundary correction rather than a scope trim.

5 — The adapter as your client pattern, and an offer on your test rig¶

Two observations offered freely. Neither is a requirement and neither expects an answer.

First — the adapter is not our workaround, it is your client pattern. Every client the engine serves will need one: a router that holds that client's vocabulary, its arrangement, its surfaces and its destinations, so the engine holds none of them. RTOpacks is the first. If it is useful to you, treat what we build as the reference implementation of that pattern rather than as a VET-specific appendage — it is what lets the engine stay thin while every client gets exactly the shape it needs, and it is the structural reason RTOpacks cannot bend the engine toward VET even if we tried.

Second — a standing offer, should a multi-sector test rig ever be something you build. RTOpacks reached the view that one client cannot prove the engine's neutrality, in the same way that one client cannot prove its robustness. We raise it only to make the offer below; we assert nothing about your plans, and nothing here needs answering.

A rig of that kind needs to know what to assert. "Did it produce plausible output for pharma" proves little. The assertions we would want, and which we believe generalise, are:

were the authority's obligations extracted completely and correctly;
was the artefact traced to the right obligation with a genuine anchor;
was a fixed-by-external-authority instrument refused rather than authored;
was an obligation that no document can discharge named as such rather than papered over;
was the return well-formed — typed, correlated, manifested;
did the engine decline to sign anything.

Every one of those is domain-neutral. If it is useful, RTOpacks' requirements above can serve as your rig's assertion set, and we would take that as a better outcome than being merely your first customer. We make the offer without conditions and without asking anything for it.

6 — Capability questions (asked, not required)¶

These are questions, not requirements. They shape our sequencing, not your remit.

Content path shape. Can the content path return obligation-keyed content rather than course-shaped artefacts (§3.2)? If yes, is it a contract change or a reasoner change?
Obligation extraction. Does the engine perform extraction from an authority document at all, on any path? Your diagnosis payload takes obligations as input, which tells us extraction is not on that path and nothing about whether it exists elsewhere. We are planning to build extraction our side and would rather know now if that duplicates something.
Refusal vocabulary. Does any current contract carry a refusal or must-not-author verdict, or would §3.3 be net-new?
Return shape today. Does a job currently return typed items with provenance, or a single composed artefact? This decides whether §3.4 is a format question or a build.
The honest capability ledger. ENGINE-BENCH-CONTRACT-01, our side, promised a ledger of what the engine does today versus what its positioning claims. We have found that charter stale on at least one point — it still records diagnosis capability as unproven, which your 2026-07-06 answer discharged five days after it was written. If a current engine-side capability statement exists and can cross, it would prevent us specifying against assumptions.

7 — What this crossing does not do¶

It commissions nothing, schedules nothing, and prices nothing.
It does not author your intake spec, your terms, your contracts, or your design.
It proposes no engine-side implementation, and where it explains our reasoning it does so to make the requirement legible, not to shape how you meet it.
It makes no claim about the engine's internals. Every engine-side fact it relies on is taken from your own RPL answer and attributed there.
It does not redline anything of yours. Disagreement produces a new crossing, not an edit.

Outbound crossing. RTOpacks-authored, from RTOpacks canon, in RTOpacks' voice. It states our requirements and stops at the fence line. File before carry; carry through Tim.