People — Spec¶

The build for the People tile — the what. This is move 4 of the Legislation-to-Tile Method: the obligations checklist (people-00-obligations, move 2) set the acceptance surface; the model (people-01-model, move 3) reasoned the tile as the answer; this spec binds the model's entities to buildable fields, each carrying its clause trace.

This spec derives from the model and points back to it. It does not restate the model's reasoning. Where a field's why is asked, the answer is in people-01-model at the cited section; this document carries the what and the trace. Read the model first; read this to build.

This spec is whole — it covers the engine, the Delivery Assignment, every compliance entity, the four-dimension display, the surfaces, the identity/tier build-layer carried from v0.3, and the Studio seam. It supersedes people-spec-v0_3 wholesale; the reconciliation register (§13 of the model; §14 here) records what changed and why.

Two layers, one document. This spec holds two kinds of substance, kept visibly distinct:

The clause-bound compliance core (§3–§9) — the legislation-grounded heart, every field carrying its anchor/obligation/consequence trace per CLAUSE-BOUND FIELDS. This is what the model reasoned.
The identity/tier build-layer (§10) — logins, tiers, seats, the Admin→Team surface, the mint rule. Carried forward from v0.3 (its only home) and reconciled to the model. Not legislative-reasoning; it is product mechanics. Marked as such so the two never blur.

Substrate grounding (verified against bytes 2026-06-17, via the model): the list is rto-nrt-db (UUID 1249760d-070a-43f8-81d7-de462b626cdf), regulated substrate under the HARD SEPARATION RULE. The engine reads qualifications, units, qualification_units, qualification_packaging_rules, skill_sets, skill_set_units; the four component classes are real columns on units. The KN sacred rows (15,128) live in units — read only, never written.

1. What this spec is¶

A buildable specification, derived field-by-field from people-01-model. Three rules govern its form:

CLAUSE-BOUND FIELDS. Every field on a regulated surface carries a stored three-part trace — anchor (clause / instrument, never bare), obligation (plain-English what-and-why), consequence (what fails in audit if absent or wrong). Authored as fact in the same act as the field; never generated at runtime, never backfilled. A field without its trace does not pass.
Derived-never-stored is a build constraint, not a preference. Every verdict, dimension state, and eligibility the model marks derived is computed on read from its inputs. The build must not persist these as columns. Where v0.3 stored them, §14 records the reconciliation.
NO ORPHAN GRAINS. The discharging events (§11) are the only things the audit ledger emits. Events reference fields; fields carry clauses; the clause is never copied onto the event.

This spec ends at ready to build. From here the work enters the build gates and brief drip in standing-rules.md. The method ends here; the spec is the handoff.

2. Trace format (how every field below is annotated)¶

Each regulated field carries its trace inline as:

field_name — anchor: {clause / instrument}; obligation: {what it answers}; consequence: {what fails in audit}. (state: stored | derived)

Where a block of fields shares an anchor, the anchor is stated once for the block and each field carries obligation + consequence. Derived fields name their inputs (what they compute from) in place of a stored value.

3. The engine — `canDeliver`¶

canDeliver( person, training_product, activity ) → { verdict, evidence, dimension_states } verdict ∈ { permitted | permitted_under_direction | not_permitted | insufficient_data }

The engine is the spine of the tile. It is a pure evaluation over held credentials and the policy table — it holds no state of its own. Model reasoning: §1, §1A, §4.

3.1 Build contract¶

Inputs: a person (resolving to held, authenticated credentials + any director link), a training_product (a TGA identity resolved against rto-nrt-db), an activity (the Credential Policy enum).
Output: the verdict, the evidence behind it, and the four dimension states (§7). All three derived on read.
The verdict is never stored. It is recomputed whenever held credentials, the assignment, the director link, or the policy/list version changes. No verdict column exists anywhere.

3.2 The foundational negative rule — role never gates evaluation¶

The engine reads held credentials. It never pre-filters the candidate pool by role. Role (the four populations: trainer_assessor / expert / support_staff / management — ADR-062) is a presentation lens (§10.6), never an input to canDeliver. Model reasoning + worked failure mode: §1A.

Build constraint: no code path that computes a verdict may read a role field. A person tagged Management who holds a Cert IV T&A is exactly as deliverable as one tagged Trainer. Enforced at the engine boundary.
Consequence if violated: a false not_permitted — telling a compliant RTO it is non-compliant, the alarming-direction failure.

