RPL — Model¶

The legislation-grounded reasoning for the RPL tile — the why. Move 3 of the Legislation-to-Tile Method: the obligations checklist (rpl-00-obligations, move 2) said what the RTO must demonstrate; this models the tile as the answer. The spec (rpl-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: RPL is an assessment process (1.6 / F2025L00354), so the judgement is the assessor's. Every entity, seam, and mode below is shaped by that fact. The engine may anchor; it never decides; nothing grants without a human signing act.

Substrate grounding: the bar the evidence is judged against is the training product's requirements as held in rto-nrt-db (Pith, read-only always) — unit identity and the component classes (elements, performance_criteria, performance_evidence, knowledge_evidence, assessment_conditions), plus supersession lineage (supersedes / superseded_by), per the columns verified for the People model (2026-06-17). RPL authors none of it. No licensing-linkage column is known on this substrate — the licence-linked flag (§2) therefore names its data-source question for the spec rather than asserting a column that has not been verified.

1. The judgement surface in one line¶

RPL Application = (candidate × target training product × units claimed) → per-unit assessor judgement { granted | gap identified → gap-training determination | not granted }, evidenced, sealed, exported.

The tile's primitive is not the candidate and not the product — it is the application: a candidate's claim, against a national training product, that prior learning and experience satisfy some or all of its units. Evidence attaches to the application; the anchor map (engine-assisted mode) is an instrument over it; the assessor's judgement is a property of it; the outcome exports from it.

The judgement is per unit (the unit is what is credited), informed by per-leaf evidence tracing beneath it. "Granted" here means the assessor's recorded determination that the unit's requirements are met by the evidence — the RTO's own issuance and SMS processes carry it from there (§13).

1A. The foundational negative rule: no path grants without the assessor¶

There is no code path in this tile that issues an RPL outcome without an assessor's recorded judgement. Not a policy, a structural fact: the outcome entity cannot exist except as the product of the signing act (§9), and the signing act requires a credentialled assessor identity (People verdict, fail-closed). The engine's findings contract is subject-locked — it carries no pass/fail/competent vocabulary and cannot be promoted into an outcome by any consumer (receipt: RTOP-RECEIVED-CROSSING-RPL-CAPABILITY-01).

This is the tile's answer to the head of ASQA's known-risk list — automatic granting, corner-cutting business models, RPL promoted as easy or guaranteed (PG; obligations §5). The RPL-mill postures are resisted by construction:

Known risk (PG)	Structural answer in this model
Automatic granting	§1A — no grant path without the signing act
Lighter-than-assessment rigour	1.6-6 held: same rules of evidence (§6), same validation cycle (§14), sealed records (§5)
Easy/quick/guaranteed promotion	Copy constraint carried to the spec: no surface or product language promises an outcome
Record-retention failure	Sealed vault, custody by default, retention floor = audit window (§5)
Authenticity unverified	Attestation + assessor + optional consent-gated anchors; engine never asserts provenance (§6)
Non-genuine students/agents	Identity capture at intake; operator-initiated invitations only (§4)
Unregulated third parties	Third-party RPL is day-two; launch runs on the RTO's own People-credentialled assessors (§9)
High-risk-work licensing thresholds	Licence-linked flag named (§2); fail toward caution where flagged
Overseas evidence unmapped	Distinct path, ruled day-two and named so it is never silently assumed (§12)
Currency untested	Adapter recency check against live `rto-nrt-db` + assessor ruling (§6)
Gap-identification insufficient	The gap map is a first-class product of every application, both modes (§10)

2. What the tile reads — the bar is the national product, owned by neither party¶

The evidence is judged against the training product's requirements as they stand on the National Register — mirrored in rto-nrt-db, read-only, Crown-owned, RTOpacks-mirrored, RTO-authored never. The same Fork-1 discipline as People: the tile keys on TGA national identity (the code), reads composition and component classes from the list, and stays evaluable for any national product whether or not Studio has built content for it.

Two consequences the model fixes now:

The leaves the engine anchors against are the unit's component-class lines — elements, performance criteria, performance evidence, knowledge evidence — addressed by stable ids in the adapter's payload (§7). The bar is the law's text, not our paraphrase of it.
Licence-linked products carry a threshold flag. Where a unit or qualification is linked to high-risk-work licensing or an industry-regulator requirement, the application surfaces it: the right to seek RPL carries the licensing caveat (1.6-2), and the PG names robustness against licensing thresholds as a known risk. Data source unresolved: no licensing column is verified on rto-nrt-db. The spec decides the source (a manual per-product flag at launch is acceptable; an authoritative feed is day-two). The flag itself is model-level and non-negotiable — what is deferred is only where its truth comes from.

3. The entity spine: the RPL Application¶

RPL Application = (candidate × target training product × units claimed)

candidate — an identity in the shared candidate store (§4). Not a People person; not a seat.
target training product — a TGA identity (qualification / skill set / unit), resolved against the list for composition. The units claimed are a subset of (or the whole of) its composition.
units claimed — the per-unit claim set. Judgement, evidence tracing, gap identification, and outcome all resolve per unit.

The application is the spine exactly as the Delivery Assignment is People's: its opening is a discharging event (the obligation attaches when a candidate's claim is formally received against a product); evidence, anchor maps, judgements, and outcomes are properties of it; the ledger reads off it. It also carries the application-level state the obligations require: the offer/awareness provenance that preceded it (1.6-1/2), the pathway fork it arrived through (§11), any third-party disclosure (1.6-4, evidence-hold, day-two), and any overseas-evidence or licence-linked flags.

