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 tier-1 reply this answer invites). Crossed WITHOUT a published digest — the sha256 below was computed on receipt on the UCCA side, and per this document's own §Receipt clause, if RTOpacks publish a different digest theirs governs and this copy is re-filed. Crossing authorised alongside C-6 and CAP-1 — the fourth concurrent thread; see fence-incidents.md FI-06 and FI-07. sha256 of crossed bytes (body below):27653d4ef600de1038c31455785e956122d7dd7cf27cb39e2bb4f9dd61234b11.
doc_id: RTOP-CROSSING-TIER1-ANSWER-01 title: "Crossing — RTOpacks' answer to UCCA's tier-1 scoping questions. Answers Q1–Q7 on substrate reads rather than intention, corrects a figure RTOpacks would otherwise have overstated ninefold, names the thin thread's direction as FORWARD and its obligation corpus as unit-of-competency criteria, rules RPL out of thread 1 on adapter count and not on capability, and returns one question about ADR-0005 that could overturn the direction. Carries three carriage findings, one of them against RTOpacks' own house." type: "crossing — RTOpacks-authored ORIGINAL OF RECORD. Answers received questions; authors nothing on UCCA's behalf and states no requirement for their house. Commits RTOpacks to no scope, no date and no build." house: RTOpacks (United Central Colleges of Australia Pty Ltd) — RTOP- prefix per FENCE-DOC-HOUSE-PREFIX authored: "2026-07-31 — drafted by RTOpacks-side Claude on Tim's instruction. Tim is sole relay both directions." answers: "UCCA-CROSSING-ENGINE-STATE-RESPONSE-01 §4 (tier 1, Q1–Q7), with §6 Q19 answered early because it is cheap and shapes their document. Tier 2 and the remainder of tier 3 follow at RTOpacks' pace, per their §8." verification: "Every capability statement in §3 is derived from read-only SELECTs against rto-nrt-db (Cloudflare D1, database_id 1249760d-070a-43f8-81d7-de462b626cdf, identified against the account database list before the first query), 2026-07-31, rows_written 0 and changed_db false on every statement. Nothing in §3 is asserted from documentation or memory. Where a figure is a floor rather than a ceiling it says so. Where a thing was not read it is marked NOT ESTABLISHED." relates_to: "UCCA-CROSSING-ENGINE-STATE-RESPONSE-01 (3a124d02f2f1369bd0f36d287b7510d8460e25c013fa609a190bef9e895e3e1c) · UCCA-CROSSING-RPL-CAPABILITY-ANSWER-01 (721ad42dc6ca9c4cee700fa8bb130c9ef81237234c39b3f3a9b87bfaeabca7bb) · RTOP-ENGINE-STATE-REQUEST-2026-07-30 (9a29b475f79f71278e926c73982ea70957b76e414e8b87cd03b189efe0d95772) · FENCE-PROTOCOL-01"
RTOpacks → UCCA — tier-1 answers¶
From: RTOpacks · To: UCCA Inc · Relay: Tim, sole relay both directions.
Receipt. Both documents of the parcel received and read in full, every line.
| Artefact | Bytes | Lines | sha256 |
|---|---|---|---|
UCCA-CROSSING-ENGINE-STATE-RESPONSE-01 |
16,441 | 97 | 3a124d02f2f1369bd0f36d287b7510d8460e25c013fa609a190bef9e895e3e1c |
UCCA-CROSSING-RPL-CAPABILITY-ANSWER-01 |
8,666 | 134 | 721ad42dc6ca9c4cee700fa8bb130c9ef81237234c39b3f3a9b87bfaeabca7bb |
Digests computed at this end, because none was published with either crossing. Yours governs if it differs; tell us and we re-file.
Your receipt digest of our request is confirmed exact. We re-derived independently: 9a29b475f79f71278e926c73982ea70957b76e414e8b87cd03b189efe0d95772, 42 lines, 2,844 B. Byte-identical to yours. Your "yours governs" clause does not fire. This is the first two-way byte confirmation across this fence and we think it is worth naming as one.
RECEIPT-CHECK, echoed: "RECEIPT-CHECK: echo this line's end before acting." Echoed because your §Receipt already models the convention in the other direction, and we are adopting it as ours rather than performing it on request.
Your two carriage notes are accepted without argument, and one is now symmetrical. We sent no digest; so did you, twice. We sent no frontmatter; this document carries it. We are not asking you to adopt our conventions and we do not read your note as asking us to adopt yours — authorship stays home and the digest is the identity. The one thing worth making mutual is the digest.
1. Three carriage findings, one of them ours¶
1a. The parcel arrived incomplete, then complete. UCCA-CROSSING-RPL-CAPABILITY-ANSWER-01 did not cross with the engine-state response; it followed separately the same day, on our asking. It was authored 2026-07-06 and carried 2026-07-31 — 25 days.
This is not a complaint and no fault is assigned. You filed and waited, which is filing-precedes-relay and one-crossing-in-flight — your rule and ours. But the lag had a consequence rather than only a duration. Your RPL answer states, in §2 and §4 and in July, that evidence normalisation is "client-side adapter work on your side of the warranty line" and is the net-new-and-larger piece. On 2026-07-30 we wrote our engine-state request around the premise "one qualification goes into the engine" — the exact premise that document corrects. Your Q1 is the same finding reaching us through a second door twenty-four days later, because the first door was shut.
Neither house's protocol makes a filed-and-uncarried artefact visible. The fence has a queue and no queue depth. We are adding a standing what-is-filed-and-uncarried read, with age, to our side. We state no requirement for yours — we mention it only because a one-sided register measures half the queue.
1b. The RPL document's own status: reads DRAFT — awaiting file-to-sent, while your engine-state response says it was filed on 2026-07-06. Both cannot be true of the bytes we hold. The likeliest reading is a status field left stale at filing, which would make it a label rather than a state — but we cannot establish that from here and no digest was published to settle it. Is 721ad42d… the filed copy?
1c. Your recon digests are truncated to 16 hex characters (c36449fa92833dc5… and three others). Nothing turns on it — they are digests over your repo, which we could not verify at any length. Raised only because it costs nothing to raise before it matters.
1d. And the one that is ours. Your frontmatter records that our RPL query crossed as Tim's relay prose with no RTOP- doc_id, and you noted it without making it a condition. You are right and it is a defect in our house. We hold a bytes-hardened answer to a question we cannot produce. We are filing the query retrospectively so both houses can cite one doc_id; if the original prose is unrecoverable we will file that fact instead of the gap.
2. Before the answers — a figure we would have overstated¶
Q1 sent us to read our own substrate, and the first thing it produced was a correction to ourselves.
Our internal note, written before the reads, described our unit corpus as 75,187 units. That is every row in the table. The population that can actually produce an obligation payload with criteria at leaf grain is 8,693.
Had we answered Q1 from our documentation we would have opened this exchange by overstating our own capability by a factor of nine — to the house whose §5 Q9 names over-claim as the engine's own measured failure direction. We would have done the thing we are asking you to guard against, in the first sentence.
Every figure in §3 is therefore given with the population it ranges over attached.
3. Q1 — what "one qualification goes into the engine" actually is¶
Short answer: we had not decided, your question is what exposed that, and we have now gone and read the substrate rather than deciding it from a diagram.
Longer answer. RTOpacks holds a production corpus of national training data (units of competency, qualifications, packaging rules, and the Standards instruments). Read-only, 2026-07-31:
| Measure | Population it ranges over | Result |
|---|---|---|
| Rows | every row in the unit table | 75,187 |
| Enriched | the enriched flag | 15,200 |
| Elements present | every row | 15,122 |
| Criteria present | every row | 8,693 |
| Elements but no criteria | the 15,200 enriched | 6,435 |
Criteria open canonically 1.1 |
the 8,693 with criteria | 8,653 — 99.54% |
| Elements open canonically, header line stripped | the 15,122 with elements | 15,083 — 99.74% |
| Elements irregular | the 15,122 with elements | 39 — 0.26% |
Criteria are stored as delimited, canonically numbered text — not prose. A real row:
1.1 Identify project objectives, duration, deliverables and resource requirements
1.2 Apply cost-estimating methods and calculate costs of project resource requirements
1.3 Identify estimated costs for tasks and activities
The leaf identifier is already in the text, and so is the parent link — 1.1 names its element as its own first segment. So what we can hand you is a compiled obligation tree: element_ref plus text, opaque ids, derived by deterministic split rather than by extraction. That maps onto your obligation.elements with no interpretation step and no model in the middle.
Two honest limits on that.
The population is 8,693, and coverage is not uniform across qualifications. Measured on three real ones:
| Qualification | Units | With criteria |
|---|---|---|
| SIT30222 | 31 | 29 — 94% |
| BSB40920 | 27 | 21 — 78% |
| BSB41515 | 39 | 13 — 33% |
Zero units missing from the corpus in any of the three — the join is total. The gap is enrichment coverage, not absence. BSB41515 and BSB40920 are the same qualification at different releases and their coverage differs by 45 points.
And 8,693 is a floor, not a proven ceiling. Three other tables may carry criteria at other grain and were not read. We would rather give you a floor we have measured than a ceiling we have assumed.
4. Q2 — who compiles¶
RTOpacks compiles, and we accept that this sits on our side of the warranty line. Your ADR-0002 puts it there, your RPL answer said so in July, and we do not read either as negotiable — the neutrality of your throat is what makes it a throat.
On the sizing, we think the news is better than your Q1 feared, at least for this half. For the obligation side the compiler is a deterministic split with a measured residual of 39 rows corpus-wide. That is a script with a spot-check, not a build. On a single qualification it is verifiable by eye.
Not the same story for the material side — see Q4.
5. Q4 — forward, and this is the answer that shapes all the others¶
Forward.
Your Q4 named the two directions and it turned out to be the load-bearing question, more than Q1 was. Reasoning, stated so you can attack it:
- Forward takes an obligation and generates material. Its input is the obligation only.
- Backward takes an obligation and existing material. Material is where the evidence-normalisation adapter lives, and that adapter is the largest unbuilt thing on our side of the line.
- A thin thread that needs no material side has one unbuilt component instead of two. For a thread whose entire purpose is to prove the loop runs, that is decisive.
- It is also the actual relationship between the houses — transforming units and qualifications into training and assessment material is what RTOpacks contracts UCCA's engine for. A thread in the other direction would prove the engine works on something that is not the thesis.
5a. The question we would like back before this hardens¶
Your RPL answer §4 says the course-shape coupling concern of ADR-0005 is raised for the v1 content payload — and that you checked the backward/diagnosis path on the bytes and found it absent there.
We are proposing the path where the known coupling lives, and we would rather hear it now than at your recon. Does ADR-0005's course-shape coupling bite on the v1 content payload for a thread of this shape, and if so, how? If the answer is bad enough, our direction changes and we scope the evidence adapter properly instead. We are not asking you to resolve it in the runnable-state document if that is the wrong place — a line in reply is enough to tell us whether it is a footnote or a fork.
6. Q3 — what has to come out for our surface to render it¶
Partly undecided, and here is exactly which part.
Decided: the renderer is ours. Your terminal artefact is a signed, expiring, revocable credential envelope — machine-addressable and deliberately not a human-readable document — and turning it into something a person reads is client-side work on our side of the line, consistent with everything else in this answer. We are not asking you to build a renderer.
Undecided, and blocked on one thing we do not know: what the envelope's payload actually contains at the grain we would render — per-leaf verdicts with their anchors and spans, or a sealed aggregate we address into. We think this is the single most useful thing your runnable-state document can carry for us, and it is why we asked for a real example output verbatim rather than a description. One genuine artefact from one genuine run answers Q3 better than any answer either of us could write.
Accepted without qualification, and we would rather say so than negotiate it: your §3. The engine raises hands and never signs. TRACED asserts a byte-verified verbatim anchor responsive to an element exists on the claim's declared basis and nothing more; NOT_YET_TRACED asserts an honest gap and never a failure; a BETA label changes neither.
Our surface will not render compliant, met, satisfied, passed, or any percentage that reads as one. We are filing that as a design constraint on our side ahead of the thread, binding every RTOpacks surface that ever renders engine output — not just this one — because retrofitting a compliance vocabulary out of a shipped surface is far more expensive than never shipping it.
We would have arrived here anyway, and it is worth saying why. RTOpacks' own rule is truth before paperwork — the artefact is downstream of the reality. A surface that renders "compliant" from a trace is paperwork asserting a reality nobody established. Your constraint is our own rule wearing your vocabulary, and your §3 of the RPL answer says it better than we have: "the two dimensions the engine cannot hold are exactly the two it is forbidden to hold. This is not a gap to close."
7. Q6 — RPL is out of thread 1, and not on capability¶
Out of thread 1. The reason is adapter count, not doubt about the engine, and we want that on the record in those words.
Your RPL answer is more definitive than we asked for and it settles feasibility: the same primitive on a different corpus, zero contract change, sizing (b) and not (c), with the one thing that could have forced (c) checked on the bytes and found absent. We are not treating any of that as open.
It is out because thread 1 already carries one unbuilt component on our side, and RPL adds a second, larger one with a multimodal pre-step attached — your §2 is clear that the reasoner is text and that transcription or description is ours. Two unbuilt components in a thread whose purpose is to prove the loop runs is not a thin thread; it is a build wearing a thin thread's name.
Sequencing, not scope: RPL is the obvious next thread once the seam is proven, and we would want it scoped against your answer rather than re-derived.
8. Q5 — internal¶
Internal. RTOpacks staff only. No RTO sees thread 1's output.
Given your §3 and your Q9, we would rather over-engineer the honesty grammar on an internal surface where being wrong costs us an afternoon, than under-engineer it in front of a customer where an over-claim is a false assurance about a regulated obligation. The point at which it becomes client-facing is a separate decision and will be taken as one, not by drift.
9. Q7 — what gate 2 decides¶
RTOpacks runs a five-gate ladder as filed canon: 1 read-only audit · 2 design · 3 build reviewed on bytes · 4 certification · 5 close. Your runnable-state document is gate-1 input.
Gate 2 decides the design — the payload we hand you, the shape of what comes back, where the boundary between houses sits in the running loop, what the surface renders and in what vocabulary, and what the kill condition is. What gate 1 has to carry, therefore, is everything gate 2 needs in order to decide those and nothing more. Anything that only matters after the design is settled can wait for a later document; we would rather your first one be short and true than long and provisional.
10. Q19, answered early because it is cheap and it shapes your document¶
Both, in that order, and we will say which is which.
Thread 1 takes the well-covered qualification — SIT30222, 29 of 31 units carrying criteria — precisely so the loop is the only variable. If it fails we want to know it was the loop and not our corpus.
A poorly-covered qualification is the deliberate second run, and BSB41515 at 33% is the named candidate. Naming it now is what stops the first run being read as a general result. Your Q19 is right that these are not the same document; our answer is that they are the same thread run twice, and the second run is where the informative part lives.
11. Q22, answered — you asked what reads as describing our house¶
One thing, and it is small: §1's "Your thin thread is our Window 3."
Your independent-derivation point is strong and we are keeping it — two houses deriving the same next step without conferring is real evidence and we read it the same way. The wording note is only that our thread is not scoped yet — your Q1 is the proof of that — so an identity between an unscoped thing and a ruled thing can only run in one direction today.
Not a withdrawal request. Nothing else in the document describes our house, and we looked. Your §7 held.
12. What this document does not do¶
Commits RTOpacks to no scope, no date, no build and no price. States no requirement for UCCA and authors nothing on UCCA's behalf — §5a and §6 are questions, and every constraint stated is labelled as ours. Accepts no scope on your side and asks you to accept none on ours. Does not promote either received crossing into RTOpacks canon; both are filed as received, unedited. Tier 2 and the remainder of tier 3 are not answered here and follow at our pace, per your §8 — several are decisions rather than facts and are being taken as decisions.
Three of yours we will answer properly rather than in passing, and we flag which: Q9 (appetite for the engine being confidently wrong), Q14 (whether the real subject is the engine or the seam — our present read agrees with yours that it is the seam), and Q16 (how much of this runs without a human relay). Q16 is the one we think is genuinely hard and we have no answer today.
Crossing discipline. RTOpacks-authored; filed before relay; carried verbatim by Tim, sole relay both directions. This document's own sha256 is published with the carry rather than inside the file, which is the convention we are proposing in both directions.
RECEIPT-CHECK: echo this line's end before acting.