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-CONTRACT-PACK-01 (assembled from it).

title: RTOPACKS-RESPONSE — answers to the assessment's questions back (Client One → engine) doc_id: RTOPACKS-RESPONSE-TO-ASSESSMENT-01 status: CROSSED — all answers filled; Q-R1a filled with real PITH sample extracts (names + SHA-256), supplement at crossings/attachments/QR1A-samples/. Q-R1a mechanism corrected to the real ingestion path (see RTOPACKS-CORRECTION-01). layer: crossing artefact (original of record filed RTOpacks side; copy crosses per FENCE-PROTOCOL-01) canonical: false authored: 2026-07-01 NYC — architect draft; slots marked voice: a client answering its vendor's intake questions. Positions stated plainly; where a value is provisional it says so. relates_to: UCCA-ASSESSMENT-RTOPACKS-BRIEF-01 §3 (the questions); ADDENDUM-01 §A-3 (Q-A3); FENCE-RULING-RECORD-01 / UCCA-FENCE-RULING-RECORD-01 (closed items); RECORD-SPEC-01 (evidence model); F2025L00354 + ASQA practice guides v1.0 (Q-A3 ground)

RTOpacks' Response to the Assessment¶

Answers Q-R1a through Q-D3 from the parent assessment plus Q-A3 from the addendum. Q-R2b and Q-B4 are closed (addendum + rulings) and not re-answered. One crossing; the sample exports (Q-R1a) accompany it as data.

Q-R1a — Sample corpus exports¶