4. The candidate — a shared, invisible identity store beside People¶

Ruled (formalising the settled design state):

The candidate is held in a dedicated candidate-identity store — its own substrate, beside People, never inside it. A student population inside the workforce-compliance tile is a category error: People answers "who may lawfully train and assess"; the candidate store answers "who is being assessed." Different obligations, different lifecycles, different privacy postures.
The store is shared substrate with LLND — RPL is its first consumer, LLND its second, and the shared assessment-intake pipeline (a later artefact, falling out of the two models) is its operating loop. Because two tiles consume it, neither owns it: it is modelled as shared substrate with its own Peel pair (§15), so LLND never depends on the RPL tile for its candidates.
Entry is UI-only (CANONICAL-IDENTITY-VIA-UI-ONLY): operator-initiated invitation, candidate-self-completed intake. No portal, no login, no countable seat — the candidate is invisible to the seat model. Manually-inserted seed rows are not identities.
student_identifier carries the meaning of the Student Identifiers Act 2014 — the USI is a verified, specially-handled identifier, never free text. Ruled for launch: the store captures and format-validates the USI; verification against the USI registry (and the transcript service the PG names for CT authentication) is day-two, and per the EXT-API RULE the USI reference doc in docs/ops/ must exist before any USI-registry integration deploys. The reference doc is owed regardless and should be filed ahead of the spec (carried on the board).

Identity capture at intake — candidate self-attestation as the floor; government photo ID and a recorded session as optional, consent-gated authenticity anchors where the context expects them (licence-linked products are the obvious case) — is the intake pipeline's surface, named here because it is the structural answer to the PG's non-genuine-students risk (§1A table).

5. Evidence — heterogeneous intake, normalised sections, sealed custody¶

Three layers, deliberately distinct:

5.1 Intake (heterogeneous, by law). 1.6-3 requires the approach to accommodate the variety of experiences and pathways candidates present — the intake is therefore an evidence bundle, not a fixed form: portfolios, employment records, references, third-party reports, transcripts, work samples. The candidate's authenticity attestation is captured at intake and sealed with the bundle (§6).

