title: Assessment-Intake Pipeline — Model (the shared operating loop of the candidate store) doc_id: intake-pipeline-01-model status: settled — ratified by Tim 2026-07-07 (one amendment accepted at ratification — §4 pre-fill); gates rpl-02-spec and llnd-02-spec (both -02s cite this artefact for every intake-side surface) — amended 2026-07-10 (intake client-dimension ruling; LLND-SURFACE-01): §7 gains the client_ref tenancy boundary on invitation layer: shared substrate model (Legislation-to-Tile move 3 grade, but not a tile — see §0) authored: 2026-07-07 NYC — RTOpacks-side Claude, for Tim's ratification naming: filename tapped by Tim at filing (INTAKE-PIPELINE-01-FILING-01) — "intake pipeline" is the name both ratified models use; Tim taps or renames (names earn the tap) sources_read_in_full_at_draft: - rpl-01-model.md §4 §5 §6 §16 §17 (settled — ratified 2026-07-06) - llnd-01-model.md §3 §4 §4A §5 §6 §8 §9 §10 §11 (settled — ratified 2026-07-07; sha256 d51821dd…, 26,380 B, digest-verified this session) - rpl-00-obligations.md (1.6 tables, rules of evidence, §5 mill posture, §6 seams) - llnd-00-obligations.md (2.2 core, reuse, custody/capture; sha256 d447b00e…, 23,084 B, digest-verified this session — the corrected 2.2-anchored redraft) - RTOP-RECEIVED-CROSSING-RPL-CAPABILITY-01 (full) + UCCA verbatim copy (referenced through the receipt per FENCE-PROTOCOL-01 §4) - IDENTITY-ENTRY-PATH-01 (the workforce entry path this pipeline deliberately is not) - COMMS-REGISTRY-01 (THE COMMS-ENTRY RULE binds this pipeline's outbound messages) relates_to: people-01-model (the store sits beside People, never inside it) · standing-rules.md (HARD SEPARATION, ops-db invariant, EXT-API RULE) · MANDARIN taxonomy (the Intake class is this pipeline's public face)

Assessment-Intake Pipeline — Model¶

0. What this artefact is, and is not¶

Both ratified models name this artefact and defer to it. rpl-01 §4: the shared candidate-identity store's "operating loop" is "the shared assessment-intake pipeline (a later artefact, falling out of the two models)." llnd-01 §3: identity capture at review time "is the intake pipeline's surface, shared with RPL." This is that artefact.

It is not a tile. It has no obligations of its own: there is no intake-pipeline-00, and none is owed. Every clause the pipeline serves is owned by a consumer tile and anchored in that tile's -00 (1.6 / F2025L00354 through rpl-00; 2.2 / F2025L00354 through llnd-00). The pipeline is shared substrate — like the candidate store it operates, it is owned by neither consumer, and per rpl-01 §4 that is precisely why it is modelled once, separately: so LLND never depends on the RPL tile for its intake, and vice versa.

It mints no discharging events. The events that fire on its surfaces are the tiles' events (rpl-01 §16, llnd-01 §11), emitted into the owning tile's ledger. NO ORPHAN GRAINS is honoured by reference: every pipeline stage maps to a tile event or is explicitly named non-discharging (§8). Nothing is double-recorded; nothing is orphaned.

One pipeline, built once, two consumers with different grades. The grades never fork the pipeline into two pipelines; they are per-consumer parameters on shared stages (§2). Where the consumers genuinely differ (submitted bundle vs conducted instrument), the difference lives in stage 4's two modes — the only stage with modes at all.

1. The pipeline in one line¶

An operator invites a candidate; the candidate authors their own identity and completes their engagement through a tokened, login-free surface; capture seals what consent permits; the tiles conduct or receive; the result or advice returns down the same channel the invitation opened — every step recorded, nothing regulated ever read back out.

Five stages: invite → self-complete → capture → conduct/submit → deliver.

2. The two consumers — one loop, per-consumer grades¶

The load-bearing table. Everything below elaborates a row of it.

Stage	Shared mechanics (both consumers)	RPL grade	LLND grade
1. Invite	Operator-initiated, from an operator surface; candidate row found-or-created in the shared store; tokened link issued; comms per register	Offer carries right-to-RPL + licensing caveat where flagged (rpl-00 1.6-1/1.6-2); CT-vs-RPL fork question attached (rpl-01 §16 e2)	The invitation is the review-opened event (llnd-01 §11 e1) — the 2.2 obligation attaches here
2. Self-complete	Candidate authors own identity facts (§4); engagement particulars completed; resumable within token life	USI mandatory, format-validated per the Act (rpl-01 §4)	USI optional, format-validated where supplied (llnd-01 §3)
3. Capture	Consent-gated anchors: photo ID (RTO-configurable requiredness), session recording where conducting; all captures digest-sealed to R2 at landing	Authenticity attestation over the submitted bundle, sealed with it (rpl-01 §5.1)	Session recording is the authenticity anchor for conducted instruments (llnd-01 §4); identity self-attestation floor
4. Conduct / submit	The stage with two modes — the tiles' machinery runs here	Submit mode: heterogeneous evidence bundle lands in the RPL vault (rpl-01 §5.3); the pipeline's job ends at sealed landing	Conduct mode: instrument delivery + response capture on the pipeline surface; the instrument, scoring and profile are LLND-domain (llnd-01 §4)
5. Deliver	Recorded delivery down the invitation's channel; delivery record = channel, address, timestamp, payload reference	Outcome notification — recorded, non-discharging (§8)	Advice delivery — load-bearing half of the 2.2(b) discharge (llnd-01 §6: "delivery is part of the discharge")

The bundled invitation — the shared-identity dividend. One invitation may carry multiple engagements (an RPL application, an LLND review, or both) against one candidate-store row. Ruled: invitation → engagement is one-to-many; each engagement fires its own tile's events into its own ledger; the candidate authors identity once per intake. Grade resolution in a bundle: the stricter grade wins per shared field — a bundle containing any RPL engagement makes USI capture mandatory for that intake; an LLND-only intake leaves it optional. A field's grade is a property of the engagement set, resolved at invite time and shown to the candidate as one coherent form, never two.

rpl-01 §4 rules the posture: no portal, no login, no countable seat — the candidate is invisible to the seat model. This artefact rules the mechanism that honours it:

The invitation link carries a capability token: high-entropy random, stored hashed, bound to the invitation (and thereby the candidate row + engagement set). The token is the only thing in the URL — no name, no email, no USI, no identifiers of any kind in URL or query string, ever.
Time-limited and resumable. The token has an expiry (value is spec's, RTO-configurable within defaults); within its life the candidate may leave and return to their own in-flight session. Expiry without completion surfaces to the operator as a visible state, never a silent death.
Re-issue rotates. A re-issued invitation mints a new token and revokes the old at the same moment. At most one live token per invitation. All presentations of dead tokens are logged.
Served same-origin through a BFF, fail-closed (CHANNEL SEPARATION RULE). The candidate surface holds no credentials and receives no session beyond its token scope.
What the token can reach — the read-back rule, stated precisely. The candidate surface is Intake-class per the MANDARIN taxonomy: public-form-writable, never-read-back-to-public. Resumability requires one carefully-scoped exception, ruled here so the spec doesn't invent it: the token may read back only the candidate's own in-flight intake session (their partially-authored form state) and the static engagement framing (product identity from Pith, the offer text, the fork question). It reads back no completed results, no advice, no other candidate's anything, no regulated tile data. Results and advice travel outward on stage 5's recorded delivery — they are never fetched by the token.

Why not the universal entry path. IDENTITY-ENTRY-PATH-01 is the workforce path: login minted, first-run gate, admin approval, seat or T4B grant — a path whose whole point is gating operational access to the platform. The candidate gets no operational access, so none of that machinery applies; importing it would mint logins and seats for people the seat model must never count. The candidate path is therefore the second canonical entry path, a deliberate sibling, and CANONICAL-IDENTITY-VIA-UI-ONLY governs both: candidate rows enter the shared store exclusively through this pipeline's surfaces (operator invite + candidate self-completion). Manually-inserted rows are not identities (rpl-01 §4, held).

4. Identity — self-authored, self-attested (the inherited spine)¶

The workforce path's two compliance insights (IDENTITY-ENTRY-PATH-01) generalise to candidates, and this artefact adopts them as the intake's identity posture:

The person authors their own facts. The operator authors only the invitation facts (name/email as addressing, the engagement set). The candidate authors their identity record on the intake surface. Pre-fill is proposal-grade (amendment accepted at ratification): upstream identity data — operator-typed at invite, or pushed by a Student Management System integration when that day-two channel lands — may pre-fill the candidate's form, but it arrives as a proposal the candidate confirms or corrects. The attestation covers the record as the candidate finalised it — that is the moment authorship happens — and each pre-filled value keeps its provenance (operator / SMS / candidate-entered), so the audit answer is honest: the upstream system proposed it, the candidate attested it. Nobody's identity facts are finalised by someone else.
The authored record terminates in a signed attestation — timestamped, versioned against the attestation text, sealed with the intake. This is the compliance asset: for RPL it is the floor under the authenticity attestation over the bundle (rules-of-evidence table, rpl-00); for LLND it is the identity floor beneath the session-recording anchor. One attestation pattern, per-consumer payloads.

USI handling, both grades. student_identifier carries the meaning of the Student Identifiers Act 2014 — a specially-handled identifier, never free text, never in a URL, never in an outbound message body. The pipeline captures and format-validates it (RPL: required; LLND: optional; bundle: stricter wins). Registry verification is day-two and is not this pipeline's work — it binds behind the USI EXT-API reference doc (owed before rpl-02-spec touches the registry; carried on the board). Nothing in this model depends on it.

Both models put the identity anchors on this surface (rpl-01 §4 last para; llnd-01 §3 last para; llnd-00 custody section). The mechanics, ruled:

Consent is captured per anchor, per intake — a versioned consent text, the candidate's affirmative act, timestamp — and the consent record seals with the capture it permits. No consent record, no capture; a capture without its consent record is a defect, not data.
Photo ID — optional, best-practice, RTO-configurable requiredness: defaulted on for funded / high-risk / CRICOS contexts, off elsewhere (llnd-00 posture, verified 2026-07-06: sight-and-retain is common practice, not a blanket legal mandate — the model does not invent stricter law).
Session recording — for conducted assessments (LLND launch; any future conducted RPL component inherits it). Biometric-adjacent sensitive data: consent-captured, sealed R2 custody, its own retention posture distinct from the document floor (llnd-00, held).
Refusal is graded, never silently absorbed — the grade-honesty pattern (llnd-01 §4A precedent, extended at ratification to configured check items; extended here to anchors). Where an anchor is configured required for the context and consent is refused, the intake cannot proceed past capture: fail-closed, with a recorded refusal the operator sees. Where optional and refused, the intake proceeds and the resulting record carries its anchor grade (attestation-only vs attestation+ID vs attestation+recording). The assessor and the advice-issuer see the grade; the audit trail carries it. Refusal never downgrades invisibly.

Custody split, stated once: the pipeline seals what it captures — consent records, ID images, session recordings, the attestation — digest-sealed to R2 at landing, immutable, amendments as new sealed objects. The tiles seal what they own — the RPL evidence bundle in the RPL vault (rpl-01 §5.3), the LLND response sets and advice records in the LLND stores (llnd-01 §9). The seam is stage 4: at submit, the pipeline hands sealed bytes and digests to the tile's vault landing; at conduct, the tile's instrument runs on the pipeline surface but writes to its own domain. No capture artefact is ever mode-dependent or consumer-dependent in its custody discipline.

6. Delivery — one recorded surface, two grades (ruled)¶

The invitation's channel is the delivery channel — the closed loop llnd-01 §6 names ("the same channel the invitation used"). Ruled:

A delivery record is minted for every outbound result/advice: channel, address used, timestamp, payload reference (never the payload's regulated content in the message body — the message carries the advice document, or a sealed reference, per spec's channel rules).
LLND grade — load-bearing. The advice record's delivery half (llnd-01 §6: "an advice generated but never delivered is an undischarged obligation") is supplied by this pipeline's delivery record and sealed into the advice record by the LLND tile. The pipeline is where "provided to each prospective student" becomes provable.
RPL grade — recorded, non-discharging. No clause in 1.6 requires candidate notification as a distinct discharging act — the discharge is the signing act and the outcome export (rpl-01 §16 e6/e8). The pipeline still records RPL outcome notifications (good practice, audit-friendly), but no synthetic event is minted — the honest-law posture llnd-01 §6 modelled, applied symmetrically.
THE COMMS-ENTRY RULE binds. Every outbound message this pipeline sends — invitation, reminder, re-issue, delivery — requires a COMMS-REGISTRY-01 entry before it ships. Ownership ruling: the pipeline takes its own register section as shared infrastructure (precedent: the register already carries a Platform/Auth section that belongs to no module). Messages whose content is tile-specific (the RPL offer text, the LLND advice) note their content-owning tile in the entry; the trigger and template belong to the pipeline section. Register entries are owed at spec/build, not now — named here so the debt is visible.

7. The data domain (MANDARIN mapping)¶

Store	Class	Holds	Notes
Candidate-identity store (shared Peel pair)	Shared substrate	Identity only	Per rpl-01 §4 + llnd-01 §3; owned by neither tile; results never live here
Pipeline state (shared substrate; DB name binds at spec per naming canon)	Peel (per-env pair)	Invitations, hashed tokens, engagement sets, intake sessions, consent records, delivery records, refusal records	Beside the candidate store; whether same pair or its own is a spec structural call (§10)
Capture custody (R2, per-env pair)	Sealed custody	ID images, session recordings, attestations, consent-sealed artefacts — digest-sealed, immutable	Recordings carry their own retention posture (llnd-00, held)
Candidate-facing surface	Intake class	Public-form-writable; read-back limited to own in-flight session + static framing (§3)	Never reads regulated tile data; never reads other candidates; served same-origin BFF
`rto-nrt-db`	Pith	Product identity for engagement framing	Read-only always; KN sacred
Tile domains (`rto-rpl-db`, `rto-llnd-db`, tile vaults)	Tile Peel/custody	Applications, reviews, results, advice, evidence bundles	The tiles', never the pipeline's — the stage-4 seam hands off, it does not absorb

ops-db is never bound — the candidate surface and every pipeline worker are customer-facing; the invariant applies with no named exception here. HARD SEPARATION holds throughout: nothing in this pipeline touches rto-micro-db or ops, and the only Pith read is product identity for framing.

AMENDED 2026-07-10 per the intake client-dimension ruling / LLND-SURFACE-01 — the client dimension on pipeline state. Invitations are operator-initiated on behalf of one client, so the Pipeline-state store carries the tenancy boundary: client_ref on invitation (NOT NULL; LOGICAL → the client identity, tier_grants.client_id semantics; cross-DB, no FK). It is a first-class field on the invitation, resolved from the operator's session at invite, never from the request body. The rest of the intake graph inherits the boundary through the FK chain — engagement, intake_session, consent_record, capture_ref, delivery_record, refusal_record all descend from invitation and carry no denormalised copy (the R1 parents-carry-it pattern). Engagement sets never span clients by construction: one invitation, one client, many tile engagements beneath it.

Sensitivity class, named for the spec: candidate identity, USI, ID images and session recordings are sensitive personal information; recordings are biometric-adjacent. Access posture (which operator roles see captures, who may view recordings) is the spec's to bind; the classification is the model's.

8. Stage → event mapping (the no-orphans ledger, by reference)¶

Events are the tiles' (rpl-01 §16, llnd-01 §11), emitted into the owning tile's ledger at these pipeline moments. Exact emission points bind at spec; the mapping is the model's.

Pipeline moment	RPL event (rpl-01 §16)	LLND event (llnd-01 §11)
Invitation issued	e1 RPL offered / awareness recorded	e1 Suitability review opened
Fork answered at intake (RPL engagements)	e2 Pathway fork recorded	—
Self-complete finalised	e3 Application opened (candidate × product × units claimed)	— (the review opened at invite; 2.2 attaches there)
Submit-mode landing sealed	e4 Evidence submitted + sealed (attestation riding with it)	—
Conduct-mode session sealed	—	e2 Assessment conducted + sealed (responses + recording)
Delivery record minted	(non-discharging — recorded, no event; §6)	supplies the delivery half of e5 Suitability advice issued

Not on this pipeline: RPL e5–e8 (engine run, signing act, gap determination, export) and LLND e3/e4/e6/e7 (external result — an operator surface, not the candidate pipeline — profile, currency write, reuse honour) are tile-side moments on tile surfaces. The pipeline neither emits nor mirrors them.

9. What hardens from this model¶

Not a tile; no -00; no owned events — shared substrate discharging the tiles' obligations on their behalf, by reference (§0).
Five stages, per-consumer grades, one fork only (submit vs conduct at stage 4) (§2).
Bundled invitation: one intake, one candidate row, many engagements; stricter grade wins per shared field (§2).
Tokened login-free access: capability token, hashed at rest, nothing personal in URLs, rotate-on-reissue, resumable within expiry, Intake-class read-back scoped to own session + static framing only (§3).
Second canonical entry path, sibling to IDENTITY-ENTRY-PATH-01, same spine (self-authored, self-attested, UI-only), no login/seat/approval; upstream pre-fill is proposal-grade with recorded provenance — attestation is authorship (§3, §4).
USI per the Act at both grades; verification day-two behind the EXT-API doc; this model carries no registry dependency (§4).
Consent per anchor, sealed with its capture; refusal graded — fail-closed where configured required, grade-marked where optional; never silent (§5).
Custody split at the stage-4 seam: pipeline seals its captures; tiles seal their domains; discipline identical everywhere (§5).
Delivery recorded once, graded twice: LLND load-bearing (the 2.2(b) delivery half), RPL non-discharging, no invented law either way (§6).
COMMS-ENTRY RULE debt named; pipeline takes its own register section (§6).
MANDARIN-clean: Intake-class public face, shared Peel state, sealed R2 custody, Pith read-only, ops-db never (§7).
Event mapping closed, no orphans, no double-records (§8).

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

Token lifetime defaults and configurability bounds; reminder cadence.
Whether pipeline state shares the candidate store's Peel pair or takes its own (naming canon binds the name either way).
Invitation channels at launch (email via CF Email Service is the assumed floor — an assumption to verify at spec, not a fact); SMS entry via SMS Connect as day-two channel.
The intake form's presentation of a bundle (one flow, sectioned) and the fork question's wording (rpl-02 territory; the mill-posture copy constraint from rpl-00 §5 applies — never promise an outcome).
Session-recording mechanics (what is recorded, prompts, storage format) and the retention values for recordings vs documents.
Which operator roles see which captures (the sensitivity access posture, §7).
Comms register entries for invitation / reminder / re-issue / delivery (owed before ship, §6).
Event emission points wired to the tiles' ledgers (§8 mapping is binding; the wiring is spec's).

Move-3-grade model for shared substrate. Both consumer models are settled beneath it (rpl-01 ratified 2026-07-06; llnd-01 ratified 2026-07-07); both -02 specs cite this artefact for every intake-side surface. One intake, two tiles, one person.