title: The Accreting Review — Model (a shared review primitive) doc_id: accreting-review-01-model status: settled — ratified by Tim 2026-07-07 (no amendment at the gate). A shared-substrate primitive both People onboarding and the RPL tile consume; anticipated future consumers named, not designed (§2) 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 discharges: the foundational "snapshot-versioning & approval-binding" ADR flagged owed in T4B-ONBOARDING-SURFACE-01 (settled 2026-06-18, never written up) — its rules are settled here, generalised from People-specific to shared. A bare decisions-registry ADR, if still wanted, points here. sources_read_in_full_at_draft: - PEOPLE-ONBOARDING-PIPELINE-MAP-01 (stages 5 review / 6 correspondence / 7 approval+audit; the architecture the pipeline waited on) - T4B-ONBOARDING-SURFACE-01 (snapshot machinery verified on bytes 2026-06-17; the snapshot-versioning & approval-binding rules settled 2026-06-18; the audit/history surface) - people-03-companion (build state 2026-06-29, commit a6b078c7 — established the loop is DESIGNED-not-built: /entry stubbed, authoring dormant) - rpl-01-model §3 §5 §10 §16 (the RPL application spine + the gap/supplement need) - intake-pipeline-01-model §2 §3 (the tokened candidate re-supply channel RPL consumes) - Practice Guide: RPL & Credit Transfer; Practice Guide: Assessment (Std 1.3/1.4/1.5, ASQA, 17 June 2025) — the reassessment/evidence-supplement obligation (1.4(a)(i) fairness) that surfaced the loop as a launch need relates_to: standing-rules.md (immutability, audit) · MANDARIN taxonomy · ADR-020 (scope-by-grant, for the history surface) · STORE-THE-ATTESTED-FACT-NOT-THE-SENSITIVE-ARTEFACT

The Accreting Review — Model¶

0. What this artefact is, and is not¶

Two surfaces in the product need the same machine: a submission reviewed section by section, where approvals accrete and lock rather than being re-litigated each round, conducted through an immutable back-and-forth, versioned so both "what was true then" and "how this section resolved over time" are reconstructable. People onboarding designed it (stages 5–7); the RPL tile needs it for evidence-supplement/reassessment (rpl-01 §10 + the 1.4(a)(i) fairness obligation). Rather than each tile re-authoring it — and diverging — it is extracted once here.

It is not a tile. No obligations of its own; no accreting-review-00. Every clause a review discharges is owned by the consuming tile and anchored in that tile's -00. The primitive is the machine; the meaning of a section, an approval, and a return is the consumer's.

It mints no discharging events. The events that fire on its transitions are the consumers' events, emitted into the owning tile's ledger (People's onboarding events; RPL's rpl-01 §16 events). NO ORPHAN GRAINS is honoured by reference — the primitive carries the mechanism, the tile carries the clause.

It holds no identity, grants no access, keeps no sensitive artefact. Those stay the consumers': People mints grants and identity; the intake pipeline holds the candidate's tokened channel and sealed captures; custody is the tile's vault. The Accreting Review is the review state machine over whatever a consumer submits — nothing more (§7).

One machine, N consumers, per-consumer parameters. The parameters never fork it into two machines; they are values plugged into shared stages (§2).

1. The primitive in one line¶

A versioned submission is reviewed section by section; each section is approved-and-locked or returned-with-reason; locked sections stay locked across resubmissions unless their own content changes; every exchange is immutable, attributed, append-only; and the whole is reconstructable along two axes — what the submission was at version N, and how each section resolved over time.

The audit artefact is not written after the review — the review is the audit artefact.

2. The consumers — one machine, per-consumer parameters¶

The load-bearing table. Everything below elaborates a column.

	People onboarding	RPL tile	Anticipated (named, not designed)
A "section" is	a compliance dimension (identity/suitability, credential, vocational competency, the two currencies)	a unit-claim (per unit of the target product)	LLND review items; Record's per-unit validation samples
"Approve → lock" means	admin marks the dimension compliant; it locks	the assessor's per-unit signing act (granted); it locks	validated / signed-off
"Return with reason" means	admin returns the dimension with a specific, logged reason; the person resupplies	the assessor returns the unit with a gap-notation; the candidate supplements evidence (the reassessment path — 1.4(a)(i) fairness)	validator returns a finding
The actor pair	T4 admin ↔ self-maintainer	RTO assessor ↔ candidate	validator ↔ assessor
The re-supply channel	the T4B authoring surface (login-gated, workforce)	the intake pipeline's tokened, login-free re-invitation against the same candidate row (intake-pipeline §2)	tile-specific
Sections share sub-elements?	no — dimensions are independent	yes — units can share leaves; the cascade (§4) is load-bearing here	per-tile

The last row is the one genuine generalisation RPL forces: sections may declare sub-element dependencies, and a re-open cascades along them (§4). Consumers whose sections are independent (onboarding) simply declare none.

3. The two version axes — never conflated (the foundational rule)¶

The single mistake this model exists to prevent: collapsing two different things that both carry versions. They are orthogonal and both reconstructable from one data set.

