title: "RPL — Spec" document: rpl-02-spec method_move: 4 (Spec) status: RATIFIED — READY TO FILE (2026-07-07). Substantive spec §1–§11 complete and ratified; NOT yet committed. §1 (build in one line), §2 (data model, practice-guide-reconcile amendments folded in), §3 (application state machine as an Accreting Review), §4 (evidence-normalisation adapter contract), §5 (engine seam contract), §6 (assessor workbench + fail-closed signing gate), §7 (intake consumption), §8 (outcome layer), §9 (deferred calls resolved), §10 (clause-bound field register — its fresh read caught and corrected an anchor-convention drift across §1–§9: internal obligation-IDs 1.6-N/1.7-N had been qualified "within F2025L00354"; all 20 occurrences normalised to real clauses; no filed doc affected), §11 (build-gate hand-off). The four design calls are ratified (§4.5 trace-map home, §4.6 currency recency-check, §4.8 assessor-conducted-forms home, §9.2 export serialisation) and the two §6 spec-originations confirmed (§6.2, §6.5). Next: the filing brief. Do not build from this until filed. pairs_with: rpl-01-model (the model this derives from), rpl-00-obligations (the acceptance surface this satisfies) consumes: - accreting-review-01-model (the review/supplement loop; §3 parameterises it, does not re-spec) - intake-pipeline-01-model (every intake-side surface; RPL parameterises, does not re-spec) - usi-registry-ext-api (USI constraints; all registry operations day-two) - people-01-model / people-02-spec (the canDeliver contract at the signing gate) authority_instruments: - F2025L00354 — Outcome Standards for NVR RTOs (Standards 1.4, 1.5, 1.6, 1.7, 3.2, 3.3) - Student Identifiers Act 2014 — the meaning of student_identifier (USI) layer_3_sources: - Practice Guide: RPL & Credit Transfer (Std 1.6, 1.7) — practice-guide-qa1 - Practice Guide: Assessment (Std 1.3, 1.4, 1.5; ASQA, 17 June 2025) — rules of evidence, principles of assessment, the reassessment/supplement obligation substrate_naming: cloudflare-naming-canon.md (names bound here are subject to build-time verification against cloudflare-resource-inventory.md) authored: 2026-07-07 NYC — RTOpacks-side Claude, for Tim's ratification method: legislation-to-tile-method.md (this is move 4 for the RPL tile)

✓ RATIFIED — READY TO FILE. This file carries the whole substantive spec, §1–§11, with the four design calls ratified 2026-07-07 (§4.5, §4.6, §4.8, §9.2) and the two §6 spec-originations confirmed (§6.2, §6.5). It files via a single docs-only brief; not yet committed. §10's fresh read caught and corrected an anchor-convention drift across §1–§9 (internal obligation-IDs qualified as instrument clauses; all 20 occurrences fixed to real clauses, §10.3); no filed document was affected. The §2 evidence and judgement tables carry the amendments agreed from the Assessment Practice Guide reconcile (evidence provenance; assessor-conducted evidence; third-party verification; required defensible rationale; the reasonable-adjustments note). §3 parameterises the Accreting Review over unit-claims and wires the eight discharging events; §4 specifies the evidence-normalisation adapter and carries three design calls, ratified (trace-map home; currency recency-check split; assessor-conducted evidence forms' home); §5 binds the engine seam; §6 specifies the assessor workbench and the fail-closed signing gate against People's canDeliver; §7 states RPL's grades on the shared intake pipeline; §8 gives the outcome layer as one record in three presentations; §9 resolves the six deferred calls (licence source; the neutral export shape, carrying a fourth ratified call on serialisation; naming; the gap hand-off; configured policy values; copy constraints); §10 is the clause-bound field register and the anchor-drift correction. This is a continuity snapshot, not a filing candidate.

RPL — Spec¶

Move 4 of the Legislation-to-Tile Method for the RPL tile. The obligations (rpl-00) said what the RTO must demonstrate; the model (rpl-01) modelled the tile as the answer; this spec derives the buildable surface from that model and binds every regulated field to its clause. Where this spec and the model appear to differ, the model governs the why and this spec governs the what — a conflict is a defect to reconcile, not a choice.

The single load-bearing fact, carried whole: RPL is an assessment process (1.6 / F2025L00354), so the judgement is the assessor's. No surface, table, or code path in this spec issues an RPL outcome without an assessor's recorded signing act (rpl-01 §1A). Every structure below is shaped by that.

What this spec originates vs consumes. The intake surfaces (invite → self-complete → capture → submit → deliver) are settled in intake-pipeline-01-model and consumed here, not re-specced (§7). The review/supplement loop is settled in accreting-review-01-model and consumed by the state machine (§3), not re-specced. All USI registry operations are day-two behind usi-registry-ext-api (§7, §8). What this spec originates: the RPL data domain (§2), the application state machine wired to the eight discharging events and parameterising the Accreting Review (§3), the evidence-normalisation adapter contract (§4), the engine seam contract (§5), the assessor workbench and fail-closed signing gate (§6), and the outcome layer's three presentations (§8).

1. The build in one line¶

RPL Application = (candidate × target training product × units claimed) → per-unit assessor judgement { granted | gap → determination or supplement→reassess | not granted }, evidenced, sealed, and consumed one of three ways: held (always), exported to an SMS (neutral shape), or retrieved locally (no-SMS RTOs).

The tile's primitive is the application (rpl-01 §3). Evidence attaches to it, the anchor map is an instrument over it, the judgement is a property of it, the outcome exports or is retrieved from it. Judgement is per unit; evidence tracing is per leaf beneath the unit; the bar is the national product's component classes read from the Pith (rpl-01 §2). The application is reviewed as an Accreting Review (§3): unit-claims are its sections, the signing act is the lock, a gap-notation is a return that re-supplies through the intake pipeline.

2. The data domain¶

Per the MANDARIN taxonomy, the HARD SEPARATION RULE, and the ops-db invariant (customer surfaces bind ops-db never — standing rule, amended 2026-07-04). Names follow cloudflare-naming-canon; the boundaries are the model's (rpl-01 §15) and do not move with naming.

2.1 Stores¶

Store	Canonical name (Peel/pair)	Class	Holds
RPL tile domain	`rtopacks-rpl-prod` / `rtopacks-rpl-dev` (D1)	Peel	Applications, unit claims, anchor-map metadata, judgements, gap determinations, outcomes, pathway-fork records, licence-linkage flags, the review/approval + correspondence substrate (§3, Accreting Review), the RPL event ledger
RPL evidence vault	`rtopacks-rpl-evidence-prod` / `-dev` (R2)	Sealed custody	Evidence artefacts (candidate-submitted, assessor-generated, third-party), digest-sealed and immutable; sealed engine-findings objects; amendments are new objects; retention floor = audit window
Candidate-identity store	`rtopacks-candidates-prod` / `-dev` (D1)	Shared Peel	Candidate identities, USI (specially handled), intake attestations' identity side. Owned by neither RPL nor LLND — name first-bound here, cited by `llnd-02`; entry UI-only via the intake pipeline; invisible to the seat model
Pith	`nrt-corpus-ref` (D1)	Reference	The bar: products, units, component classes, supersession. Read-only always; KN sacred
Pipeline state + capture custody	the pipeline's stores (`intake-pipeline-01-model` §7)	—	Referenced, never owned here. The stage-4 seam hands sealed bytes to the RPL vault; it does not absorb pipeline custody

Customer-facing RPL surfaces read the Pith and their own Peel stores; ops-db is never bound. People is consumed through its contract (§6), never through its tables. The RPL event ledger's exact substrate (tile-domain table vs a shared audit store) binds at build against the resource inventory; the content is the model's (§3).

2.2 The core tables (`rtopacks-rpl`)¶

Each regulated field carries its clause trace; the full anchor / obligation / consequence per field is collected in the field register (§10, pending). Below is the shape and the load-bearing regulated fields, with the practice-guide-reconcile amendments folded in.

rpl_application — the entity spine (rpl-01 §3). Candidate × target product × the application-level state the obligations require. - candidate_ref → rtopacks-candidates (never a People person, never a seat) - target_tga_id → Pith (national identity; composition resolved from the list, rpl-01 §2) - status — the state-machine position (§3; the application is an Accreting Review submission) - submission_version — monotonic per application; each submit freezes a snapshot (Accreting Review §3) - pathway_fork_ref → rpl_pathway_fork (the fork it arrived through, 1.6-1 / 1.7-1) - overseas_evidence_flag — set where any evidence item is overseas-sourced (day-two path named, never silently assumed — rpl-01 §12) - licence_linked_flag + licence_note — manual per-product flag at launch (1.6-2 licensing caveat; fail-toward-caution where set) - reasonable_adjustments_note — [AMENDMENT] optional; records reasonable adjustments considered/applied for this candidate, so the fairness discharge is recordable (1.4(a)(i) fairness / F2025L00354). Launch, light-touch — a note, not a workflow - third_party_disclosure_ref — reserved, day-two (1.6-4)

rpl_unit_claim — the per-unit claim (rpl-01 §3); a section in the Accreting Review (§3). Judgement, evidence tracing, gap identification, and outcome all resolve per unit. - application_ref, unit_tga_id → Pith - claim_state — { claimed | traced | gap_identified | returned_for_supplement | granted | not_granted } (only the signing act sets granted/not_granted; returned_for_supplement is the Accreting Review return, §3) - lock_state + approved_at_version — the accreting-approval binding (Accreting Review §4); a granted unit locks; content-change to its evidence re-opens it, cascading to units sharing a leaf

