People — Model¶

The legislation-grounded reasoning for the People tile — the why. This is move 3 of the Legislation-to-Tile Method: the obligations checklist (people-00-obligations, move 2) said what must be demonstrated; this models the tile as the answer, every entity grounded in the instrument bytes. The spec (people-02-spec, move 4) derives from this document and points back to it; it does not restate it.

This document is whole: it covers the credential evaluation engine, all four compliance dimensions, both relationship entities (direction, expert), the four-dimension display, and the Studio consume seam. Where a structural call belongs to the build rather than the model (table shape, presentation), it is flagged for the spec, not decided here.

Substrate grounding (verified against bytes 2026-06-17): the list is rto-nrt-db (UUID 1249760d-070a-43f8-81d7-de462b626cdf), 2.9 GB, regulated substrate under the HARD SEPARATION RULE. Tables the engine reads: qualifications, units, qualification_units, qualification_packaging_rules, skill_sets, skill_set_units. The four component classes are real columns on units: elements, performance_criteria, performance_evidence, knowledge_evidence, assessment_conditions, plus supersedes/superseded_by and training_package_code. The KN sacred rows (15,128) live in units as kn_* columns — the engine reads only, never writes.

1. The engine in one line¶

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

The engine evaluates whether a person may lawfully perform an activity for a training product. It computes the acceptable-credential set from the Credential Policy for that (activity, product-type), checks whether the person's held credentials intersect it, and — failing that — whether a valid under-direction arrangement rescues it. The verdict is derived, never stored; it is recomputed when held credentials, the assignment, the director link, or the underlying policy/list version changes.

The four verdicts are distinct and the distinctions are load-bearing: - permitted — held credentials satisfy the requirement directly. - permitted_under_direction — held credentials satisfy a working-towards/under-direction fallback with a valid eligible director. - not_permitted — evaluated, and the requirement is not met. A negative verdict. - insufficient_data — cannot be evaluated yet (e.g. a stub person with no compliance record). Distinct from not_permitted: absence of data is not a negative verdict. Surfaced by the Studio seam's Never Block constraint (§9); load-bearing across tile boundaries.

1A. The foundational negative rule: the engine evaluates held credentials, never role tags¶

The engine looks at what credentials a person holds and whether they intersect the required set. 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 — a way to view the workforce — never an input to the verdict.

Worked example (the failure mode this rule prevents). A two-person RTO. One person is tagged "Management" and also genuinely holds a Cert IV T&A and delivers. If role were treated as a gate — "only evaluate people tagged Trainer/Assessor" — the engine would scan the workforce, see the deliverer tagged Management, skip them, and return "nobody can deliver this." A false not_permitted, caused entirely by a presentation-layer tag the engine should never have consulted. In a compliance product this fails in the alarming direction — it tells a compliant RTO they are non-compliant, which is worse in trust terms than the reverse.

This is the same discipline the whole model holds: the verdict derives from evidence (held credentials), never from a stored label. Role-as-gate is the stored-status error wearing a different hat. A person tagged Management who holds a Cert IV T&A is exactly as deliverable as one tagged Trainer. The hat is how you look at them; the credential is what they can do.

