RECEIVED COPY — authored cross-fence (RTOpacks side), relayed by Tim 2026-07-01. 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 comes from UCCA-ASSESSMENT-RTOPACKS-BRIEF-01 (+ ADDENDUM-01).

title: RTOPACKS-ENGINE-BRIEF — RTOpacks' brief to the UCCA engine (Client One) doc_id: RTOPACKS-ENGINE-BRIEF-01 status: DRAFT — §5 drafted from instruments (F2025L00354 + ASQA practice guides v1.0); three residual ⟨TIM/JIMMY⟩ items open (hand-raise tolerance, lived sign-off practice, performance-assessment colour). Tim's call whether it crosses with those open or filled. layer: crossing artefact (original of record filed RTOpacks side; copy crosses per FENCE-PROTOCOL-01) canonical: false authored: 2026-07-01 NYC — architect draft from RTOpacks canon; domain content pending voice: a client's brief to its vendor. RTOpacks states what it needs and why; the engine assesses. Authorship direction per FENCE-PROTOCOL-01 §2. relates_to: ENGINE-BENCH-CONTRACT-01 (the agreed model and honest ledger this brief is built from); WS-PRODUCT-01 (the anchor — "the engine raises hands; it never signs"); STUDIO-TEACH-ASSESS-WORKBENCH-01 (the self-authored mode's surface); FENCE-PROTOCOL-01 (governs this crossing) supersedes: nothing this side. Renders UCCA-RTOPACKS-NEEDS-01 (engine-side draft, withdrawn) obsolete — that doc was authored on the wrong side of the fence and dies unfiled.

RTOpacks' Brief to the UCCA Engine¶

Directive to the UCCA side (read first — you are new to this protocol too).

This is a client brief under FENCE-PROTOCOL-01. What we want back is a written assessment, filed your side, copy crossing back, that:

Answers each numbered requirement in §2–§4 with one of three verdicts — YES / NO (with reasons) / ADAPTER, NOT GATE — plus a sentence of reasoning per verdict. A table is fine; reasons are not optional.

Does not edit or redline this document. If a requirement is malformed, say so in the assessment and we will re-cross a revised brief.

States, for every YES, what the engine needs from us to deliver it (inputs, formats, sequencing) — as questions back, not assumptions filled in on our behalf.

Flags anything in this brief that fails your drift-check ("only works because the client is VET") even where we thought it didn't. That check working is the point.

Suggested doc_id your side: UCCA-ASSESSMENT-RTOPACKS-BRIEF-01. File it as your original; we file the received copy verbatim.

§5 of this brief is domain truth from the client's compliance authority. It is not assessable — it is the ground your assessment must not contradict.

1. Who the client is¶

RTOpacks is a compliance platform for Australian Registered Training Organisations operating under the SRTOs 2025 regime. Its market requires human professional judgement on the record: material an RTO relies on must be defensible at audit, and the accountable signature on it must be a qualified human's.

RTOpacks buys reasoning about how instructional and assessment material relates to a unit's requirements — pointed in two directions. Course creation is one use case of that reasoner, not the engine's identity. RTOpacks is one client; this brief is written so it can be assessed like any client's.

2. Services requested¶

R-1. Forward generation, as a service across the boundary. Accept a validated triumvirate-shaped job across the API and return generated material whose coverage of the obligation is traceable by construction (analysis first, generation falling out of it — not generate-then-check), wrapped in the UCCO envelope with full provenance. We know generation is proven on disk (one unit, Dec 2025); what we require is that capability as a service across a boundary, which it is not yet.

R-2. Backward diagnosis (the crown). Accept a validated triumvirate plus the client's existing human-authored material, and return the engine's account of its own reasoning: where it cannot trace coverage. Hand-raises, never verdicts — "I cannot reason how this meets requirement X; look here." It does not correct, does not author, returns the pen. We know from the shared recon that this is unproven; we are briefing it as a requirement so its build (or proof) is sequenced against a stated client need, not speculation.

R-3. Contextualisation as request parameters. Voice / jurisdiction / audience adaptation of generated material, supplied as parameters of a generation request — never as engine knowledge of our domain resident inside the gate.

R-4. Contract stability for the unbuilt direction. Expose at minimum a stub endpoint shape for diagnosis in the first API contract, so the contract does not churn when the crown lands. We would rather integrate against a stub that 501s honestly than re-plumb the boundary twice.

3. Boundary requirements (what we require the engine to refuse)¶