The submission version. Monotonic per submission subject, incrementing on each submit (v1 / v2 / v3 across return cycles). Each version freezes an immutable snapshot of the submitted field-set at that moment. (People's substrate already holds this: pc_attestations carries version, the frozen snapshot JSON, attested_at, attested_by — verified on bytes 2026-06-17. RPL binds its own equivalent in rto-rpl-db; the shape is the model's, the table is the tile's.)
The per-section approval. Accretes independently of the submission version. A single snapshot can have section A approved and section B returned. An approval is a fact about a section, not about the whole submission.

Conflating them produces one of two failures, both fatal: re-litigating every section on every resubmission (infuriating, and it makes the review never converge), or letting a section approved against old content ride forward over changed content (dangerous — the approval no longer describes what it approved). §4 is the rule that keeps them apart.

4. Accreting approval + the lock rules¶

A section's approval binds to the snapshot version it was approved against. The approval record carries { section, approved-at-submission-version, approver, timestamp }. It is an attributed historical fact, never mutated.
An approved section stays locked through later resubmissions — unless its own content changes. If the resubmission leaves section A's content byte-identical, A's approval rides forward untouched (no re-litigation). If section A's content changes, A's lock breaks and A re-enters review (the approval stands as history, against its old version, but no longer governs the current submission). This is the trap named and closed: content-change is the only thing that re-opens a locked section.
The sub-element cascade (RPL's generalisation). Where sections declare sub-element dependencies, a content change that touches a shared sub-element re-opens every section that depends on it — not only the section the candidate edited. In RPL: supplementary evidence re-tracing a leaf shared by units X and Y re-opens both, even if only X was returned. Consumers with independent sections declare no dependencies and the cascade is a no-op. The dependency graph is the consumer's to declare; the cascade rule is the model's.
Convergence. The review is complete when every section is locked-approved against the current submission version (or the submission is withdrawn/failed per the consumer's terminal rule). Because locks accrete and only content-change re-opens them, the outstanding set shrinks monotonically toward zero — the review is guaranteed to narrow, not thrash.

5. The correspondence loop¶

The back-and-forth between reviewer and subject — return-with-reason, clarification request, response — is not a side channel; it is part of the record.

Immutable, timestamped, attributed, append-only. Nothing is edited or deleted; a correction is a new entry. Every entry names its author and its moment.
Bound to its section and its submission version. A return-with-reason references the section it returned and the version it returned against, so the log reconstructs why a section re-opened, not merely that it did.
The audit answer. "How did this record come to be approved?" is answered by replaying the correspondence against the version axis — the process, not a summary of it, is the evidence.

6. Reconstruction along both axes¶

From the same immutable data, the surface must reconstruct:

The temporal view — "what the submission was at version 2" (a frozen snapshot + the approval state as it stood then).
The sectional view — "how the Credential dimension / unit-claim resolved over time" (the section's return/approve history across versions, with its correspondence).

Both are reads over the version-and-approval records; neither is stored as a separate narrative. If a design can produce only one axis, it has conflated the two versions (§3).

7. The boundary — what the Accreting Review does not do¶

Named explicitly so no consumer's spec quietly grows the primitive past its job:

It does not grant access or mint identity. People mints grants and identity; the candidate store holds candidate identity; the primitive reviews a submission, it does not decide who may log in or be counted. (A submission is never tacit elevation — the grant is a separate, deliberate act on the consumer's side.)
It does not hold the sensitive artefact. Custody is the consumer's (the RPL vault; the intake pipeline's sealed captures). The primitive references sealed digests; it stores review state, not evidence bytes. STORE-THE-ATTESTED-FACT-NOT-THE-SENSITIVE-ARTEFACT applies.
It does not carry clauses. Sections, approvals and returns are anchored to clauses by the consuming tile's fields (CLAUSE-BOUND FIELDS lives in the tile, not here). The primitive is legislatively neutral — which is exactly why it is shared.
It does not choose the re-supply channel. People uses the login-gated authoring surface; RPL uses the intake pipeline's tokened re-invitation. The primitive requires a channel; the consumer names which.

8. What hardens from this model¶

Not a tile; no -00; no owned events — a shared machine discharging the consumers' reviews by reference (§0).
One machine, per-consumer parameters, never forked (§2).
Two version axes, never conflated — submission-version (frozen snapshots) vs per-section-approval (accretes independently) (§3).
Accreting locks: approval binds to the version it was made against; a locked section stays locked unless its own content changes; content-change is the only re-opener (§4).
The sub-element cascade — a shared-sub-element change re-opens all dependent sections; independent-section consumers declare none (§4).
Guaranteed convergence — the outstanding set shrinks monotonically (§4).
Correspondence is the record — immutable, attributed, append-only, bound to section + version (§5).
Dual-axis reconstruction — temporal and sectional from one immutable data set (§6).
Bounded — no access, no identity, no custody, no clauses; those stay the consumers' (§7).
Discharges the foundational snapshot-versioning/approval-binding ADR onboarding awaited.

9. Deferred to the consuming specs (structural & presentation calls, not model questions)¶

The concrete substrate each consumer binds (People: pc_attestations + an approval/ correspondence store; RPL: rto-rpl-db tables) — the shape is the model's, the tables the tile's.
Content-change detection mechanism (digest-per-section vs field-diff) — a spec call; the rule (content-change breaks the lock) is the model's.
The terminal states beyond approve/return (withdraw, fail, expire) — consumer-defined.
The review surface's presentation (the progress-list vs glass-on-arrival treatment is People's design language; RPL's assessor workbench is rpl-02 §6).
Which roles see which histories — scope-by-grant per ADR-020; the capability (everyone sees their own; operators see their scope) is the model's, the role bindings the tile's.
Notification/reminder cadence on a return (rides each consumer's comms surface).

Move-3-grade shared-substrate model. Extracted 2026-07-07 from the People onboarding design (stages 5–7) and the snapshot-versioning rules settled 2026-06-18, generalised to serve the RPL tile's evidence-supplement loop. Designed-not-built in both consumers as at extraction — the cheapest moment to author it once. One machine; many reviews; the process is the evidence.