Three real PITH extracts accompany this crossing as the attachments supplement (crossings/attachments/QR1A-samples/) — real bytes off our TGA-API ingestion path (structured store + R2 raw-JSON archive). Per unit: the structured content row + qualification packaging context (with the packaging parse's retained raw_input and its confidence flag) + the R2 raw TGA JSON (current and one dated snapshot, byte-identical here — the current pointer is the latest dated write). Three units — clean, middling, and one genuinely ugly. Design against these bytes. (Hash-chain + query shapes in MANIFEST.md, §C-3.)

SITTIND003 (clean) — structured ea5620197923aa3064ab6e5684f316322dcc282d0ba909f7d8a778ee919c2a20 · raw d4eed3e53ccfdcdf3578c279919d94442b7dfc167d0d1559db0a864a6fc9c59a · raw.2026-06-28 d4eed3e53ccfdcdf3578c279919d94442b7dfc167d0d1559db0a864a6fc9c59a
HLTAHA049 (middling — HTML entities) — structured 483cb49486fbaf4693e9f8c7cbb98063bb96bf31ebc4a440956b209c979ddd09 · raw b8840e977d6a8bf433996408e63771d9077a0bd9d4fc9824c856f7ff2da3c3d1 · raw.2026-06-28 b8840e977d6a8bf433996408e63771d9077a0bd9d4fc9824c856f7ff2da3c3d1
MSL975041 (ugly — NULL performance_criteria + HTML in knowledge_evidence) — structured 3535e9f246a0e3ae8cfcf119203ac349fb474033984daba874ef193fcd074fab · raw 8a9108028d37edf3e063ccd16ca346026df42dd6dc6e82a12a3c6a7712d80317 · raw.2026-06-27 8a9108028d37edf3e063ccd16ca346026df42dd6dc6e82a12a3c6a7712d80317

Q-R1b — Interactive vs batch¶

Both, by direction — and the contract should be async-first regardless:

Forward generation (assistive, at the canvas): interactive-async. A user is waiting; seconds-to-low-minutes tolerance; the bench surfaces progress. But "the user waits" is our presentation-layer choice — at the contract we want submit → job-id → poll/webhook, never a long-held synchronous call.
Backward diagnosis (recurring, corpus-scale): batch. A queue drains across a scope of registration on validation cadence. Same async contract, different consumption pattern.

One async model serves both; interactivity is client-side UX, not a contract property. No latency guarantee is requested at this stage. As a UX design point (not a contract term): ~2 minutes per unit is the working threshold at the bench, beyond which our presentation shifts to notify-when-done. Latency scaling with requested density is expected and acceptable — it maps to our consumption/credits model, where more density costs more and notionally takes longer. Any SLA is a commercial discussion for later, both sides. (Downstream media generation — video and the like — is world-side post-processing after your text returns; not an engine ask.)

Q-R1c — What we parse from the envelope vs pass through¶

We parse (and therefore freeze with the contract):

The content payload — generated material, structured, for rendering onto the Studio canvas as nodes.
The trace map — requirement ID ↔ generated element, at source_ref granularity. This drives both the canvas (coverage display) and the evidence rendering (Q-A3).
The provenance block — run identity, timestamps, input hashes, triumvirate schema version, contextualisation brief ID + hash, direction of run (A-2/B-5), and for diagnosis: hand-raise IDs (stable, per A-5). This is what the adapter renders into Standard 1.3/1.5 evidence shapes.
Signatures — verified at receipt, then stored.

We pass through opaquely: any engine-internal reasoning artefacts, model/runtime metadata, and anything else in the envelope not named above. Evolve those freely; version-bump the four parsed surfaces.

Q-R3 — Contextualisation: one slot, opaque payload¶

Withdrawing the enumerated-list shape — it is a hangover from the engine's single-purpose era (hand-steered transliteration: "CASA→FAA, metres→feet"). The real contextualisation input is a written brief — potentially long, specifying market, operator, terminology, regulatory colouring of examples, audience — and its internal structure is world-side product design we have deliberately not done yet (it is the parked contextualisation-input problem in our assistive sub-fork).

What the contract therefore carries — deliberately minimal:

One slot: contextualisation_brief — opaque payload (verbatim text, optionally with client-side structured fields the engine ignores), plus a client-assigned brief ID and brief hash.
The engine applies it as generation guidance only — request payload, never engine knowledge of our domain (B-4 / R-3 as assessed).
The engine echoes ID + hash in provenance, so our contextualisation evidence (Q-A3.B) cites exactly what was applied, verbatim, retrievable our side.

This is stronger for the gate than enums: nothing client-shaped freezes into your schema, and we can evolve the brief's structure indefinitely without a contract change. When our Studio-side design work produces a structured brief format, that structure is ours; you keep receiving one opaque, hashed payload.

Q-B2 — "Provenance records" the engine may retain¶

Confirmed as the engine's stated position, exactly: hashes, structural traces, audit events, and signatures — never content bodies. That is B-2's intent with no narrowing. Structural traces means shape and reference (requirement IDs, element IDs, counts, versions), never text of our corpus or outputs.

Q-D3 — Hash discipline at ingest¶

The hash chain has three links, each recorded, so identity survives from export to job:

export_hash — over the raw export file's bytes exactly as received at the adapter, before any parsing, cleaning, or normalisation. This is the anchor that survives audit: it names the artefact a human could re-produce from the source system.
corpus_hash — over the adapter's normalised corpus derived from that file (deterministic normalisation, so re-running it on the same export re-produces the hash).
triumvirate_hash — over the conformed job as signed and submitted; this is the one that crosses the gate and the one the engine's provenance cites.

Each link records its parent, so any envelope traces back to raw bytes without any content crossing. If the engine's contract needs only the third, record it as citing a corpus_hash it never sees the preimage of — that is the point.

Q-A3 — Field-level requirements for the rendered evidence shapes¶

The question that lets the provenance schema freeze verified-complete. Sources: F2025L00354 Standards 1.2, 1.3, 1.4, 1.5; ASQA Practice Guides QA1 (example-activities columns and known risks); Credential Policy §§3A–3B; RECORD-SPEC-01 (the evidence model these render into — generated artefacts carry provenance in the artefact record; evidence is linked, never duplicated).

A. Pre-use review record (Standard 1.3)¶

What the rendered artefact must contain:

Field group	Fields
Tool identity	tool title; tool version; training product (unit code + release); delivery context (mode, environment); cohort descriptor
Review identity	reviewer (person); reviewer credential status at review date (People link); review date
Review substance	per-criterion notes against the principles of assessment (fairness, flexibility, validity, reliability) and rules of evidence (validity, sufficiency, authenticity, currency) — substantive text per criterion, not booleans (ASQA known risk: "generic templates or checklists")
Coverage trace	each requirement of the training product (elements/PCs, performance evidence, knowledge evidence, assessment conditions) → where in the tool it is assessed. This is the trace map, rendered — the engine's requirement↔element mapping is the raw material
Outcome & loop	fit-for-use determination; changes required; evidence review outcomes informed changes to the tool (1.3's close-the-loop indicator)
Provenance (internal)	run reference, input hashes, triumvirate version — held in the artefact record per RECORD-SPEC, never on the RTO-facing face of the artefact (B-3)

What the envelope must therefore supply: the trace map at requirement granularity; the triumvirate version; input hashes; run identity and timestamps. The review substance and outcome are human-authored world-side — the engine supplies the trace, never the judgement (A-2).

B. Contextualisation evidence (Standards 1.3 + 1.2 linkage)¶

Field group	Fields
Base identity	base tool/material + version; target training product + release
Target context	cohort descriptor; learning environment; delivery mode — the three things ASQA's known risk says generic tools fail to fit
What changed	the deltas (or generation parameters where material was generated contextualised): the contextualisation brief applied (ID + hash, content retrievable verbatim our side) (Q-R3), plus any human contextualisation applied after
Why	rationale linking each delta to a cohort/environment/product characteristic; industry or employer input where it informed the change (Standard 1.2 linkage)
Re-trace confirmation	statement that requirement coverage was re-verified post-contextualisation (the trace map holds after the changes)
Identity & date	who contextualised; credential status; date

What the envelope must therefore supply: the contextualisation brief's ID + hash as applied (content held our side), and a trace map that survives (or is re-emitted after) contextualised generation.

C. Validation record (Standard 1.5) — included for completeness per §5.4¶

Field group	Fields
Scope	training product; components of the assessment system validated; sample size with the risk rationale for both (1.5's risk-based indicators)
Validator identity	person(s); collective credentials per Credential Policy §§3A–3B (People link); independence attestation for TAE products (not employed/subcontracted, no other interest)
Evidence parity	confirmation the validator had access to the same evidence the assessor used
Findings & loop	findings; outcome; changes to the assessment system flowing from the outcome, with the change evidence linked (close the loop, again)
Cadence	validation date; next-due derivation (five-year floor, risk triggers)
Diagnosis inputs	where engine diagnosis reports were consumed: report IDs (dated, versioned, referenceable per A-4), overridden hand-raise IDs with the human's override notes (A-5 — the override is Standard 1.4 evidence)

What the envelope must therefore supply (diagnosis direction): report identity (dated, versioned, citable), stable hand-raise IDs, and per-raise the exact requirement not traced at source_ref granularity.

The completeness test (answering the question as asked)¶

The provenance schema is verified complete when every "what the envelope must therefore supply" line above is satisfiable from the envelope alone, with no side channel. Concretely, the schema must carry: trace map (requirement↔element, source_ref granularity) · triumvirate schema version · input hash (the triumvirate_hash, citing a parent it never sees) · run identity + timestamps · direction of run · contextualisation brief ID + hash · and for diagnosis: report ID + stable hand-raise IDs + per-raise requirement refs. Everything else on the rendered artefacts is world-side human content by design.

Q-R2a — Human-authored material formats (for diagnosis)¶

Ruled (Tim, 2026-07-01): raw client formats never cross the gate. RTOpacks ingests and normalises all human-authored material world-side into a canonical document representation — structured text + images (JSON-shaped, versioned) — and that is what a diagnosis job carries. Read once at the door; manipulate the canonical form thereafter. Consequences:

The engine parses exactly one document format: ours, spec'd in the contract. No docx/PDF/OCR plumbing inside the gate — the conformer ruling (sender conforms) applied to documents. The canonical-form spec becomes contract surface alongside the triumvirate and envelope schemas.
The hash chain extends (per Q-D3's pattern): raw_document_hash over the file as received from the RTO → normalised_document_hash over the canonical form the job cites. Originals are retained world-side in Record's evidence repository, linked and hashed — the normalised form is the working copy, never a replacement for the audit artefact.
Unreadable inputs are a world-side ingestion outcome, not an engine outcome class. The engine only ever receives well-formed canonical documents.

For your stress-testing interest only (what our ingestion door will face, most common first): docx, text PDF, xlsx mapping matrices, pptx, scanned/image PDF (legacy — OCR-dependent, quality floor enforced at our door). None of it reaches you.

(World-side note: normalise-at-ingest is an RTOpacks ADR candidate; mints at build proof.)

Closed items (not re-answered)¶

Q-R2b — closed by ADDENDUM-01 (recurring; bar = vocabulary; tolerance ⟨TIM⟩ residual). Q-B4 — closed by the ruling records both sides (conformer ours, gate theirs, warranty boundary at the gate).

Client One answering its vendor: async-first contract, four parsed envelope surfaces frozen, three hash links back to raw bytes the engine never sees, three parameter slots whose values our evidence records verbatim, and the field-level ground that lets the provenance schema freeze verified-complete. Three slots open before it crosses; nothing in them moves the architecture.