B-1. Never sign. No output may constitute or imply a compliance verdict. Alerts are epistemic hand-raises returned to a qualified human. This is not a preference — it is the property that makes our artefacts audit-defensible, and it must hold even when the engine is wrong: a false alert costs our human ten seconds; a false blessing cannot occur because the engine never blesses.

B-2. Never hold our IP. Process and return. Our corpus, context, and outputs live in our world; the engine retains provenance records, not content.

B-3. Never be visible. Zero engine fingerprinting on any surface an RTO sees. The RTO's relationship is with RTOpacks.

B-4. Never ingest our shape. The engine accepts triumvirate-conformant jobs only. All VET-specific translation (TGA units, AQF levels, packaging rules, SRTOs clauses) lives in the TGA adapter, our side of the gate.

B-5. The mode is on the record. Whether a job ran self-authored (backward) or assistive (forward) is part of the artefact's provenance. Our users choose which direction touches their work, and that choice must survive into the record.

4. Delivery requirements¶

D-1. API only. The boundary in ENGINE-BENCH-CONTRACT-01 §5 is physical. No shared code, no imported internals, no "just for now."

D-2. No local dependency. Nothing in the delivery path may depend on the Mac Mini or any local process. Cloudflare-first on our side; your side's infrastructure is yours, but the contract surface must be reachable as a service.

D-3. Ingest via our export path. Corpus reaches the adapter through our export pipeline (Power BI Excel exports into our regulated store). The engine does not scrape or fetch from training.gov.au. Any earlier design implying network acquisition on cache-miss is superseded.

D-4. Isolation inherited, not negotiated. Per-world database, per-client adapter instance, per-client audit namespace — independently freezable, exportable, deletable.

D-5. Sign-off lives our side. The human countersign is a world-layer workflow in RTOpacks. The UCCO envelope carries the engine/adapter signature over provenance only — it never carries, implies, or substitutes for the human's compliance signature. (This answers the dual-signature ambiguity in the March design: the expert co-signs at issuance in our workflow, not in your envelope.)

5. Audit-defensibility — the domain ground¶

The ground your assessment must not contradict. Drafted from the primary instruments and ASQA's published practice guides; sources named per subsection. Three items remain open to the client's compliance authority, marked ⟨TIM/JIMMY⟩ — everything else is instrument-anchored and verifiable.

Governing instruments. The Outcome Standards for NVR Registered Training Organisations Instrument 2025 (F2025L00354, commenced 1 July 2025) and its companion Compliance Standards, plus the Credential Policy, together forming the SRTOs 2025 regime. ASQA's Practice Guides (v1.0, published 17 June 2025) are the regulator's own published account of what its assessors look for, standard by standard. ASQA reviews are conducted as performance assessments organised around three questions: is practice compliant, is there a working system assuring ongoing compliance, and does the provider self-assure — monitor, review, and improve its own operations. Material is tested inside that frame, not as a document checklist.

5.1 What the regulator tests about the material itself¶

Under Quality Area 1 of F2025L00354:

Standard 1.3 (assessment system fit-for-purpose): assessment must be consistent with the requirements of the training product; assessment tools must be reviewed prior to use against the principles of assessment and rules of evidence; and review outcomes must inform changes to the tools. A tick-box review does not satisfy this — ASQA's named known risks include "generic templates or checklists to conduct the review of assessment tools prior to use" and "reliance on generic purchased assessment tools that are not contextualised" to cohort, environment, and training product.
Standard 1.4 (fair and valid assessment) imposes two distinct lenses, and the distinction is load-bearing for the engine:
Principles of assessment — fairness, flexibility, validity, reliability — apply to the design and use of the assessment system itself.
Rules of evidence — validity, sufficiency, authenticity, currency — apply to individual assessor judgements. The assessor must be able to justify each competency determination against all four.
Systems satisfy the principles; judgements satisfy the rules. The engine's coverage tracing operates at the first lens (is the tool built so the requirement is assessable); the human's override record lands at the second (is this judgement justified). The engine must never conflate the two.

5.2 The bar for R-2's hand-raises (what "good enough" means)¶

The bar is not accuracy — B-1's never-sign property already makes the system sound against an imperfect engine. The bar is vocabulary: a hand-raise is useful to the extent it names the failure in the regulator's terms.

