Skip to content

title: "LLND — Spec" document: llnd-02-spec method_move: 4 (Spec) status: RATIFIED 2026-07-07 (Tim) — §1–§11 complete; all three deferred calls resolved: §4.3 (digital-literacy framework — DigComp 2.2, version-pinned, verify-at-commissioning), §8.6 (export serialisation — CSV at launch, JSON day-two, one row per review), §9.3 (access posture — T4 + assigned-T4A default, with an explicit T4-only fallback if the per-review scoping concept is not bound at build). Anchor discipline applied at authoring time — §10 drift check confirmed ZERO drift (no retroactive correction needed, unlike rpl-02 §10.3). NOT yet filed: files via a single docs-only brief (the RPL-02-SPEC-FILING-01 pattern). Do not build until filed. — amended 2026-07-10 (build rulings; see llnd-build-rulings-01) — nine redlines applied: seven-state LLN (§4.2), instrument authorship sealed (§4.1), oral-communication observation checklist (§4.9), human-rated rater identity/rubric version (§4.10), divergence-is-loud (§6.2), T4-only access ruling (§9.3), screening-indicator-not-psychometric-test (§9.5), process-metadata disciplines RC-3 (§9.6), and client-scoping of review/config/currency (§2.2). — amended 2026-07-10; conduct commissioning (LLND-CONDUCT-01): §4.1 + §9.6 — the launch session anchor is a disclosed interaction record, not AV (AV is a day-two increment). pairs_with: llnd-01-model (the model this derives from), llnd-00-obligations (the acceptance surface this satisfies — the 2026-07-07 redraft, filed 8662979a, sha256 d447b00e…) consumes: - intake-pipeline-01-model (every intake-side surface — invite → self-complete → advice delivery; LLND parameterises, does not re-spec) - usi-registry-ext-api (USI format-validation only; USI optional at the LLND stage — §2, §3) cites (does not consume, does not re-bind): - rpl-02-spec §2.1 — the shared candidate-identity store rtopacks-candidates is FIRST-BOUND there; LLND cites the name and adds its stage deltas (§2). LLND never re-binds it. - rpl-01-model §4 / intake-pipeline-01-model — the shared-identity contract and intake pattern does NOT consume: - accreting-review-01-model — LLND's review does not accrete per-section approvals (contrast RPL). Reuse (§3, model §8) is a fresh review honouring prior results, not an accretion. - people-01-model / people-02-spec — no assessor gate on a 2.2 procedure; People not consumed at launch (model §6, §9). Any day-two issuing-role binding enters through People's contract, never its tables. authority_instruments: - F2025L00354 — Outcome Standards for NVR RTOs (Standards 2.1, 2.2, 2.3, 2.4) — read against the rebuilt verified corpus (STANDARDS-CORPUS-REBUILD-01) - Student Identifiers Act 2014 — the meaning of student_identifier (USI); optional at this stage layer_3_sources: - Practice Guide: VET Student Support — Information PG (Standards 2.1, 2.2) + Training Support PG (Standards 2.3, 2.4) — practice-guide-qa2 (verbatim ASQA, 17 June 2025) 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 LLND tile)

✔ RATIFIED 2026-07-07 (Tim). This file carries the whole substantive spec: §1 (build in one line), §2 (data domain — candidate store cited from rpl-02 §2.1, never re-bound), §3 (review state machine — a linear review, NOT an Accreting Review), §4 (instruments + external-result intake), §5 (capability-bar config), §6 (the advice — the 2.2(2)(b) discharge, no People gate), §7 (the 2.1/2.3/2.4 seams + no-1.5 ruling), §8 (currency, reuse, outcome/export), §9 (deferred calls resolved), §10 (the clause-bound field register — drift check clean, zero correction), §11 (build-gate hand-off). All three deferred calls are ratified (§4.3 framework — DigComp 2.2; §8.6 export serialisation — CSV at launch; §9.3 access posture — T4 + assigned-T4A with T4-only fallback). This is the ratified spec, pending filing — it files via a single docs-only brief. Do not build until filed.

LLND — Spec