Flagged to the spec (move 4), not decided here: the multi-hat presentation (non-exclusive role views — a person appears in every view their hats earn), and the possible role-field restructure (the existing spec's role field reads as single-select, which would prevent recording a multi-hat person correctly — this may be a structural data-model change, not only a presentation one).

2. What the engine reads — "the list" and "the law" (owned by neither tile)¶

The credential obligation is judged against national reference data the Crown owns and RTOpacks mirrors faithfully. RTOpacks authors none of it. Two bodies of reference data, both in rto-nrt-db, both read-only to the tiles (Pith), both under the HARD SEPARATION RULE:

The list — the national training register (what exists, what's made of what):

Read	Table in `rto-nrt-db`	Used for
Qualifications	`qualifications`	product identity, AQF level
Units of competency	`units`	unit identity; the four component classes
Qual → unit composition	`qualification_units`, `qualification_packaging_rules`	unit-level vocational competency
Skill sets + composition	`skill_sets`, `skill_set_units`	skill-set products
Training-package membership	`units.training_package_code`, `qualifications` + classification	TAE-ness (Fork 2)
Supersession lineage	`units.supersedes`, `units.superseded_by`	equivalence evidence

The law — the Credential Policy decision table: the platform-level decision table mapping (activity, product-type) → acceptable-credential set. Versioned to the instrument (v. 10 Dec 2025). Every RTO judged against the identical table. Held at platform level. The engine reads it; never authors it.

Principle (Fork 1): People keys on TGA national identity (the code). It does not own product composition and does not depend on Studio for it — both People and Studio read composition from the same rto-nrt-db list. People stays evaluable for any national product whether or not Studio has built content for it.

3. The entity the engine evaluates: the Delivery Assignment¶

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.

Delivery Assignment = (person × training_product × activity)

activity — the Credential Policy enum: deliver_and_assess, assess_only, deliver_assess_under_direction, provide_direction, validate.
training_product — a TGA identity (qual / skill set / unit), resolved against the list for level, composition, and TAE-membership.
person — brings held credentials (evidenced) and, for under-direction cases, a director link.

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.

4. The evaluation, by activity and product-type¶

4.1 Section 1 vs Section 2 routing (Fork 2 — TAE)¶

The engine reads two facts from the list — is this product in the TAE training package? and what is its AQF level? — and routes:

Non-TAE product → Credential Policy Section 1 (1A deliver+assess, 1B assess-only, 1C working-towards, 1D under-direction, 1E direction).
TAE product → Credential Policy Section 2 (2A deliver, 2B under-direction, 2C direction), level-aware: "the qualification or skill set at least to the level being delivered" (2A). Faithfully held carve-out: to deliver the Cert IV TAE itself (TAE40122 or successor), a Diploma-level TAE qualification is required — the trainer-of-trainers rule.

Same canDeliver() shape; TAE-ness and level are reads from the list, not judgements.

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

Compute acceptable-credential set from the policy table for (activity, product-type [, level if TAE]).
Intersect with the person's held, authenticated credentials.
Non-empty → permitted.
Empty → check under-direction fallback (CP §1C/§1D + §1E, or §2B + §2C for TAE): 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 to evaluate (stub) → insufficient_data (§1, §9).
Authentication gate: a credential counts only if document-level evidence is attached and verified — never a bare code.
Judgement block: working-towards / under-direction states carry cannot make assessment judgements as a negative capability on the verdict.

5. Vocational competency: two modes (Fork 3)¶

Vocational competency (anchored 3.3(a)(i) / F2025L00354) is evaluated at unit level — aligned to all units the person delivers/assesses, read from qualification_units, never assumed from the qualification. Two satisfaction modes:

5.1 Matched (computable)¶

The person holds a qualification/skill set/unit from the list that covers the unit. The engine reads held-vs-required and returns satisfied. No human judgement.

5.2 Asserted-equivalent (structured record; human determination)¶

No exact holding, so a gap-analysis mapping matrix is required. The highest-audit-exposure surface in People.

Structure: - 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: 100% or incomplete. - Each requirement carries a fact-to-requirement triple: 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. - Evidence types (admissible, each verified): authenticated alternative/superseded qualifications (with syllabus mapping); verified workplace artefacts; attested third-party verifications (stat-decs / supervisor references); active regulatory/industry licences. Superseded-unit evidence checks units.supersedes/superseded_by. - Currency is mandatory and must address gaps introduced by technology/regulation change. Ties to the industry-currency dimension (§6) — the same Currency Record, read here as backing evidence. - Sign-off — dated, attributed, competent-authority level (Academic Manager). The discharging event.

Two non-negotiable engine behaviours: 1. Fail-closed default. The legal burden of proof is on the RTO; the presumption is not credentialled until demonstrated. An incomplete equivalence mapping is red, not amber. Default not_satisfied until the matrix is 100% complete and signed. 2. Never computes sufficiency. The engine reads requirements, holds the evidence per requirement, checks completeness. It does not decide the mapping is sufficient — that is the signed human determination. Output is "equivalence asserted, mapping complete/incomplete, signed by X on date Y," never "equivalent: yes."

Anchor note (a worked instance of the concordance problem). Vocational/industry competency — and so this equivalence determination — anchors to 3.3(a)(i) / F2025L00354 (industry competencies relevant to, and at least to the level of, the training product, for all persons delivering). Two external legal-standard sources cited it — one to the superseded 2015 cl.1.13–1.16 (dead instrument), one to a bare 3.3 — which, against the authorised instrument, was substantially right (industry competency is 3.3(a)(i)). The "3.2(b)" error was this note's own prior 'correction', not the sources' citation; 3.2(b) is the under-direction PI, not competency. The real future-concordance entry is 2015 cl.1.13–1.16 → 2025 Standard 3.3(a)(i) / F2025L00354 — no Credential Policy in the anchor: the CP prescribes T&A credentials (and expert direction), not vocational-competency equivalence machinery; its only equivalence provision is Cert IV TAE (§2B), a different obligation. (Corrected 2026-07-07, STANDARDS-ANCHOR-BLAST-RADIUS-01. The prior "3.2(b) + Credential Policy" cite rode the defective pre-rebuild corpus, which placed competency inside 3.2's credential neighbourhood; retaining "+ CP" would mint a false incorporation of the same defect class. The equivalence method is described by the ASQA practice guide, Layer 3 — cited there, never the CP.)

6. The four compliance dimensions¶

Every person × Delivery Assignment resolves to four independent dimension states. Never collapsed into one score: a person can be green on credentials and red on industry currency; all four surface separately. The critical distinction — two gate delivery, two flag it:

Dimension	Anchor	Source	State	Fails closed?
Credential	3.2(a) / F2025L00354 + CP	The engine (`canDeliver`)	permitted / under-direction / not-permitted / insufficient-data	Yes
Vocational competency	3.3(a)(i) / F2025L00354	Engine Fork 3	matched / asserted-equivalent (complete+signed vs incomplete)	Yes
Industry currency	3.3(a)(ii) / F2025L00354	Currency Record (§6.1)	current / ageing / stale	No
T&A currency	3.2(c) / F2025L00354	CPD Record (§6.2)	current / ageing / stale + ad-hoc-pattern flag	No

A red credential means cannot deliver; a red currency means deliver, but flagged. This difference in kind is the single most important thing the four-dimension surface communicates (§8).

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

Currency Record = (person × vocational_area × dated_evidence_of_engagement)

PI c requires currency in the vocational area of what the person delivers/assesses — tied to the products on their assignments, not a generic badge. The instrument prescribes no cadence, method, or interval ("maintains current"); the recurrence/staleness requirements are practice-guide Layer-3, held as self-assurance-grade, not clause-level.

Field	Anchor	Note
`person × vocational_area`	3.3(a)(ii) / F2025L00354	resolves against assignment products (`rto-nrt-db`)
`engagement_event` (dated, typed)	3.3(a)(ii) / F2025L00354	a concrete act, not self-certification
`evidence` (authenticated)	3.3(a)(ii); PG known risk	document-level, mirrors credential authentication
`currency_date`	3.3(a)(ii) / F2025L00354	currency is a point in time
`how_applied_to_practice`	3.3(a)(ii); absorbed from spec v0.3	the reflexive field that turns a log into evidence — mandatory; named into the model from the early spec
`review_cadence` (self-assurance)	PG known risk (not a PI)	recurring, not once-at-onboarding
`staleness` (derived)	PG known risk	current / ageing / stale

Posture: does not fail closed to not_permitted — a currency lapse is a 3.3(a)(ii) quality concern surfaced, not a credential revocation (keep distinct obligations distinct, surface hard, don't auto-revoke). One inherited exception: where a currency lapse touches an asserted-equivalent vocational competency (Fork 3), the equivalence determination's own fail-closed default applies — there, currency is a mandatory completeness component. The dimension doesn't fail closed; the determination it feeds does. One record, two consumers, two postures.

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

CPD Record = (person × t_and_a_practice × dated_PD_evidence)

The Currency Record's second instance — same shape, subject swapped from vocational area to T&A practice. 3.3(a)(ii) is currency in what you deliver (industry practice); 3.2(c) is currency in how you train and assess (T&A CPD, this instance).

The one genuine difference: a pattern derivation over the PD log. "Ongoing" is the clause word (3.2(c)); "systematic, not ad-hoc, not audit-clustered" is the practice-guide sharpening (held as self-assurance). Five PD events all dated the month before an audit pass a naive recency check but fail the actual obligation — the pattern field catches that.

Field	Anchor	Note
`person × t_and_a_practice`	3.2(c) / F2025L00354	per person
`pd_event` (dated, typed)	3.2(c) / F2025L00354	a concrete PD act
`evidence` (authenticated)	3.2(c); PG known risk	document-level
`pd_date`	3.2(c) / F2025L00354	point-in-time
`staleness` (derived)	3.2(c) / F2025L00354	current / ageing / stale
`pattern` (derived, self-assurance)	PG known risk (not a PI)	systematic vs ad-hoc/audit-clustered

Posture: does not fail closed; no equivalence consumer (doesn't feed Fork 3), so no second-consumer exception. Purely a dimension state — cleaner than industry currency in that one respect.

The spec's three CPD types (TA/VC/VET) 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): the earlier "corrected to 3.2(c)/3.2(d)" itself inverted — it moved industry currency into 3.2 against the authorised instrument, where industry currency sits at 3.3(a)(ii) and T&A CPD at 3.2(c) (there is no 3.2(d)). The spec's original "3.3" instinct for industry currency was nearer right.

7. The relationship entities¶

7.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. Director eligibility is canDeliver(director, training_product, provide_direction) → permitted — same engine, same derived-never-stored posture, per-product (a director eligible for one product is not automatically eligible for another).

Field	Anchor	Note
`directed_person` → assignment	3.2(b) / F2025L00354 + CP §1C/§1D	the person lacking full credential
`director_person`	CP §1E (non-TAE) / §2C (TAE)	holds the direction credential
`director_eligibility` (derived)	CP §1E/§2C, via the engine	per-product, never stored
`supervision_arrangement`	3.2(b) / F2025L00354	reflective of the directed person's skills
`director_responsibility_acknowledged`	CP §1E (oversight/guidance/QA para)	the director's named accountability
`review_cadence`	3.2-18 (PG); 3.2(b) / F2025L00354	scheduled, not ad-hoc
`reviews[]` (discharging events)	3.2-16, 3.2-18	work reviewed; supervision level reassessed

The discharging event is the review, not the link (read off the obligations checklist: 3.2-16 work systematically reviewed; 3.2-18 supervision level reassessed, overdue surfaced).

Two fail-states: - Ineligible director → under-direction fallback does not rescue; verdict is not_permitted. Surfaces red, naming the missing §1E/§2C credential. - Overdue review → degrades standing and warns; does not block delivery (settled decision, 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.)

7.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 (§4 Definitions / F2025L00354 — the third party definition excludes 'experts engaged by the organisation', exclusion (b)): 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, their legitimacy coming entirely from relevant expertise + working under an eligible director. Reuses the direction spine, inverts the weight (the expertise is the asset, the direction is the control).

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 3.3 expert surface is richer: relevance (3.3(c)(i)), engagement by reference to product/cohort and specific need (3.3(b)(i)–(ii)), work under an eligible director (3.3(c)(ii)), assess-alongside where judgement is involved (3.3(c)(iii)), and organisational oversight (3.3(c)(iv)) are all clause PIs; only documenting the assisted judgement remains practice-guide Layer-3 (self-assurance, not a clause gate). Clause-anchoring these does not change their postures (clause-bound does not force fail-closed — the industry-currency precedent). The count moved 3 → 5-plus-1; it remains a worked instance of INSTRUMENT-QUALIFIED ANCHORS / ADR-049 §2 — now a double one, the defect having first mis-lettered and then mis-counted.

Field	Anchor	Note
`expert_person`	§4 Definitions (third-party exclusion (b)) / F2025L00354	the SME, not a third party
`director_person` (reuses spine)	3.3(c)(ii) → CP §1E	only under a §1E-eligible director
`director_eligibility` (derived via engine)	CP §1E	per-product
`involves_assessment_judgement` (bool)	3.3(c)(iii) / F2025L00354	triggers assess-alongside
`assess_alongside_satisfied` (derived, conditional)	3.3(c)(iii) / F2025L00354	a qualified assessor assessed alongside
`organisational_oversight`	3.3(c)(iv) / F2025L00354	RTO oversight evidence
`relevance_assessment`	3.3(c)(i) / F2025L00354	expert industry competencies/SME directly relevant to the product
`engagement_justification`	3.3(b)(ii) / F2025L00354	engaged in response to a specific need

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 = hard breach, fails closed red.

8. The four-dimension display¶

A read surface, not an entity — the rendering of §6 against the engine. Each person × assignment shows four dimension states side by side, never collapsed. The display's defining job: 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 that renders all four identically gets this wrong.

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, the matrix is the engine's natural output shape — a query over assignments, no new modelling.

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).

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

Studio owns: the assignment intent and the rendering (the canvas compliance question, e.g. "does this trainer have the currency to deliver this unit?" — which is canDeliver by another name).
People owns: the verdict (the engine), 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, owned by neither). This is why Studio can ask about a unit People has never seen.

Graceful degradation (Studio's Never Block principle): - 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. Absence of data is not a negative verdict. - Person doesn't exist → Studio creates the stub; no People call until it has data.

This seam is what surfaced the insufficient_data verdict (§1): within People's own surfaces an unevidenced person was just red; across the seam, under Never Block, "can't tell you yet" must be distinct from "forbidden."

Studio-spec divergence flagged (move-4 redline): 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.

10. The discharging events (the audit ledger)¶

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

Credential authored + authenticated — a credential with verified document evidence.
Delivery assignment created/changed — person × product × activity asserted (obligation attaches).
Vocational competency matched — computed satisfaction against an assignment's units.
Equivalence sign-off — dated, attributed competent-authority determination on a complete matrix.
Industry-currency event recorded — dated, typed, evidenced (also read by the equivalence engine where it backs an assertion).
Direction review performed — dated, attributed, carrying work-quality assurance + supervision-level determination. (Relationship creation attaches the obligation; the review discharges it.)
Validator eligibility asserted — for the validation activity (read by Record).
PD event recorded — dated, typed, evidenced.
Expert engagement asserted — expert × product × director, with the judgement flag (3.3(b)).
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.

Ten discharging events — matching the move-2 checklist's forecast of "a dozen, as predicted." Read off the obligations one cut at a time, never guessed. Landing near a dozen (not twenty) is confirmation the discharging-event discipline works: the events fell out of the obligations, exactly as NO ORPHAN GRAINS requires. Over-capture would have signalled an error; it didn't.

11. What hardens from this model¶

Engine: canDeliver(person, product, activity) → four verdicts (incl. insufficient_data); derived, never stored.
Role never gates evaluation (§1A) — the engine reads held credentials, never role tags; role is presentation only.
List grounding: rto-nrt-db read substrate; People keys on TGA identity; owns/authors none of it.
Fork 1: composition read by both tiles, owned by neither; People independent of Studio for it.
Fork 2: TAE is a read (membership + level) → Section 2 level-aware sub-table incl. Cert-IV-needs-Diploma carve-out.
Fork 3: vocational competency = matched (computed) | asserted-equivalent (100%-complete matrix, fact-to-requirement triples, mandatory currency, human sign-off, fail-closed, sufficiency never computed). Anchored 3.3(a)(i).
Four dimensions: credential + vocational competency gate; industry + T&A currency flag. The display communicates the difference in kind.
Direction relationship: director eligibility derived per-product through the engine; discharging event is the review; overdue review degrades-and-warns, doesn't block.
Expert engagement: distinct entity, supervision-driven; five clause obligations + one PG-grade practice (re-counted 2026-07-07); assess-alongside (3.3(c)(iii)) is the sharp fail-closed gate.
Studio seam: backend contract; Studio owns intent + rendering, People owns the verdict, neither owns composition; degrades to insufficient_data under Never Block.
Entity spine: the Delivery Assignment.
Ten discharging events (§10).

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

Multi-hat presentation — non-exclusive role views (Management view / Trainer-Assessor view as lenses over one workforce; a person appears in every view their hats earn). The safety-critical half (engine never consults role) is settled at §1A; the presentation half is the spec's.
Role-field restructure — the existing spec's role reads as single-select, which cannot record a multi-hat person; may be a structural data-model change, not only presentation. Flagged.
Configured policy values, deliberately not invented as model constants: staleness thresholds (industry + T&A currency — the spec's 12-month is a reasonable default, recorded as configured, not hardcoded); director capacity (3.2-17 "sufficient support to supervise" — a ratio/threshold that is an RTO-operational judgement); ad-hoc PD threshold; engagement-event and PD-event type taxonomies.
Oversight evidence shape (3.3(c)(iv)) — likely shares the direction review-event shape; named, not specced.
Expert person-shape — distinct entity, but separate table vs typed person-record is a structural call.
Working-towards 2-year countdown (CP §1C) — belongs to the credential dimension's currency surfacing.

13. Spec reconciliation register (the move-4 redline inputs)¶

The existing people-spec-v0_3 predates this model and diverges. Itemised for the spec rewrite:

Anchor errors (RESOLVED 2026-07-07, STANDARDS-ANCHOR-BLAST-RADIUS-01). This headline redline was itself inverted and is withdrawn. It read: "spec anchors vocational competency and industry currency to '3.3'; correct is 3.2(b)/3.2(c); 3.3 is experts." Against the authorised F2025L00354 that is backwards — vocational/industry competency is 3.3(a)(i) and industry currency 3.3(a)(ii) (3.3(a) covers all persons delivering; experts are 3.3(b)–(c)); 3.2(b) is under-direction, and there is no 3.2(c) for competency. The spec's original "3.3" was correct; the redline "correcting" it to 3.2 rode the defective pre-rebuild corpus. Anchors are now corrected to the authorised text throughout this doc.
No Delivery Assignment entity. Spec allocates competency "per training product" but never names the assignment as the entity the obligation attaches to. Biggest structural addition.
Stored-vs-derived statuses. Spec stores can-make-assessment-judgements on the credential record and vocational status (Verified/Pending/Gap/Expired) as enums; the model derives both. Reconcile to derived.
CPD anchors — industry currency → 3.3(a)(ii); T&A CPD → 3.2(c) (corrected 2026-07-07; the earlier "3.2(c)/3.2(d)" inverted — industry currency sits at 3.3(a)(ii), and there is no 3.2(d)).
Supervision record is sound but stores the supervisor rather than deriving director eligibility per-product through the engine. Reconcile.
12-month threshold recorded as the configured default, not a hardcoded constant.
Studio-spec (separate doc): Trainer Mapper verdict is People's, not Studio's.
Role field — single-select → multi-hat (§12).

One reverse-flow already absorbed: the spec's "how applied to practice" reflexive field (better than the rigorous pass first had) is pulled up into the Currency Record (§6.1).

The People model, whole. Move 3 of the Legislation-to-Tile Method. Grounded in F2025L00354, the Credential Policy (10 Dec 2025), and rto-nrt-db substrate, all read against the bytes 2026-06-17. The spec (people-02-spec, move 4) derives from this document and points back to it.