LLND — Model¶

The legislation-grounded reasoning for the LLND tile — the why. Move 3 of the Legislation-to-Tile Method: the obligations checklist (llnd-00-obligations, the 2026-07-07 redraft against the corrected corpus) said what the RTO must demonstrate; this models the tile as the answer. The spec (llnd-02-spec, move 4) derives from this document and points back to it; it does not restate it.

The single load-bearing fact, carried whole from move 2: Standard 2.2 / F2025L00354 mandates a pre-enrolment review of every prospective student's skills and competencies — naming LLN proficiency and digital literacy in the PI itself (2.2(a)) — and a per-student suitability advice based on the review's outcome (2.2(b)). The tile is the operational form of a whole mandated procedure, not a support tool discharging a fragment.

Substrate grounding: the target product is a TGA national identity resolved against rto-nrt-db (Pith, read-only always) for identity, composition, and title — the same Fork-1 discipline as People and RPL. The capability bar is not on the Pith: no ACSF or digital-capability profile exists as a substrate column, and none is asserted. The per-product capability requirements are the tile's own configured data (§2). No Pith column is claimed that has not been verified.

1. The review surface in one line¶

Suitability Review = (prospective candidate × target training product) → capability profile (assessed and/or recorded per capability, keyed to the product's configured requirements) → suitability advice { suitable | suitable-with-identified-support | not-suitable-with-alternatives } — issued to the student, sealed, provably prior to enrolment.

The tile's primitive is the review, not the test. 2.2(b)'s advice rests on "the outcome of the review" — singular — so the review is one entity per (candidate, product, enrolment attempt), and the LLN and digital-literacy assessments are instruments within it, not the spine itself. This is the direct structural echo of RPL's Application and People's Delivery Assignment: the review's opening is a discharging event, the assessments and check items are properties of it, the advice issues from it, the ledger reads off it.

1A. Scope ruling — the tile hosts the whole 2.2 review¶

Ruled (flagged in move 2; decided here). 2.2(a) mandates review of "skills and competencies… including" LLN and digital literacy — the mandated review is broader than the two named capabilities (the PG names physical requirements, prior experience, prerequisites, entry requirements). The tile hosts the whole review:

Why: the advice (2.2(b)) is singular per review. A tile holding only the LLN/digital slice fragments the RTO's 2.2 discharge across systems, and the advice artefact — the headline discharge — would rest on outcomes the tile cannot see. Whole-review custody is what makes the tile the 2.2 surface rather than an input to it.
How, without launch bloat: the review's components are two grades. Assessed components — LLN and digital literacy, the tile's conducted instruments (§4). Configured check items — the product's other suitability requirements (prerequisites, physical demands, experience declarations), declaration/verification grade at launch: per-product configuration names the item; the candidate declares or the RTO records verification; the item lands in the profile carrying its grade — declared or RTO-verified — the same per-component grade-honesty §4A applies to external results. No new assessment machinery; a form surface and a config.
The tile name stays LLND — the name is ruled (frozen-launch-scope) and names earn the tap. Whether the whole-review scope eventually warrants a broader surface name is Tim's call, not this document's.

1B. The foundational posture: review + advice, never test → exclude¶

Carried structural from move 2. The instrument mandates review and advice; it nowhere mandates exclusion, and the PG's activities run the other way (advise alternatives and pathways). Structurally: there is no reject outcome in this tile. The advice enum is three-way — suitable / suitable-with-identified-support / not-suitable-with-alternatives — and the third carries its alternatives-or-pathways limb as a required property, never an empty "no." A surface that presented as an entry exam would miss the obligation and read as the wrong product; the differentiator is that the tile helps the student land in training they can complete, which is exactly what 2.2 asks.

2. What the tile reads — the bar is (national product identity + configured capability¶

requirements)

Two layers, deliberately distinct:

Product identity from the Pith. The target product is a TGA code resolved against rto-nrt-db — title, composition, supersession lineage. RTO-authored never. The review is keyed to the national identity so it stays evaluable for any national product.
Capability requirements from the tile's own config. What LLN levels (ACSF-aligned) and digital-literacy capabilities a product demands is not substrate data — it is a per-product configuration the RTO owns, seeded per product before the first review runs. The config is versioned; every review seals the config version it was conducted against — the defensibility of "accurate advice" (move 2, 2.2-7) requires knowing what bar was applied. Launch = RTO-configured with a guided setup; assisted derivation of a proposed profile from unit text is named day-two (§5) and is an assist, never an authority.

The check items (§1A) ride the same config: per product, the RTO names the non-LLN/digital suitability items the review must cover.

3. The candidate — second consumer of the shared store¶

The shared candidate-identity store ruled in rpl-01-model §4 (dedicated substrate beside People, UI-only entry, no seat, invisible to the seat model) serves LLND as its second consumer. Deltas the LLND side adds to the shared contract:

Earlier-stage identity. An LLND candidate is a prospective student — often pre-enrolment, sometimes pre-USI. Ruled: the USI is optional on the LLND intake (format- validated where supplied, per the Act's meaning); enrolment-time USI capture is the SMS's business. RPL's stricter posture (USI captured at intake) is RPL's own; the store supports both grades.
One identity, both tiles. A candidate invited to LLND who later enters RPL (or vice versa) is the same store row — this is the shared-identity dividend, and the bundled invitation (one intake carrying LLND + RPL) is the intake pipeline's surface, already named in rpl-01-model §4.
Results do not live in the store. The store holds identity only. Capability results are LLND-domain records (§9) referencing the candidate id — the same pattern as RPL applications referencing the candidate. The store stays thin, shared, and privacy-simple.

Identity capture at review time — self-attestation floor; session recording as the authenticity anchor for conducted assessments; optional consent-gated photo ID per the ruled posture (move 2, custody section) — is the intake pipeline's surface, shared with RPL.

4. The instruments — two assessments, one review; conducted, versioned, sealed¶

LLN and digital literacy are two instruments under one review, per move 2's one-tile-two-products ruling:

Conducted, not submitted. Each instrument is administered by the tile: item delivery, response capture, session recording sealed as the authenticity anchor. There is no submitted-evidence bundle (the RPL distinction, held).
Versioned. Every instrument (item set, rubric, framework mapping) carries a version; every result seals the instrument version + the product-config version it ran against. An advice challenged at audit replays: this instrument, this bar, this response set, this profile, this advice.
Framework-aligned. LLN maps to ACSF levels (the sector's lingua franca; the incumbents' own frame — matching it is table stakes, integration is the differentiator). Digital literacy maps to a named capability framework at spec time; the model fixes only that a framework is named and versioned, not invented ad hoc per product.
Two cadences. 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) — configured values, not model constants.
Independently commissionable. Nothing couples the two instruments' launch: the review runs with whichever instruments the RTO's configuration and the launch sequencing provide, plus external results (§4A) for capabilities not assessed in-tile. Ship-together vs digital-leads is a commercial sequencing call (frozen-launch-scope territory); the model makes either free.

4A. External results — the honest wedge, ruled¶

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

Legal honesty: 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" would quietly leave the RTO's 2.2 discharge fragmented — the exact thing §1A exists to prevent.
Commercial mechanics: the wedge becomes honest and the displacement path becomes one toggle. The RTO keeps its incumbent LLN tool, buys digital, and the review + advice already live here; when the incumbent's contract lapses, the LLN instrument is already waiting on the same surface. The point-solution incumbent cannot answer this because it does not hold the review.

External results carry a lower evidence grade (recorded, not conducted — no session capture, no in-tile rubric) and the profile marks the grade per capability. The advice does not distinguish; the audit trail does.

5. The engine question — ruled: no UCCA dependency; deterministic-first; AI-assist is¶

day-two and never determines

Ruled (the model question move 2 refused to assume). The UCCA engine's one competency is reasoning about how material relates to a unit's requirements — evidence-to-obligation tracing. The LLND review is a different machine: a conducted instrument scored against a capability framework. The engine's primitive does not apply, and no cross-fence dependency exists in this tile:

Launch is fully deterministic. Item delivery, constrained-response scoring (selected response, numeric, task completion), rubric mapping to framework levels, profile assembly against the configured bar, and a rubric-proposed advice (§6). No AI in the discharge path at all.
Two AI assists are named day-two, both propose-never-determine:
Open-response marking assist — where instrument design includes writing samples, AI-proposed ACSF-level marking with human moderation. Instrument design at launch prefers constrained-response items precisely so this assist is an enhancement, not a dependency.
Product-profile derivation assist — a proposed capability profile derived from unit text, presented to the RTO to confirm/edit at config time (§2). This is the one job adjacent to the engine's competency; whether it commissions engine-side or home-grown (KN-pattern, RTOpacks-side) is deliberately left to its own day-two decision — either way it proposes a config the RTO owns.
The house rule generalises cleanly: the engine raises hands; it never signs. In LLND terms: nothing AI-derived ever is the advice, the profile, or the bar — it may only propose what a human confirms. This keeps the tile's audit answer identical in shape to RPL's AI-authenticity ruling: AI narrowed to assistive roles, barred from judgement, published as positioning rather than confessed as caveat.

The fence consequence is worth stating: LLND launches with zero cross-fence traffic. The tile is self-contained on RTOpacks substrate, which is exactly the dependency posture the fence protocol wants for a launch-critical surface.

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

The advice is the tile's consequential output and the headline discharging event move 2 minted. Its shape:

Advice record = { review id, profile snapshot, advice ∈ { suitable | suitable-with-identified-support | not-suitable-with-alternatives }, support/alternatives payload, issuing identity, issued-to + delivery record, timestamp } — sealed.

Rulings:

Rubric-proposed, human-issued — launch. The tile derives a proposed advice deterministically (profile vs configured bar). An RTO staff identity confirms or amends and issues; the issuing act is recorded with the identity. Auto-issue for clear-pass cases is a named day-two configuration (config-version sealed if ever enabled); the model fails toward the human. The instrument does not mandate who advises — there is no 3.2/3.3 assessor requirement on a 2.2 procedure, so no People fail-closed gate is imported here (contrast RPL's signing act, where 1.6-9 demands it). The human-issue posture is chosen on product and audit grounds, not compelled by clause — and the model says so honestly rather than inventing a stricter law than exists.
The middle verdict carries the support seam. suitable-with-identified-support binds the identified needs to the advice: the support items proposed (2.3 seam) and any reasonable-adjustment signal (2.4 seam) travel in the advice payload, discharging move 2's 2.2-9 (the fully-informed decision) in the same act.
not-suitable-with-alternatives requires its payload. Alternatives and/or pathway programs are a structurally required property of the third verdict — the PG posture made by-construction. An empty rejection cannot be issued.
Provably prior to enrolment. Enrolment lives in the SMS, outside the fence of this tile's control — so the tile cannot enforce the ordering, and does not pretend to. It evidences it: the advice record's sealed timestamp is the tile's half of the ordering proof; the export (§10) 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 on the review, never silently absorbed.
Delivery is part of the discharge. Advice "provided to each prospective student" means the record carries how it reached them (the intake pipeline's delivery surface at launch — the same channel the invitation used). An advice generated but never delivered is an undischarged obligation, and the model treats delivery as a recorded property, not an assumption.

7. The support and adjustment seams (2.3 / 2.4) — outputs, not anchors¶

Correctly demoted by the move-2 redraft; the model gives them their working shape:

2.3 (training support): the profile's identified needs are a principal input to the RTO's support-services determination (2.3(a)). The tile records the needs and the proposed support items in the advice payload; provision is an RTO act, evidence-held — the tile never claims to have 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.
2.4 (reasonable adjustments): the review may surface a disability disclosure signal (candidate-initiated, consent-framed — the PG's supported-to-disclose posture). The signal routes to the RTO's 2.4 process; the tile holds the signal's existence, never the adjudication.
Record: reviews, profiles, and advice artefacts are the RTO's 2.2 evidence — surfaced to Record/Observatory as the student-support picture's pre-enrolment layer.
No 1.5 validation seam. The review is a 2.2 procedure, not an assessment system under 1.3/1.4 — the five-yearly validation cycle does not attach. Instrument quality assurance (moderation of the LLN/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.

8. Currency and reuse — the result is reusable; the discharge never is¶

Move 2's sharpened ruling, given mechanics:

A capability result carries: capability class, level(s), instrument version (or external source), assessed/recorded date, and grade (conducted / external).
The currency policy is per capability class, configured, versioned — LLN slow, digital faster; values are the RTO's within RTOpacks defaults, never model constants (the RPL precedent on configured policy values, held).
Reuse flow: a later review (same candidate, new product) is offered current prior results per capability; the currency policy rules re-assess-or-honour against the new product's configured bar — a current result below the new bar forces re-assessment 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 record seals which results were honoured, under which currency ruling, against which bar — and a fresh advice issues for the new enrolment. Reuse compresses the assessment, never the discharge (2.2 attaches per prospective enrolment).

The embedding payoff stands as move 2 stated it: each subsequent enrolment carries less friction, and only the platform holding the persistent identity can offer it.

9. The data-domain ruling¶

Per the MANDARIN taxonomy and the HARD SEPARATION RULE:

Store	Class	Holds	Notes
`rto-llnd-db` / staging pair (name binds at spec per naming canon)	Peel (per-env pair)	Reviews, instrument configs + versions, product capability configs + versions, results, profiles, advice records, currency policies	The tile's writable domain
LLND conducted-assessment store (R2, per-env pair)	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 (move 2, held)
Candidate-identity store (shared Peel pair)	Shared substrate	Identity only; owned by neither RPL nor LLND	Per rpl-01-model §4 + §3 deltas above
`rto-nrt-db`	Pith	Product identity, composition, supersession	Read-only always; KN sacred

Customer-facing LLND surfaces read the Pith 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); if a day-two configuration ever binds an issuing role to a People-verified identity, it enters through People's contract, never its tables. Sensitivity class named for the spec: capability results and disability-disclosure signals are sensitive personal information — access posture (which T4 roles see what) is the spec's to bind, the classification is the model's.

10. The SMS boundary¶

Mirrors rpl-01-model §13, held: custody stays home; the outcome leaves. The review, responses, recordings, and advice records are RTOpacks-domain custody. What crosses is the advice outcome + profile summary + the ordering-proof timestamp — launch = an importable export; SMS Connect round-trip = day-two. Where the RTO has no SMS, the export is the record they file. The export carries student_identifier only in its Act-defined meaning and only where held (§3 — USI is optional at this stage).

11. The discharging events (the audit ledger)¶

Per NO ORPHAN GRAINS — read off the move-2 checklist, refined by this model. Events reference fields; fields carry instrument-qualified clauses; the clause is never copied onto the event.

Suitability review opened — candidate × target product, pre-enrolment; the invitation (the obligation attaches; discharges the procedures-in-place demonstration in the running).
Assessment conducted + sealed — per instrument (LLN / digital): responses + session recording landed with digests.
External result recorded — per capability, where the review honours an outside assessment (source, date, level, document sealed) (§4A).
Capability profile produced — assembled against the product's configured bar, config-version sealed.
Suitability advice issued — the human-issued (launch) three-way advice, with its payload, delivery record, and sealed timestamp — the headline 2.2(b) discharge.
Result written with currency marker — the reusable artefact persists against the candidate.
Prior result honoured under currency ruling (reuse reviews only) — which results, which ruling, against which bar; the fresh review + fresh advice still discharge (§8).

Seven launch events. Reserved, named, not launch: auto-issued advice under configuration (if the day-two config ever ships, §6); assisted profile derivation accepted (day-two, §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 — it is an information-surface event, not double-recorded here.

12. What hardens from this model¶

Entity spine: the Suitability Review (candidate × product), instruments within it (§1).
Whole-2.2 scope: assessed components (LLN, digital) + configured check items (grade-marked); the tile is the 2.2 discharge surface (§1A).
No reject outcome: three-way advice; the third verdict structurally carries alternatives (§1B, §6).
The bar is two-layer: Pith product identity + the tile's own versioned capability config; no unverified substrate column claimed (§2).
Shared candidate store, second consumer: USI optional at this stage; results live in the tile's domain, identity in the store (§3).
Instruments conducted, versioned, framework-aligned, independently commissionable; two cadences (§4).
External-result intake — the honest wedge and the displacement path (§4A).
No UCCA-engine dependency; zero cross-fence traffic at launch; AI-assist day-two, propose-never-determine (§5).
Advice rubric-proposed, human-issued at launch; delivery recorded; ordering evidenced, not enforced; no People gate imported that the law does not demand (§6).
2.3/2.4 are output seams; no 1.5 validation seam — instrument QA is self-assurance-grade, honestly labelled (§7).
Result reusable within configured currency; the discharge always fresh (§8).
Data domain: own Peel pair + sealed conducted-assessment store + shared candidate store; ops-db never; sensitivity class named (§9).
SMS boundary: custody home, advice leaves; launch export, day-two round-trip (§10).
Seven launch discharging events; two reserved (§11).

13. Deferred to the spec (move 4) — structural and presentation calls, not model questions¶

Store and bucket naming — per cloudflare-naming-canon; boundaries fixed here.
The digital-literacy framework binding — named and versioned at spec; candidates evaluated against the same published frame.
Instrument item design — constrained-response-first per §5; item banks, forms, accessibility posture.
Check-item taxonomy — the configured non-LLN/digital suitability items' shapes.
Access posture for sensitive results — which roles see profiles, disclosures (§9).
Export format binding — the SMS-importable advice/profile shape (§10).
Configured policy values, deliberately not invented as model constants: currency windows per capability class; advice auto-issue thresholds (day-two); recording retention within the sealed store's floor.
Intake/delivery surfaces — the shared pipeline's LLND expressions (invite, self-complete, advice delivery) — specced once with RPL per the pipeline artefact.
Copy constraints — no surface language implies a pass/fail entry exam or a promised outcome; the review-and-advice framing is the product's voice (§1B).

The LLND model. Move 3 of the Legislation-to-Tile Method. Grounded in F2025L00354 (2.1, 2.2, 2.3, 2.4), read against the rebuilt verified corpus 2026-07-07 (canonical 9d7cd1ac… at 7bdf8d98; in-session portable export ce79657a…), and practice-guide-qa2 (verbatim ASQA). Answers llnd-00-obligations (2026-07-07 redraft, filed 8662979a). Shares the candidate store and intake pipeline with rpl-01-model; imports no engine dependency and no People gate. The spec (llnd-02-spec, move 4) derives from this document and points back to it.