3.3 Activity enum (the assignment's `activity`)¶

deliver_and_assess | assess_only | deliver_assess_under_direction | provide_direction | validate. Anchor: Credential Policy §1A–§3B / CP v. 10 Dec 2025. The enum is the policy's, not ours.

3.4 Routing — Section 1 vs Section 2 (Fork 2, TAE)¶

The engine reads two facts from the list and routes. Model: §4.1.

Non-TAE product → Credential Policy Section 1 (1A–1E).
TAE product → Credential Policy Section 2 (2A–2C), level-aware: the credential must be "at least to the level being delivered" (2A). Carve-out faithfully held: delivering the Cert IV TAE itself (TAE40122 or successor) requires a Diploma-level TAE qualification — the trainer-of-trainers rule.

product_is_tae — anchor: CP §2A–§2C / CP v. 10 Dec 2025; obligation: routes the evaluation to the TAE sub-table; consequence: a TAE product evaluated under Section 1 applies the wrong credential set — false verdict. (derived: read from rto-nrt-db training-package membership) product_aqf_level — anchor: CP §2A / CP v. 10 Dec 2025; obligation: enforces "at least to the level being delivered" incl. the Diploma-to-deliver-Cert-IV carve-out; consequence: under-levelled trainer passes — direct breach. (derived: read from rto-nrt-db)

TAE-ness and level are reads from the list, not judgements.

3.5 The credential check (Fork 1 + under-direction fallback)¶

Model: §4.2. The evaluation, in order:

Compute the acceptable-credential set from the policy table for (activity, product-type [, level if TAE]).
Intersect with the person's held, authenticated credentials (§5).
Non-empty → permitted.
Empty → check under-direction fallback (CP §1C/§1D + §1E, or §2B + §2C): a working-towards/under-direction credential and a valid director link to a §1E/§2C holder → permitted_under_direction.
Neither, but a compliance record exists → not_permitted.
No compliance record (stub) → insufficient_data (§3.6, §9).
Authentication gate — a credential counts only with verified document-level evidence attached. A bare code never counts (§5.2).
Judgement block — working-towards / under-direction states carry cannot make assessment judgements as a negative capability on the verdict (derived, §5).

3.6 The four verdicts (all derived; the distinctions are load-bearing)¶

Verdict	Meaning	Build note
`permitted`	held credentials satisfy directly	green; deliverable
`permitted_under_direction`	working-towards/under-direction + valid director	deliverable with the judgement block; surfaces the director link
`not_permitted`	evaluated, requirement not met	red; a negative verdict
`insufficient_data`	cannot be evaluated yet (stub)	amber, not red — absence of data ≠ negative. Distinct from `not_permitted`. Surfaced by the Studio Never Block (§9).

The insufficient_data / not_permitted distinction is load-bearing across the Studio seam and must not be collapsed in any surface. Model: §1, §9.

4. The Delivery Assignment — the entity the engine evaluates¶

Delivery Assignment = (person × training_product × activity)

The thing evaluated is not a person and not a product — it is the assignment of a person to perform an activity for a training product. This is the biggest structural addition over v0.3, which allocated competency "per training product" but never named the entity the obligation attaches to (§14, item 2). Model: §3.

The assignment is the spine: its creation/change is a discharging event (the obligation attaches when the RTO says "this person delivers this product"); the verdict is a derived property of it; evidence attaches to it; the Compliance Matrix is a query over it (§8).

Entity: pc_delivery_assignments

anchor (entity): Standard 3.2(a) / F2025L00354 + CP §1A–§3B / CP v. 10 Dec 2025 person_ref → pc_persons — obligation: the person carrying the obligation; consequence: no person = no one accountable for the activity. (stored) training_product_ref — obligation: the TGA identity (qual / skill set / unit) the activity is for, resolved against rto-nrt-db; consequence: unresolved product = the acceptable-credential set cannot be computed. (stored: TGA code; resolves to list) activity — obligation: which Credential Policy activity (§3.3); consequence: wrong activity applies the wrong credential set. (stored: enum) verdict — obligation: whether the person may lawfully perform this activity; consequence: a stored verdict goes stale the moment a credential or the policy changes. (derived: canDeliver(person_ref, training_product_ref, activity); never stored) status (active / archived) — obligation: assignment lifecycle; on scope removal the assignment archives, not deletes — audit trail preserved; consequence: deletion destroys the historical record an auditor needs. (stored)

5. The Credential record¶

Anchor (block): Standard 3.2(a) / F2025L00354 + Credential Policy v. 10 Dec 2025. Model: §4.2. The held-vs-required evaluation is the engine's (§3); this entity holds the held side.

Entity: pc_credentials (child of pc_persons)

credential_type — obligation: the Credential Policy class held (1A/1B/1C/1D/1E or §2/§3 equivalents); consequence: unclassified credential cannot be intersected with the required set. (stored: enum) specific_credential (code, title, version) — obligation: the precise national credential; consequence: a vague credential cannot be matched to the policy table. (stored) issuing_rto — obligation: provenance of the credential; consequence: unattributable credential weakens the evidence chain. (stored) date_awarded — obligation: when the credential was earned; consequence: undated credential cannot support currency or working-towards horizons. (stored)

5.1 Working-towards fields (CP §1C only)¶

Anchor: CP §1C / CP v. 10 Dec 2025. enrolment_date, expected_completion — obligation: evidences "actively working towards" within the 2-year horizon (TAE40122/TAE50122); consequence: a working-towards claim with no horizon is unbounded — breach. (stored) satisfactory_progress — obligation: the person is making satisfactory progress; consequence: stalled progress invalidates the working-towards state. (stored: Y/N, dated) working_towards_remaining — obligation: surfaces the 2-year countdown to the credential dimension; consequence: an expired working-towards state silently continuing is a breach. (derived: expected_completion − today against the 2-yr cap; model §12)

5.2 Authentication (the evidence gate)¶

Anchor: Standard 3.2(a) / F2025L00354; PG known risk "no system to authenticate credentials." evidence_ref — obligation: document-level evidence of the credential (certificate / USI transcript / issuing-RTO confirmation / reference), stored in Record, linked here; consequence: a credential entered as a bare code, with no artefact, does not count in the engine — and in audit is an unsupported assertion. (stored: link) verification_method — obligation: how the credential was authenticated (USI transcript / issuing-RTO confirmation / certificate sighted / reference); consequence: unverifiable method = the credential cannot reach a trusted state. (stored: enum) verified_by, verified_date — obligation: attribution of the verification act (the administrator, for manual paths; the system, for the USI path — §10.4); consequence: unattributed verification cannot be defended. (stored)

5.3 The judgement capability (derived, not stored — §14 item 3)¶

can_make_assessment_judgements — anchor: Standard 3.2(b) / F2025L00354 + CP §1B, §1C; obligation: whether the person may make assessment judgements (a fully-credentialled assessor can; a working-towards/under-direction person cannot); consequence: a working-towards person making judgements is a hard breach. Derived from credential_type + verdict — never a manually-set column. v0.3 stored this; reconcile to derived. (derived)

6. Vocational competency (Fork 3) — anchored 3.3(a)(i)¶

Headline reconciliation (§14 item 1): v0.3 anchored vocational competency to "3.3" — substantially right: the authorised instrument places it at 3.3(a)(i) / F2025L00354 (industry competency, required of all persons delivering; experts are the 3.3(b)–(c) subset). The intervening "corrected to 3.2(b)" inverted against the authorised text and is withdrawn (it rode the defective pre-rebuild corpus). Corrected throughout. Model: §5.

Vocational competency is evaluated at unit level — against all units the person delivers/assesses, read from qualification_units, never assumed from the qualification. Two satisfaction modes.

6.1 Matched (computable)¶

vocational_competency_state (matched branch) — anchor: Standard 3.3(a)(i) / F2025L00354; obligation: the person holds a qualification/skill set/unit from the list that covers the assigned unit; consequence: an uncovered unit means delivery beyond competency. Derived — the engine reads held-vs-required, no human judgement. v0.3 stored a status enum (Verified/Pending/Gap/Expired); reconcile to derived. (derived)

6.2 Asserted-equivalent — its own structured entity¶

No exact holding → a gap-analysis mapping matrix is required. This is the highest-audit-exposure surface in People, and the model gives it real structure (§5.2). It is specced as its own child entity, not a field on the credential record (§ judgment-call 2).

Entity: pc_equivalence_mappings (child of pc_persons, scoped to a unit)

Anchor (entity): Standard 3.3(a)(i) / F2025L00354. Concordance note (stored with the entity): two external legal-standard sources miscited this obligation — one to superseded 2015 cl.1.13–1.16 (dead instrument), one to a bare "3.3". Against the authorised instrument the 3.3 pointer was substantially right: vocational/industry competency is 3.3(a)(i) / F2025L00354 (industry competencies at-level, all persons delivering). Future-concordance entry: 2015 cl.1.13–1.16 → 2025 Standard 3.3(a)(i) / F2025L00354. No Credential Policy in the anchor — the CP holds T&A credentials and expert direction, not vocational-competency equivalence (its only equivalence provision is Cert IV TAE, §2B, a different obligation); the equivalence method cites the practice guide (Layer 3). (Corrected 2026-07-07, STANDARDS-ANCHOR-BLAST-RADIUS-01: the prior "3.2(b) + Credential Policy" cite rode the defective pre-rebuild corpus.) Model: §5.2 anchor note.

unit_ref — obligation: the unit the equivalence is claimed against; consequence: an unscoped mapping proves nothing specific. (stored) component_coverage — obligation: maps against 100% of the unit's four component classes (elements/performance criteria, performance evidence incl. volume/frequency/context bounds, knowledge evidence, assessment conditions), read from units; completeness is total, not substantial; consequence: a partial mapping is red, not amber — an incomplete equivalence asserted as complete is a fabricated competency claim. (derived: completeness over the requirement set; the requirements are read from rto-nrt-db) requirement_triples[] — obligation: each requirement carries requirement_ref → cited verified evidence item (typed) → objective reasoning; the reasoning field is constrained to fact-to-requirement analysis (subjective/conclusory language is non-compliant by form); consequence: conclusory reasoning ("clearly equivalent") is not evidence — fails on inspection. (stored, per requirement) evidence_items[] (typed, verified) — obligation: admissible types — authenticated alternative/superseded qualifications (with syllabus mapping, checking units.supersedes/superseded_by); verified workplace artefacts; attested third-party verifications (stat-decs / supervisor references); active regulatory/industry licences; consequence: unverified or inadmissible evidence cannot back a requirement. (stored) currency_backing — obligation: currency is mandatory and must address gaps from technology/regulation change; ties to the Currency Record (§7.1) read here as backing evidence; consequence: a stale equivalence is not a current competency. (derived from the Currency Record; see §7.1 dual-consumer note) signoff (dated, attributed, competent-authority level — Academic Manager) — obligation: the human determination of equivalence; consequence: an unsigned matrix asserts equivalence with no accountable determiner. This is the discharging event (§11). (stored) equivalence_state — obligation: the surfaced state; consequence: a "yes/no equivalent" output would mean the engine computed sufficiency, which it must never do; (derived, and constrained: output is "equivalence asserted, mapping complete/incomplete, signed by X on date Y" — never "equivalent: yes.")*

Two non-negotiable engine behaviours (build constraints, model §5.2):

Fail-closed default. The burden of proof is on the RTO; the presumption is not credentialled until demonstrated. An incomplete equivalence is red, default not_satisfied until the matrix is 100% complete and signed.
Never computes sufficiency. The engine reads requirements, holds evidence per requirement, checks completeness. It does not decide the mapping is sufficient — that is the signed human determination.

7. The currency dimensions (industry + T&A) — anchor fixes §14 items 1, 4¶

Two Currency Records, same shape, different subject. Industry currency anchors to 3.3(a)(ii); T&A CPD to 3.2(c) (corrected 2026-07-07, STANDARDS-ANCHOR-BLAST-RADIUS-01 — v0.3's "3.3" for industry currency was substantially right; the intervening "3.2(c)/3.2(d)" correction inverted, moving industry currency into 3.2 against the authorised instrument). Model: §6.

Both flag, do not gate — a currency lapse is a quality concern surfaced, not a credential revocation. This difference-in-kind from the gating dimensions is the display's defining job (§7.3, §8).

7.1 Industry currency (3.3(a)(ii)) — the Currency Record¶

Currency Record = (person × vocational_area × dated_evidence_of_engagement)

Entity: pc_currency_records (child of pc_persons). Anchor (block): Standard 3.3(a)(ii) / F2025L00354. The instrument prescribes no cadence/method/interval ("maintains current"); recurrence/staleness are practice-guide Layer-3, held self-assurance-grade, not clause-level.

person × vocational_area — obligation: currency in the vocational area of what the person delivers/assesses, resolved against assignment products (rto-nrt-db) — not a generic badge; consequence: currency in the wrong area proves nothing for the assignment. (stored: vocational_area resolves to list) engagement_event (dated, typed) — obligation: a concrete act of industry engagement, not self-certification; consequence: "I keep current" with no event is unsupported. (stored) evidence_ref (authenticated) — obligation: document-level evidence, mirroring credential authentication; consequence: unevidenced engagement is an assertion, not a record. (stored: link) currency_date — obligation: currency is a point in time; consequence: undated currency cannot be aged. (stored) how_applied_to_practice — anchor: 3.3(a)(ii) / F2025L00354; absorbed from v0.3; obligation: the reflexive field that turns a log into evidence — mandatory; consequence: a logged event with no application to practice is incomplete as evidence (surfaced incomplete, not hard-blocked). (stored) — This is the one reverse-flow from v0.3, pulled up into the model (§6.1) and kept here. review_cadence (self-assurance) — anchor: PG known risk (not a PI); obligation: currency is reviewed recurrently after onboarding, not once; consequence (self-assurance): once-at-onboarding currency drifts stale unnoticed. (stored: configured) staleness (derived) — anchor: PG known risk; obligation: surfaces current / ageing / stale; consequence: un-aged currency hides lapses. (derived: today − currency_date against the configured threshold, §12)

Posture: does not fail closed to not_permitted. One inherited exception: where a currency lapse touches an asserted-equivalent competency (§6.2), the equivalence determination's own fail-closed default applies — there, currency is a mandatory completeness component. One record, two consumers, two postures (model §6.1): the dimension flags; the equivalence determination it feeds fails closed.

7.2 T&A currency / CPD (3.2(c)) — the CPD Record¶

CPD Record = (person × t_and_a_practice × dated_PD_evidence)

Entity: pc_cpd_records (child of pc_persons). Anchor (block): Standard 3.2(c) / F2025L00354. Same shape as §7.1, subject swapped to T&A practice. 3.3(a)(ii) is currency in what you deliver (industry practice, §7.1); 3.2(c) is currency in how you train and assess (T&A CPD, this block).

person × t_and_a_practice — obligation: per-person T&A currency; consequence: no record = no demonstrable T&A currency. (stored) pd_event (dated, typed) — obligation: a concrete PD act; consequence: unlogged PD cannot be demonstrated. (stored) evidence_ref (authenticated) — obligation: document-level evidence; consequence: unevidenced PD is an assertion. (stored: link) pd_date — obligation: point-in-time; consequence: undated PD cannot be aged or pattern-checked. (stored) review_cadence (self-assurance) — anchor: PG known risk (not a PI); obligation: T&A practice is reviewed recurrently after onboarding, not once; consequence (self-assurance): once-at-onboarding CPD drifts stale unnoticed. (stored: configured) Mirrors §7.1; drives staleness + the weekly nudge; flags, never blocks (§7.3). staleness (derived) — anchor: 3.2(c) / F2025L00354; obligation: current / ageing / stale; consequence: un-aged CPD hides lapses. (derived, §12) pattern (derived, self-assurance) — anchor: PG known risk (not a PI); obligation: "ongoing" is the clause word; "systematic, not ad-hoc, not audit-clustered" is the sharpening — five PD events all dated the month before an audit pass a naive recency check but fail the obligation; consequence (self-assurance): audit-clustered PD is a known ASQA red flag. (derived: distribution over pd_date history)

Posture: does not fail closed; no equivalence consumer (doesn't feed §6.2), so no second-consumer exception — cleaner than industry currency in that one respect.

v0.3's three CPD types map onto these two records: VC → industry currency (3.3(a)(ii)); TA/VET → T&A currency (3.2(c)). Corrected 2026-07-07 (STANDARDS-ANCHOR-BLAST-RADIUS-01): industry currency sits at 3.3(a)(ii), T&A CPD at 3.2(c) (no 3.2(d)); v0.3's original "3.3" for industry currency was nearer right than the intervening "3.2" correction.

7.3 Gate vs flag — the difference in kind¶

Dimension	Anchor	Source	Fails closed?
Credential	3.2(a) / F2025L00354 + CP	engine (`canDeliver`)	Yes — red = cannot deliver
Vocational competency	3.3(a)(i) / F2025L00354	engine Fork 3	Yes — red = cannot deliver
Industry currency	3.3(a)(ii) / F2025L00354	Currency Record	No — red = deliver, flagged
T&A currency	3.2(c) / F2025L00354	CPD Record	No — red = deliver, flagged

This table is a build constraint on the display (§8), not decoration. A red credential blocks; a red currency warns. The surface must communicate the difference.

8. The four-dimension display + Compliance Matrix¶

A read surface, not an entity — the rendering of §7.3 against the engine. Model: §8.

Each person × assignment shows four dimension states side by side, never collapsed into one score. A person can be green on credentials, red on industry currency — all four surface separately.
Build constraint: the display must communicate the difference in kind between gating dimensions (credential, vocational competency — red = cannot deliver) and flagging dimensions (industry, T&A currency — red = deliver, but flagged). A naive four-dot UI rendering all four identically is non-compliant by design — it tells the user a flag is a block.

The Compliance Matrix is the same data pivoted: training_product × person, each cell the four-dimension state for that assignment. Because the engine keys on the Delivery Assignment (§4), the matrix is the engine's natural output shape — a query over assignments, no new modelling. Answers "everyone delivering SIT30122 whose industry currency expires within 60 days" as a filter over the pivot.

Display note: "Next review due" shown to the person is derived (currency_date + review_cadence), not stored. It drives the staleness flag and the weekly unsubmitted/ageing nudge. It flags, never blocks (§7.3) — a passed review date surfaces "ageing/stale", never not_permitted.

9. The Studio consume seam¶

A contract, not an entity — how Studio asks People a question and People answers with the engine. Felt-not-seen (a backend read, not a UI handoff). Model: §9.

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

Studio owns the assignment intent and the rendering (the canvas compliance question — which is canDeliver by another name).
People owns the verdict, the evidence, the four dimension states. Derived, never stored.
Neither owns composition — both read rto-nrt-db (Fork 1). The join is on training product (TGA identity). This is why Studio can ask about a unit People has never seen.

Graceful degradation (Studio's Never Block):

Evaluable person → full verdict + dimension states.
Stub (no compliance record) → insufficient_data, not not_permitted. Studio shows the amber "profile incomplete" nudge, not a red block.
Person doesn't exist → Studio creates the stub; no People call until it has data.

Studio-spec redline (action separately — §14 item 7): the Studio spec describes "Trainer Mapper" as if Studio computes trainer-to-unit verdicts. It does not — the verdict is People's (the engine). Studio asks and renders; People evaluates. This is a studio-spec edit, flagged here, to be actioned against that document — not resolved in this spec.

10. The identity / tier build-layer (carried from v0.3; reconciled — NOT clause-bound compliance)¶

This section is product mechanics, not legislative-reasoning. The model is silent on it because it is not the law's response — it is how logins, tiers, and seats work. It is carried forward from people-spec-v0_3 (its only home) so it is not lost, and reconciled to the model where they touch. Fields here do not carry clause traces, because they are not regulated-surface compliance fields; where one does touch a Standard (e.g. accountability), the anchor is noted.

Outbound interactions (invite, return-for-correction, sign-in, and any future approval/grant messaging) are registered in COMMS-REGISTRY-01 under the People module, per the COMMS-ENTRY rule. People owns the wording and trigger of its own outbound voice.

10.1 The two-layer identity model¶

A human exists at two layers, same person, different questions, different governance (ADR-040):

Layer 1 — System identity (admin/identity layer, ADR-020/024): the login (users in identity-db, keyed to email), the tier grant(s), seat consumption + billing posture. Governed from Administration → Team, never from People. People never mints a login.
Layer 2 — Extended identity (the People layer): the pc_persons record + children — the compliance substance of §5–§7. Exists whether or not the person has a login; a contractor can be a compliance record with no system identity.

The join: pc_persons.user_id → users.id (ADR-040) — nullable, admin-asserted, a conduit not a merge. Neither layer auto-materialises the other; email is a non-binding suggestion; USI is never a join key. Legal name lives once, on pc_persons.full_legal_name.

Accountability vs authorship (touches Standard 3.2 / F2025L00354): the RTO is accountable to ASQA — unchanged under any tier model. Authorship of a person's own facts may be delegated to that person (T4B). Delegating authorship to the party with the strongest claim to know the fact strengthens the evidence position; it does not weaken accountability. This aligns with the model's "self-attested data is a stronger audit asset" posture.

10.2 Tiers and access¶

Tier	Who	Seat?	People access
T3 Operator	RTOpacks staff	n/a	impersonation only (ADR-022); not in the client register
T4 Administrator	RTO manager / compliance owner	No (role)	Full — author/edit any record; mint logins; form seat↔person links
T4A Client user	trainer / author / designer	Yes (billable)	read register; author/edit own record; module work
T4B Self-maintainer	maintains only their own record	No (uncharged, unlimited)	author/edit own record only; no register, no others, no admin, no modules

T4 and T4A are separable roles on the same human (ADR-020). T4B is the deliberately minimal self-authorship tier.

10.3 T4B — the self-maintainer¶

A login whose entire purpose is for a person to keep their own extended-identity record current. The most locked-down surface in the product.

Why it exists — provenance, not convenience: the most authoritative source for a trainer's own currency is the trainer. T4B moves authorship to the party with the strongest claim to know the fact; the audit trail inherits its legitimacy from that authorship (ADR-042; aligns with model "trust terminates with the author").
Seatless + unlimited: a T4A seat represents operational capacity (the billing unit); a T4B consumes a login and a few kilobytes. An 80-trainer RTO should be encouraged, not taxed, to have all 80 self-maintain. A free-tier cap was considered and rejected — the threat (bulk junk accounts) doesn't match the population (compliance staff), and a cap would tax the exact provenance behaviour the tier promotes.
Scope — can: view/edit own pc_persons + children, upload/link own evidence, see own four-dimension status. Cannot: see the register, see/reference any other person, access Administration, consume a seat, enter any module, or change own tier/seat/role.
T4B → T4A promotion: a grant change, not a re-onboard. Both tiers attach to the same users.id and linked pc_persons; an administrator adds the T4A grant (seat consumed); history/credentials/login persist. This is why T4B must be visible in Administration → Team as well as in People — the administrator sees self-maintainers in the workforce totality to promote them.

10.4 Verification — manual vs USI (no-administrator-in-loop)¶

Self-authored facts are legible as self-asserted until verified. Verification reaches a trusted state by one of two paths (ADR-042):

Manual path — certificate sighted / reference / issuing-RTO confirmation. An administrator act.
USI path — the person consents to a lookup of their own government transcript; the system pulls the authenticated transcript M2M (OSIR) and the credential flips to "Verified via USI transcript." A system act the person triggers; no administrator in the loop.

The USI path is the highest-integrity rail: the same self-authorship act that makes the claim authorises its verification against a government source. (USI/OSIR integration is Phase 2 — DPO Authentication Kit prerequisite, government lead time; start early.)

10.5 The Admin-Only Mint Rule¶

All system identity — every login and tier grant, including T4B — is minted only from Administration → Team. A T4 administrator mints via Invite member. A T4A cannot self-mint; they raise an access request routing to an administrator. People may carry the trigger (e.g. "invite this person to maintain their own record (T4B)"), but that action routes to Administration as a request/mint — it does not mint from People. The seat↔person link is formed by the administrator's mint, satisfying ADR-040's admin-asserted-link requirement.

Open question carried from v0.3 (§13): whether the Admin→Team surface canonically belongs to People or its own workspace-admin spec. This spec documents People's dependency on it; ownership should be settled so the two don't drift.

10.6 Role as presentation — single-valued now; multi-hat named-future (§14 item 8; ADR-062)¶

Role is the four-population vocabulary (trainer_assessor, expert, support_staff, management), and it is single-valued in the current build (ADR-062). Standalone trainer / assessor are removed — deliver-vs-assess is the engine's per-assignment verdict (canDeliver, §3.2), never a standing role tag, so there is one teaching population: trainer_assessor.

Multi-hat is named-future, re-weighted up — not current state. v0.3 framed role as moving to multi-select (a person holding a set of tags — the RTO manager who also delivers). That remains the eventual target — and it is re-weighted upward, because in the micro/small-RTO segment the multi-hat operator is the dominant shape, not the edge — but it is not built: today role holds exactly one value. The hat a person also wears (e.g. a trainer_assessor who runs the business) currently rides their tier/grant (the access axis), not their role (the record axis).
Build note: making role multi-valued (a multi-valued attribute or its own child relation, not a single enum column) is the structural data-model change this implies — backlogged, named-future.
The engine never reads role (§3.2) — this is presentation only, and that half is settled and unchanged. §3.2 is the safety-critical half (engine never gates on role); §10.6 is the descriptor half. A person whose role is management who also holds a Cert IV T&A is fully deliverable by the engine; the role is how the record is described, the credential is what they can do.

10.7 `position` — the person's title (product-layer, non-gating)¶

position (product-layer, non-gating, non-clause-bound) — free-text job title / position (e.g. "Head of Department", "Lead Trainer"). Descriptive only. Does not carry a clause trace and does not affect compliance status or any canDeliver determination. Distinct from role (§10.6): role is the four-population descriptor the workforce is viewed through (single-valued now, ADR-062); position is the person's own title. Pre-pays the later org-chart touchpoint (reporting line derives from position + pc_supervision, §12) without diluting the spine. Captured optional on the T4B Identity tile.

11. The discharging events (the audit ledger emit points)¶

Per NO ORPHAN GRAINS — these, not UI actions, are what the ledger records. Each references the field(s) it touches; the clause is reached through the field, never copied onto the event. Model: §10. Ten events, matching the move-2 forecast of "a dozen."

Credential authored + authenticated — a credential with verified document evidence (§5).
Delivery assignment created/changed — person × product × activity asserted; the obligation attaches (§4).
Vocational competency matched — computed satisfaction against an assignment's units (§6.1).
Equivalence sign-off — dated, attributed competent-authority determination on a complete matrix (§6.2).
Industry-currency event recorded — dated, typed, evidenced (also read by the equivalence engine where it backs an assertion) (§7.1).
Direction review performed — dated, attributed, carrying work-quality assurance + supervision-level determination (§12.1). (Relationship creation attaches the obligation; the review discharges it.)
Validator eligibility asserted — for the validation activity; read by Record (§13).
PD event recorded — dated, typed, evidenced (§7.2).
Expert engagement asserted — expert × product × director, with the judgement flag (3.3(b)) (§12.2).
Expert-assisted assessment judgement documented — dated record of assessment conducted alongside a qualified assessor (3.3(c)(iii)); the practice guide's loudest known-risk (§12.2).

Build note: the ledger report is not built early. Capture is built correctly (these events emit, referencing fields); the report is a read over captured events, called when there is something to say (NO ORPHAN GRAINS; method deferred-work register item 5).

12. The relationship entities¶

12.1 The Direction Relationship¶

Direction Relationship = (directed_person × director_person × delivery_assignment)

Not a foreign key — a supervised relationship the law holds the RTO accountable for maintaining and reviewing. Born when a permitted_under_direction assignment requires a director; lives as long as the assignment; reviewed on a cadence. It reuses the engine, does not duplicate it. Model: §7.1.

Reconciliation (§14 item 5): v0.3 stored the supervisor on the supervision record. This spec derives director eligibility per-product through the engine — canDeliver(director, training_product, provide_direction) → permitted — same engine, derived-never-stored, per-product (a director eligible for one product is not automatically eligible for another).

Entity: pc_direction_relationships

directed_person → assignment — anchor: 3.2(b) / F2025L00354 + CP §1C/§1D; obligation: the person lacking full credential, tied to the assignment; consequence: untied direction supervises nothing specific. (stored) director_person — anchor: CP §1E (non-TAE) / §2C (TAE); obligation: who holds the direction credential; consequence: no director = the under-direction fallback cannot rescue. (stored) director_eligibility — anchor: CP §1E/§2C, via the engine; obligation: the director is themselves eligible to direct for this product; consequence: an ineligible director means the fallback fails — verdict is not_permitted. (derived: canDeliver(director, product, provide_direction); per-product; never stored) supervision_arrangement — anchor: 3.2(b) / F2025L00354; obligation: arrangements reflective of the directed person's skills; consequence: a generic arrangement isn't the tailored supervision the clause requires. (stored) director_responsibility_acknowledged — anchor: CP §1E (oversight/guidance/QA para); obligation: the director's named accountability; consequence: unacknowledged responsibility leaves oversight unowned. (stored) review_cadence — anchor: 3.2-18 (PG) + 3.2(b) / F2025L00354; obligation: scheduled, not ad-hoc; consequence: an unscheduled relationship drifts unreviewed. (stored: configured, §12.3) reviews[] — anchor: 3.2-16, 3.2-18; obligation: work systematically reviewed + supervision level reassessed; consequence: an unreviewed relationship is a supervision-quality breach. The review is the discharging event (§11.6). (stored, dated, attributed)

Two fail-states (model §7.1):

Ineligible director → fallback does not rescue; verdict not_permitted, surfaced red, naming the missing §1E/§2C credential.
Overdue review → degrades standing and warns; does not block delivery (settled, Tim 2026-06-17). The person was lawfully under direction; an overdue review is a supervision-quality failure (3.2-18), distinct from credential-holding (3.2-1). Surface hard, don't auto-revoke. (Conservative alternative — overdue also drops the verdict — considered and rejected as conflation.)

12.2 Expert Engagement (Standard 3.3 — the actual experts standard)¶

Expert Engagement = (expert_person × training_product × director_person × [assessment_judgement?])

An expert is defined by exclusion (instrument definitions): engaged by the RTO, explicitly not a third party. Distinct entity from a trainer/assessor — a trainer's compliance is credential-driven, an expert's is supervision-driven (they may hold no T&A credential; legitimacy comes from relevant expertise + working under an eligible director). Reuses the direction spine, inverts the weight. Model: §7.2.

Binds to five clause obligations plus one practice-guide-grade practice (re-counted 2026-07-07, STANDARDS-ANCHOR-BLAST-RADIUS-01). The earlier "exactly three" was reasoned against the defective corpus's three-PI 3.3; the authorised expert surface is: relevance (3.3(c)(i)), engagement by reference to product/cohort + specific need (3.3(b)(i)–(ii)), work under an eligible director (3.3(c)(ii)), assess-alongside on judgement (3.3(c)(iii)), organisational oversight (3.3(c)(iv)) — all clause PIs; only documenting the assisted judgement is practice-guide Layer-3. Clause-anchoring does not change postures (clause-bound ≠ fail-closed, per the industry-currency precedent). Now a double worked instance of INSTRUMENT-QUALIFIED ANCHORS / ADR-049 §2 — mis-lettered then mis-counted.

Entity: pc_expert_engagements

expert_person — anchor: §4 Definitions (third-party exclusion (b)) / F2025L00354; obligation: the SME, not a third party; consequence: a third party recorded as an expert misclassifies the relationship. (stored) director_person — anchor: 3.3(c)(ii) → CP §1E; obligation: the expert works only under a §1E-eligible director; consequence: an unsupervised expert is outside the standard. (stored; reuses spine) director_eligibility — anchor: CP §1E, via the engine; obligation: the director is eligible for this product; consequence: ineligible director = engagement non-compliant. (derived, per-product) involves_assessment_judgement — anchor: 3.3(c)(iii) / F2025L00354; obligation: whether the engagement touches assessment judgement (triggers assess-alongside); consequence: an unflagged judgement engagement misses the assess-alongside gate. (stored: bool) assess_alongside_satisfied — anchor: 3.3(c)(iii) / F2025L00354; obligation: where judgement is involved, a qualified assessor assessed alongside; consequence: expert + judgement + alone = hard breach, fails closed red. (derived, conditional) organisational_oversight — anchor: 3.3(c)(iv) / F2025L00354; obligation: RTO oversight evidence over what the expert delivers; consequence: unoversighted expert delivery is outside the standard. (stored) — shape likely shares the direction review-event shape (model §12); named, not over-specced. relevance_assessment — anchor: 3.3(c)(i) / F2025L00354; obligation: experts have industry competencies/skills/knowledge/SME directly relevant to the product; consequence: unassessed expert relevance is an unmet 3.3(c)(i). (stored) engagement_justification — anchor: 3.3(b)(ii) / F2025L00354; obligation: engaged by reference to the product/cohort and in response to a specific need; consequence: an unjustified engagement is an unmet 3.3(b). (stored)

The sharp fail-closed gate (3.3(c)(iii)): stricter than the trainee case. A trainee cannot make assessment judgements at all; an expert can be involved — but only alongside a qualified assessor. Expert + judgement + alone fails closed red.

12.3 Configured policy values (deliberately not invented as constants — §14 item 6, model §12)¶

These are configured defaults, not hardcoded constants. Recorded as configuration so an RTO can set them and the law-vs-product layers stay clean:

Currency staleness thresholds (industry + T&A) — the 12-month value is a reasonable default, recorded as configured, not hardcoded. The instrument prescribes none.
Director capacity (3.2-17 "sufficient support to supervise") — a ratio/threshold that is an RTO-operational judgement.
Ad-hoc PD threshold — what counts as "systematic vs ad-hoc."
Engagement-event and PD-event type taxonomies.
Working-towards 2-year countdown (CP §1C) — the horizon is the instrument's; its surfacing belongs to the credential dimension (§5.1).

13. Validation eligibility (sourced from People, consumed by Record)¶

People is the source; Record/Observatory consume. Model: discharging event §11.7.

validator_eligibility — anchor: CP §3A + Standard 1.5 / F2025L00354 (non-TAE: validators collectively meet the requirement, at least one holds the CP §3A credential); CP §3B (TAE: at least one validator holds the product being validated or higher); obligation: the validation panel is collectively eligible; consequence: an ineligible panel invalidates the validation. (derived via the engine for each validator; the panel-level "collectively" check is Record's composition over People's per-person eligibility)

14. Reconciliation register — what changed from v0.3, and why¶

people-spec-v0_3 predates the model and diverges. This spec supersedes it wholesale. The redlines (model §13), as applied:

Anchor errors (headline) — RE-CORRECTED 2026-07-07 (STANDARDS-ANCHOR-BLAST-RADIUS-01). v0.3 anchored vocational competency + industry currency to "3.3" — substantially right: against the authorised instrument, vocational/industry competency is 3.3(a)(i) (§6) and industry currency 3.3(a)(ii) (§7.1), both for all persons delivering; experts are 3.3(b)–(c) (§12.2). The intervening "corrected to 3.2(b)/3.2(c)" moved them into 3.2 against the authorised text and is withdrawn — it rode the defective pre-rebuild corpus. 3.2 is credentials (a) / under-direction (b) / T&A CPD (c).
Delivery Assignment entity — added (§4). The biggest structural addition; v0.3 had no entity for the obligation to attach to.
Stored-vs-derived statuses — reconciled to derived. can_make_assessment_judgements (§5.3) and vocational status (§6.1) were stored enums in v0.3; both now derived.
CPD anchors — re-corrected 2026-07-07 (STANDARDS-ANCHOR-BLAST-RADIUS-01). The earlier "3.2 & 3.3 → 3.2(c)/3.2(d)" was inverted against the authorised instrument. Correct: industry currency → 3.3(a)(ii); T&A CPD → 3.2(c) (no 3.2(d) exists). §7 anchors updated accordingly.
Supervision record — reconciled. v0.3 stored the supervisor; director eligibility is now derived per-product through the engine (§12.1).
12-month threshold — recorded as configured default, not a hardcoded constant (§12.3).
Studio-spec redline — flagged, not resolved here (§9). Trainer Mapper verdict is People's, not Studio's — a studio-spec edit to action against that document.
Role field — single-valued now, four populations (§10.6, ADR-062); multi-hat is named-future / re-weighted-up, not current state. The single→multi change (a structural data-model change) is backlogged, not built.

One reverse-flow absorbed: v0.3's "how applied to practice" reflexive field was pulled up into the model's Currency Record and is kept (§7.1) — the one place v0.3 was sharper than the rigorous pass first was.

Downstream canon touchpoints (for Tim — not spec body): the v0.3 canon checklist (glossary T4B entry, ADR-042 consequences, ADR-020 fourth-tier note, Admin→Team ownership) carries forward unchanged where not yet actioned; the §9 studio-spec redline is new.

15. Obligations coverage map (the acceptance check)¶

The method requires the spec to be complete only when every line of people-00-obligations is answered by a modelled, clause-bound surface, or carries a principled deferral. The map:

Obligation	Answered by
3.1-1 maintains records of credentials/competency/currency	The register + §5–§7 (the record is this)
3.1-2 workforce planning sufficiency	Evidence-hold — the workforce picture (§8); planning is an RTO act
3.1-3 induction/PD/performance arrangements	Evidence-hold — PD records (§7.2); arrangements are RTO-operational
3.1-4 supports currency maintenance	Evidence-hold — currency records (§7); support is an RTO act
3.2-1 holds credentials for the activity	The engine (§3)
3.2-2 evaluated against activity × product (incl. TAE level)	The engine routing + credential check (§3.4, §3.5)
3.2-3 under-direction where not full credential	Under-direction fallback + Direction Relationship (§3.5, §12.1)
3.2-4 working-towards evidenced, 2-yr, no judgement	Working-towards fields + judgement block (§5.1, §5.3)
3.2-5 credentials authenticated	The authentication gate (§5.2)
3.2-6 no tasks beyond credential scope	The engine's negative case (§3.5, §3.6)
3.2-7 working-towards makes no judgements	`can_make_assessment_judgements` derived (§5.3)
3.2-8 vocational competency to level	Vocational competency dimension (§6)
3.2-9 unit-level, not qual-level	Unit-level evaluation (§6, opening)
3.2-10 maintains current vocational-area knowledge	Industry currency (§7.1)
3.2-11 dated, evidenced engagement event	`engagement_event` + `evidence_ref` (§7.1)
3.2-12 reviewed regularly after onboarding	`review_cadence` + `staleness` (§7.1)
3.2-13 ongoing PD for T&A currency	CPD Record (§7.2)
3.2-14 systematic, not ad-hoc PD	`pattern` derivation (§7.2)
3.2-15 supervision reflective of skills	`supervision_arrangement` (§12.1)
3.2-16 practice assured, work systematically reviewed	`reviews[]` (§12.1)
3.2-17 supervisor adequately skilled + capacity	`director_eligibility` + director capacity (§12.1, §12.3)
3.2-18 reviewed for supervision-level adjustment; overdue surfaced	`reviews[]` + overdue degrades-and-warns (§12.1)
3.3-1 expert SME relevance	`relevance_assessment` + expert record (§12.2)
3.3-2 engaged by reference to a specific need	`engagement_justification` (§12.2)
3.3-3 only under an eligible director	`director_person` + `director_eligibility` (§12.2)
3.3-4 assess alongside where judgement involved	`assess_alongside_satisfied` (§12.2)
3.3-5 assisted judgement documented	Discharging event §11.10 (§12.2)
3.3-6 organisational oversight	`organisational_oversight` (§12.2)
V-1 validators collectively eligible (non-TAE)	`validator_eligibility` (§13)
V-2 TAE-product validator holds product-or-higher	`validator_eligibility` TAE case (§13)
Self-assurance A/P questions (C-SA1–7, 3.1-SA4/5)	Read surfaces over §5–§8 + §12; the A/P set feeds Observatory (Phase 3). The E-class questions are external by design.

Coverage: every Core obligation is answered by a clause-bound surface in §3–§13. Evidence-hold obligations (3.1-2/3/4) are answered to the boundary of People's role (it holds the evidence; the RTO performs the act), per the obligations checklist's own classification. No Core line is unanswered; no line carries an un-principled gap.

The People spec, whole. Move 4 of the Legislation-to-Tile Method. Derived from people-01-model, answering people-00-obligations, superseding people-spec-v0_3. Grounded in F2025L00354, the Credential Policy (10 Dec 2025), and rto-nrt-db substrate, read against the bytes 2026-06-17. The model is the why; this is the what; the build gates are next.

§16 — The People access model (Round-1 settled)¶

Settled product decisions from the Round-1 build (entry → approve → appears; revoke → stays). Captured provisionally in session 2026-06-27, corrected against the walked build and promoted to canon at Round-1 close, 2026-06-28 (BRIEF-PEOPLE-ROUND-1-01).

People is not a flat staff registry. Despite the name, People is a store of credentialed people who operate in the compliance workspace, plus the resources that support it. The organising principle is compliance role, not system access. TAE4 is the linchpin — the switch between "carries a full four-dimension compliance record" and "appears as a resource line / differently-shaped record."

The librarian model (the access model in one image). People is a bookcase of vetted resources. The T4 admin is the librarian — the sole authority who shelves, vets, and removes records; all others are read-only. The only entry into People is a T4 grant. Anyone can take a book off the shelf and use it (read the compliance picture); no one but the librarian edits the books. This is why People has no write affordances for non-T4 users, and why the grant is the act of shelving.

Four populations, banded by compliance weight:

Trainers / assessors (hold TAE4) — the primary population; full four-dimension compliance record. What People is for.
Experts / industry specialists — appear, but different: may be highly credentialed in their field (doctor, professor) yet do not hold TAE4; legitimacy is expertise-under-direction, not T&A credential. Supervision-driven record (pc_expert_engagements), not credential-driven.
Support / clerical / office — part of the resource picture ("who we have available"), but no compliance dimensions; appear as name + position/title only.
Admins (management) — the accountable party (accountability to ASQA sits with management), not a teaching obligation. Always appears, wafer-thin — name / role / contact, not a full compliance record. (The earlier "appear-as-name vs absent" open question is closed: the accountable party cannot be invisible in the compliance record, so management appears — thin, never absent. ADR-062, depth-of-record-follows-depth-of-obligation.)

Revoked persons stay — revocation is audit evidence, never expunged. A revoked/deactivated person remains visible in People, shown revoked + when. Audit rationale: a five-yearly audit may need a trainer who delivered for two years then left — they were part of the compliance picture during delivery, so the record must persist. Show-as-revoked, never remove. Ties to ADR-023 sentinel posture / deactivate-not-delete. This is a correctness rule, not a Round-2 refinement.

Lifecycle gate (BUILT + WALKED — BRIEF-PEOPLE-ROUND-1-01 §C, 2026-06-28). The gate is app-level, in persons/route.ts GET: it reads pc_persons WHERE org_id, calls internal-api getMembers over the INTERNAL_API service binding, and joins in app code — not a SQL cross-db join (HARD SEPARATION held). It gates on the member's status, not tier:

Appears: any member with status:"active" — any membership_type, including admin_only (pure-T4). Tier is out of the appearance decision entirely (tier still drives read-redaction per ADR-061; it does not gate appearance).
Stays-marked: status:"revoked" → the row stays, rendered "Revoked {date}" (audit evidence, ADR-023 deactivate-not-delete).
Hidden: no active-or-revoked member match (pending invite / no grant) → dropped. A pending person remains visible in Teams, not People.

After schema cleanup there is no NULL-user_id case (0 orphans, dev+prod) — a NULL is treated as a regression (logged + dropped), not a state to handle.

New hard runtime dependency: People → internal-api. The list can no longer render from workspace-db alone; if getMembers can't be resolved the endpoint fails closed (502), rather than showing an unfiltered or silently-empty list. This is the operational trade for the gate — recorded as such.

(Round-1 correction: the earlier capture stated this gate was already live and reused via getMembers. The build proved otherwise — the gate did not exist on the People surface; it was built in §C of this round. This paragraph reflects what is now true and walked.)

The colour / grouping system is OWED (Round 2, not yet designed). The four-population banding needs a visual grouping/colour system to distinguish the populations. This is an open design question — not yet decided — drawn from SIGNAL-LANGUAGE canon when designed in Round 2. Do not invent it here; this line records that it's owed.

Schema legibility (governance principle, candidate for standing-rules.md). Every table earns its place; nothing sits empty or unreferenced; the schema should read as a living system a human or a future instance can understand at a glance. Debris is removed, not left dormant. (Established 2026-06-27.)

Studio seam consequence (flag for studio-spec, not actioned here). Revoking a trainer tied to a delivery assignment in Studio creates a delivery/assessment gap — the written course loses the trainer mapped against its units. People holds the verdict; Studio consumes it; so a revoked trainer should surface as a delivery risk in Studio. A studio-spec seam note, to action when the People↔Studio seam is built.

Promoted to canon at Round-1 close (2026-06-28). The settled product decisions are firm; the lifecycle gate is built and walked (status-based, app-level, admin_only appears, People→internal-api dependency recorded); the colour/grouping system remains explicitly not-yet-designed (Round 2, SIGNAL-LANGUAGE).