rpl_evidence_item — bundle metadata; bytes live in the vault (rpl-01 §5). - application_ref, vault_object_key, digest (sha256 sealed at landing) - provenance — [AMENDMENT] { candidate_submitted | assessor_generated | third_party }. The load-bearing distinction the Assessment PG forced: sufficiency is rarely met by candidate-submitted evidence alone (1.4(b)(ii) sufficiency / F2025L00354); the assessor-generated forms below are how the tile hosts the competency conversation and the practical observation that clinch it - source_type — portfolio / employment-record / reference / third-party-report / transcript / work-sample / competency-conversation / practical-observation (RTO-configurable taxonomy — 1.6-3 requires accommodating variety; not a closed model constant) - overseas_sourced_flag (feeds the application flag) - authenticity_attestation_ref → the candidate attestation sealed at intake (1.6-5, rpl-01 §6). For assessor_generated items the attestation is the assessor's, not the candidate's - third_party_verification_ref — [AMENDMENT] for provenance = third_party: a recorded verification action { who was contacted, when, method, outcome } feeding the authenticity ruling (1.4(b)(iii) authenticity / F2025L00354; the PG's "unverified third parties" risk). Named as an authenticity affordance, not a mandated mechanism - recording_ref — [AMENDMENT] where an assessor-generated competency conversation is recorded (audio/video): biometric-adjacent sensitive data; consent-captured and retained per the intake pipeline's §5 posture even though it vaults RPL-side - adapter_section_ids[] — the stable-id'd sections this artefact produced (§4); empty for image/video/observation items (out of adapter v1, vaulted and read by the assessor directly — rpl-01 §5.2)

Assessor-conducted evidence — [AMENDMENT], the workbench forms (§6). Not candidate-facing conduct mode (that is day-two, on the tokened surface). These are assessor-side workbench affordances; the assessor conducts the activity (in person / by call) and records it, where it vaults as assessor_generated evidence and feeds the per-leaf marking and the sufficiency ruling: - Competency-conversation record — structured Q&A tied to knowledge-evidence leaves; the full question-bank instrument drawing questions from Studio content is day-two, the recording surface is launch (1.4(a)(iii) validity; 1.4(b)(ii) sufficiency) - Practical-observation record — the assessor's observation of the candidate performing a task, live or via video; answers the PG's known risk of tick-box evidencing of practical assessment

rpl_anchor_map / rpl_finding — engine-assisted mode only (rpl-01 §5, §7). Per-leaf finding metadata for the workbench; the sealed findings object lives in the vault. - unit_claim_ref, leaf_ref (element / performance-criterion / performance-evidence / knowledge-evidence id from Pith) - finding — TRACED | NOT_YET_TRACED (subject-locked; no pass/fail/competent vocabulary — rpl-01 §7) - verbatim_anchor_span, adapter_section_ref, vault_digest_ref — the trace chain: leaf → anchor → section → vaulted digest (rpl-01 §5). An anchor that cannot resolve to sealed bytes is not evidence and fails the job.

rpl_judgement — the signing act, per unit (rpl-01 §9; the foundational negative rule §1A). The outcome entity cannot exist except as the product of this record. - unit_claim_ref, assessor_person_ref → People - verdict_snapshot — sealed: People's canDeliver verdict + evidence pointers + the policy/list versions it was computed against (the permanent answer to "was this assessor credentialled at the time" — §6) - sufficiency_ruling, authenticity_ruling, currency_ruling — the assessor's rulings on the three rules the engine cannot hold (rpl-01 §6) - defensible_rationale — [AMENDMENT] REQUIRED narrative. The signing gate is un-signable without it — same fail-closed posture as the People verdict. Directly discharges 1.4(b) ("assessment judgements that are justified") and 1.6-10 (documented, defensible); answers the PG's "missing rationale" pitfall - signed_at — the discharging moment (e6); this act is the Accreting Review lock for the unit

rpl_gap_determination — the gap-training answer (1.6-13, rpl-01 §10). Distinct from the judgement: the judgement identifies the gap; this answers it. One of two paths at a gap — gap training (this record) or supplement-and-reassess (the Accreting Review return, §3). - application_ref (or unit_claim_ref), amount, delivery_mode, cost, worked_with_candidate (affirmed), pathway_pointer — Studio content ref or external (hand-off wired day-two, §9)

rpl_outcome — the export/retrieval source (rpl-01 §13). Per unit: granted / not-granted, gap + determination attached, sealed with the verdict snapshot. The single record all three §8 presentations read (held / SMS-neutral export / local retrieval). - student_identifier carried in its Act-defined meaning (never in a URL or message body — §7, §8)

rpl_pathway_fork — CT-vs-RPL at intake (1.6-1, 1.7-1, rpl-01 §11). - determination — { credit_transfer → routed to the RTO's manual CT process, recorded | rpl → this tile }; a refused/inapplicable CT surfaces the RPL pathway. The launch-time discharge of both offer obligations at the awareness level.

Review substrate — [AMENDMENT, Accreting Review consumption] (detailed in §3). The application's review runs as an Accreting Review; its state lives here: - rpl_correspondence — append-only, immutable, attributed; each entry bound to its unit-claim section and submission version (Accreting Review §5) - per-section approval records — carried on rpl_unit_claim (lock_state, approved_at_version) plus the signing act (rpl_judgement) as the approving event

rpl_event — the discharging-events ledger (rpl-01 §16). Events reference fields; fields carry clauses; the clause is never copied onto the event (method: NO ORPHAN GRAINS). Eight launch events (§3); two reserved (CT equivalence match; third-party disclosure).

3. The application state machine — an Accreting Review over unit-claims¶

The application is not a form that is filled and sent; it is a review that accretes. This spec does not re-specify the review machine — that is accreting-review-01-model, consumed here — it parameterises it for RPL and wires it to the eight discharging events (§2, rpl-01 §16). The foundational negative rule holds throughout: no state below issues a grant except the assessor's signing act (§1A, rpl-01 §1A).

3.1 The parameterisation (Accreting Review → RPL)¶

The generic review primitive binds to RPL entities one-for-one. Nothing in this table re-authors the model; it names which RPL entity plays each role.

Accreting Review primitive	RPL binding	Substrate (§2)
Submission (versioned)	The application at a `submission_version` (monotonic; each submit freezes a snapshot)	`rpl_application.submission_version`
Section	The unit-claim	`rpl_unit_claim`
Section approval → lock	The per-unit signing act	`rpl_judgement` + `rpl_unit_claim.lock_state` / `approved_at_version`
Correspondence (append-only, attributed, immutable)	Return notes, gap notations, assessor↔candidate exchange	`rpl_correspondence` (bound to unit-claim section + `submission_version`)
Content-change re-opens a locked section	Content-change to a unit's evidence re-opens it	`lock_state` transition (§3.4)
Sub-element cascade (RPL's one generalisation)	Units sharing a Pith leaf re-open together (the shared-leaf cascade)	trace chain (§4.5) resolves the shared leaf
Two-axis reconstruction (temporal + sectional)	Whole-application-across-versions, or one-unit-claim-across-versions	`rpl_correspondence` + versioned snapshots

Boundaries the Accreting Review does not supply — access, identity, custody, and clause anchors — stay RPL's (model §7): custody is the vault (§4.9), identity is the candidate store (§2, rpl-01 §4), the signing gate is fail-closed against People (§6), and every regulated field carries its own clause trace (§10).

3.2 The application-level lifecycle¶

The application moves through states the obligations require; each transition that discharges an obligation is a ledger event (§3.6). The offer/fork provenance (events 1–2) precedes the application proper and is carried onto it (pathway_fork_ref, offer/awareness provenance — rpl-01 §3), so an opened application already answers "how did this claim arrive."

(offer/awareness recorded ─ e1) ─▶ (pathway fork recorded ─ e2)
        │  fork = rpl
        ▼
   OPEN ── e3 (application opened: candidate × product × units claimed)
        │
        ▼
   EVIDENCED ◀──────────────┐   e4 (evidence submitted + sealed) — iterates on each submit/supplement
        │                   │
        │ (engine mode)     │
        ▼                   │
   ANCHORED ─ e5 (engine anchor run; instrument, not verdict) [engine-assisted mode only]
        │                   │
        ▼                   │
   UNDER JUDGEMENT          │
        │                   │
        ├─ per unit ─▶ signing act (e6) ─▶ unit-claim GRANTED / NOT_GRANTED (locks; §3.3)
        │                   │
        └─ gap at a unit ──▶ FORK (§3.5):
                 ├─ gap-training determination (e7)  ── discharges 1.6-13
                 └─ return_for_supplement ───────────┘  (re-invite via intake pipeline; iterates e4)
        │
        ▼ (all unit-claims resolved: granted / not_granted / gap-determined)
   OUTCOME ── e8 (outcome exported / retrieved)

The application is never globally "complete" as a gate — it resolves per unit-claim, and the outcome record (§8) reads whatever mix of granted / not-granted / gap-determined the unit-claims have settled into. A single not-yet-resolved unit-claim does not block a resolved one's outcome; the Accreting Review's whole point is that approvals accrete independently.

3.3 The unit-claim lifecycle (the section machine)¶

Each unit-claim runs its own state, per §2's claim_state enum. This is the section-level machine the application-level view aggregates.

claimed ─▶ traced ─┬─▶ granted        (signing act; locks — §3.4)
                   ├─▶ not_granted     (signing act; locks)
                   └─▶ gap_identified ─┬─▶ (gap-training determination) → resolved-with-gap
                                       └─▶ returned_for_supplement ─▶ (re-supply, e4) ─▶ traced …

claimed — the unit is in the claim set; no evidence traced yet.
traced — evidence traced to the unit's leaves (assessor by hand in manual mode; anchor map in engine mode). Not a grant — tracing is validity; the grant needs sufficiency + authenticity + currency ruled and signed (§6, rpl-01 §6).
gap_identified — the per-leaf not-yet map stands at judgement; forks per §3.5.
returned_for_supplement — the Accreting Review return: the unit is handed back to the candidate to supply more, re-invited through the intake pipeline (§3.7), not a bespoke RPL upload path.
granted / not_granted — set only by the signing act (e6); both lock the unit-claim.

Only granted and not_granted are set by the signing act; every other transition is a working state. insufficient_data at the People gate does not appear here — it blocks the signing act from occurring (§6), so the unit-claim cannot leave traced/gap_identified for a grant at all.

3.4 The lock and the shared-leaf cascade¶

The signing act locks the unit-claim (lock_state = locked, approved_at_version = the submission version it was signed against). Locking is what makes approvals accrete: a locked unit-claim is not re-reviewed on a later submission — the candidate can resubmit to supplement a different unit without disturbing the ones already signed.

The lock releases on exactly one condition, and its cascade is RPL's one generalisation of the review model:

Content-change re-opens. If the evidence underpinning a locked unit-claim changes (a new sealed object supersedes one its grant traced through), that unit-claim re-opens: lock_state → unlocked, claim_state → traced (or returned_for_supplement). The prior rpl_judgement is not deleted — it is immutable and append-only (§2); it is superseded, and its sealed verdict_snapshot stands as the historical fact that the assessor was credentialled at that time. A fresh signing act is required for the new version.
The cascade follows the shared leaf. Because one evidence artefact can trace to leaves in more than one unit (a work sample demonstrating a performance criterion common to two units), a content-change re-opens not only the changed unit-claim but every locked unit-claim whose sealed trace chain (§4.5) resolved through the changed artefact. This is the trap the model closes: without it, supplementing evidence for one unit could silently leave a different granted unit resting on evidence that no longer exists in the form it was signed against. The cascade is a by-construction consequence of the trace chain, not a policy the assessor must remember.

3.5 The gap fork — two paths, no new event¶

At a gap, the model gives two answers, and the state machine forks to exactly one per unit-claim (rpl-01 §10; the Assessment PG's reassessment obligation):

Gap-training determination (e7). The gap is answered by training: rpl_gap_determination records amount, delivery mode, cost, and that it was worked with the candidate (1.6-13). The unit-claim resolves with a gap noted — the outcome record (§8) carries the determination.
Return for supplement (no new event). The gap is answered by more evidence: the unit-claim goes returned_for_supplement, the candidate is re-invited through the intake pipeline (§3.7) to supply it, and the resupply lands as e4 again (evidence submitted + sealed). The supplement loop therefore iterates e4 and invents no event — the eight-event ledger holds. Reassessment is the Accreting Review doing what it is for.

Which path is the assessor's call, worked with the candidate. The tile records the fork; it does not choose it. A unit-claim can traverse the return loop several times (each a new submission_version) before it grants, is not-granted, or is gap-determined.

3.6 The eight events, mapped to transitions¶

The ledger is rpl_event (§2). Events reference fields; fields carry instrument-qualified clauses; the clause is never copied onto the event (NO ORPHAN GRAINS). Eight launch events; two reserved.

#	Event	Fires when	Primary discharge (obligation-ID; resolved to clauses in §10.1)
e1	RPL offered / awareness recorded	Invitation issued, carrying right-to-RPL + licensing caveat where flagged	1.6-1, 1.6-2; 1.7-1 awareness via the fork
e2	Pathway fork recorded	CT-vs-RPL determination at intake	1.6-1 / 1.7-1 (offer level)
e3	Application opened	Candidate × product × units claimed formally received	the obligation attaches
e4	Evidence submitted + sealed	Vault landing with digest + candidate attestation; iterates on every supplement (§3.5)	1.6-5, 1.6-12
e5	Engine anchor run (engine mode only)	Per-leaf trace + gap map produced, bound to the application	instrument provenance (§5)
e6	Assessor judgement — the signing act	Per-unit ruling; People verdict snapshot sealed; fail-closed gate	1.6-5/6/7/8/10/11
e7	Gap-training determination	Amount/delivery/cost, worked with candidate	1.6-13
e8	Outcome exported / retrieved	Outcome record leaves to SMS or is retrieved locally	(§8)

Reserved, not launch: CT equivalence match + transcript authenticated (ships with CT mode, §11); third-party disclosure recorded (1.6-4, with third-party RPL, §9). 1.6-14 (validate the RPL process) is Record's event, fed by this tile as a sample supplier (§14) — not double-recorded here. 1.6-15 (staff understand the consequences of wrong grants) is discharged structurally by §1A plus the RTO's People PD record — no synthetic event.

3.7 The intake-pipeline seam¶

RPL originates no intake surface — invite → self-complete → capture → submit → deliver is intake-pipeline-01-model, parameterised in §7. Two couplings matter to the state machine here:

First submission lands through the pipeline's submit-mode seam (stage-4): sealed bytes cross to the RPL vault, e3/e4 fire, the application opens at submission_version = 1.
The supplement return (§3.5) is a re-invitation through the same pipeline, not a new mechanism: a returned_for_supplement unit-claim triggers a re-invite carrying the return correspondence; the candidate re-completes only what was asked; the resupply lands as e4 at the next submission_version. The pipeline's stage→event mapping is the authority for the crossing; RPL supplies only the parameters (what was returned, against which unit-claim section). Custody stays the pipeline's until the stage-4 seal hands to the RPL vault — RPL never reaches back into pipeline custody (§2).

4. The evidence-normalisation adapter — the contract¶

The adapter is the substantial our-side build the crossing sized (receipt RTOP-RECEIVED-CROSSING-RPL-CAPABILITY-01 §2; rpl-01 §5.2). It sits on our side of the warranty line: the engine's payload shape is fixed and already fits; converting a heterogeneous evidence bundle into that shape is ours. This section specifies the contract — input, transform, output, and the boundaries it must not cross. All engine-capability claims bind through the receipt, never the UCCA copy directly (FENCE-PROTOCOL-01 §4).

4.1 What it is and where it sits¶

Input: the sealed evidence bundle for an application (§2 rpl_evidence_item + vaulted bytes).
Output: the engine payload — material.sections (stable-id'd text) — plus the trace map (§4.5) that makes each section resolvable to sealed bytes.
When it runs: the adapter is on the engine path. In engine-assisted mode it normalises the bundle, emits the payload, and persists the trace map. In manual mode it does not run — the assessor reads sealed evidence directly (rpl-01 §8), so rpl_evidence_item.adapter_section_ids[] is empty for a manual-only application. That emptiness is correct, not a gap: sections exist because the adapter ran, not as a precondition of custody. Custody (§4.9) is mode-independent and always runs.

4.2 The input contract — accepted item types (v1)¶

Ruled for v1 (rpl-01 §5.2): text-and-documents only.

Item form	v1 path	Enters engine payload?
Native text (typed statements, digital documents with a text layer)	Direct extraction → sections	Yes
Scanned / image-only documents	OCR → text → sections	Yes
Image / video / audio (incl. assessor-conducted recordings)	Vaulted, not normalised	No — assessor reads directly (rpl-01 §5.2)
Assessor-conducted records (competency-conversation, practical-observation — as authored text)	Treated as native text, `provenance = assessor_generated`	Yes

Every item carries, at landing: its provenance tag (candidate_submitted | assessor_generated | third_party, §2); its digest (sha256, sealed); and its authenticity attestation reference (the candidate's, or the assessor's for assessor_generated items). Image/video/audio items vault and reach the assessor's eyes directly; they never enter the adapter, and adapter_section_ids[] stays empty for them. Multimodal normalisation (a transcription/description pre-step) is day-two adapter work, not an engine dependency (§4.8).

4.3 The normalisation transform¶

Native text → extracted and segmented into stable-id'd sections. A section is a coherent span (paragraph/block granularity) carrying a deterministic, re-derivable id — the id is a function of (source digest, span offset), so re-running the adapter on the same sealed bytes yields the same ids. Determinism is what lets the trace map survive re-derivation (§4.9).
Scanned/image documents → OCR to a text layer first, then the same segmentation. The OCR output is itself derived-and-sealed so the span offsets are stable.
Sections map to the engine's material.sections. VET vocabulary stays client-side — the engine's section ids are opaque to it; unit/leaf/element language never crosses into the engine (receipt §2; rpl-01 §7).

4.4 The obligation side — the bar, read from the Pith¶

The other half of the engine payload — obligation.elements — is the target unit's component-class leaves (element / performance-criterion / performance-evidence / knowledge-evidence), each an element_ref + its text, read read-only from the Pith (nrt-corpus-ref; KN sacred; §2). The adapter composes obligation.elements from the Pith for the claimed unit; it authors no criteria and edits no leaf. This is the reliability boundary held in advance of §6: RPL reads the Crown-owned bar and traces to it; it never authors per-unit marking guides (Std 1.3 assessment-tool territory, Studio/Record — rpl-01, §6 forthcoming).

4.5 The trace map — the adapter's durable output¶

The adapter's second output (beside the payload) is the map that makes every future engine anchor resolvable to sealed bytes:

section id → (vault_digest, span offset)

Combined with the engine's return (leaf → verbatim anchor → section), this completes the model's audit spine (rpl-01 §5): unit leaf → engine anchor (verbatim span) → adapter section id → vaulted artefact digest. An anchor that cannot resolve through this map to sealed bytes is not evidence — the mirror, on the return side, of the engine's own contract, which fails a job rather than sealing a fabricated or absent anchor (byte-verified anchor, receipt §2).

Ratified (2026-07-07) — the trace map's home. The map is derived application-state about vaulted evidence, not evidence itself. Spec default: it lives tile-domain-side (rtopacks-rpl), keyed to rpl_evidence_item, referencing rtopacks-rpl-evidence digests — the vault holds bytes, the tile domain holds the map over them. Bind-at-build against the resource inventory; ratified as above.

4.6 What the adapter carries, and what it refuses to assert¶

The adapter is metadata-carrying, not judgement-making. The rules-of-evidence split (rpl-01 §6) sits at this boundary:

Rule	Adapter's part	Not the adapter's
Validity	Produces the sections the engine anchors against	The anchor act is the engine's; confirmation is the assessor's
Sufficiency	— (carries nothing)	Assessor-only; the engine is barred; the adapter never aggregates
Authenticity	Carries `provenance`; surfaces the third-party verification record and attestation refs (§2)	The ruling is the assessor's; the adapter asserts no provenance truth
Currency	Ratified — surfaces a recency delta (evidence date vs the live `rto-nrt-db` requirement)	The ruling on what recency means here is the assessor's

Ratified (2026-07-07) — currency recency-check. Spec default: the adapter surfaces the recency delta; the assessor rules. This keeps the adapter clear of a sufficiency-adjacent judgement — it presents a fact (dates), never a verdict. Ratified.

4.7 The engine handoff¶

Emit: { material.sections, obligation.elements } — nothing else; no VET vocabulary, no candidate identity, no provenance (provenance stays tile-side for the assessor).
Receive: per-leaf TRACED / NOT_YET_TRACED with byte-verified verbatim anchors — subject-locked findings, no pass/fail/competent vocabulary (rpl-01 §7). Vocabulary version (TRACED semantics vs literal "DEMONSTRATED") is deferred to commissioning; model default: reuse v1 TRACED unchanged (§5).
Persist, do not interpret: the adapter binds the returned anchors into rpl_anchor_map / rpl_finding (§2) via the trace map, and hands the anchor map to the assessor workbench (§6) as an instrument to start from — never a verdict. The engine run is itself event e5 — an instrument's provenance (§3.6).
Fabricated/absent anchor fails the job. A returned anchor that does not resolve through the trace map to sealed bytes is rejected at persistence: it is not written as a finding. The tile never seals an unresolvable anchor.

4.8 The v1 boundary and what is day-two¶

v1: native text + OCR'd documents → sections → payload + trace map. This clears manual mode's needs entirely (manual mode doesn't invoke the adapter) and gives engine-assisted mode a real payload for text-and-document bundles.
Day-two, adapter-side (not engine dependencies): multimodal normalisation (image/video/audio transcription-and-description pre-step); a richer competency-conversation question-bank instrument drawing from Studio content (§6 names the launch recording surface; the bank is day-two); overseas- evidence mapping (rpl-01 §12, its own reference corpus).
Ratified (2026-07-07) — assessor-conducted evidence forms' home. The competency-conversation and practical-observation forms (the workbench affordances the assessor uses to conduct and record) live in §6 (the workbench), not here. §4's only claim on them: their authored-text output normalises exactly like native text, tagged assessor_generated. Their recordings vault unnormalised (§4.2). Ratified.

4.9 Fail-closed and custody invariants¶

Seal before normalise. Every item is digest-sealed at vault landing before the adapter reads it. The adapter reads sealed bytes and writes derived artefacts (sections, OCR text, trace map); it never mutates a source object (amendments are new sealed objects — §2, rpl-01 §5.3).
Re-derivable. Because section ids are deterministic over (digest, span), the entire adapter output is re-derivable from the sealed sources. A lost or corrupted section index is regenerated, not recovered from a mutable cache.
No resolvable map ⇒ not emitted. If a section cannot be given a resolvable (digest, span) entry, it is not emitted to the payload — the adapter fails that section closed rather than feed the engine an unanchored section. Fail-closed is the posture on both sides of the seam: the adapter won't emit an unresolvable section; the engine won't seal an unresolvable anchor.
Custody is mode-independent. The vault seals in both modes; only the adapter is engine-path-only (§4.1).

4.10 Clause anchors (partial — full register in §10)¶

Adapter concern	Instrument-qualified anchor
Heterogeneous intake accommodated	1.6(2)(a) within F2025L00354 + PG (variety); cf 1.4(2)(a)(ii) flexibility
Rules of evidence held at the boundary	1.4(2) within F2025L00354
Candidate/assessor attestation sealed	1.4(2)(b)(iii) + 1.6(2)(b) within F2025L00354
Sealed custody to the retention floor	1.6(2)(b)/(c) within F2025L00354 + PG (record retention)
Third-party verification affordance	1.4(2)(b)(iii) within F2025L00354

5. The engine seam contract¶

Largely settled by rpl-01 §7 (bound through the receipt RTOP-RECEIVED-CROSSING-RPL-CAPABILITY-01) and §4.7 above. This section states the contract as the spec's own and adds nothing the receipt does not license. All engine claims bind through the receipt, never the UCCA copy (FENCE-PROTOCOL-01 §4).

5.1 The contract, restated as spec¶

Emit: the adapter sends { material.sections, obligation.elements } (§4.4, §4.7) — nothing else; no VET vocabulary, no candidate identity, no provenance.
Return: per-leaf { leaf_ref, finding, verbatim_anchor_span }, finding ∈ { TRACED | NOT_YET_TRACED } — subject-locked, no pass/fail/competent vocabulary (rpl-01 §7). The engine's section/leaf ids are opaque; VET vocabulary stays client-side.
Instrument, not verdict: the engine raises a hand on validity and surfaces gaps; it never rules sufficiency or authenticity, and it never grants (rpl-01 §7). The run is e5 (§3.6) — an instrument's provenance, bound to the application.

5.2 Findings vocabulary — v1 default, revisit at commissioning¶

Whether the sealed findings object carries literal "DEMONSTRATED" wording versus TRACED semantics is a findings-schema version choice deferred to commissioning (receipt §2). Spec default: reuse v1 TRACED unchanged — a TRACED-with-anchor leaf already means "this leaf is demonstrated by this evidence span," and the tile's own surfaces (§6.2) present operator-facing language without touching the sealed vocabulary (rpl-01 §7).

5.3 Designed-in, separately commissioned¶

No commitment crossed (receipt §5): the engine-assisted RPL mode is designed-in — this spec is the design — but opens as its own gated units on Tim's word, across the fence. This is exactly why manual mode is the launch spine (§6.1; rpl-01 §8): the tile ships with no dependency on an uncommissioned cross-fence mode. The commissioning trigger is out of scope here — a fence-crossing brief on Tim's word; §11 names the hand-off.

5.4 Fail-closed at the seam (the mirror of §4.9)¶

A returned anchor that does not resolve through the trace map (§4.5) to sealed bytes is rejected at persistence — never written as a finding. The adapter won't emit an unresolvable section; the engine won't seal an unresolvable anchor; the tile persists only resolvable trace chains. Fail-closed is the posture on both sides of the seam.

5.5 Clause anchors¶

The seam itself is not clause-bound — it is an engine contract. The findings it produces feed validity (1.4(2) within F2025L00354), which the assessor confirms (§6). The two rules the engine is barred from — sufficiency and authenticity — are held in §6.

6. The assessor workbench + the fail-closed signing gate¶

One judgement surface, both modes; manual is the launch spine and never a degraded path (rpl-01 §8). The workbench is where the assessor does what the engine cannot: rules sufficiency, authenticity and currency; conducts assessor-side evidence; and performs the signing act. The foundational negative rule governs the whole section — no grant exists except as the product of the signing act (§1A).

6.1 One surface, two modes¶

Manual mode (launch spine). The assessor reads the vaulted evidence directly, traces it to the unit's leaves by hand (marks demonstrated / not-yet), records the gap map, rules the three, and signs. The adapter does not run (§4.1); every obligation is dischargeable in this mode alone.
Engine-assisted mode. Identical surface. The anchor map (per-leaf TRACED / NOT_YET_TRACED with resolvable anchors, §4.5) arrives as an instrument the assessor starts from — confirms, corrects, and signs over. The engine run is e5; an instrument's provenance, never a verdict.
Mode is a property of the run (rpl-01 §8): same entities, custody, signing act, ledger. No surface may make manual mode a lesser path — it is the reference implementation of the judgement surface.

6.2 The per-leaf marking surface¶

Per unit-claim, per leaf (element / performance-criterion / performance-evidence / knowledge-evidence from Pith, §4.4): demonstrated / not-yet.
In manual mode the assessor's marks are the map. In engine mode the marks start from the anchor map; an assessor override (rejecting a TRACED anchor, or accepting a NOT_YET) is recorded and attributed — the instrument informs, the assessor decides.
The not-yet map is the gap map — it feeds the §3.5 fork directly.
The reliability boundary, held. The workbench presents the Crown-owned bar — the leaves, read read-only from the Pith — and the assessor traces to it. It does not author per-unit marking guides or criteria: that is assessment-tool territory (Standard 1.3), living in Studio/Record. The workbench is a tracing surface, not an assessment-tool authoring surface. This is the boundary named in §4.4, enforced here at the surface where the temptation to drift would arise.

6.3 Assessor-conducted evidence — the workbench forms (from §4.8)¶

Not candidate-facing conduct mode (day-two, on the tokened surface). These are assessor-side affordances: the assessor conducts the activity (in person or by call) and records it; the output vaults as assessor_generated (§4.2), normalises as native text (§4.8), and feeds the per-leaf marking and the sufficiency ruling.

Competency-conversation record — structured Q&A tied to knowledge-evidence leaves. The recording surface ships at launch; the full question-bank instrument drawing questions from Studio content is day-two (§4.8). Recordings (audio/video) vault unnormalised and consent-captured (§2 recording_ref). Anchors: 1.4(a)(iii) validity, 1.4(b)(ii) sufficiency.
Practical-observation record — the assessor's observation of the candidate performing a task, live or via video. Answers the PG's known risk of tick-box evidencing of practical assessment.

6.4 The three rulings the engine cannot hold¶

The assessor rules sufficiency_ruling, authenticity_ruling, currency_ruling (§2), per rpl-01 §6. The engine holds none of them.

Sufficiency — assessor-only; the aggregate judgement the engine is constitutionally barred from.
Authenticity — the assessor reads the candidate attestation, the adapter's provenance, and the third-party verification record (§2, §4.6), and rules. The AI-generated-evidence position (rpl-01 §6) lands here: the workbench surfaces provenance, the assessor rules authenticity, the engine is barred — the tile's AI narrows to the one rule it can serve (validity tracing) and is kept off the rest. A positioning asset, ruled and published, not a caveat.
Currency — the adapter surfaces the recency delta (§4.6, ratified); the assessor rules what recency means for this evidence.
reasonable_adjustments_note (§2) surfaces here — light, optional (1.4(a)(i) fairness).

6.5 The fail-closed signing gate — the crux¶

The signing act is e6 (§3.6); it is the only act that sets granted / not_granted and locks the unit-claim (§3.4, §1A). At the moment of signing, the tile calls People through the existing contract (people-02-spec §3, §9), with no re-implementation of assessor credentialling:

People.canDeliver( assessor, target_training_product, assess_only ) → { verdict, evidence, dimension_states }

Only permitted may sign. The other three verdicts block:

Verdict	At the signing gate
`permitted`	Sign proceeds.
`permitted_under_direction`	Blocked — not by an RPL-specific rule but by the People contract itself: under-direction verdicts carry "cannot make assessment judgements" as a negative capability (people-02-spec §3.5 item 4). The RPL signing act is an assessment judgement, so an under-direction assessor is barred from it. (Such a person may still work the RPL evidence under direction; the pen is held by a `permitted` assessor — §6.5 note.)
`not_permitted`	Blocked — red; a negative verdict.
`insufficient_data`	Blocked — and this is stricter than Studio's Never Block. Never Block is right for a planning canvas, where "can't tell yet" must not paint a compliant RTO red; it is the wrong posture for a regulatory signing act, where an unevaluable assessor signing a grant is precisely the 1.6-9 exposure.

The insufficient_data / not_permitted distinction is preserved in the messaging even though both block — amber "assessor profile incomplete" versus red "assessor not eligible". The two must not be collapsed in any surface (people-02-spec §3.6).
Planning versus signing. Planning surfaces inside the tile (assigning an assessor to an application queue) may inherit Never Block's amber nudge; the signature may not (rpl-01 §9).
Under-direction conduct, permitted pen (launch rule). At launch the signing identity must itself be permitted — where the assessment was conducted under direction, the director (who is permitted) holds the pen and signs. The split workflow (under-direction assessor conducts, director co-signs via provide_direction) is named day-two, not launch — a seam, not a redesign.

6.6 The verdict snapshot — sealed with the judgement¶

People's verdict is derived and moves with the evidence behind it; the judgement is a historical fact (rpl-01 §9). So the signing act seals verdict_snapshot (§2): the verdict, its evidence pointers, and the policy/list versions it was computed against (CP version, product-list version). This is the permanent answer to "was this assessor credentialled at the time" — the question an auditor actually asks. The snapshot is immutable and survives the cascade (§3.4): when a unit-claim re-opens and is re-signed, the prior judgement's snapshot stays sealed as the historical fact of the prior grant.

6.7 `defensible_rationale` — required; un-signable without it¶

rpl_judgement.defensible_rationale (§2) is REQUIRED; the signing act cannot complete without it — the same fail-closed posture as the verdict gate. It discharges 1.4(b) (judgements that are justified) and 1.6-10 (documented, defensible), and answers the Assessment PG's "missing rationale" pitfall. A grant with no recorded reasoning is not a grant this tile will seal.

6.8 Third-party assessors — day-two¶

At launch the signing identity is the RTO's own People-registered assessor (rpl-01 §9). Third-party assessors enter through People (credentialled the same way) and carry the same-rigour monitoring obligation (1.6-14) — named now so day-two inherits a seam, not a redesign.

6.9 Clause anchors (partial — full register in §10)¶

Workbench concern	Instrument-qualified anchor
Assessor meets the credential/currency standards	via People (people-02-spec: 3.3(a)(i), 3.3(a)(ii), 3.2(c) within F2025L00354)
Rules of evidence held	1.4(2) within F2025L00354
Judgement justified, documented, defensible	1.4(2)(b) + 1.6(2)(c) within F2025L00354 + PG (defensible)
Assessor-conducted validity + sufficiency	1.4(2)(a)(iii) + 1.4(2)(b)(ii) within F2025L00354
Fairness / reasonable adjustments	1.4(2)(a)(i) within F2025L00354

7. Intake consumption — RPL's parameters on the shared pipeline¶

RPL originates no intake surface. invite → self-complete → capture → conduct/submit → deliver is intake-pipeline-01-model, consumed here. This section states RPL's per-consumer grades on the shared stages — parameters, not a re-spec. The pipeline emits RPL e1–e4; e5–e8 (engine run, signing act, gap determination, export) are tile-side moments on tile surfaces (§6, §8), and the pipeline neither emits nor mirrors them.

7.1 The five stages, RPL-graded¶

Stage	RPL grade	Event
1. Invite	Operator-initiated; candidate found-or-created in the shared store; tokened link. The offer carries right-to-RPL + the licensing caveat where flagged; the CT-vs-RPL fork question is attached	`e1` (offer/awareness); `e2` when the fork is answered
2. Self-complete	Candidate authors identity once (§7.2); units-claimed particulars completed; resumable within token life. USI mandatory, format-validated per the Act	`e3` at finalisation (application opened)
3. Capture	Consent-gated anchors (photo ID at RTO-configurable requiredness; session recording only where a component is conducted); all captures digest-sealed to R2. The authenticity attestation over the submitted bundle seals with it	—
4. Submit	Submit mode: the heterogeneous evidence bundle lands in the RPL vault; the pipeline's job ends at sealed landing (the stage-4 seam, §3.7, §4.9). Conduct mode is LLND's; any future conducted RPL component inherits it, day-two	`e4`
5. Deliver	Outcome notification down the invitation's channel — recorded, non-discharging. Distinct from the discharging outcome export/retrieval, which is tile-side (§8)	—

7.2 Identity and the attestation floor¶

The candidate authors identity once per intake, self-authored and self-attested (§7.3; rpl-01 §4). Upstream pre-fill (operator-typed at invite, or pushed) is proposal-grade with recorded provenance; the attestation is the authorship act. The authored record terminates in a signed attestation — timestamped, versioned against the attestation text, sealed with the intake.

For RPL the intake attestation is the floor under the authenticity attestation over the bundle (§2 authenticity_attestation_ref; rules of evidence, §6.4). One attestation pattern, per-consumer payloads.
USI: student_identifier carries its Student Identifiers Act 2014 meaning; captured and format-validated at self-complete; registry verification is day-two behind the USI EXT-API reference doc, which is owed before any USI-registry integration deploys (EXT-API RULE; rpl-01 §4).

7.3 The tokened surface — what RPL inherits (not re-specified)¶

Tokened, login-free, no seat — the candidate is invisible to the seat model (rpl-01 §4). The token is the only thing in the URL; no name, email, USI, or any identifier in URL or query, ever. Time-limited, resumable within token life; re-issue rotates (at most one live token per invitation). Served same-origin through a BFF, fail-closed (CHANNEL SEPARATION RULE).
Read-back rule (Intake-class): the token reads back only the candidate's own in-flight session and the static engagement framing (product identity from Pith, offer text, the fork question). It reads back no results, no advice, no regulated tile data. Outcomes travel outward on stage-5 delivery — never fetched by the token. This is precisely why the outcome export (§8) is not a token-reachable artefact.

7.4 The supplement re-invite (the Accreting Review return, §3.5)¶

The §3.5 return runs as a re-invitation through this pipeline, not a bespoke RPL upload path.

A returned_for_supplement unit-claim triggers a re-invite carrying the return correspondence (§2 rpl_correspondence); the candidate re-completes only what was asked; the resupply lands as e4 at the next submission_version (§3.7).
Scoped re-invite — RPL's parameter on the invite is that the re-invitation names which unit-claim section(s) were returned, and the candidate supplies against those. A supplement re-invite is not a fresh full application.
Token discipline — re-issue rotates: the supplement re-invite mints a fresh token and revokes the prior, so the candidate resumes into the supplement scope only.

7.5 The bundled invitation (the shared-identity dividend)¶

One invitation may carry multiple engagements (an RPL application, an LLND review, or both) against one candidate-store row; each engagement fires its own tile's events into its own ledger; the candidate authors identity once. Grade resolution: the stricter grade wins per shared field — any RPL engagement in the bundle makes USI mandatory for that whole intake (an LLND-only intake leaves it optional). Resolved at invite time, shown to the candidate as one coherent form, never two. RPL does not own the shared store (§2); it sets the strict USI grade whenever it is present.

7.6 Custody split at the stage-4 seam¶

The pipeline seals what it captures — consent records, ID images, session recordings, the attestation — to R2, immutable, amendments as new sealed objects. The RPL tile seals what it owns — the evidence bundle in the RPL vault (§4.9). The seam is stage 4: at submit, the pipeline hands sealed bytes and digests to the RPL vault landing; RPL never reaches back into pipeline custody (§2, §3.7). No capture artefact's custody discipline is mode- or consumer-dependent.

7.7 Clause anchors (partial — full register in §10)¶

Intake concern	Instrument-qualified anchor
Offer + licensing caveat at invite	1.6(2)(a) within F2025L00354 + PG (licensing caveat)
Authenticity attestation sealed	1.4(2)(b)(iii) + 1.6(2)(b) within F2025L00354
Sealed capture custody	1.6(2)(b)/(c) within F2025L00354 + PG (retention)
USI meaning	Student Identifiers Act 2014

8. The outcome layer — one record, three presentations¶

The judgement's product is the outcome record (rpl-01 §13): per unit, granted / not-granted, with any gap and determination attached, sealed with the verdict snapshot (§6.6). One sealed record (§2 rpl_outcome), read three ways. Custody stays home; only the outcome leaves.

8.1 The outcome record — the single source¶

rpl_outcome (§2) is assembled from the signed rpl_judgement records across the application's unit-claims: per unit granted / not-granted, gap + determination where present, student_identifier in its Student Identifiers Act 2014 meaning, sealed with the verdict snapshot.
Custody boundary (rpl-01 §13): the evidence bundle, anchor maps and judgement records stay in RTOpacks-domain custody (the vault + the RPL store). What leaves is the outcome — the per-unit result — never the evidence.

8.2 Presentation 1 — held (always)¶

The outcome record is always held in the RPL store, readable by the RTO on the tile's own surface. This is the floor: with no SMS and no export at all, the RTO still holds the record. It also feeds Record as an audit artefact (rpl-01 §14): the units-credited fact enters Record's audit/validation surface without the evidence bundle leaving custody — Record reads the fact, not the bundle.

8.3 Presentation 2 — neutral SMS-consumable export (launch)¶

Launch: an importable outcome export in a neutral, SMS-consumable shape (the format binds in §9). It is a file the RTO imports, not a link.
Vendor adapters are day-two: once a design partner's SMS is known, a targeted adapter maps the neutral shape to that vendor. SMS Connect round-trip / push-back is day-two (rpl-01 §13); launch is one-way.
student_identifier travels in the export in its Act meaning — never in a URL or a message body (§7 read-back rule). No export invents an identifier.

8.4 Presentation 3 — local retrieval (no-SMS RTOs)¶

Where an RTO has no SMS, the outcome record is retrievable locally: view / print / PDF the record they file. For these RTOs the export is the record they file (rpl-01 §13).
Scope line, held: this is the outcome record, not a student-management system. No enrolment, scheduling, invoicing, or AVETMISS reporting; no cross-student roll-up. A cross-student file is Record's territory, day-two. The local surface shows one application's outcome, filed — nothing more.

8.5 The `e8` discharge¶

e8 (outcome exported / retrieved) fires when the outcome record leaves to the SMS or is retrieved locally (§3.6). It is the tile-side export/retrieval act — distinct from, and not to be conflated with, the pipeline's stage-5 candidate notification (§7.1), which is recorded and non-discharging.

8.6 Clause anchors (partial — full register in §10)¶

Outcome concern	Instrument-qualified anchor
Assessment result documented and retained	1.6(2)(c) within F2025L00354 + PG (retention)
Units-credited fact enters audit/validation	1.5(2) within F2025L00354 + PG (Record's events, fed here)
Identifier meaning	Student Identifiers Act 2014

9. Deferred calls resolved¶

The spec left six calls pointing at "§9." Each is resolved here as a launch answer + a named day-two seam, with configured numbers named as configured defaults, not constants (mirroring people-02-spec §12.3) and the copy that carries regulatory meaning pinned so no surface collapses a load-bearing distinction. §9 carried one further design call (the export serialisation, §9.2); with the three in §4, all four are ratified 2026-07-07.

9.1 Licence source (the 1.6-2 licensing caveat)¶

§2's licence_linked_flag / licence_note are a manual per-product flag at launch: the RTO sets, per training product, whether a licensing/regulatory caveat attaches, and the note that carries it. Where set, the offer carries the caveat (§7.1) and the posture is fail-toward-caution.

Why manual, not sourced. There is no single national licensing register to bind — occupational licensing in Australia is fragmented across state/territory regulators and industry bodies. No clean Crown feed exists, so launch invents no external licence-source dependency.
Day-two: an RTO-configurable licence-reference table (product → caveat note), still RTO-authored, not a Crown feed. If any external licensing register is ever integrated it takes a reference doc in docs/ops/ first (EXT-API RULE). The flag's meaning (1.6(2)(a) within F2025L00354 + PG) does not move with its source.

9.2 Export format — the neutral SMS-consumable shape (§8.3)¶

§8.3 deferred the shape of the launch export here. Resolved:

Not AVETMISS/NAT. The §8.4 scope line holds — this is an outcome file, not a statistical-reporting artefact. It carries no enrolment/scheduling/AVETMISS shape.
Grain: one row per unit-claim outcome — per-unit is the judgement grain (§1).
Field set (neutral, vendor-agnostic): candidate name + student_identifier (USI, in its Student Identifiers Act 2014 meaning); target product tga id + title; unit tga id + title; outcome (granted | not_granted | granted_with_gap); gap-determination summary where present (§2); assessor identity + signed_at; the verdict_snapshot reference (the "credentialled at the time" pointer, §6.6); application_ref; export timestamp. No evidence bytes, no anchor maps — the custody boundary (§8.1) travels with the file: what leaves is the outcome, never the evidence.
Invariants: student_identifier appears only as a field value in the file body — never in a filename, URL, or query (§7 read-back rule). The artefact is a file the RTO imports, not a link (§8.3). No export invents an identifier.
Ratified (2026-07-07) — serialisation. Spec default: CSV at launch (universally importable by SMS and spreadsheet alike), with the field set above as documented columns; a JSON emission of the same schema is the day-two alternate for API-capable SMS. The schema (fields + invariants) is the spec call and is firm; the serialisation default (CSV) is ratified.
Day-two: per-vendor adapters map this neutral shape to a named SMS's import schema once a design partner's SMS is known; SMS Connect round-trip / push-back is day-two (§8.3). Launch is one-way, file-out.

9.3 Naming — what is settled vs bound at build¶

Names follow cloudflare-naming-canon; none is minted as canon here without the build-time inventory check against cloudflare-resource-inventory.md (SUBSTRATE-NAME-MATCHES-SHAPE).

Settled (written in §2, subject to build-time verification): rtopacks-rpl-prod/-dev (tile domain, D1); rtopacks-rpl-evidence-prod/-dev (vault, R2).
Shared name first-bound here: rtopacks-candidates-prod/-dev (D1) — owned by neither RPL nor LLND. llnd-02 inherits it, does not re-bind (carried tail); confirm at build it is not double-created.
Bound at build, not now: the RPL event-ledger substrate — a tile-domain rpl_event table vs a shared audit store (§2). The ledger's content is fixed (§3.6, the eight events); its home is an open build-time call against the inventory. Named as open, not silently defaulted.

9.4 The gap hand-off (§2 `pathway_pointer`)¶

§2's rpl_gap_determination.pathway_pointer resolves as a launch/day-two split:

Launch: a recorded reference — a Studio content ref or a free-text external pathway — captured with the determination (amount / delivery mode / cost / worked-with-candidate, §2). It documents what training answers the gap (1.4(2)(a)(i) + 1.6(2)(b) within F2025L00354 + PG). Launch records the pointer.
Day-two: the wired hand-off — click-through from the gap determination into Studio to build or enrol the gap-training delivery. A seam, not a redesign: launch records; it does not action the enrolment.

9.5 Configured policy values (mirroring people-02-spec §12.3)¶

Configured defaults, not hardcoded constants — recorded as configuration so an RTO can set them and the law-vs-product layers stay clean. The instrument prescribes none of these numbers.

Token life (intake + supplement re-invite, §7.3) — a configured default inherited from the intake pipeline's config (intake-pipeline-01-model), not RPL-invented.
Retention floor (§2, "retention floor = audit window") — RPL records the floor as the RTO's audit window; the number is a configured default, not a hardcoded year-count.
Photo-ID requiredness (§7.1) — RTO-configurable per intake; not a constant.
Currency-recency — deliberately NO threshold constant. §4.6 rules the adapter surfaces the delta and the assessor rules; RPL invents no currency number (contrast People's staleness default, which is a flag not a gate). Named explicitly so no one later adds a hidden constant here.
Attestation text + version (§7.2) — the attestation is versioned against its text; the text is configured with a version stamp, not a code constant.
source_type evidence taxonomy (§2) — RTO-configurable (1.6(2)(a) within F2025L00354 + PG requires accommodating variety); an open taxonomy, not a closed model constant.

9.6 Copy constraints — the surface-copy invariants¶

The copy that carries regulatory meaning, pinned so no surface collapses a load-bearing distinction:

Amber ≠ red at the signing gate (§6.5): insufficient_data → amber "assessor profile incomplete"; not_permitted → red "assessor not eligible." Never collapsed (people-02-spec §3.6).
Instrument, never verdict (§5, §6.1): engine findings render as TRACED / NOT_YET_TRACED, an instrument the assessor starts from — no surface may render an engine finding as a grant or outcome.
Offer copy (§7.1): the invitation carries right-to-RPL, the licensing caveat where flagged, and the CT-vs-RPL fork question.
Stage-5 notification carries no results (§7.1, §7.3 read-back): the delivery notification is recorded and non-discharging — it announces that an outcome is available; it does not carry the outcome down the token channel.
Manual mode is never named as degraded (§6.1): no copy frames manual mode as a lesser path — it is the reference implementation of the judgement surface.
defensible_rationale is named as required (§6.7): the signing surface states the rationale is required and the act un-signable without it — the copy states the bar, it does not bury it.

10. The clause-bound field register¶

Every regulated field on an RPL surface carries a stored, instrument-qualified clause trace authored at build time (CLAUSE-BOUND FIELDS — Legislation-to-Tile), never generated at runtime. This section is the consolidated trace: per regulated field, its real clause within F2025L00354 (or the Act), the obligation it discharges, and the consequence if the field is wrong or absent. It is the audit spine's index — an auditor follows a field here to the actual law.

Anchor convention (established this pass, §10.3). The 1.6-N / 1.7-N labels used throughout are rpl-00-obligations internal obligation IDs — a decomposition of the standards' performance indicators into granular, addressable obligations. They are not clauses in the instrument. Standard 1.6 as-made is 1.6(1) (outcome) + 1.6(2)(a)/(b)/(c) (three PIs); Standard 1.7 the same shape. Every anchor below therefore resolves to a real clause, with + PG appended where the granular obligation's specificity is sourced from the ASQA Practice Guide beyond the bare PI. The internal ID is retained as a human-readable cross-reference; it is never qualified "within F2025L00354."

10.1 The obligation-ID → clause key¶

The Rosetta key the whole register (and the §1–§9 tables) resolve through.

Obligation-ID (rpl-00)	Real clause within F2025L00354 (+ PG)	The obligation, in one line
1.6-1	1.6(2)(a)	Students are offered RPL and made aware of the RTO's RPL policy
1.6-2	1.6(2)(a) + PG	The right to seek RPL, carrying the licensing/regulatory caveat
1.6-3	1.6(2)(a) + PG (cf 1.4(2)(a)(ii) flexibility)	The approach accommodates the variety of experience and pathways
1.6-4	1.6(2)(a) + PG	A third-party role in RPL is disclosed to the student (reserved, day-two)
1.6-5	1.6(2)(b)	Decisions are based on evidence of prior skills, learning, experience
1.6-6	1.6(2)(b) + PG	Conducted per the RTO's assessment system — same rigour, not a lighter path
1.6-7	1.4(2)(b) + 1.6(2)(b)	Judged against the rules of evidence + principles of assessment
1.6-8	1.6(2)(b)/(c)	Consistent with, and maintains the integrity of, the training-product requirements
1.6-9	via People → 3.3(a)(i), 3.3(a)(ii), 3.2(c)	The RPL assessor meets the credential/currency standards
1.6-10	1.6(2)(c) + 1.4(2)(b) + PG	Decisions documented, justified, defensible
1.6-11	1.6(2)(c)	Decisions fair, transparent, consistent among students
1.6-12	1.6(2)(b)/(c) + PG	RPL assessment records retained to the retention floor
1.6-13	1.4(2)(a)(i) + 1.6(2)(b) + PG	Where gaps are found, work with the student on gap training (amount/delivery/cost)
1.6-14	1.5(2) + 1.6(2) + PG	The RTO validates/assures its RPL practices
1.6-15	PG; structural (§1A)	Staff understand the consequences of wrongly granting RPL
1.7-1	1.7(2)(a)	Students are offered credit transfer and made aware of the CT policy

Notes on the + PG load-bearers (honest flags): - 1.6-12 (retention) — the instrument does not carry a numbered RPL retention PI; records are part of 1.6(2)(b)/(c) "documented decisions," and the PG names retention as an RPL known-risk. The fuller instrument home for record-retention is governance/records (Part 4) — noted for Record, not re-anchored here. - 1.6-13 (gap training) — the instrument locus for reassessment is 1.4(2)(a)(i) fairness ("enabling reassessment where necessary"); the gap-training-worked-with-the-student specifics (amount/delivery/cost) are PG. - 1.6-15 (consequences) — no performance indicator exists; it is a PG known-risk discharged structurally by the foundational negative rule (§1A) plus the RTO's People PD record. Anchored honestly as PG, never a bare clause. - 1.4 sub-parts are cited with their PI subsection restored to full precision — 1.4(2)(a)(i) fairness, (2)(a)(iii) validity, (2)(b)(ii) sufficiency, (2)(b)(iii) authenticity, (2)(b)(iv) currency — all verified against the authorised text.

10.2 The field register¶

Per entity (§2), the regulated fields and their traces. Operational scaffolding (foreign keys, refs) is omitted where it carries no independent clause; it inherits its entity's anchor.

rpl_application

Field	Anchor (within F2025L00354 / Act)	Obligation	Consequence if wrong / absent
`target_tga_id`	1.6(2)(b)/(c)	the bar is the national product read from the Pith	judged against the wrong/absent requirement set — integrity breach (1.6(2)(c))
`pathway_fork_ref`	1.6(2)(a) / 1.7(2)(a)	the CT-vs-RPL offer provenance	the offer obligation is undischarged; the correct pathway can't be shown to have been offered
`overseas_evidence_flag`	1.4(2)(b)(iii) + PG	overseas-sourced evidence is flagged for authenticity handling	authenticity risk unmanaged
`licence_linked_flag` / `licence_note`	1.6(2)(a) + PG (cf 1.7(2)(b))	the licensing/regulatory caveat surfaces at offer	a student is misled about a licence-gated pathway
`reasonable_adjustments_note`	1.4(2)(a)(i) fairness	reasonable adjustments considered/applied are recordable	the fairness discharge is not demonstrable
`third_party_disclosure_ref`	1.6(2)(a) + PG (reserved)	a third-party RPL role is disclosed	(day-two)

rpl_unit_claim

Field	Anchor	Obligation	Consequence
`claim_state`	1.6(2)(b)	per-unit evidence/judgement state	the outcome is computed off a wrong state
`lock_state` / `approved_at_version`	1.6(2)(b)/(c)	the accreting-approval binding — a grant is fixed to the version it was signed against	a grant silently rests on superseded evidence (the shared-leaf trap, §3.4)

rpl_evidence_item (+ assessor-conducted forms, §6.3)

Field	Anchor	Obligation	Consequence
`digest` (sha256)	1.6(2)(b)/(c) + PG	evidence is sealed and tamper-evident at landing	evidence integrity unprovable; retention/authenticity fail
`provenance`	1.4(2)(b)(iii)	candidate / assessor / third-party origin recorded	the authenticity ruling is made blind to origin
`source_type`	1.6(2)(a) + PG (variety)	the heterogeneous evidence taxonomy (open, RTO-configurable)	intake forced to a fixed form — 1.6(2)(a) breach
`authenticity_attestation_ref`	1.4(2)(b)(iii) + 1.6(2)(b)	the attestation floor under the bundle	no authenticity floor
`third_party_verification_ref`	1.4(2)(b)(iii)	the verification action feeding the authenticity ruling	unverified third-party evidence relied on
`recording_ref`	1.4(2)(a)(iii) + 1.4(2)(b)(ii) + PG	consent-captured conducted-evidence recording	validity/sufficiency of conducted evidence unprovable; consent gap

rpl_anchor_map / rpl_finding (engine-assisted mode)

Field	Anchor	Obligation	Consequence
`finding` (`TRACED`/`NOT_YET_TRACED`)	1.4(2)(a)(iii)/(iv)	a per-leaf validity instrument the assessor confirms — never a verdict	the instrument mis-starts the assessor; the grant is still the assessor's (§6)
`verbatim_anchor_span` / `vault_digest_ref`	1.6(2)(b) + PG	the trace chain resolves a finding to sealed bytes	an unresolvable anchor is not evidence — fails the job (§4.5)

rpl_judgement — the signing act (the crux, §6.5)

Field	Anchor	Obligation	Consequence
`assessor_person_ref`	via People → 3.3(a)(i), 3.3(a)(ii), 3.2(c)	the signer is a credentialled, current assessor	1.6(2)(b) + workforce-standards breach; wrongful-grant exposure
`verdict_snapshot`	via People + 1.6(2)(c)	sealed "credentialled at the time" record	the auditor's actual question can't be answered
`sufficiency_ruling`	1.4(2)(b)(ii)	the assessor's sufficiency judgement (engine barred)	insufficient evidence grants competence
`authenticity_ruling`	1.4(2)(b)(iii)	the assessor's authenticity judgement	fabricated / AI / unverified evidence grants competence
`currency_ruling`	1.4(2)(b)(iv)	the assessor's currency judgement	stale evidence grants current competence
`defensible_rationale`	1.4(2)(b) + 1.6(2)(c) + PG	required; the act is un-signable without it	a grant with no recorded reasoning — indefensible at audit
`signed_at`	1.6(2)(c)	the discharging signing moment (`e6`)	no discharging act — no grant exists (§1A)

rpl_gap_determination

Field	Anchor	Obligation	Consequence
`amount` / `delivery_mode` / `cost` / `worked_with_candidate`	1.4(2)(a)(i) + 1.6(2)(b) + PG	the gap-training answer, worked with the student	the gap is unaddressed — reassessment/fairness fail
`pathway_pointer`	1.6(2)(b) + PG	reference to the gap-training pathway (launch: recorded; wired hand-off day-two, §9.4)	the gap answer is undocumented

rpl_outcome

Field	Anchor	Obligation	Consequence
per-unit result (`granted`/`not_granted`/gap)	1.6(2)(c)	the documented per-unit decision	an undocumented decision — 1.6(2)(c) breach
`student_identifier` (USI)	Student Identifiers Act 2014	USI in its Act meaning; never in a URL/filename (§7, §8)	Act breach; identifier exposure
units-credited fact → Record	1.5(2) + 1.6-14 (→ 1.5/1.6(2)) + PG	the fact enters the validation/audit cycle	RPL judgements escape validation

rpl_pathway_fork · rpl_correspondence · rpl_event

Field	Anchor	Obligation	Consequence
`determination` (CT vs RPL)	1.6(2)(a) + 1.7(2)(a)	the offer-level discharge of both pathway obligations	the student is not offered the correct pathway
`rpl_correspondence` (append-only, attributed)	1.6(2)(c) + PG	the auditable review trail (returns, gap notations)	the decision trail is unreconstructable
`rpl_event` (the ledger)	the referenced field's anchor (§10.1)	discharge points; the clause rides the field, never copied onto the event (NO ORPHAN GRAINS)	discharge unprovable, or a clause orphaned onto an event (method breach)

10.3 The clause-trace drift check — what this pass caught¶

The register's fresh read did its job: it caught one drift and corrected it in the same pass.

Caught. rpl-02's partial anchor tables (§3.6 discharge-column header, §4.10, §6.9, §7.7, §8.6) and three §9 lines had promoted rpl-00's internal obligation-IDs (1.6-N, 1.7-N) into instrument-qualified clauses — e.g. "1.6-13 within F2025L00354". The authorised instrument carries no such sub-numbering.
Corrected. All 20 occurrences normalised to real clauses per §10.1; the internal IDs are retained as rpl-00 cross-references and are no longer qualified "within F2025L00354."
Blast radius — contained, confirmed. rpl-00-obligations is correct (its real-clause column was intact all along); rpl-01-model uses the IDs only as prose shorthand, never falsely qualified. No filed document reopens — the fix lived entirely in this unfiled draft.
Substantive mappings — verified sound. The granular decompositions resolve correctly against the authorised text (1.6-5 → 1.6(2)(b); the 1.4 sub-parts → 1.4(2)(a)(i)/(iii), (b)(ii)/(iii)/(iv); 1.7-1 → 1.7(2)(a)). This was a citation-format drift, not a misreading of the law — categorically lighter than the standards-outcome.md mismatch.
Pinned for §11 / build. Every clause-bound field stores its §10.1-resolved real anchor, authored at build time; the internal obligation-ID may travel as a human-readable label beside it, but the stored trace is the clause.

11. What hands to the build gates¶

This spec is move 4 — the buildable surface. It is not itself a build brief: each buildable unit derives its own brief from the sections above and runs the five-gate canonical pattern (standing-rules). This section states the launch spine, the designed-in/commissioned split, the build order and its external dependencies, the substrate checks owed at build, the day-two register handed forward, and the one hand-off that crosses the fence.

Dependency assertions below are load-bearing and to be confirmed at build, not taken from memory — each names what must be true, flagged where its current state needs verification.

11.1 The launch spine — manual mode, no cross-fence dependency¶

The surface that ships without the engine:

§2 the data domain · §3 the application state machine (the Accreting Review over unit-claims) · §6 the manual assessor workbench + the fail-closed signing gate · §7 intake consumption · §8 the outcome layer.

Manual mode discharges every obligation (§6.1; rpl-01 §8): the assessor reads sealed evidence, traces to the Pith leaves by hand, rules the three, and signs. The tile therefore ships with no dependency on an uncommissioned cross-fence mode (§5.3). Manual mode is the reference implementation, never a degraded path (§6.1, §9.6 copy invariant).

11.2 Designed-in, separately commissioned — engine-assisted mode¶

§4 (the evidence-normalisation adapter) + §5 (the engine seam) + the engine-mode workbench affordances (§6.1 identical surface, §6.2 anchor-map start). Fully designed here; opens as its own gated units, across the fence, on Tim's word (§11.7). Not a launch dependency, and nothing downstream of the launch spine waits on it.

11.3 Build order and external dependencies¶

Consumed — must be available and confirmed at build:

Dependency	Consumed at	State to confirm
People — the `canDeliver` contract	the signing gate (§6.5)	People is deployed (Phase 1); confirm `canDeliver(assessor, product, assess_only)` is callable at the §6.5 contract shape before the gate is wired
intake-pipeline-01-model — the five-stage pipeline	intake consumption (§7)	consumed, not re-specced; confirm the pipeline's build state and its stage→event seam (§3.7, §7) at build
accreting-review-01-model — the review primitive	the state machine (§3)	the model is filed + live; its substrate realisation in the RPL tile is part of this tile's build (§3 parameterises the model, it does not inherit a built substrate)
Pith (`nrt-corpus-ref`, KN sacred)	the bar (§4.4, §6.2)	read-only reference; already live

Build order within the tile (each a five-gate unit):

Shared candidate store (§2) — foundational, first-bound here, shared with LLND; its name and shape are inherited by llnd-02 (confirm not double-bound, §11.4).
RPL tile domain + evidence vault (§2).
Intake consumption parameters (§7) on the shared pipeline.
State machine + Accreting Review substrate (§3).
Manual workbench + People integration + the fail-closed signing gate (§6).
Outcome layer + neutral export (§8, §9.2).

11.4 Substrate checks owed at build (bind-at-build)¶

Names/homes bound provisionally in the spec, to verify against cloudflare-resource-inventory.md before deploy (SUBSTRATE-NAME-MATCHES-SHAPE; none minted as canon without the inventory check):

Candidate-store name rtopacks-candidates-prod/-dev — confirm not double-created; llnd-02 inherits, does not re-bind.
RPL event-ledger home — tile-domain rpl_event table vs a shared audit store (§9.3, open).
Trace-map home — §4.5 (ratified): tile-domain (rtopacks-rpl), keyed to rpl_evidence_item, over rtopacks-rpl-evidence digests.

11.5 The EXT-API gate¶

USI registry operations are day-two and gated: no USI-registry integration deploys without usi-registry-ext-api in docs/ops/ first (EXT-API RULE). Launch captures and format-validates the USI per the Act (§7.2); it does not verify against the registry.

11.6 The day-two register handed forward¶

Each is named in-place above; collected here as the clean "not now" for the build gates:

CT mode — the credit-transfer build (rpl-00's 1.7 obligations) and its reserved events (§3.6).
Third-party RPL + third-party assessors (§6.8; §2 third_party_disclosure_ref).
Adapter multimodal normalisation; the competency-conversation question bank; overseas-evidence mapping (§4.8).
SMS vendor adapters + round-trip / push-back (§8.3); launch export is one-way, file-out (§9.2).
The wired gap hand-off into Studio (§9.4); launch records the pointer.
The split under-direction workflow — under-direction conduct + director co-sign via provide_direction (§6.5); at launch the permitted director holds the pen.

11.7 The engine-mode commissioning hand-off (§5.3) — a fence crossing¶

The one hand-off that leaves the house. Engine-assisted RPL mode is designed-in (this spec, §4/§5); commissioning it opens UCCA-side work across the fence, on Tim's word, via a fence-crossing brief (FENCE-PROTOCOL-01; Tim the sole relay). The commissioning brief must carry:

the emit/receive contract (§5.1) as the fixed interface;
the findings-vocabulary version decision (§5.2 — v1 TRACED default; revisit at commissioning);
fail-closed at the seam (§5.4) as a commissioning acceptance test;
the adapter + trace map (§4) named as the RTOpacks-side build surface that must exist first.

All engine-capability claims bind through the receipt (RTOP-RECEIVED-CROSSING-RPL-CAPABILITY-01), never the UCCA copy (FENCE-PROTOCOL-01 §4). Nothing about the commissioning is in scope of this spec beyond naming the hand-off.

11.8 The spec's exit — ratification, then filing¶

At §11 the substantive spec is complete (§1–§11). It exits to:

Ratification (done, 2026-07-07) — the four design calls confirmed: §4.5 trace-map home; §4.6 currency recency-check split; §4.8 assessor-conducted-forms home; §9.2 export serialisation (CSV default). Plus the two §6 spec-originations Tim confirmed (§6.2 engine-override-recorded; §6.5 under-direction/ permitted-pen launch rule).
The filing brief — Gate-1 digest anchor; a single docs-only commit; nav registration alongside rpl-00 / rpl-01 under the RPL tile; METADATA-RECONCILIATION-AT-COMMIT for any pointers (including the llnd-02 candidate-store inheritance note and any rpl-01 cross-references touched).

Only then does buildable work begin.