Move 4 of the Legislation-to-Tile Method for the LLND tile. The obligations (llnd-00) said what the RTO must demonstrate; the model (llnd-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: Standard 2.2 / F2025L00354 mandates a pre-enrolment review of every prospective student's skills and competencies — including LLN proficiency and digital literacy (2.2(2)(a)) — and a per-student suitability advice based on the review's outcome (2.2(2)(b)). The tile is the operational form of that whole mandated procedure, not a support tool discharging a fragment (model §1, §1A). Every structure below is shaped by that: the review is the entity, the assessments are instruments within it, the advice is the headline discharge, and there is no reject outcome (model §1B).

What this spec originates vs consumes. The intake surfaces (invite → self-complete → advice delivery) are settled in intake-pipeline-01-model and consumed here, not re-specced (§3.6, and §7 when drafted). The shared candidate-identity store is cited from rpl-02 §2.1, where its name is first-bound; LLND adds only its stage deltas and never re-binds the name (§2). What this spec originates: the LLND data domain (§2), the review state machine wired to the seven discharging events (§3), the two conducted instruments and the external-result intake (§4), the capability-bar config (§5), the advice and its provably-prior-to-enrolment evidencing (§6), the seams to 2.1/2.3/2.4 (§7), the currency/reuse and outcome/export layer (§8).

1. The build in one line

Suitability Review = (prospective candidate × target training product) → per-capability result { conducted in-tile | recorded external } assembled against the product's sealed configured bar → capability profile → human-issued suitability advice { suitable | suitable-with-identified-support | not-suitable-with-alternatives }, delivered, sealed, and provably prior to enrolment.

The tile's primitive is the review (model §1), not the test. 2.2(2)(b)'s advice rests on "the outcome of the review" — singular — so the review is one entity per (candidate, product, enrolment attempt); the LLN and digital-literacy assessments are instruments within it (§4), and the product's other suitability requirements ride the same review as configured check items (§5, model §1A). The advice is a property of the review, human-issued (§6). There is no reject state — the third verdict structurally carries its alternatives-or-pathways limb (§3.3, §6, model §1B). A later review for the same candidate against a new product may honour current prior results under a currency ruling, but the discharge is always fresh (§3.5, §8).

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 (llnd-01 §9) and do not move with naming.

2.1 Stores

Store Canonical name (Peel/pair) Class Holds
LLND tile domain rtopacks-llnd-prod / rtopacks-llnd-dev (D1) Peel Reviews, instrument configs + versions, product-capability configs + versions, per-capability results, capability profiles, advice records, currency policies, check-item results, the disclosure-signal existence records, the LLND event ledger
LLND conducted-assessment store rtopacks-llnd-evidence-prod / -dev (R2) Sealed custody Response sets, session recordings, external-result documents — digest-sealed, immutable; amendments are new objects. Session recordings are biometric-adjacent: consent-captured, own retention posture (model §9); retention floor = audit window
Candidate-identity store rtopacks-candidates-prod / -dev (D1) Shared Peel Candidate identities; USI (specially handled, optional at the LLND stage — §2.3). First-bound in rpl-02 §2.1; owned by neither RPL nor LLND. Cited here, never re-bound; entry UI-only via the intake pipeline; invisible to the seat model
Pith nrt-corpus-ref (D1) Reference The product identity: code, title, composition, supersession. Read-only always; KN sacred. The capability bar is NOT on the Pith — no ACSF/digital-capability column exists there and none is claimed (model §2)
Pipeline state + capture custody the pipeline's stores (intake-pipeline-01-model §7) — Referenced, never owned here. The pipeline's delivery/capture surfaces are LLND's intake and advice-delivery channel (§3.6); custody stays the pipeline's until its seam hands sealed bytes to the LLND store

Customer-facing LLND surfaces read the Pith (read-only reference) and their own Peel stores; ops-db is never bound. People is not consumed at all in this tile's launch path (no assessor gate — §6, model §9). Sensitivity class: capability results and any disability-disclosure signal are sensitive personal information; the access posture (which T4 roles see what) binds at §9 (pending), the classification is fixed here.

2.2 The core tables (rtopacks-llnd)

Each regulated field carries its clause trace; the full anchor / obligation / consequence per field is collected in the field register (§10, pending). The instrument-qualified clauses are the fully-nested forms — 2.2(2)(a) (the review), 2.2(2)(b) (the advice) — never the model's 2.2(a)/(b) shorthand (§10 will normalise every occurrence; llnd-00 already records that its short-form denotes the (2)(a)/(2)(b) clauses). Below is the shape and the load-bearing regulated fields.

llnd_review — the entity spine (model §1). Candidate × target product × the review-level state the obligation requires. One per (candidate, product, enrolment attempt). - client_ref → the client identity (tier_grants.client_id semantics; cross-DB logical, no FK) — AMENDED 2026-07-10 per llnd-build-rulings-01: the tile is multi-tenant (the bar is the RTO's §5, the currency policy is the RTO's §8.2, sensitive results gate to the client's T4 §9.3), so the client boundary is a first-class field on every review; children inherit scope through review_ref (no denormalised copies) - candidate_ref → rtopacks-candidates (never a People person, never a seat) - target_tga_id → Pith (national identity; composition/supersession resolved from the list, model §2) - status — the state-machine position (§3) - product_capability_config_ref + config_version — the bar, sealed at review open (model §2): the defensibility of "accurate advice" (2.2-7) requires knowing which bar was applied - review_kind — { fresh | reuse }; a reuse review honours current prior results against the new product's bar (§3.5, §8) and still issues a fresh advice - sequencing_exception_flag — set where an enrolment is detected as preceding the sealed advice; the known failure mode surfaces visibly, never silently absorbed (model §6) - disclosure_signal_ref — optional → llnd_disclosure_signal (the 2.4 seam; existence only — §2.2, model §7)

llnd_product_capability_config — the bar the RTO owns (model §2, §1A). Per client × product, versioned; seeded before the first review runs; RTO-configured with guided setup at launch (assisted derivation from unit text is day-two, model §5). Not substrate data — no Pith column is claimed. - client_ref → the client identity (cross-DB logical, no FK) — AMENDED 2026-07-10 per llnd-build-rulings-01: the bar is the RTO's own, so the config is scoped per client; uniqueness is (client_ref, target_tga_id, version) (two RTOs may demand different levels for the same product) - target_tga_id → Pith, version (monotonic), authored_by, authored_at - lln_bar — the required ACSF level(s) per LLN skill (learning / reading / writing / oral communication / numeracy) - digital_bar — the required digital-literacy capabilities, against the named framework (§4, bound at spec) - check_items[] — the configured non-LLN/digital suitability items the review must cover (prerequisites, physical demands, experience declarations); each names its grade mode { declared | rto_verified } (model §1A). Their taxonomy is §5 (pending)

llnd_instrument_config — the conducted instrument, versioned (model §4). Per capability class; every result seals the version it ran against. - capability_class — { lln | digital } - version (monotonic), framework_ref (ACSF for LLN; the named digital framework for digital — §4), item_set_ref, rubric_ref - Independently commissionable — nothing couples the two instruments' launch (model §4); the review runs with whichever instruments are configured, plus external results (§4A) for the rest

llnd_result — the per-capability result (model §8). The reusable artefact; one per (review, capability), conducted or external. - review_ref, capability_class (+ capability_ref for a specific digital capability) - grade — { conducted | external } — the load-bearing honesty marker (model §4A): conducted = in-tile instrument with sealed responses + session recording; external = a recorded outside result - level / levels — the assessed outcome, framework-aligned - instrument_version — for conducted; or external_source + external_document_ref → store + recorded_date for external (model §4A: source, date, level, document reference) - response_set_ref, recording_ref → the sealed store (conducted only; recording is the authenticity anchor, biometric-adjacent, consent-gated — model §4, §9) - assessed_date, currency_marker — feeds reuse against the configured currency policy (§8)

llnd_check_item_result — the configured check item's outcome (model §1A). One per (review, check_item); lands in the profile carrying its grade. - review_ref, check_item_ref → the product config's check_items[] - grade — { declared | rto_verified } (from the config's grade mode) - outcome / value, verification_ref — recorded where rto_verified

llnd_capability_profile — assembled against the sealed bar (model event 4). - review_ref, config_version (sealed — the bar this profile was assembled against) - per capability: { assessed level, required bar, met | shortfall, grade (conducted/external) } - the check-item results ride the profile (model §1A), grade-marked

llnd_advice — the discharge, 2.2(2)(b) (model §6). The tile's consequential output and the headline discharging event. Sealed. - review_ref, profile_snapshot (the profile as it stood at issue) - advice ∈ { suitable | suitable_with_identified_support | not_suitable_with_alternatives } - support_alternatives_payload — structurally required for the third verdict (alternatives and/or pathway programs — model §1B, §6); carries the support/adjustment seam for the middle verdict (§7) - issuing_identity — the RTO staff identity that confirmed and issued (human-issued at launch; auto-issue is a named day-two config, model §6). Not a People canDeliver gate — no 3.2/3.3 requirement attaches to a 2.2 procedure (§6, model §6) - issued_to + delivery_record — how the advice reached the student (delivery is part of the discharge — an advice generated but never delivered is undischarged, model §6) - issued_at — the sealed timestamp; the tile's half of the ordering proof (provably prior to enrolment — evidenced, not enforced, §6)

llnd_currency_policy — per capability class, configured, versioned (model §8). RTO-configured defaults within RTOpacks; deliberately not model constants (mirrors people-02-spec §12.3 / rpl-02 §9.5 — the "no currency-recency constant" precedent). - client_ref → the client identity (cross-DB logical, no FK) — AMENDED 2026-07-10 per llnd-build-rulings-01: the currency window is the RTO's within RTOpacks defaults, so the policy is scoped per client; uniqueness is (client_ref, capability_class, version) - capability_class, currency_window, version — LLN slow-clock, digital faster (model §4, §8)

llnd_disclosure_signal — the 2.4 seam, existence only (model §7). Candidate-initiated, consent-framed; the tile holds the signal's existence and routes it, never the adjudication. - review_ref, raised_at, consent_ref, routed_to_rto_flag — no adjudication content; sensitive personal information (§9 access posture)

llnd_event — the discharging-events ledger (model §11). Events reference fields; fields carry instrument-qualified clauses; the clause is never copied onto the event (method: NO ORPHAN GRAINS). Seven launch events (§3.4); two reserved (auto-issued advice under config; assisted profile derivation accepted — both day-two).

2.3 USI at the LLND stage — optional, ruled (model §3)

An LLND candidate is a prospective student, often pre-enrolment and sometimes pre-USI. The USI is optional on the LLND intake — format-validated where supplied (per the Act's meaning), never required to open a review. Enrolment-time USI capture is the SMS's business (model §3, §10). The shared store supports both grades — RPL's stricter intake-time USI posture is RPL's own; the same store row serves a candidate who later enters RPL (the shared-identity dividend, model §3). student_identifier appears in the export (§8) only in its Act-defined meaning and only where held — never in a URL or message body.

3. The review state machine — a linear review with a reuse entry path

The review is not an Accreting Review (contrast RPL §3). It does not accrete per-section approvals: it assesses the configured capabilities, assembles a profile against the sealed bar, and issues one advice. Reuse (§3.5) is a fresh review that honours current prior results — it compresses the assessment, never the discharge (2.2 attaches per prospective enrolment — model §8). The foundational posture holds throughout: review and advice, never test → exclude; there is no reject state (model §1B).

3.1 The review lifecycle

(invitation issued via intake pipeline)
        │
        ▼
   OPEN ── ev1 (suitability review opened: candidate × target product, pre-enrolment;
        │        config bar sealed at open — §2)
        ▼
   ASSESSING ◀───────────────┐  per configured capability, one of:
        │                    │    ev2 (assessment conducted + sealed — LLN / digital instrument)
        │                    │    ev3 (external result recorded — source/date/level/document, §4A)
        │  (iterates until every configured capability + check item has a result)
        ▼
   PROFILED ── ev4 (capability profile produced against the sealed config bar; check items ride it)
        │
        ▼
   ADVISED ── ev5 (suitability advice ISSUED — human, three-way; delivery recorded)
        │          — the headline 2.2(2)(b) discharge
        ▼
   (result written with currency marker ── ev6, per capability)
        │
        ▼
   COMPLETE

reuse entry ─▶ OPEN(review_kind = reuse): at ASSESSING, current prior results may be HONOURED
              under the currency ruling ── ev7 — against the NEW product's bar; a fresh advice
              still issues (ev5). Reuse compresses assessment, never the discharge (§3.5, §8).

There is no rejected / excluded state anywhere in this machine. The not_suitable_with_ alternatives verdict is an advice value (§6), not a terminal reject — and it carries its alternatives payload by construction (§3.3).

3.2 What each state means

  • OPEN — the review exists: candidate × product, pre-enrolment, config bar sealed. Opening is the discharging event ev1 and the demonstration that "procedures are in place" (2.2-1) is running.
  • ASSESSING — capability results are landing, per capability, in either grade (conducted ev2 / external ev3); check items are declared or RTO-verified. The state iterates until every configured capability and check item has a result — the review cannot profile against a partial bar.
  • PROFILED — the profile is assembled against the sealed config_version (ev4); each capability reads met / shortfall; the check items ride the profile with their grades.
  • ADVISED — the advice is issued (ev5): rubric-proposed, human-issued, three-way, delivered, sealed. This is the consequential state — the headline 2.2(2)(b) discharge.
  • COMPLETE — the advice is issued and delivered, and each capability result is written with its currency marker (ev6) for future reuse. "Complete" is not a compliance gate the SMS reads — it is the tile's record that the 2.2 discharge is whole for this enrolment attempt.

3.3 The advice values are not states — and there is no bare "no"

The advice enum lives on llnd_advice (§2, §6), not on the review status. Two consequences the model forces (§1B, §6):

  • not_suitable_with_alternatives is un-issuable empty. The alternatives-or-pathways limb is a structurally required property of the third verdict (support_alternatives_payload) — the PG posture made by-construction. The machine cannot reach a terminal "not suitable, full stop."
  • suitable_with_identified_support binds its needs. The identified support items (2.3 seam) and any reasonable-adjustment signal (2.4 seam) travel in the advice payload (§7), discharging the fully-informed-decision obligation (2.2-9) in the same act.

3.4 The seven events, mapped to transitions

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

# Event Fires when Primary discharge (obligation-ID; resolved to clauses in §10.1)
ev1 Suitability review opened Invitation issued; candidate × product; config bar sealed 2.2-1, 2.2-2 (the procedure, pre-enrolment)
ev2 Assessment conducted + sealed Per instrument (LLN / digital): responses + session recording landed with digests 2.2-3, 2.2-4
ev3 External result recorded Per capability: outside result entered (source, date, level, document sealed) 2.2-3 (coverage held via external grade, §4A)
ev4 Capability profile produced Assembled against the sealed configured bar; check items ride it 2.2-4, 2.2-5
ev5 Suitability advice issued Human-issued three-way advice; payload, delivery record, sealed timestamp 2.2-6 (the headline 2.2(2)(b) discharge); 2.2-8, 2.2-9 via payload
ev6 Result written with currency marker The reusable per-capability artefact persists against the candidate (enables §8 reuse)
ev7 Prior result honoured under currency ruling (reuse reviews only) Which results, which ruling, against which bar — the fresh review + fresh advice still discharge 2.2-3/4 (re-satisfied against the new bar, §8)

Reserved, not launch: auto-issued advice under configuration (if the day-two config ships, §6); assisted profile derivation accepted (day-two, §5, model §5). The 2.1 seam (capability demands published pre-enrolment) is discharged on the RTO's information surfaces fed by the tile's product configs (§7) — an information-surface event, not double-recorded here (model §11).

3.5 Reuse — the fresh review that honours prior results

A later review (same candidate, new product) opens with review_kind = reuse. At ASSESSING, the tile offers the candidate's current prior results per capability; the currency policy (§8) rules re-assess-or-honour against the new product's configured bar:

  • A current result at or above the new bar may be honoured (ev7) — recorded on the new review with which results, under which currency ruling, against which bar.
  • A current result below the new bar forces re-assessment (ev2) or an advice that reflects the shortfall — "we have it on file" is never "it still counts" (model §8).

The discharge is always fresh: the new review seals its own config version, and a fresh advice issues for the new enrolment (ev5). Reuse compresses the assessment, never the discharge — 2.2 attaches per prospective enrolment (model §8).

3.6 The intake-pipeline seam

LLND originates no intake surface — invite → self-complete → advice delivery is intake-pipeline-01-model, parameterised in §7 (pending). Two couplings matter to the state machine here:

  • Review open is triggered by the pipeline's invitation (the bundled invitation may carry LLND + RPL together — the shared-identity dividend, model §3); identity capture (self-attestation floor, optional consent-gated ID, session recording as the conducted-assessment authenticity anchor) is the pipeline's surface, shared with RPL.
  • Advice delivery (ev5's delivery record) rides the pipeline's delivery surface — the same channel the invitation used (model §6). Custody stays the pipeline's until its seam hands sealed bytes to the LLND conducted-assessment store; LLND never reaches back into pipeline custody (§2).

4. The instruments — two conducted assessments + the external-result intake

LLN and digital literacy are two instruments under one review (model §4). Each is conducted, not submitted: the tile delivers items, captures responses, and seals a session recording as the authenticity anchor. There is no submitted-evidence bundle — that is RPL's distinction, held. Every result seals the versions it ran against (§4.4); the two instruments are independently commissionable (§4.7); and where a capability is not assessed in-tile, a recorded external result lands in the same review (§4.5).

4.1 The conducted instrument — delivery, capture, sealed session

  • Constrained-response-first at launch (model §5). Item types are selected-response, numeric, and task-completion — scored deterministically, no AI in the discharge path. Open-response items (writing samples) are permitted but their marking is the day-two AI assist (§4.7); launch instrument design prefers constrained-response precisely so that assist is an enhancement, never a dependency.
  • The sealed session anchor is the interaction record — AMENDED 2026-07-10 per LLND-CONDUCT-01. At launch the authenticity anchor of a conducted result is the interaction record: an event stream — item presented / answered timestamps, focus / blur, response revisions — digest-sealed to rtopacks-llnd-evidence (R2), immutable. There is no candidate-side AV at launch (no webcam, microphone, or screen capture; no browser media permission is ever requested). AV arrives day-two together with the oral-communication AV task (§4.9) under one consent framework, and the biometric-adjacent posture attaches to the AV when it arrives — not to the interaction record. The line stands: a conducted result without its sealed session bytes is incomplete — at launch the session bytes are the interaction record.
  • Responses seal too. The response set vaults alongside the recording (response_set_ref), so an advice challenged at audit replays from bytes, not from a score.
  • Instrument authorship — AMENDED 2026-07-10 per llnd-build-rulings-01. The conducted instruments are RTOpacks-authored against the pinned frameworks and published sealed (§4.4). There is no blank-slate authoring surface and no item-level customer editing — an edited item silently destroys its framework mapping, which is the whole defensibility of the result. Contextualised variants are RTOpacks-authored and mapped; customer customisation lives in the wrapper (branding, welcome text, delivery, choice of variant) and in the RTO's consequential policy config (§5), never in the item set. This is why llnd_instrument_config is global, not per-client (§2.2).

4.2 The LLN instrument — ACSF-aligned

LLN maps to the Australian Core Skills Framework (ACSF) — the sector's lingua franca and the incumbents' own frame; matching it is table stakes, integration is the differentiator (model §4). The ACSF describes five core skills — learning, reading, writing, oral communication, numeracy — across levels 1–5. The instrument maps items to an ACSF skill and level; the result is a per-skill ACSF level. The ACSF version is pinned on llnd_instrument_config.framework_ref, and every result seals it (§4.4).

AMENDED 2026-07-10 per llnd-build-rulings-01 — the LLN result carries seven states per skill. Below ACSF Level 1 the result resolves to Pre Level 1 stage 1A or Pre Level 1 stage 1B (ACSF Pre Level 1 supplement, 2017; ACER review of ACSF & DLSF, Aug 2022, p.4), giving the full ladder pre_1a · pre_1b · 1 · 2 · 3 · 4 · 5. The bar (§5.2) stays Levels 1–5; any below-Level-1 result reads shortfall against any configured bar. The framework_ref pin therefore names the ACSF main framework (2019) and the Pre Level 1 supplement (2017) as the paired frame. (The substrate expresses this as a seven-state CHECK on llnd_result.level, scoped to capability_class='lln'; digital rides the levels field, not this ladder.)

O1 value-set — the remote-screen representation (RC-L2 Option A, ruled 2026-07-11; ADR-067). A remote conducted LLN result carries five skills, and the remote screen cannot distinguish 1A/1B — it emits an undistinguished Pre Level 1 floor. Ruled: the LLN conducted result mirrors the digital shape — level NULL, per-skill values in the levels JSON — with the value-set pre_1 · pre_1a · pre_1b · 1 · 2 · 3 · 4 · 5, where pre_1 is the undistinguished remote floor (pre_1a/pre_1b remain the operator-assisted distinctions, CONDUCT-MODES-01). The seven-state CHECK on the single level column permits level IS NULL for lln, so this passes unchanged; the value-set is enforced at pack-level validation (the published pack's testlet level_mapping values), not by a DB CHECK on the JSON — exact parity with how digital levels are already governed. Per-skill ceilings (RC-L2: reading/numeracy/writing/oral 4, learning 3) live in the pack, not the CHECK.

Schema v2 — routing (RC-L3; ADR-067). A routed pack (schema_version: 2) carries, per skill, a routing block: a locator stage, a sealed routing_rule (locator raw score → testlet band), three testlets (floor/mid/upper), each with 2 equated parallel forms (form_id a first-class, addressable property). Flat digital v1/v2 packs carry no routing block and conduct byte-identically (the discriminator branches the conduct path once at pack load). Items may carry audio_ref/pilot/replay_limit (schema fields; asset serving is LLND-LLN-ASSETS-01). Scoring routes deterministically and counts within the selected testlet form.

4.3 The digital-literacy instrument — the framework binding (ratified 2026-07-07: DigComp 2.2)

The digital instrument maps to a named, versioned digital-literacy framework — the model fixes only that a framework is named and versioned, evaluated against the same published frame, never invented ad hoc per product (model §4, §13). No clause mandates which framework: Standard 2.2(2)(a) names "digital literacy" but leaves the frame to the RTO, so this is a product-and-defensibility call, not a legal one — the spec names one and honestly says why, rather than inventing a stricter law than exists (the model's posture, held).

Ratified 2026-07-07 — DigComp 2.2 is the named framework (source-verified at ratification: the current DEWR-preferred frame, with DigComp 3.0 live in the EU since Nov 2025 but Australian requirements still pointing at 2.2). The Australian landscape remains in flux; verify the current DEWR position at instrument commissioning before pinning a version. The three candidates weighed:

Framework Standing (as at 2026-07) Fit for a 2.2 pre-enrolment screen
DigComp 2.2 The Australian Government's preferred framework from 2025 (DEWR); internationally recognised; DigComp 3.0 released Nov 2025, adoption pending Durable, versioned, government-aligned — the defensible default. Broad workforce capability (5 areas, 8 levels): heavier than a pre-enrolment screen strictly needs; the tile maps to a pre-enrolment-relevant subset
ADCF (Australian Digital Capability Framework) A translation of DigComp 2.1 for the Australian context; referenced in sector PD as the 2025-Standards frame — but being overtaken by direct DigComp adoption Australian-contextualised, but binding to it risks binding to a superseded translation as the government moves to DigComp direct
DLSF (Digital Literacy Skills Framework) Purpose-built to enhance the ACSF up to Level 3; developed for the Foundation Skills for Your Future program — but draft/unvalidated and SEE-provider-focused The tightest conceptual fit for a 2.2 pre-enrolment review and for our ACSF LLN binding — but its draft status is an audit-defensibility risk

The ratified call (2026-07-07): name DigComp 2.2 as the pinned frame — it is the government-preferred, versioned, durable choice, and defensibility favours the standard the regulator's own department recognises; the tile maps to a pre-enrolment-relevant subset of its competence areas. The alternative weighed and not chosen was DLSF (tight ACSF-pairing, but its draft status is an audit-defensibility risk). As named: the version is pinned on the instrument config, candidates are evaluated against the same published frame, and the choice is revisited at commissioning against the then-current position (notably DigComp 3.0 adoption). This is a load-bearing external-standard assertion — treat the landscape above as verify-at-commissioning, not settled fact.

AMENDED 2026-07-10 per LLND-CONDUCT-01 — DigComp 2.2 pin verified at commissioning: the DEWR position at 2026-07-10 is DigComp 2.2, so the pin holds. DigComp 3.0 watch — trigger: DEWR names 3.0 (or a 3.0-based ADCF successor) → a new instrument version.

4.4 Versioning and sealing — the replay guarantee

Every llnd_result seals three versions: the instrument version, the product-config version (the bar), and the framework version. An advice challenged at audit replays exactly: this instrument, this bar, this frame, this response set, this profile, this advice (model §4). Instruments are versioned wholes — item set, rubric, framework mapping move together under one version.

4.5 External results — the honest wedge (model §4A)

The review accepts, per capability, either an in-tile conducted result or a recorded external result: the RTO's incumbent tool's outcome, entered with source, date, level, and document reference (grade = external, evidence-hold). Two reasons, one legal and one commercial:

  • Legal honesty. 2.2(2)(a) requires the review to cover LLN and digital literacy. An RTO adopting only the digital instrument discharges 2.2 wholly in-tile only if its existing LLN result can land in the same review — without external intake, "digital standalone" quietly fragments the RTO's 2.2 discharge, the exact failure §1A exists to prevent.
  • Commercial mechanics. The wedge is honest and the displacement path is one toggle: the RTO keeps its incumbent LLN tool, buys digital, and the review + advice already live here; when the incumbent lapses, the LLN instrument is already waiting on the same surface. The point-solution incumbent cannot answer this — it does not hold the review.

External results carry a lower evidence grade (recorded, not conducted — no session capture, no in-tile rubric); the profile marks the grade per capability (§2 llnd_result.grade). The advice does not distinguish; the audit trail does. The external document vaults to rtopacks-llnd-evidence, digest-sealed like any conducted artefact.

4.6 Two cadences → the currency policy (forward to §8)

LLN is slow-clock, near-one-time within currency; digital lapses faster and recurs. Cadence is a property of the capability class, expressed in the currency policy (§8) as configured values, not model constants — the "no currency-recency constant" precedent, held (model §4, §8).

4.7 Independently commissionable; day-two assists; zero cross-fence traffic

  • Nothing couples the two instruments' launch. The review runs with whichever instruments the RTO's configuration and the launch sequencing provide, plus external results for the rest. Ship-together vs digital-leads is a commercial sequencing call the model leaves free (model §4).
  • Two AI assists are named day-two, both propose-never-determine (model §5): open-response marking assist (AI-proposed ACSF-level marking with human moderation), and product-profile derivation assist (§5.5). Neither is in the launch discharge path; whether the derivation assist commissions engine-side or home-grown is its own day-two decision.
  • LLND launches with zero cross-fence traffic — the tile is self-contained on RTOpacks substrate (model §5), the dependency posture the fence protocol wants for a launch-critical surface.

4.8 Clause anchors (partial — full register in §10)

Field / mechanism Clause (fully-qualified in §10) Obligation-ID
The two instruments = the review's LLN + digital coverage 2.2(2)(a) / F2025L00354 2.2-3
Assessment keyed to the target product's configured bar 2.2(2)(a) / F2025L00354 2.2-4
External-result intake preserves whole-2.2 coverage 2.2(2)(a) / F2025L00354 2.2-3
Method leads to accurate advice (ACSF alignment; framework binding) PG activity 2.2-7

4.9 Oral-communication conduct — the structured observation checklist (AMENDED 2026-07-10 per llnd-build-rulings-01)

The ACSF oral-communication skill is assessed at launch as a structured observation checklist — an operator-conducted component inside the versioned instrument, its items anchored to the ACSF oral-communication performance features. It is recorded in-tile with rater identity + rubric version (§4.10); there is no candidate-side AV capture at launch. The AV-recorded oral task is a day-two increment — when built it inherits the conducted-instrument posture wholesale: consent-per-anchor, sealed R2 custody, its own retention, and a non-AV alternative. Per-product omission is permitted where the configured bar does not gate on oral communication (or an external result covers it, §4.5).

4.10 Human-rated components record rater identity and rubric version (AMENDED 2026-07-10 per llnd-build-rulings-01)

Where a component is human-rated — the oral-communication observation (§4.9), open-response marking — the result records the rater identity and the rubric version applied, on llnd_result (rater_identity, rubric_version). This is the conducted-result analogue of the sealed instrument/response bytes: a human judgement is replayable at audit only if who applied which rubric is on the record.

4.11 The instrument asset substrate + tokened serving (LLND-LLN-ASSETS-01, ADR-068)

Listening items reference audio by digest — the pack item carries audio_ref {digest, mime, duration_ms} (the schema field shipped inert by MACHINERY-01, §4.2). The substrate that stores and serves that media is a distinct custody class from the evidence vault and the capture store — published-served instrument content — and the classes do not mix.

  • Store. Bucket pair rtopacks-llnd-instrument-assets-{dev,prod}. Keys are bare {sha256} (content-addressed); the mime travels on the object (httpMetadata.contentType), so serving needs no pack load. Put-if-absent, immutable — an amendment is a new digest, never an overwrite. Same digest across packs → same object (free dedup).
  • Assemble. tools/assemble-llnd-lln-pack.mjs — an asset-augmentation pass over hand-authored LLN packs (separate from the source-pinned digital assembler); content-addresses each audio file into the env bucket and stamps audio_ref onto the mapped items. Reproducible: identical inputs → byte-identical pack.
  • Verify at publish. The publish tool GET-and-re-hashes every audio_ref before the pack row lands; a missing object (ASSET_MISSING) or a digest mismatch (ASSET_DIGEST_MISMATCH) refuses the publish and nothing inserts. The seal must not trust the write path.
  • Serve. GET /s/:token/asset/{digest} on the candidate surface, through the live tokened session (dead/revoked token → 410; unknown digest → 404). Range → 206 (mobile scrub); Cache-Control: private, max-age=31536000, immutable (digest-keyed); ETag. Never a public bucket, never a signed URL to a third party. The bucket is bound read-path-only by code discipline (no put/delete call site on the surface — the platform does not enforce read-only, so the discipline plus content-addressing is the guarantee; verified per gate by grep). Scoping is token-plus-unguessable-digest (the digest is capability-grade and reaches a candidate only via their own served projection; the content is shared published question-media with no per-candidate leakage). A tighter per-request membership check is the designated day-two upgrade (served-digest stamped on the exposure row, single indexed lookup — no pack load). See ADR-068.

4.12 The candidate sitting surface — sequence, resume, and the routing round-trip (LLND-LLN-SITTING-UI-01, ADR-069)

The conducted instrument is delivered to the candidate by a mobile-first, self-contained client served by the candidate surface itself (GET /s/:token, text/html) — no framework, foundation.md tokens applied directly. One item per screen; progress by block never by count; no visible timer; explicit play buttons (no autoplay); replay_limit enforced client-side and every play recorded as a process fact. It projects audio_ref/replay_limit (§4.2 schema fields) to the candidate; answer_key/competence_id/level_target never cross.

  • The routing round-trip (corrects the earlier "client routes locally" narrative). A routed pack's band is a function of the locator raw score, and the raw score needs the answer keys — which the candidate projection correctly withholds. So the client cannot route locally. Instead it POSTs the skill's locator responses to the seam, which computes the band with keys server-side and returns the band label only (never the score, never keys). The band is stored one-shot per skill (routed_bands on the conduct-session state) — a candidate cannot iterate locator answers against the endpoint to map keys. routing_rule therefore leaves the candidate projection entirely (it stays a sealed pack property, seam-side).
  • Conduct-session state (transient, not custody). llnd_conduct_session (one row per review) holds the pinned forms (per skill × band, with exhaustion), the routed bands, saved responses, and the sealed-block list. It gives durable resume at block boundaries (a sitting paused across days, or resumed on a second device, returns the same pinned forms + saved answers). Swept at 15 days with the interaction buffer, cleared at submit — a swept, never-submitted sitting leaves no sealed artefact (§4.1 adjudication holds).
  • W1 closed by pinning. Form selection is pinned once at first session-open (concurrency-safe via the state table's primary key); submit scores the pinned forms; the band recomputed from the submitted locator responses is a fail-closed tripwire, not the authority. The sealed manifest's pin_provenance records exactly what was served. Block order is the pack routing insertion order (sealed bytes; no schema field). Flat (digital) packs ride the same client — one block, no routing/audio. See ADR-069.

5. The capability-bar config — the product's demands, the RTO's to own

The bar is two-layer (model §2): product identity from the Pith (read-only), and capability requirements from the tile's own versioned config. No Pith column is claimed — no ACSF or digital-capability profile exists as substrate, and none is asserted. The config is the RTO's own data, seeded per product before the first review runs, and every review seals the config version it was conducted against (§4.4) — the defensibility of "accurate advice" requires knowing which bar applied.

5.1 The config entity

llnd_product_capability_config (§2), per product, versioned, RTO-owned. Holds the lln_bar (§5.2), the digital_bar (§5.3), and the check_items[] (§5.4). Seeded via guided setup at launch; assisted derivation is day-two (§5.5).

5.2 The LLN bar

Per ACSF skill (learning / reading / writing / oral communication / numeracy), the required level the product demands — or not-required for skills a product does not gate on. The review assesses against the required skills; the profile reads met / shortfall per skill against this bar (§6). The bar names ACSF levels, not raw scores — the framework alignment is the defensible unit.

5.3 The digital bar

The required digital capabilities against the named framework (§4.3), per-capability level. Same structure as the LLN bar: the config names what the product demands; the profile reads met/shortfall against it. The framework version the bar is expressed in is pinned with the config version.

5.4 The check-item taxonomy (model §1A)

The review hosts the whole 2.2 review, not just the LLN/digital slice (model §1A). The configured check items are the product's other suitability requirements, covered at declaration/verification grade — no new assessment machinery, a form surface and a config. Each check item names a type and a grade mode:

Check-item type What it covers Grade mode
prerequisite A prior qualification / unit the product requires declared | rto_verified
physical_demand Physical requirements of the training/occupation declared | rto_verified
experience_declaration Prior experience the product assumes declared (typically)
entry_requirement Licence, clearance, or occupational-licence precondition rto_verified (typically)
other_configured An RTO-named product-specific suitability item declared | rto_verified

The item lands in the profile carrying its grade (llnd_check_item_result, §2): the candidate declares, or the RTO records verification. The same per-component grade-honesty as external results (§4.5) applies — the profile is honest about how each item was established. The taxonomy is RTO-extensible via other_configured; it is not a closed model constant (the review must accommodate the variety real products carry).

5.5 Guided setup (launch) vs derivation assist (day-two)

  • Launch = RTO-configured with guided setup. The RTO seeds the bar and check items per product; the tile guides but never authors the requirement — the config is the RTO's (model §2).
  • Day-two = assisted derivation, propose-never-determine. A proposed capability profile derived from unit text, presented to the RTO to confirm or edit at config time (model §5). It proposes a config the RTO owns; it never is the bar. Whether it commissions engine-side or home-grown (KN-pattern, RTOpacks-side) is its own day-two decision — either way the house rule holds: the engine raises hands, it never signs.

5.6 Clause anchors (partial — full register in §10)

Field / mechanism Clause Obligation-ID
Bar keyed to the training product's requirements 2.2(2)(a) / F2025L00354 2.2-4
Config version sealed per review (accurate-advice defensibility) 2.2(2)(b) / F2025L00354; PG 2.2-6, 2.2-7
Check items = whole-2.2 review coverage 2.2(2)(a) / F2025L00354 2.2-1, 2.2-3
Capability demands feed the pre-enrolment info surface 2.1(2)(b)/(c)(i) / F2025L00354 2.1-1, 2.1-2

6. The advice — the discharge (2.2(2)(b)), human-issued, provably pre-enrolment

The advice is the tile's consequential output and the headline discharging event (ev5). Its shape is on llnd_advice (§2). The rulings below are the model's (§6), specced to the surface.

6.1 Rubric-proposed — deterministic

The tile derives a proposed advice deterministically from the profile against the sealed bar (§5): all-met → suitable; shortfalls with identified support → suitable_with_identified_support; shortfalls beyond support → not_suitable_with_alternatives. No AI in the discharge path (model §5) — the proposal is a rubric, not a judgement.

6.2 Human-issued — the issue act, and the gate the law does not demand

An RTO staff identity confirms or amends and issues; the issuing act is recorded with the identity (issuing_identity). Two rulings the spec states honestly:

  • No People canDeliver gate. The instrument mandates no who on a 2.2 procedure — there is no 3.2/3.3 assessor requirement on a suitability review — so no fail-closed People gate is imported here (contrast RPL §6, where the assessor requirement is real and the gate is compelled). The human-issue posture is chosen on product and audit grounds, not by clause, and the spec says so rather than inventing a stricter law than exists (model §6). People is not consumed in this launch path (§2).
  • Auto-issue is day-two. Auto-issue for clear-pass cases is a named day-two configuration (§6.6); if ever enabled it seals a config version. The model fails toward the human at launch.
  • Divergence is loud — AMENDED 2026-07-10 per llnd-build-rulings-01. Where the issuing identity amends away from the rubric-proposed advice (§6.1), the advice record carries an explicit divergence marker (divergence_marker + divergence_note on llnd_advice, §2). The amendment is a discrete, visible, signed fact — recorded and surfaced, never a silent overwrite of the deterministic proposal. A human may override the rubric; the record makes it plain that they did.

6.3 The three verdicts and their required payloads

The advice enum is a property of llnd_advice, not a review state (§3.3). Each verdict's payload is part of the discharge:

  • suitable — the profile meets the bar; no support/alternatives limb required.
  • suitable_with_identified_support — shortfalls answerable by support. The identified support items (2.3 seam) and any reasonable-adjustment signal (2.4 seam) travel in support_alternatives_payload, discharging the fully-informed-decision obligation (2.2-9) in the same act (§7).
  • not_suitable_with_alternatives — alternatives and/or pathway programs are a structurally required property; the tile blocks the issue act if the payload is empty. There is no bare "no" — the third verdict helps the student land in training they can complete (model §1B, §6).

6.4 Provably prior to enrolment — evidenced, not enforced

Enrolment lives in the SMS, outside this tile's control — so the tile cannot enforce the ordering and does not pretend to (model §6). It evidences it:

  • issued_at is a sealed timestamp — the tile's half of the ordering proof. The export (§8) carries it so the RTO's enrolment record can stand beside it.
  • The known failure mode (enrol first, review later) surfaces as a visible sequencing exception (sequencing_exception_flag, §2) on the review — never silently absorbed. The tile reports the anomaly; it does not paper over it.

6.5 Delivery is part of the discharge

"Advice provided to each prospective student" (2.2(2)(b)) means the record carries how it reached them (delivery_record) — the intake pipeline's delivery surface, the same channel the invitation used (§3.6). An advice generated but never delivered is an undischarged obligation; delivery is a recorded property, not an assumption (model §6).

6.6 Auto-issue — reserved, day-two

The ev5 auto-issue variant is reserved (§3.4): a named configuration, config-version sealed if enabled, fails toward the human at launch. Not built.

6.7 Clause anchors (partial — full register in §10)

Field / mechanism Clause Obligation-ID
The advice, per prospective student, on the review outcome 2.2(2)(b) / F2025L00354 2.2-6
The alternatives/pathway limb (third verdict) PG activity 2.2-8
Support/adjustment payload (fully-informed decision) 2.2(2)(b) / F2025L00354; seams 2.3, 2.4 2.2-9
Delivery recorded as part of the discharge 2.2(2)(b) / F2025L00354 2.2-6
Issue act by a recorded identity (no People gate imported) 2.2(2)(b) / F2025L00354 2.2-6

7. The seams — 2.1 upstream, 2.3 / 2.4 downstream, Record, and no 1.5

The review sits in a web of adjacent standards. The tile carries results to where each is operated and claims nothing it does not do (model §7). One seam is upstream (2.1); two are downstream (2.3, 2.4); Record consumes the lot; and one seam that looks tempting (1.5 validation) is honestly ruled out.

7.1 The 2.1 seam (upstream) — capability demands published pre-enrolment

The product config's capability requirements (§5) feed the RTO's pre-enrolment information surface: the LLN and digital-literacy demands of a product, and where the RTO requires a specific test, are surfaced ahead of enrolment and fees. This is discharged on the information surface, not double-recorded in the LLND ledger (model §11) — an information-surface event, fed by the tile's configs. The tile's job here is to be the source of truth for the demands, not to re-publish them.

Anchors: 2.1(2)(b) (identify which information students require prior to enrolment and communicate it) and 2.1(2)(c)(i) (requirements to commence/complete, including assessment requirements) / F2025L00354.

7.2 The 2.3 seam (downstream) — training support determination

The profile's identified needs — shortfalls and the proposed support items — are a principal input to the RTO's 2.3(2)(a) determination of training support services. The tile:

  • records the needs and the proposed support items in the advice payload (support_alternatives_payload, §6.3); and
  • claims nothing about provision. Support provision is an RTO act, evidence-held — the tile never asserts it has provided support.

The PG's known risk ("not conducting pre-enrolment checks…") is discharged by the review's existence; the seam carries the result to where support is operated. Anchor: 2.3(2)(a) / F2025L00354.

7.3 The 2.4 seam (downstream) — reasonable adjustments

The review may surface a disability-disclosure signal (llnd_disclosure_signal, §2): candidate-initiated, consent-framed — the PG's supported-to-disclose posture. The tile holds the signal's existence and routes it to the RTO's 2.4 process; it holds neither the disability detail as adjudicable content nor the adjustment decision — those are the RTO's (2.4(2)(b)/(c)). The signal is sensitive personal information; its access posture binds at §9.

Anchors: 2.4(2)(a) (supported to disclose) / F2025L00354; 2.4(2)(b)/(c) are the RTO's process, seamed not held.

7.4 Record surfacing

Reviews, profiles, and advice artefacts are the RTO's 2.2 evidence — surfaced to Record (and Observatory) as the pre-enrolment layer of the student-support picture. Record consumes; LLND originates. No Record surface is specced here; the seam is named so the evidence lands where the audit picture assembles.

7.5 No 1.5 validation seam — honestly labelled

The review is a 2.2 procedure, not an assessment system under 1.3/1.4 — so the five-yearly validation cycle (1.5) does not attach. Instrument quality assurance — moderation of the LLN and digital instruments, rubric review — is real, and named as self-assurance-grade practice (PG layer), deliberately not dressed as a clause obligation that does not exist (model §7). The spec states this rather than inventing a validation obligation; the honesty is the point (the same posture as §6.2's "no People gate the law doesn't demand").

7.6 Clause anchors (partial — full register in §10)

Seam Clause Obligation-ID
2.1 — demands published pre-enrolment (info-surface event) 2.1(2)(b), 2.1(2)(c)(i) / F2025L00354 2.1-1, 2.1-2
2.3 — needs feed the support determination; provision RTO-held 2.3(2)(a) / F2025L00354 2.2-9 (via advice); 2.3 seam
2.4 — disclosure signal routed; adjudication RTO-held 2.4(2)(a) / F2025L00354 2.2-9 (via advice); 2.4 seam
1.5 — no validation seam; instrument QA is self-assurance-grade — (deliberately none) model §7

8. Currency, reuse, and the outcome / export layer

The result is reusable; the discharge never is (model §8). This section gives the currency mechanics, the reuse read, and the outcome/export layer — one source, three presentations.

8.1 The result's currency fields

A llnd_result (§2) carries: capability class, level(s), instrument version (or external source), assessed/recorded date, and grade (conducted / external). The currency_marker is read against the currency policy (§8.2) to rule re-assess-or-honour at a later review.

8.2 The currency policy — configured, versioned, not model constants

llnd_currency_policy (§2) is per capability class: a currency window, versioned. LLN is slow-clock; digital lapses faster (§4.6). The values are the RTO's, within RTOpacks defaults — never model constants (the RPL / people-02-spec §12.3 precedent on configured policy values, held). No currency-recency constant is invented here — the deliberate omission, carried.

8.3 Reuse — the fresh review that honours (mechanics of §3.5)

A reuse review (§3.5) offers the candidate's current prior results per capability; the currency policy rules re-assess-or-honour against the new product's configured bar:

  • A current result at or above the new bar may be honoured (ev7) — the new review records which results, under which currency ruling, against which bar.
  • A current result below the new bar forces re-assessment (ev2) or an advice that reflects the shortfall. "We have it on file" is never "it still counts."

The discharge is always fresh: honouring a prior result is a form of the review — the new review seals its own config version and a fresh advice issues for the new enrolment (ev5). Reuse compresses the assessment, never the discharge (2.2 attaches per prospective enrolment). The embedding payoff stands: each subsequent enrolment carries less friction, and only the platform holding the persistent candidate identity can offer it (model §8).

8.4 The outcome source — the advice record itself

A divergence from RPL, ruled here. RPL needed a separate per-unit rpl_outcome table because its outcome aggregates per-unit judgements (rpl-02 §8). LLND's outcome is the advice — one per review — so llnd_advice with its sealed profile_snapshot and issued_at (§2) is the single outcome source. No separate outcome table is minted; the three presentations (§8.5) read the advice record directly. Minting a redundant outcome table would violate the shape-matches-substrate discipline.

8.5 One source, three presentations (the pattern, mirrored from rpl-02 §8)

  1. Held (always) — the advice + profile snapshot in the tile; the RTO's own record and the Record surfacing (§7.4).
  2. Neutral SMS-consumable export (launch) — the importable file (§8.6).
  3. Local retrieval (no-SMS RTOs) — the RTO downloads the same export as the record it files (model §10). Where the RTO has no SMS, the export is the filed record.

8.6 The export shape + serialisation (ratified 2026-07-07: CSV at launch)

Custody stays home; the outcome leaves (model §10). What crosses the SMS boundary is the advice outcome + profile summary + the ordering-proof timestamp — no evidence bytes, no recordings, no response sets ever leave.

  • Row grain: one row per review. One advice = one (candidate × product) suitability determination — exactly what the SMS attaches to the enrolment record. (Contrast RPL's one-row-per-unit-claim: LLND's unit of discharge is the review, not a per-unit grant.)
  • Columns: candidate identifier (USI only where held, in its Act-defined meaning — never in a filename or URL, §2.3); target product (code + title); the advice verdict; issued_at (the ordering-proof timestamp); a profile summary (per-capability met/shortfall + grade — conducted / external); and a support/alternatives summary (the payload's headline, not its full content).
  • Ratified 2026-07-07 — serialisation: CSV at launch (schema firm; JSON day-two alternate) — mirroring the ratified rpl-02 §9.2 export call, so an RTO running both tiles imports one serialisation family.
  • SMS Connect round-trip is day-two. Launch is a one-way importable export; the round-trip (advice pushed into the SMS, enrolment-ordering confirmed back) waits (model §10).

8.7 Clause anchors (partial — full register in §10)

Field / mechanism Clause Obligation-ID
Reuse re-satisfies against the new product's bar; fresh advice 2.2(2)(a), 2.2(2)(b) / F2025L00354 2.2-3/4, 2.2-6
Export carries the ordering-proof timestamp (provably prior) 2.2(2)(b) / F2025L00354 2.2-6
student_identifier in its Act-defined meaning, held-only Student Identifiers Act 2014 (privacy invariant)

8.8 The Review Evidence Manifest (REM) — the sealed package (RC-L10, ADR-067; LLND-LLN-MACHINERY-01)

The outcome (§8.4) is the advice; the REM is the sealed binding of the whole review — one tamper-evident artefact from which any part replays by digest. Assembled mechanically at COMPLETE (it rides the ev6 currency-marker transition — the currency ruling is the last discharging act, so COMPLETE is the moment the review is whole; no new event is minted — RC-L10 ruled REM rides COMPLETE, not an ev8). Shape:

  • identities — review_id, candidate_ref, target_tga_id + resolved title, client_ref, review_kind, conduct_mode.
  • sealed_frame — config version (the bar); per conducted instrument its version + pack digest + framework_ref; the currency-policy version(s) in force for the client; the consent-text version affirmed on the intake.
  • per_capability_evidence — per result: grade, level(s), and the digest of every vaulted artefact — response set, interaction record, presented-form manifest (a named member, §4.x / L3-A), external document; honoured (reuse) rows reference the prior review's REM digest (chaining designed; population day-two).
  • discharge — profile-snapshot digest, advice value, support/alternatives payload digest, divergence marker+note, issuing identity, issued_at, delivery record.

The REM is canonical-JSON, content-addressed to the evidence vault at {review_id}/manifest/{sha256} (put-if-absent, immutable — a correction is a new review, never a rewrite), its digest landing on llnd_review.rem_digest. PKI signatures stay deferred (RC-L10) — the hash-manifest over an append-only substrate is the tamper-evidence; the REM is signature-ready if a counterparty ever demands one. Custody-side only: the REM never leaves; the export (§8.6) carries the outcome, evidence stays home.

9. Deferred calls resolved

The model (§13) deferred a set of structural and presentation calls to this spec. Here they are, resolved. Three carried ratification markers and were ratified by Tim on 2026-07-07 (the digital framework §4.3, the export serialisation §8.6, and the access posture §9.3); the rest are spec calls the model's boundaries already determine.

9.1 The digital-literacy framework — resolved at §4.3 (ratified 2026-07-07)

See §4.3. Ratified: DigComp 2.2 named, version pinned, mapping to a pre-enrolment-relevant subset; verify the DEWR position at commissioning (DigComp 3.0 watch). No clause mandates the frame — a product-and-defensibility call.

9.2 Export serialisation — resolved at §8.6 (ratified 2026-07-07)

See §8.6. CSV at launch (schema firm; JSON day-two), one row per review, mirroring the ratified rpl-02 §9.2 so a two-tile RTO imports one serialisation family.

9.3 Access posture for sensitive results (ratified 2026-07-07: T4 + assigned-T4A, with T4-only fallback)

The classification is the model's (§9): capability results and disclosure signals are sensitive personal information. The access posture is the spec's:

  • Capability profiles + per-capability results: visible to T4 (client administrator) and to the T4A identity assigned to conduct the review / issue the advice — not to unrelated T4A identities.
  • Disclosure signals (2.4): existence + routing visible to T4; the tile holds existence, not adjudicable disability detail (§7.3), so the sensitive surface is minimal by design; consent-gated at capture.
  • The sealed conducted-assessment store (recordings, response sets): access is review-scoped — the issuing identity and T4; recordings (biometric-adjacent) carry the tightest gate, consent-bound.

Ratified 2026-07-07 — this is the tier-mapping default; tighten if the RTO role model demands finer granularity (bind-at-build against the live role model, §11.4). If the per-review assignment/scoping concept is not bound at LLND build, sensitive results gate to T4-only at launch (coarser but safe); the assigned-T4A refinement lands when the scoping concept confirms.

AMENDED 2026-07-10 per llnd-build-rulings-01 — the fallback is now the ruling, not a conditional. The per-review assignment/scoping concept is confirmed ABSENT — no per-candidate operator-assignment edge exists in the workspace permission model (ONBOARDING-PERMISSION-USI-RECON-01, 2026-07-08; WORKSPACE-PERMISSION-MODEL-AUDIT-01). Therefore sensitive results gate to T4-only at LLND launch (the coarser-but-safe posture), scoped by client_ref (§2.2). The assigned-T4A refinement is a later increment, gated on first building the assignment edge — it is not a launch capability. Scoping is therefore tier × client only, matching the substrate's client_ref boundary.

9.4 Configured policy values (mirroring people-02-spec §12.3 / rpl-02 §9.5)

Deliberately not invented as model constants:

  • Currency windows per capability class — LLN slow, digital faster; RTO defaults within RTOpacks. No currency-recency constant (the deliberate omission, §8.2).
  • Recording retention floor — within the sealed store's audit-window floor; the biometric-adjacent recordings carry their own consent-bound retention.
  • Advice auto-issue thresholds — day-two only (§6.6); no launch constant.

9.5 Copy constraints — the surface-copy invariants (model §1B)

The review-and-advice framing is the product's voice; the copy must never read as an entry exam or a promised outcome:

  • No pass/fail-exam language. The surface is a review, not a test with a pass mark; a "result" is a capability level, never "pass/fail."
  • Shortfall ≠ rejection. A shortfall shows the gap and the support/alternatives — never a "fail" or a "no" (the amber≠red discipline, LLND form).
  • Instrument-never-verdict. The instrument produces a level; the advice is the verdict, human-issued. Copy never lets an instrument score read as the suitability decision.
  • No promised outcome. The advice speaks to suitability for enrolment, never guarantees completion or a qualification.
  • Manual-never-degraded. Human issue (launch) is never framed as a lesser or slower mode than a future auto-issue.
  • Alternatives-required in copy. The third verdict's surface always presents alternatives/pathways — there is no UI path to a bare "not suitable."
  • Screening-indicator, never psychometric-test — AMENDED 2026-07-10 per llnd-build-rulings-01. Surface and artefact language claims a structured screening indicator mapped to published frameworks (ACSF, DigComp 2.2), never a validated psychometric test. Psychometric validation is a maturity step, never a launch claim; the copy must not assert a validity the instrument has not earned.

9.6 Process-metadata disciplines (RC-3) (AMENDED 2026-07-10 per llnd-build-rulings-01)

Any process metadata a conducted session yields — timing, focus, response cadence and the like — is governed by five disciplines, none of which is a launch capability beyond the anchors §4 already seals:

  • Facts-not-verdicts. Process metadata records observations; it emits no authenticity conclusion. The tile never declares a session genuine or fraudulent.
  • Disclosed-never-covert. Any capture is disclosed to the candidate; there is no covert behavioural surveillance.
  • Signals-inform-never-gate. Process signals never auto-block, never raise mid-flight flags, and are never shown to the candidate; they inform the RTO's later human review only.
  • Two strata strictly separated. Process metrics never enter the ACSF/DigComp capability computation — the assessment stratum and the process stratum do not mix.
  • Launch capture is anchor-limited — AMENDED 2026-07-10 per LLND-CONDUCT-01. At launch the anchor-limited capture set is the interaction-capture record + the sealed response sets (§4.1) — no candidate-side AV. Extended telemetry beyond that stays day-two, under these same disciplines. The four disciplines above bind the interaction record explicitly: it records facts, never verdicts; its capture is disclosed, never covert; its signals inform the RTO's later human review and never gate; and it sits in the process stratum only — the interaction stream never enters the ACSF / DigComp scoring (the two strata stay strictly separated).

Binding at launch: all intake consent and disclosure text is readable at ACSF Pre Level 1 — the people the review screens must be able to read what they are consenting to.

10. The clause-bound field register

Move 4 binds every regulated field to its real, fully-qualified clause within F2025L00354 — never a bare number, and never an internal obligation-ID qualified as an instrument clause (the drift rpl-02 §10.3 caught retroactively; this spec applied the discipline at authoring time — §10.3). The internal obligation-IDs (2.2-N, 2.1-N) from llnd-00 are cross-references into the register, never themselves instrument-qualified.

10.1 The obligation-ID → clause key

Read against the authorised as-made F2025L00354 (registered 14 Mar 2025, compilation 0; the verified corpus, STANDARDS-CORPUS-REBUILD-01). llnd-00 records that its short-form 2.2(a)/(b) denote the instrument's 2.2(2)(a)/(2)(b); this register uses the fully-nested clauses only.

Obligation-ID (llnd-00) Real clause Source
2.2-1 — procedures in place to review 2.2(2)(a) / F2025L00354 instrument
2.2-2 — prior to enrolment, provably 2.2(1) + 2.2(2)(a) / F2025L00354 instrument
2.2-3 — covers LLN + digital literacy 2.2(2)(a) / F2025L00354 instrument
2.2-4 — takes the product's requirements into account 2.2(2)(a) / F2025L00354 instrument
2.2-5 — reaches each prospective student individually 2.2(2)(a) + 2.2(2)(b) / F2025L00354 instrument
2.2-6 — advice per student, on the review outcome 2.2(2)(b) / F2025L00354 instrument
2.2-7 — leads to accurate advice — PG activity
2.2-8 — alternatives/pathways where lacking — PG activity
2.2-9 — fully-informed decision (support/adjustment) 2.2(2)(b) / F2025L00354 + seams 2.3(2)(a), 2.4(2)(a) instrument + PG
2.1-1 — LLN/digital demands, info pre-enrolment 2.1(2)(b) + 2.1(2)(c) / F2025L00354 instrument + PG
2.1-2 — specific-test requirement accessible 2.1(2)(c)(i) / F2025L00354 instrument + PG

Downstream seam clauses (held by the RTO, seamed not held by the tile): 2.3(2)(a); 2.4(2)(a)/(b)/(c) / F2025L00354.

10.2 The field register

Every load-bearing regulated field → its clause → the consequence if absent. (Fields from §2; the grade, version-sealing, and payload fields are where "accurate advice" and audit-replay live.)

Field (entity.field) Clause Obligation-ID Consequence if absent
llnd_review.target_tga_id 2.2(2)(a) / F2025L00354 2.2-4 review not product-keyed; advice not in the product's context
llnd_review.product_capability_config_ref + config_version 2.2(2)(b) / F2025L00354; PG 2.2-6, 2.2-7 the bar applied is unknown; accurate-advice defensibility lost
llnd_review.sequencing_exception_flag 2.2(1) / F2025L00354 2.2-2 enrol-first goes silently absorbed; pre-enrolment ordering unevidenced
llnd_product_capability_config.lln_bar / digital_bar 2.2(2)(a) / F2025L00354 2.2-3, 2.2-4 LLN/digital coverage or product-context missing
llnd_product_capability_config.check_items[] 2.2(2)(a) / F2025L00354 2.2-1 the whole-2.2 review fragments across systems
llnd_result.grade (conducted / external) 2.2(2)(a) / F2025L00354; PG 2.2-3, 2.2-7 evidence honesty lost; the audit trail can't distinguish
llnd_result.instrument_version / external_source 2.2(2)(b) / F2025L00354; PG 2.2-7 audit-replay and defensibility gone
llnd_capability_profile (met/shortfall vs sealed bar) 2.2(2)(a) / F2025L00354 2.2-4, 2.2-5 advice not resting on a real, per-student profile
llnd_advice.advice + support_alternatives_payload 2.2(2)(b) / F2025L00354; PG 2.2-6, 2.2-8, 2.2-9 the headline discharge missing, or a bare "no" issued
llnd_advice.issuing_identity 2.2(2)(b) / F2025L00354 2.2-6 advice unattributed
llnd_advice.delivery_record 2.2(2)(b) / F2025L00354 2.2-6 "provided to each prospective student" unevidenced
llnd_advice.issued_at 2.2(1) / F2025L00354 2.2-2 the ordering-proof half is missing
llnd_disclosure_signal 2.4(2)(a) / F2025L00354 2.2-9 (2.4 seam) supported-to-disclose unevidenced
product config → 2.1 info surface 2.1(2)(b), 2.1(2)(c)(i) / F2025L00354 2.1-1, 2.1-2 capability demands not published pre-enrolment

10.3 The clause-trace check — what this pass confirmed

Unlike rpl-02 §10 — whose fresh read caught 20 occurrences of internal obligation-IDs qualified as instrument clauses and corrected them retroactively — this spec applied the anchor discipline at authoring time. The §4.8/§5.6/§6.7/§7.6/§8.7 anchor tables carried the real clause and the internal ID in separate columns from the first draft. The §10 fresh read, plus a programmatic check (internal 2.x-N never adjacent to F2025L00354), confirmed zero drift — no correction pass was needed. The RPL lesson held forward, which is the register's whole purpose.

11. What hands to the build gates

11.1 The launch spine — manual mode, fully deterministic, zero cross-fence dependency

Item delivery → constrained-response scoring → framework mapping → profile assembly against the sealed bar → rubric-proposed, human-issued advice → recorded delivery. No AI in the discharge path; no UCCA engine; no People gate; zero cross-fence traffic (model §5). The whole launch tile is RTOpacks-substrate self-contained — the dependency posture the fence protocol wants for a launch-critical surface.

11.2 Designed-in, separately commissioned

  • The two AI assists (open-response marking; product-profile derivation) — propose-never-determine, day-two, separately commissioned (engine-side or home-grown, its own decision).
  • Auto-issue advice — day-two config (§6.6); launch fails toward the human.
  • SMS Connect round-trip — day-two (§8.6); launch is a one-way importable export.
  • The conducted instruments (item banks, rubrics per capability class) — independently commissionable (§4.7); ship-together vs digital-leads is a commercial sequencing call.

11.3 Build order and external dependencies (confirm-at-build)

  • Candidate store — already bound by RPL. rtopacks-candidates is first-bound in rpl-02 §2.1; confirm it exists and bind to it — do NOT re-create (§2). The load-bearing inheritance.
  • Intake pipeline — shared build state. Invite / self-complete / delivery are the pipeline's; LLND's expressions are specced once with RPL per the pipeline artefact (§3.6, §11.6). Confirm the pipeline's LLND parameters at build.
  • ACSF mapping — the LLN instrument's framework mapping; ACSF version pinned.
  • The digital-literacy framework — the ratified DigComp 2.2 choice (§4.3); confirm framework + version against the current DEWR position at instrument commissioning (DigComp 3.0 adoption watch).
  • People canDeliver — not called at launch (no gate); any day-two issuing-role binding enters through People's contract, never its tables.

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

  • Store/bucket names per cloudflare-naming-canon, verified against cloudflare-resource-inventory (rtopacks-llnd-prod/-dev; rtopacks-llnd-evidence-prod/-dev).
  • The candidate-store cite: verify RPL bound it; bind, don't re-create.
  • The LLND event-ledger substrate (tile-domain table vs a shared audit store) — bind at build (mirrors rpl-02 §11.4).
  • The §9.3 access posture — confirm a per-review assignment/scoping concept exists to bind "assigned-T4A" to; if it does not, the T4-only fallback holds at launch and the assigned-T4A refinement lands when the scoping concept confirms (§9.3).
  • The currency-policy defaults + recording retention floor — configured values seeded at build (§9.4).

11.5 The EXT-API gate

  • USI — format-validation only at launch (usi-registry-ext-api); optional at intake (§2.3); any registry operation is day-two behind the ext-api doc (EXT-API RULE).
  • The digital-literacy framework — if the chosen framework's mapping pulls from an external registry/API (vs a static published reference), an EXT-API reference doc is owed in docs/ops/ before deploy. A static published reference (the likely case) needs no ext-api gate — confirm which at commissioning.

11.6 The shared-pipeline coordination with RPL

LLND and RPL share the candidate store and the intake pipeline. The bundled invitation (one intake carrying LLND + RPL) is the shared-identity dividend (model §3); its surface is the pipeline's, specced once. Build coordination: LLND must not fork the pipeline or the candidate store — it consumes both.

11.7 The ratification roll-up

Three calls, all ratified 2026-07-07 (Tim):

  1. §4.3 — the digital-literacy framework: DigComp 2.2, pinned, verify-at-commissioning.
  2. §8.6 — export serialisation: CSV launch / JSON day-two; one-row-per-review.
  3. §9.3 — access posture: T4 + assigned-T4A default, with the T4-only fallback; the assigned-T4A binding depends on the per-review scoping concept confirming (a read-only recon is queued on that question) — filing does not wait on it, because the fallback is safe either way.

Plus the intake-pipeline and candidate-store bind-at-build confirmations (§11.3/§11.4) — mechanical, not design calls.

The LLND spec. Move 4 of the Legislation-to-Tile Method for the LLND tile. Derived from llnd-01-model, answering llnd-00-obligations (the 2026-07-07 redraft), read against the authorised as-made F2025L00354 (Standards 2.1, 2.2, 2.3, 2.4) and practice-guide-qa2. It cites the shared candidate store first-bound in rpl-02 §2.1 and never re-binds it; consumes the intake pipeline; imports no UCCA-engine dependency and no People gate; and binds every regulated field to its real, fully-qualified clause — the register applied at authoring time, drift zero. The launch tile is a deterministic, self-contained 2.2 pre-enrolment review-and-advice surface with no reject outcome. All three deferred calls were ratified by Tim on 2026-07-07; the tile files via a single docs-only brief.