5.2 Normalisation — the adapter, our side of the warranty line. The evidence-normalisation adapter converts the bundle into the engine's payload shape: stable-id'd text sections (evidence → material.sections; the unit's component-class leaves → obligation.elements), per the receipt. This is the substantial our-side build the crossing sized. Ruled for v1: the adapter is text-and-documents only — native text plus OCR for scanned documents. Image/video evidence requires a transcription/description pre-step (the engine core is text, by design) and is out of v1; multimodal is day-two adapter work, not an engine dependency. At launch, image/video items are vaulted (custody is never mode-dependent) and reach the assessor's eyes directly in manual review — they simply do not reach the engine.

5.3 Custody — the sealed vault. A dedicated R2 evidence vault: every submitted artefact digest-sealed at landing, immutable thereafter (amendments are new sealed objects, never mutations), retained to the assessment-record-retention floor — the audit window (1.6-12; PG known risk). Custody is the default, not an option; it applies identically in both modes.

The trace chain — the model's audit spine. Every adapter section id maps back to a vaulted source artefact digest and span. So the full chain reads: unit leaf → engine finding anchor (verbatim span) → adapter section id → vaulted artefact digest. An anchor that cannot resolve to sealed bytes in custody is not evidence — and the engine's own contract fails a job rather than sealing a fabricated or absent anchor (receipt). This chain is what makes the anchor map an audit instrument rather than an opinion, and it is why the vault and the adapter are modelled together: the adapter without custody produces unanchored claims; custody without the adapter produces unread archives.

6. The rules of evidence, held by design (anchor: 1.4 / F2025L00354)¶

Carried from move 2 and hardened by the crossing — the engine's capability boundary maps exactly onto the law, and the two rules the engine cannot hold are the two it is forbidden to hold (receipt: RTOP-RECEIVED-CROSSING-RPL-CAPABILITY-01):

Rule	Held by	In this model
Validity	Engine anchors → assessor confirms	The per-leaf TRACED-with-anchor act is the validity trace (§7); in manual mode the assessor performs the same trace by hand against the same leaves
Sufficiency	Assessor only	An aggregate judgement the engine is constitutionally barred from; it exists nowhere in the tile except the signing act (§9)
Authenticity	Candidate attestation + adapter + assessor	Attestation sealed at intake; adapter carries provenance metadata; the assessor rules; the engine never asserts provenance
Currency	Adapter + assessor	Adapter recency check against the live `rto-nrt-db` requirement; the assessor rules on what recency means for this evidence

The AI-generated-evidence question, ruled head-on. The PG now names evidence "generated with artificial intelligence tools" as an authenticity risk, and an RPL product with an AI engine inside will be asked exactly this at audit. The model's answer is structural and worth stating in product language: the engine that anchors validity is constitutionally the wrong tool to launder authenticity. It reads text and traces it to requirements; it has no access to provenance and its contract forbids it from asserting any. Authenticity in this tile rests where the law puts it — the candidate's sealed attestation, the adapter's provenance record, the optional consent-gated identity anchors (§4), and the assessor's judgement. The tile's use of AI narrows to the one rule AI can legitimately serve (validity tracing, with byte-verified anchors) and is barred from the rest. This is a positioning asset, not a caveat — rule it, publish it, and let the audit question land on a prepared answer.

7. The engine seam — anchor-not-decide (the crossing, bound locally)¶

All engine-capability claims here rest on RTOP-RECEIVED-CROSSING-RPL-CAPABILITY-01 (the home-side receipt; the verbatim UCCA copy is held at ops/fence/received/ and is never cited directly for local rulings). What the receipt binds:

Reachable and already built. Evidence→competency is the engine's proven backward primitive pointed at a different corpus — a new mode on the existing core, not a re-engineer (sizing (b)).
Contract shape, zero change: candidate evidence → material.sections (stable-id'd text); target unit leaves → obligation.elements (element_ref + text). VET vocabulary stays client-side; the engine's ids are opaque.
Findings are subject-locked: per-leaf TRACED / NOT_YET_TRACED with byte-verified verbatim anchors; no pass/fail/competent vocabulary; a fabricated or absent anchor fails the job rather than sealing. The per-leaf not-yet map is the gap map (§10).
Vocabulary decision deferred to commissioning: whether the sealed object carries literal "DEMONSTRATED" wording is a findings-schema version choice (reuse v1 as-is vs cut v2). Model default: reuse v1 TRACED semantics unchanged — a TRACED-with-anchor leaf already means "this leaf is demonstrated by this evidence span," and the tile's own surfaces can present operator-facing language without touching the sealed vocabulary. Revisit only at commissioning, as the receipt provides.
No commitment crossed. The crossing is a capability answer only. Any engine-side RPL mode opens as its own gated units on Tim's word, across the fence. This model therefore treats the engine mode as designed-in but separately commissioned — which is exactly why §8 rules the manual mode the launch spine.

The seam's one rule, stated once and inherited everywhere: the engine raises a hand on validity and surfaces gaps; it never rules sufficiency or authenticity, and it never grants.

8. Dual-mode — one judgement surface, two modes; manual is the launch spine¶

Ruled. The tile is one application → evidence → judgement → outcome surface, with the engine anchor as an optional instrument on it:

Manual mode (the human shell). The assessor works the application directly: reads the vaulted evidence, traces it to the unit's leaves by hand, marks per-leaf demonstrated / not-yet, records the gap map, and signs. Every obligation in move 2 is dischargeable in this mode alone.
Engine-assisted mode. Identical surface; the anchor map (per-leaf trace + gaps, with resolvable anchors per §5's trace chain) arrives as an instrument the assessor starts from, confirms, corrects, and signs over. The engine run is itself a recorded event (§16) — an instrument's provenance, never a verdict.

Mode is a property of the application run, not two systems — same entities, same custody, same signing act, same ledger. The mode-switch demo (obligations §5: depth proven by contrast, never by shortcut) falls straight out of this: switch the instrument off and the same judgement surface stands.

Why manual is the launch spine (strategic, not just architectural): the crossing commits no build and no schedule. A tile whose launch depends on an uncommissioned cross-fence mode has a dependency the fence protocol exists to prevent. Manual mode clears the incumbent's workflow bar on the spine substrate we already hold (People, Record, the vault) and ships on our own clock; the engine mode is designed-in (this section is the design) and commissions when Tim says so. Nothing in the spec may make manual mode a degraded path — it is the reference implementation of the judgement surface.

9. The assessor and the People seam — fail-closed at the signing act¶

The assessor who judges RPL evidence must meet Standards 3.2 and 3.3 (1.6-9). RPL does not re-implement assessor credentialling — it consumes People's verdict through the existing contract:

People.canDeliver(person, training_product, activity) → { verdict, evidence, dimension_states }

with the activity drawn from the Credential Policy enum (assess_only covers the RPL judgement; validate covers the validation seam, §14).

Ruled — the signing gate is fail-closed, and stricter than Studio's Never Block: at the moment of the signing act, the signing assessor's People verdict for (assessor, target product, assess_only) must be permitted. insufficient_data blocks signing exactly as not_permitted does — Never Block is the right posture for a planning canvas, where "can't tell you yet" must not paint a compliant RTO red; it is the wrong posture for a regulatory signing act, where an unevaluable assessor signing an RPL grant is precisely the exposure 1.6-9 exists to prevent. Planning surfaces inside the RPL tile (assigning an assessor to an application queue) may inherit Never Block's amber nudge; the signature may not.

The verdict snapshot seals with the judgement. People's verdict is derived and moves with the evidence behind it; the judgement is a historical fact. So the signing act captures the verdict, its evidence pointers, and the policy/list versions it was computed against, sealed into the judgement record — the permanent answer to "was this assessor credentialled at the time," which is the question an auditor actually asks.

Third-party assessors (1.6-4, 1.6-9's "including through third parties," and the PG's outsourcing risk) are day-two: at launch the signing identity is the RTO's own People-registered assessor. When third-party lands, it enters through People (the third-party assessor is credentialled the same way) and carries the same-rigour monitoring obligation (1.6-14) — named now so day-two inherits a seam, not a redesign.

10. Gaps → gap training (1.6-13)¶

The gap map is a first-class product of every application, both modes: per unit, per leaf, what is demonstrated and what is not yet. In engine-assisted mode the not-yet-traced map proposes it; in manual mode the assessor's per-leaf marks are it. Where gaps stand at judgement, the tile records the gap-training determination — amount, delivery mode, and any cost, worked with the candidate — as a discharging event distinct from the judgement itself (the judgement identifies the gap; the determination answers it). The determination is where RPL hands toward enrolment/training pathways; the hand-off target (Studio content, external delivery) is a spec matter, but the recorded determination is the obligation's discharge and lives here.

11. Credit transfer — ruled: the workflow is day-two, the fork ships at launch¶

Standard 1.7 is a distinct mechanism — an equivalence match on a prior recognised completion, not an assessment (move 2). Three facts drive the ruling:

CT is cheap where it is ours: equivalence per the PG's own definition (current code/title, or superseded-equivalent as published on the National Register) maps one-for-one onto rto-nrt-db supersession lineage. The match is a read we can already perform.
CT is expensive where it is not ours: the PG's compliance activity for 1.7 is transcript authentication — "directly accessing the USI transcript service or contacting the issuing organisation." That is an external integration (EXT-API doc, USI registry access, day-two per §4) or a manual verification workflow. Authentication, not equivalence, is CT's tall pole.
The pathway decision cannot be deferred even if the workflow is: the PG's self-assurance questions require staff to recognise when a CT request becomes an RPL request, and the known risks require that a refused CT is met with an alternative pathway (RPL or gap training), with the rationale explained.

Therefore:

The CT workflow (equivalence match + transcript authentication + CT outcome record) is day-two. It will ship as a light second mode on this tile — no evidence vault, no engine, a lighter record — not as a sub-case of RPL.
The pathway fork ships at launch. Intake asks the question the PG demands staff can answer: is this claim a completed equivalent product (CT — routed to the RTO's manual CT process at launch, with the routing recorded) or prior learning and experience to be assessed (RPL — this tile)? A refused or inapplicable CT surfaces the RPL pathway. The fork's record is the launch-time discharge of the offer obligations for both standards (1.6-1, 1.7-1) at the awareness level.
One structural guard is named now for when CT ships: the PG lists issuing a qualification via CT based on training wholly completed through RPL/CT at a different RTO as a known risk. When the CT mode lands, that condition is a by-construction check on the CT record, not a policy note.

12. Overseas evidence — ruled: day-two, and named so it is never silently assumed¶

Evidence of overseas qualifications or competencies must be mapped to Australian legislative and regulatory requirements (WHS and industry-specific law — PG known risk). That mapping is a distinct evidence path with its own reference corpus, and the tile does not claim it at launch. At launch: intake captures an overseas-sourced flag on evidence items; a flagged application surfaces the PG risk to the assessor as guidance; the assessor's judgement proceeds under ordinary rules of evidence with the mapping burden explicit and manual. Day-two: a modelled overseas-evidence path, if demand warrants. The flag exists from launch precisely so day-two has data and launch has honesty — the tile never silently implies the mapping is handled.

13. The outcome and the SMS boundary¶

The judgement's product is the outcome record: per unit, granted / not granted, with gaps and determinations attached, sealed with the verdict snapshot (§9). Two rulings:

Custody stays home; the outcome leaves. The evidence bundle, anchor maps, and judgement records are RTOpacks-domain custody (the vault and the RPL store). What crosses to the Student Management System is the outcome. Launch = an importable outcome export (SMS-consumable format, spec to bind); SMS Connect round-trip (push-back) = day-two. Where an RTO has no SMS, the export is the record they file.
The export carries student_identifier in its Act-defined meaning (§4). No outcome export invents an identifier.

The outcome is also an audit artefact Record reads (§14) — the units-credited fact enters the audit evidence surface without the evidence bundle leaving custody.

14. The validation seam (1.6-14; Standard 1.5) — RPL judgements enter the cycle¶

RPL is conducted in accordance with the assessment system (1.6-6), so RPL judgements are assessment judgements and enter the assessment-validation cycle — Standard 1.5's risk-based, five-year-floor validation of practices and judgements. The seam is Record's to operate; RPL's obligation is to supply the sample: sealed applications, evidence (in custody, accessible to validators — 1.5 requires validators to see the same evidence the assessor judged on), anchor maps where present, and judgements with their verdict snapshots. The trace chain (§5) is what makes an RPL judgement validatable — the validator replays evidence → leaf → judgement on bytes.

One flag named now: 1.5(d) requires independent validation (a person not employed or subcontracted by the RTO, with no other interest) for AQF qualifications and skill sets from the TAE Training Package. An RTO running RPL on TAE products inherits that independence requirement on this seam. It is Record's rule to enforce; it is named here so the seam carries it from birth rather than discovering it at a customer's first TAE validation.

15. The data-domain ruling¶

Per the MANDARIN taxonomy and the HARD SEPARATION RULE:

Store	Class	Holds	Notes
`rto-rpl-db` / `rto-rpl-db-staging`	Peel (per-env pair)	Applications, claims, anchor-map metadata, judgements, gap determinations, outcome records, pathway-fork records	The tile's writable domain
RPL evidence vault (R2, per-env pair)	Sealed custody	Evidence artefacts, digest-sealed, immutable; attestations sealed with bundles	Amendments are new objects; retention floor = audit window; naming per `cloudflare-naming-canon` at spec
Candidate-identity store (own Peel pair, shared)	Shared substrate	Candidate identities, USI (special handling), intake attestations' identity side	Owned by neither RPL nor LLND; UI-only entry; invisible to the seat model (§4)
`rto-nrt-db`	Pith	The bar: products, units, component classes, supersession	Read-only always; KN sacred

Customer-facing RPL surfaces read the Pith and their own Peel stores; ops-db is never bound (customer surfaces bind ops-db never — standing rule, amended 2026-07-04). People is consumed through its contract (§9), never through its tables. Exact database and bucket names bind at the spec against the naming canon; the boundaries above are the model's and do not move with naming.

16. The discharging events (the audit ledger)¶

Per NO ORPHAN GRAINS, chosen deliberately — 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.

RPL offered / awareness recorded — the invitation, carrying the right-to-RPL and the licensing caveat where flagged (discharges 1.6-1, 1.6-2; the fork record discharges the 1.7-1 awareness level at launch).
Pathway fork recorded — CT-vs-RPL determination at intake; a refused/inapplicable CT surfaces the RPL pathway (§11).
Application opened — candidate × product × units claimed (the obligation attaches).
Evidence submitted + sealed — vault landing with digest, carrying the candidate's authenticity attestation (1.6-5, 1.6-12).
Engine anchor run (engine-assisted mode only) — per-leaf trace + gap map produced and bound to the application; an instrument's provenance, never a verdict (§7).
Assessor judgement recorded — the signing act — per-unit ruling on sufficiency, authenticity, currency, and confirmed validity; People verdict snapshot sealed in; fail-closed gate (§9) (discharges 1.6-5/6/7/8/10/11).
Gap-training determination recorded — amount, delivery, cost, worked with the candidate (discharges 1.6-13).
Outcome exported — the outcome record leaves to the SMS or as the importable export (§13).

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

17. What hardens from this model¶

Entity spine: the RPL Application (candidate × product × units claimed) (§3).
No grant without the signing act — structural, not policy (§1A).
Judgement is per unit; tracing is per leaf; the bar is the national product's component classes read from Pith (§2).
Candidate identity: dedicated shared store beside People, UI-only entry, no seat, USI per the Act; registry verification day-two behind an EXT-API doc (§4).
Evidence: heterogeneous intake → text-and-documents adapter (v1) → sealed immutable vault; the trace chain unit leaf → anchor → section → vaulted digest is the audit spine (§5).
Rules of evidence held by design: validity engine-anchored, sufficiency assessor-only, authenticity attestation+assessor (engine barred), currency adapter+assessor; AI-authenticity ruled head-on as a positioning asset (§6).
Engine seam per the receipt: new mode, no re-engineer; subject-locked findings; v1 TRACED vocabulary as default; designed-in, separately commissioned (§7).
Dual-mode: one judgement surface; manual mode is the launch spine and never a degraded path; mode is a property of the run (§8).
People seam fail-closed at signature: permitted required to sign; insufficient_data blocks; verdict snapshot seals with the judgement (§9).
Gap map first-class in both modes; determination is its own discharge (§10).
CT: workflow day-two, fork at launch, wholly-via-CT/RPL guard named (§11).
Overseas evidence: day-two, flagged from launch, never silently assumed (§12).
SMS boundary: custody home, outcome leaves; launch export, day-two round-trip (§13).
Validation seam: RPL supplies the sample to Record; TAE independence flag carried from birth (§14).
Data domain: rto-rpl-db Peel pair, sealed R2 vault, shared candidate store; ops-db never (§15).
Eight launch discharging events; two reserved (§16).

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

Licence-linkage data source — manual per-product flag at launch vs authoritative feed; substrate has no verified column (§2).
Export format binding — the SMS-importable outcome shape (§13).
Vault and store naming — per cloudflare-naming-canon; boundaries fixed here, names bound there (§15).
Intake pipeline surfaces — invitation, self-complete form shapes, consent-gated identity anchors; shared with LLND, specced once the pair of models stands.
Assessor workbench presentation — how the anchor map and manual per-leaf marking render on one surface; the model fixes that they are one surface (§8).
Gap-training hand-off target — where the determination points (Studio content, external); the determination record itself is the model's (§10).
Configured policy values, deliberately not invented as model constants: evidence-recency defaults for the currency check; queue/aging thresholds; evidence-type taxonomy for the bundle.
Copy constraints — the no-promised-outcome language rule carried into every RPL-facing surface (§1A).

The RPL model. Move 3 of the Legislation-to-Tile Method. Grounded in F2025L00354 (1.4, 1.5, 1.6, 1.7, 3.2, 3.3) and practice-guide-qa1, read against the bytes 2026-07-06; engine capability bound by RTOP-RECEIVED-CROSSING-RPL-CAPABILITY-01 (the received crossing digest-verified in-session, 721ad42d…abca7bb). The spec (rpl-02-spec, move 4) derives from this document and points back to it. Files at docs/docs/workspace/apps/rpl-01-model.md, joining the RPL nav group opened at 731aa47b.