"I cannot trace how this performance-evidence item is assessed by any instrument in this tool" is a Standard 1.3 finding in embryo. "This tool appears uncontextualised to the stated cohort" is a named ASQA known risk. Hand-raises that map onto the Standards and the known-risk catalogue are audit-relevant evidence; hand-raises in generic quality-speak are noise.
The calibration corpus exists and is ours to supply: every ASQA practice guide closes each standard with "Known risks to quality outcomes" — the regulator's curated list of what assessors actually flag. That catalogue (QA1 for material; CP for credentials) is the reference set the engine's hand-raise taxonomy should resolve against. It crosses as adapter-side domain content per B-4 — the engine reasons over the triumvirate; the adapter translates its findings into this vocabulary.
A false alert is not merely tolerable — the override is evidence. When our qualified human records "no, that's covered, here" against a hand-raise, that is documented professional judgement of exactly the kind Standard 1.4's rules of evidence demand and Standard 1.5's validation process consumes.
⟨TIM⟩ Tolerance threshold remains ours to set: how many false alerts per unit before the product is unusable to a working course-developer. Product judgement, not regulation — to be calibrated in the bench build, not answered by the engine.

5.3 What the human sign-off must be¶

Per Standard 1.4, the accountable judgement is the assessor's, justified against all four rules of evidence. Per the Credential Policy, the signer must hold the specified credentials, and persons working under direction must not make assessment judgements — ASQA's self-assurance questions probe exactly this. Per Standard 3.3, an engaged expert involved in assessment judgement conducts it alongside the credentialled assessor, never alone.
This is why D-5 stands as written: the compliance signature is a world-layer act by a credentialled human in our workflow. Anything in your envelope that could read as a judgement of competence or compliance would put an unqualified, non-human signature where the regime demands a qualified human one.
⟨TIM/JIMMY⟩ Lived practice remains open: who actually signs at a working RTO (assessor vs RTO manager co-sign patterns) and what the day-to-day judgement record looks like beyond the instrument's minimum. To follow from the compliance authority; nothing in it will loosen the instrument-anchored floor above.

5.4 What provenance must be showable¶

From the practice guides' "example activities" columns — the regulator's own statement of what evidence it accepts:

Records of pre-use review of assessment tools, with substantive notes (see the generic-checklist known risk), and evidence that review outcomes changed the tools.
Contextualisation evidence on any imported or generated tool — how it was fitted to cohort, environment, and product.
Validation records in which the validator had access to the same evidence the assessor used, with a demonstrable link between evidence and judgement.
Therefore: the UCCO envelope's provenance must be renderable into RTO-facing evidence — the RTO must be able to show, in its own artefacts, that a tool was reviewed, by whom, against what, with what outcome. Engine-internal provenance that cannot surface into this shape (without violating B-3's invisibility) fails the client's purpose. This is the acceptance test behind your Q-C: the Dec 2025 run bundle's provenance is sufficient iff the adapter can render it into Standard 1.3/1.5 evidence shapes.

5.5 Validation cadence — R-2 is recurring, structurally¶

Standard 1.5 (F2025L00354) requires:

Every training product on scope validated at least once every five years, and more frequently where risks to training outcomes, product changes, or feedback from students, trainers, assessors, or industry indicate.
A risk-based approach to selecting which components of the assessment system and what sample size to validate.
TAE products: validated once the first student cohort completes, by a person independent of the organisation — not employed or subcontracted by it, with no other interest in its operations.
Validation outcomes must feed changes to the assessment system — the loop must demonstrably close.

Consequence for R-2: diagnosis is not a one-shot pre-release check. It is a service the client will invoke on a recurring, risk-triggered cadence across a whole scope of registration, and its reports become inputs to the validation evidence chain. Sequencing and pricing assumptions on your side should treat R-2 as a standing workload, not a build-time gate.

⟨TIM/JIMMY⟩ Performance-assessment experience remains open: what a real assessment feels like from the provider's chair — what gets requested first, where providers actually bleed, rectification windows in practice. Colour from the compliance authority; the instrument-anchored content above stands regardless.

6. Non-requirements (recorded so they can't creep)¶

We do not require, and must not receive: domain knowledge inside the gate; qualification assembly (world-layer concern, ours); output-format awareness (our Creation Backplane's concern); a compliance verdict in any form; real-time TGA synchronisation (D-3 is the ingest path); engine telemetry or identity surfaced to our end users.

7. What we want back (restated for clarity)¶

One document: UCCA-ASSESSMENT-RTOPACKS-BRIEF-01, per the directive block above. Verdicts on R-1 through R-4, B-1 through B-5, D-1 through D-5. Questions back where the engine needs inputs from us. Drift-check flags where we missed our own test. No redlines. One crossing at a time — this is the crossing in flight.

A client's brief, authored client-side per FENCE-PROTOCOL-01. The engine reasons over the obligation; we translate our world to triumvirate shape and return human judgement to the record. The actor changes; the obligation does not — and neither does who holds the pen for whose needs.