RTOP-CROSSING-EXCHANGE-MODEL-POSITION-01¶

The client requirement set for the RTOpacks↔UCCA exchange — positions, with evidence¶

From: RTOpacks · To: UCCA · Relay: Tim, sole relay both directions. Status: DRAFT — becomes a crossing when Tim relays it. Digest computed on the relayed bytes and published with the carry. Travels under the standing transport convention (RTOP-CROSSING-AB-SCOPE-ACCEPT-ACK-01 §3, adopted both directions). Standing on: the A/B scope amendment, accepted and binding (UCCA-CROSSING-AB-SCOPE-ACCEPT-01 §1) — nothing here touches it. Your filed granularity statement (ibid. §4: module-level element_ref governs until contract revision) is relied on below as a filed agreement.

1. What this is¶

RTOpacks is one client of the engine, and this is that client's requirement set for the exchange, stated as positions with their evidence attached. Three positions and one request. None is a schema tweak; each names what the exchange must carry for the product an RTO buys to be assemblable at all. Sequencing is negotiable throughout; the requirements are not, and §5 explains why the largest one has no workaround on our side of the line.

Nothing here asks for immediate build. We ask for written agreement on each position (or a counter-position with its evidence), and a jointly-owned revision path for the contract. The eventual canonical form we propose for that revision is an executable one — a schema plus fixture corpus both houses run in CI, so future divergence is a failing test rather than a discovered surprise.

2. Position — identity: retire the field named `course_code` ★¶

The field, not the codes. National register codes are the backbone of everything both houses do; this position exists to protect them. The job schema's course_code field has never held what its name claims: in every sealed forward envelope, its value is a unit code, duplicating source_code exactly — facts your house holds in its own store and both houses have jointly established. A real, resolvable identifier presented at the wrong register level is worse than a fabricated one, because it survives being checked: a reader who resolves it finds a genuine unit of competency and an artefact calling it a course.

The position:

The field named course_code is retired from the unit-level job schema. Nullable does not discharge this — the defect is presence and misattribution, not absence.
Unit-level identity travels as unit_code — the code of the unit whose obligation is in the payload, nothing else, ever.
Qualification identity travels inside the contextualisation brief, structured (code, release, role, group) — four of those five facts are already structured scalars in our cr-2.0.0 payload; this formalises existing practice.
The word "course" does not appear in the schema at all. On the Australian register it strictly names an accredited course (NAT-suffixed) — a different level from both qualifications and units — while everyday usage means the qualification. The name is ambiguous before any value lands in it; the value that did land was from a third level again.
If your house needs a course-level identity for its own registry, it is your namespace: a UCCA-*-prefixed shape, structurally distinct from every national code, so a UCCA identifier can never be mistaken for a register claim. Nothing in the exchange ever mints or carries a national-register-shaped identifier at any level other than the one it actually names.

3. Position — the sealed envelope attests the release¶

An obligation is not "the unit"; it is a release of the unit. The obligation hash pins the text; nothing in the exchange names the register release that text belongs to. Consequence: an artefact cannot answer "was this generated against the current release?", and a re-release produces hash movement with no register-level explanation.

The position: a sealed forward envelope must carry, attestably, the unit code, the release number generated against, and generation-time currency status. Proposed placement: inside the contextualisation brief (hashed there, so the attestation is as strong as the brief hash your container already recomputes over what it used) — deliberately not inside the obligation hash, preserving its property that identical obligation text yields one hash for any client. The corollary we adopt on our side: no production job runs briefless; a null-brief job is an experimental configuration (the A/B's Arm 0), never a product path.

4. Position — the obligation we send becomes four-class, and the gate must carry it¶

Disclosed in the A/B amendment and repeated here as a commitment: our adapter's current triumvirate carries elements and performance criteria only. The Assessment Requirements of a unit — knowledge evidence, performance evidence, assessment conditions — never cross. That is our defect and our build: we will correct the slice so the full obligation travels.

What we need from you: written confirmation that the gate and reasoner will accept and consume the expanded obligation — and specifically that no exact allow-list posture on the triumvirate bounces legitimate expansion. An exact allow-list built from an incomplete contract blocks every correction of the contract; we found and are fixing the same posture defect in our own outbound validation, and the revision path in §1 should rule the posture on both sides, not patch the lists.

5. Requirement — the return is a training-and-assessment artefact with item-level anchoring¶

The unit of sale in this market is the training and assessment package. A market-standard commercial trainer/assessor manual (held under licence this side; anatomy stated here, content not reproduced) ships, per unit: learner material organised by element; a suite of assessment instruments — knowledge questions, projects, observation reports, third-party reports — with benchmark answers in the assessor rendition; and mapping matrices joining performance criteria, performance evidence and knowledge evidence to instruments at item level ("Question 5", "Project 1, 2" — never a tick). That is the floor a buyer measures against.

The contract today, by your own filed citations: the output schema's only assessment-shaped structure is modules[].quiz.questions[]; nothing provides for observation checklists, practical tasks or marking guidance; the trace floor is module-level element_ref (governing, per your filed statement); instruments are carried by zero payloads and read by nothing.

The requirement: the forward return is a coupled triple, as data —

Training material that teaches what the obligation requires;
Assessment instruments anchored twice — to the obligation (which requirements each instrument evidences) and to the training as generated (nothing assessed that was not taught) — with the instrument pattern supplied by the client in the brief, the engine instantiating it and free to propose deviations with their derivation attached;
The mapping as data: every requirement of every class → where taught, where assessed, by what method, with requirement refs at item level on both faces. The mapping emitted by the same reasoning pass that produced both faces — mapping produced anywhere else is generate-then-check, which the forward direction exists to avoid.

The boundary that stands regardless: the engine proposes, with derivation; it never signs. Sufficiency remains a human act on the client's side, always — the safety property both houses already hold.

Why there is no workaround, stated once so the weight is understood. Presentation of engine data is our job and we will do all of it. But a missing assessment face cannot be filled on our side: client-authored instruments presented as generated is void under both houses' rules, and client-authored instruments presented honestly makes the client the content house — which collapses the two-house architecture inward. The engine returns the coupled triple, or the product this exchange exists to produce cannot be assembled by anyone. That is why this is a requirement rather than a feature request, and why we ask for a staged revision path rather than a refusal-or-rebuild answer: staging is negotiable; the destination is not.

6. Request — enumerate the sealed forward envelopes¶

Confirmatory, not blocking: a structural enumeration of content_payload across the sealed real-unit forward envelopes in your store — does anything populate quiz in practice; are answer_index and explanation present; does any trace entry anchor below module level — crossed as a filed artefact under the standing convention. The §5 sizing stands on the contract facts either way; this closes the gap between what the contract provides for and what the store contains.

7. What this crossing does not do¶

It does not amend the A/B (settled, binding). It does not ask you to pause anything in flight — the deploy, the migration, the ceiling measurement and branch all proceed as committed. It does not attach our internal working documents; each position above carries its evidence in place, and disputed facts can be re-derived jointly on request. And it does not name dates: we ask for agreement on the shape first, then a jointly-owned staging of the work.

End of crossing. RTOpacks drafting seat, 2026-08-01. Relayed by Tim; authorship stays home.