✓ RATIFIED — READY TO FILE. Draft 1 ratified by Tim 2026-07-09, same session, on full-bytes read. The six [DESIGN CALL] flags (collected at §12.0) are confirmed as spec defaults; the §3.3 delivery-leg-only keyhole precision is ratified with the whole. Drafted under the same-day draw-order ruling (claude/ruling-2026-07-09-tas-02-draw-order.md); ratification brought forward by Tim at approval. Not yet committed; the TAS build stays behind LLND and RPL. Where this spec and the model appear to differ, the model governs the why and this spec governs the what — a conflict is a defect to reconcile, not a choice.

TAS — Spec¶

Move 4 of the Legislation-to-Tile Method for the TAS tile. The obligations (tas-00) said what the RTO must demonstrate; the model (tas-01) modelled the tile as the answer; this spec derives the buildable surface from that model and binds every regulated field to its clause. It points back to the model and does not restate it.

The single load-bearing fact, carried whole: no standard in F2025L00354 names a training and assessment strategy — the document is testimony, not compliance (tas-01 §1, doctrine §4). The tile is therefore built as the author of reasons and composer of claims — never a custodian of facts held elsewhere (R1). And the foundational rule beneath every table below: structural truth only (tas-01 §1A) — there is no code path in this spec that asserts a substantive judgement. The signer's ratification is the RTO's act; the keyhole demands a key exist and never judges it.

What this spec originates vs consumes. The per-student pacing overlays (placement, credit) live on the shared candidate/intake spine (intake-pipeline-01-model, R6/M12) — this tile states the rules and consumes the seam (§4.3, §14). The consultation loop is Studio substrate (R7) — this tile consumes dispositions (§6). Assurance-evidence custody is Record's, held in-tile interim under the phasing rider (§8.4). Recognition posture is RPL-tile state, reference-rendered (§5.5). What this spec originates: the TAS data domain (§2), the strategy lifecycle wired to the ten discharging events (§3), the substrate section schemas (§4), the reference-layer read contracts (§5), the review register (§6), the variance surface (§7), the resource register surface and interim custody schema (§8), the three renders and the first-read ledger (§9), the composed-claims surfaces (§10), and the interpretive-position packaging (§11).

1. The build in one line¶

Strategy = (training product × cohort × mode-set) as delivered by this RTO → authored substrate sections + live references → ratify-block { every named slot permitted | keyed | unnamed } → sealed baseline vN, signed by the RTO-named signer → three pinned renders + a ledgered first-read → accreting review inputs + variance records → reasoned closure → vN+1.

The tile's primitive is the Strategy (tas-01 §1): product × cohort × mode-set as delivered by this RTO, versioning on local decisions only — a package version event is a review input (§6), never an edit to a baseline. Granularity is the RTO's design decision, recorded not prescribed (§12.1). The baseline is the sealed artefact including its reasoning; renders are generated, pinned to (baseline version, substrate read time), and reproducible as at a date (R3; §9).

2. The data domain¶

Per the MANDARIN taxonomy, the HARD SEPARATION RULE, and the ops-db invariant (customer surfaces bind ops-db never — standing rule, amended 2026-07-04). Names follow cloudflare-naming-canon; the boundaries are the model's (tas-01 §16) and do not move with naming.

2.1 Stores¶

Store	Canonical name (Peel/pair)	Class	Holds
TAS tile domain	`rtopacks-tas-prod` / `rtopacks-tas-dev` (D1)	Peel	Strategies, baselines (sealed, versioned, with reasoning), working substrate sections, provision-design entries, signer naming records, assignment slots + verdict snapshots, keyhole records, review register, variance records, render pins, first-read ledger, interpretive-position adoptions, the org staffing story, interim evidence-item metadata (§8.4), the TAS event ledger
TAS render archive	`rtopacks-tas-renders-prod` / `-dev` (R2)	Sealed custody	Issued renders (auditor / public-info / first-read-pinned delivery briefs), digest-sealed, immutable; amendments are new objects; retention floor = audit window
TAS interim evidence custody	`rtopacks-tas-evidence-prod` / `-dev` (R2)	Sealed custody — interim, phasing rider (§8.4)	Assurance-artefact bytes (certificates of currency, third-party agreements, walkthrough records, placement risk documents) pending Record deployment; migrates to Record wholesale as data, not design
Pith	`nrt-corpus-ref` (D1)	Reference	The bar: products, composition, component classes incl. `assessment_conditions`, supersession lineage. Read-only always; KN sacred
People / Studio / Record / RPL	peer tiles	—	Consumed through contracts and state reads, never through their tables (§5)

[DESIGN CALL — store naming] Spec default: rtopacks-tas-*. "TAS" is a sector-established acronym, but it is also the tile's working name ("names earn the tap" — tas-00 frontmatter), and the canon prefers plain words. The alternative is rtopacks-strategy-* (canon-pure, name-tap-neutral). Per canon Principle 8, renaming is metadata, not migration — so the cheap call is rtopacks-tas-* now, renamed if the tile's earned name differs. Ratify the default or substitute.
[DESIGN CALL — render sealing] Renders must be reproducible as at a date (R3). The substrate half of the pin (baseline version) is re-derivable; the reference half is not — other tiles' state moves after the read. Spec answer: an issued render seals as bytes in the render archive, with its pin record (§2.2 tas_render_pin) carrying the artefact digest and a sealed reference-state snapshot. Reproducibility is thereby held as custody, not re-computation. This adds the R2 pair above. Ratify.

Customer-facing strategy surfaces read the Pith and the tile's own Peel stores; ops-db is never bound. People is consumed through its contract (§5.1), never through its tables. The TAS event ledger's exact substrate (tile-domain table vs a shared audit store) binds at build against the resource inventory, mirroring rpl-02 §9.3; the content is the model's (tas-01 §17).

2.2 The core tables (`rtopacks-tas`)¶

Each regulated field carries its clause trace; the consolidated register is §13. Below is the shape and the load-bearing regulated fields.

tas_strategy — the entity spine (tas-01 §1). Product × cohort × mode-set as delivered by this RTO. - target_tga_id → Pith (national product identity; composition resolved from the list) - cohort_label — short human label; the full premise is the cohort-premise section (§4.1) - mode_set[] — one or more modes; one strategy may span two modes with mode reasoning covering both, or the RTO may run sibling strategies (granularity mechanics §12.1) - status — { active | retired }; retirement is an org decision, ledgered, never a deletion - current_baseline_version — the ratified head; null while only a draft exists - placement_required_flag — derived from the product + provision design; gates the conditional sections (§4.8; M8 — surfaced only where placement is real)

tas_baseline — the sealed artefact (R3; tas-01 §6). - strategy_ref, version (monotonic per strategy) - sealed_snapshot — the frozen substrate: every §4 section's structured payload + reasoning, the provision-design entries, the position adoptions in force, at the moment of ratification - assignment_seal — the named slots as at ratification, each with its sealed People verdict snapshot and any keyhole record ref (§3.3) - ratified_by → tas_signer_naming (the signer in force), ratified_at - seal_digest — sha256 over the canonical serialisation of the above; the citable "planned X" - status — { draft | ratified | superseded }; ratified baselines are immutable — revision is vN+1, never an edit (R2 lifecycle) - closure_kind — for versions ≥ 2: { reasoned_change | reasoned_no_change }; a reasoned no-change closure re-seals the same substrate at a new version with its closure reasoning — the instrument's own closure logic applied to ourselves (tas-01 §6)

tas_section — the working substrate (unsealed). One row per (strategy, section_type); the twelve types and their payload schemas are §4. Working sections are editable; ratification snapshots them into the baseline seal. A ratified strategy's working sections continue to accrete edits toward vN+1 — the working surface never mutates a seal. - strategy_ref, section_type (§4 enum), payload (structured per §4), updated_by/at

tas_signer_naming — the RTO names its signer (R3; event 1). - person_ref → People (a workforce person; NOT required to hold trainer credentials — a department head or director qualifies; the naming, not a credential, is the authority source) - named_by, named_at, superseded_by_ref (nullable — naming history is append-only) - The naming record is itself 4.2(2)(d) evidence — roles documented, accountable decision-making. The record is the discharge; no separate artefact.

tas_assignment_slot — named and designed-but-unnamed slots (tas-01 §7, new-precision ruling 2). - strategy_ref, activity — { deliver | assess | both }, scope — product-level or a unit subset (unit tga ids) - credential_requirement — derived: what a person named into this slot will be tested for (the People dimension set for this product × activity); this is what the load model consumes for unnamed slots - named_person_ref → People (nullable; null = designed-but-unnamed) - slot_state — { designed_unnamed | named_supported | named_keyed } - verdict_snapshot — sealed at the naming test (§3.3/§3.4): People's verdict + evidence pointers + the policy/list versions it was computed against (the People pattern, rpl-02 §6.6) - keyhole_ref → tas_keyhole_record (nullable; delivery-leg slots only — §3.3) - named_at, named_by

tas_keyhole_record — the documented 3.2(2)(b) arrangement (R4; event 3). - slot_ref, person_ref (the under-direction person) - director_ref → People — the named director; director eligibility is Credential Policy §1E state read from People at record time and snapshotted (the Layer-2 precision verified at model draft: the named-director leg is CP state, not 3.2(2)(b) text) - judgement_block — the documented statement that the person does not make assessment judgements (3.2(2)(b) / F2025L00354 verbatim demands systems ensuring exactly this) - quality_delivery_design — the documented under-direction delivery design (the second 3.2(2)(b) limb) - documented_at, recorded_by — named and dated; the key - The lock demands the key exist; no field in this record carries a system judgement of the arrangement's adequacy — veracity lies with the keyholder (doctrine §8.2). The record is a discrete, signed, dated, falsifiable artefact — the attestation import, priced in (doctrine §8.3).

tas_review_input / closure — the accreting review register (R2; events 6–7; §6). - strategy_ref, input_type — { advice_disposition | validation_outcome | variance_pattern | intake_signal | product_version_event } - source_ref — the referenced substrate (Studio loop disposition id, Record validation outcome ref, tas_variance ref, intake-spine signal ref, Pith supersession pair) - payload, received_at - comms_flag — product_version_event only: { required | discharged (with discharged_at, discharged_note) } — the 2.1(2)(e) students-informed leg; execution is operational, the flag and its disposition are tile state (tas-01 §8) - status — { open | closed }; closure — { disposition ∈ adopted | adapted | rejected_with_reasons | noted_no_change, reason, closed_by/at, resulting_baseline_version (nullable — set when a register close produces vN+1) } - This is the modelled home of 1.2(2)(b) and 1.5(2)(g) closure (tas-01 §8); the register's closure record is the discharge.

tas_variance — authorship capture (R2/§9 of the model; event 8). - strategy_ref, baseline_version (the citable "planned X"), planned_ref (section/block pointer into the seal) - delivered — what happened (Y), reason — why (Z) - authored_by → People — the person who made the call; the trainer delivery brief is the natural capture surface (§7); occurred_at, recorded_at - No field promises automated delivery capture; the substrate does not have it and this spec does not invent it (tas-01 §9, held).

tas_render_pin — pinned, reproducible renders (R3/R5; event 9; §9). - strategy_ref, render_type — { auditor | delivery_brief | public_info } - baseline_version, read_at — the two pin halves - reference_snapshot — the sealed reference-state read (what People/Studio/Pith/Record/RPL said at read_at), digest-referenced to the render archive - artefact_key → render archive (R2), artefact_digest (sha256) - issued_by/at

tas_first_read — the delivery-brief first-read ledger (event 10; §9.2). - person_ref → People, strategy_ref, baseline_version, read_at, render_pin_ref - One row per (person, strategy, baseline version) — a new baseline version invites a fresh first-read; the ledger accretes, never overwrites. Close to a literal 4.2(2)(a) discharge at trainer level (tas-01 §11).

tas_position_adoption — the interpretive-position adoption model (tas-01 §3, new-precision ruling 1; event 5; §11). - position_id + template_version — which registered position, at which shipped version - scope — { rto | strategy }, strategy_ref (nullable; strategy-scope only — the guest-speaker line is drawn per product) - adopted_text — the sealed copy; the adopted position is the RTO's own, owned by its named signer; the product supplied the reasoning, the RTO owns the stance - adopted_by → tas_signer_naming, adopted_at, status — { adopted | revised | retired }, supersedes_ref

tas_org_staffing_story — the org-level 3.1 reasoning line (tas-01 §5). - [DESIGN CALL — org-level entity] The 3.1(2)(a) composition is org-level by construction (People roster × the load models of every live strategy). The composition itself is computed, never stored (§10.2). But the model gives the honest small-RTO answer — "me, all hats, and here is why that carries this cohort" — as a stated reasoning line over the same composition, and a stated line is authored content needing a home. Spec answer: one org-level versioned, signer-signed note; rendered with the composition on the staffing surface. It is the only org-level (non-per-strategy) authored substrate in the tile — flagged because it slightly widens the tile's authoring surface. Ratify. - version, story_text, signed_by → tas_signer_naming, signed_at, status

Interim custody (Record-shaped) — tas_evidence_item (§8.4; phasing rider). - kind — { certificate_of_currency | third_party_agreement | walkthrough_record | placement_risk_document | other_assurance } - subject — the provision-design entry / premises / provider / product it evidences - vault_key → interim evidence custody (R2), digest (sha256, sealed at landing) - valid_from, expires_at — the clock (the People expiring-credential shape, applied to premises — tas-01 §10); recorded_by/at - Clock events (expiry/renewal) mint in this Record-shaped form so they migrate as data, not design; they are Record's events, reserved, not TAS launch events (tas-01 §17).

tas_event — the discharging-events ledger (tas-01 §17). Events reference fields; fields carry instrument-qualified clauses; the clause is never copied onto the event (NO ORPHAN GRAINS). Ten launch events (§3.6); resource clock events reserved to Record.

3. The strategy lifecycle — the state machine and the ten events¶

The lifecycle is R2's loop: baseline vN → live record + accreting inputs → reasoned revision → vN+1, with reasoned no-change a valid closure. The foundational negative rule holds throughout: no state below asserts a substantive judgement; the signing act is the RTO's, through its named signer.

3.1 The strategy-level lifecycle¶

(signer named ─ e1, org-level, precedes everything)
        │
        ▼
   DRAFT ── substrate sections authored/edited (§4); slots designed, named or left unnamed;
        │   planning surfaces show amber nudges freely (§3.5)
        ▼
   RATIFY-BLOCK CHECK (§3.3) ── every NAMED slot resolves { permitted → snapshot |
        │                        keyed (delivery legs only) | unnamed to proceed }
        ▼
   RATIFIED vN ── e2 (the signing act; seal + assignment seal + digest)
        │
        ├── renders issued against vN ── e9 (auditor / public-info; §9)
        ├── delivery-brief first-reads ledgered ── e10
        ├── person named into a slot post-ratification ── e4 (§3.4)
        ├── review inputs accrete ── e6 (§6); variance records ── e8 (§7)
        │
        ▼
   REGISTER CLOSE (§6.3) ── dispositions recorded ── e7
        │
        ├── reasoned change → new DRAFT → ratify → vN+1 (e2 again)
        └── reasoned no-change → re-seal at vN+1 with closure reasoning (e2, closure_kind set)

Strategy retirement (delivery ends) is an org decision recorded on tas_strategy.status, ledgered; baselines and their history are never deleted — the record outlives the delivery.

3.2 What ratification seals¶

The signing act (e2) freezes, in one seal: the twelve substrate sections' payloads and reasoning (§4); the provision-design entries (§8.2); the position adoptions in force (§11); the assignment seal — every slot's state, each named slot's People verdict snapshot, each keyhole record ref; and the seal digest. The baseline is thereafter immutable. Renders cite it; variance records cite it; the auditor reproduces it byte-true.

3.3 The ratify-block — the gate at the signing act (R4)¶

At e2, for every named slot, the tile calls People through the existing contract (people-02-spec — no re-implementation of credentialling):

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

Verdict	`activity = deliver` (or the deliver leg of `both`)	`activity = assess` (or the assess leg)
`permitted`	Ratify proceeds — verdict snapshot seals	Ratify proceeds — snapshot seals
`permitted_under_direction`	Keyhole path — ratifiable only with a `tas_keyhole_record` (named director CP §1E-read, judgement-block, quality-delivery design, dated). Slot seals as `named_keyed`	Blocked, no keyhole — the under-direction verdict carries cannot make assessment judgements as a negative capability (people-02-spec); the 3.2(2)(b) keyhole is the delivery-leg exception and does not reach assessment. Unname, or change the person
`not_permitted`	Blocked — red; unname or change the person	Blocked — red
`insufficient_data`	Blocked — amber; ratification is a signing act, not a planning canvas (new-precision ruling 3; the rpl-01 §9 posture imported). Unname to proceed	Blocked — amber; same rule

Designed-but-unnamed slots ratify freely. They carry their credential requirement (which is what the load model needs) and make no claim — a claim exists only when a person is named (new-precision ruling 2). A pre-delivery RTO ratifies a fully-designed, fully-unnamed strategy without a single People test; the gate context (tas-00 §1) is served by design, not fiction.
Reality is recordable. The block gates the seal, never the working record — assignments can always be entered on the draft; the contradiction is surfaced loudly on every working surface (R4). Denying the record of a real assignment doesn't prevent the assignment; it loses the record.
The keyhole is never judged. The gate checks the record exists and is complete (named director with CP §1E eligibility as read from People, judgement-block text, dated) — it asserts structural truth only. Adequacy is the keyholder's.

3.4 Naming into a slot post-ratification (e4)¶

Naming a person into a designed-but-unnamed slot after ratification is a ledgered event tested against People at that moment, with the same gate table as §3.3 — permitted completes the naming; permitted_under_direction completes only with a keyhole record (delivery legs only); not_permitted and insufficient_data block the naming act. The verdict snapshot attaches to the slot; the baseline does not re-ratify — its design already provided for the slot (new-precision ruling 2). Un-naming and re-naming are likewise ledgered. A naming that the design did not provide for (a new slot, a changed activity or scope) is a design change: it lands on the working sections and rides to vN+1.

3.5 Planning surfaces vs the signature¶

Planning surfaces inside the tile (slot design, draft assignment, staffing what-ifs) inherit Never Block's amber nudge — insufficient_data renders amber, informs, never blocks a draft. The signature does not inherit it (§3.3). The amber/red distinction is preserved in all copy: amber "person's profile incomplete", red "person not eligible" — never collapsed (the people-02/rpl-02 discipline, §12.8).

3.6 The ten events, mapped¶

The ledger is tas_event (§2.2). Events reference fields; fields carry the clauses (§13); the clause is never copied onto the event.

#	Event	Fires when	Primary discharge (real clause; §13)
e1	Signer named / changed	The RTO names (or re-names) its ratification authority	`4.2(2)(d) / F2025L00354` — the naming record is the evidence
e2	Baseline ratified — the signing act	Seal per §3.2; ratify-block passed per §3.3	demonstrability of `1.1(2)(b)–(c)`, `2.2(2)(a)` premise, `2.3(2)(b)–(d)`, `3.1(2)(a)` at design level
e3	Keyhole recorded	The documented 3.2(2)(b) arrangement lands	`3.2(2)(b) / F2025L00354` — structural discharge
e4	Person named into a slot	Post-ratification naming, gate-tested, snapshot attached	`3.2(2)(a) / F2025L00354` via People (the Δ1-shaped claim, dated)
e5	Interpretive position adopted / revised	Signer ratifies an adoption (§11)	tas-00 §10 register; doctrine §3 lifecycle
e6	Review input received	Advice disposition / validation outcome / variance pattern / intake signal / product version event (with comms flag)	accretion side of `1.2(2)(b)`, `1.5(2)(g)`; `2.1(2)(e)` flag
e7	Review closed	Disposition recorded; reasoned change or reasoned no-change	`1.2(2)(b)`, `1.5(2)(g)` / F2025L00354 — the closure home
e8	Variance recorded	Planned X / delivered Y / because Z, authored by the person who made the call	testimony integrity (doctrine §4); feeds e6 as pattern
e9	Render issued	Auditor or public-info render sealed with its pin	`2.1(2)(a)`, `2.1(2)(c)` accuracy by construction
e10	Delivery-brief first-read	Ledgered per (person, strategy, baseline version)	`4.2(2)(a) / F2025L00354` at trainer level

Reserved, not launch: resource evidence clock events (expiry/renewal) — Record's events, minted in the Record-shaped interim schema (§8.4) so they migrate as data.

3.7 The supersession watch¶

The tile learns of product version events by reading the Pith it already reads: a scheduled prod worker pass compares every active strategy's target_tga_id (and component refs in its sealed floor, §8.1) against Pith supersession lineage (supersedes / superseded_by). A hit mints a product_version_event review input with comms_flag = required (e6). No external API is touched — the Pith is in-house substrate; EXT-API RULE not triggered. The watch never edits a baseline: a package event is an input to review, never an edit (tas-01 §1).

3.8 The Accreting Review — deliberately NOT consumed (the rider-11 stitch)¶

[DESIGN CALL — argued, for ratification.] accreting-review-01-model (read in full at draft, 13,933 B working-tree copy) is the shared review primitive RPL and People onboarding consume: a versioned submission reviewed section by section, approvals accreting and locking, correspondence immutable, content-change the only re-opener. Its §2 names anticipated consumers — LLND review items, Record's validation samples. TAS is not named, and neither TAS surface fits the machine:

Baseline ratification is atomic, not sectional. The signing act seals the whole substrate in one act (§3.2); sections do not accrete independent approvals, there is no reviewer↔subject return loop, and no convergence problem exists. Parameterising the primitive here would force a section-approval shape onto an act the model rules is single and whole (R3).
The review register is an input-disposition ledger, not a submission review. Register inputs are heterogeneous external events closed with dispositions (§6); there is no versioned submission, no lock, no re-open. Its accretion is accumulation toward a revision, not approval convergence.

The overlap is vocabulary ("accreting"), not machinery. Consuming the primitive anyway would grow it past its own §7 boundary and fork its semantics — the exact failure its §0 exists to prevent. Spec ruling: not consumed; this section is the deliberate cross-reference so the non-consumption is a recorded decision, not an omission. If Record's validation-sample consumption later gives the TAS validation seam an Accreting Review face, that is Record's consumption, referenced by this tile like any other Record state (§5.4). Ratify.

4. The substrate section schemas¶

The model fixed what each authored section must hold and reason (tas-01 §3); this section fixes fields. Every section is first-class authored content: versioned inside the baseline, ratified with it, signed by the named signer. Structured fields carry the machine-consumable shape; reasoning fields carry the authored argument — the reasoning is substrate, not decoration (the seal includes it; R3). Section payloads are structured JSON in tas_section.payload; provision design additionally normalises into tas_provision_entry rows (§8.2) because evidence items reference its entries.

Anchors below are the tas-00 rows (internal obligation-IDs, resolved to real clauses in §13.1 — never themselves qualified as clauses; the rpl-02 §10.3 discipline).

4.1 Cohort premise (tas-00 2.2-1)¶

premise — who this delivery is designed for, stated concretely: prior-context assumptions (work status, industry exposure, typical entry pathway), LLN/digital-literacy expectations at entry, equipment/connectivity assumptions (feeds the access-gap position, §11), language/ support expectations
The premise must be concrete enough that the 2.2(2)(a) review has something to test against — the intake seam consumes it as the tested hypothesis (§14); intake signals that contradict it are register inputs (§6)

4.2 Mode reasoning (tas-00 1.1-2) — the keystone strategy-original section¶

Per mode in mode_set: four named argument fields, one per ES factor — cohort_argument, mode_resources_technology_facilities_argument, industry_expectations_argument, breadth_complexity_argument
provision_refs[] — the §8.2 entries this reasoning rests on (structurally entangled: the mode claim is only as strong as the resource claim beneath it)
assessment_posture_ref — the §4.6 posture it entangles with (1.1(2)(b) ⇄ 1.8 ⇄ 1.4(2)(a)(iii))

4.3 Pacing baseline (tas-00 1.1-3, Δ4)¶

blocks[] — the designed structure: ordered delivery blocks, each { unit_refs[] (Pith), designed_span (calendar representation: start/duration at week grain), activity_mix — the four named activities (instruction, practice, feedback, assessment) each present or reasoned absent for the block, sufficiency_reasoning — why this span carries these activities for this cohort }
The calendar representation is design, never compliance arithmetic — no field stores or derives nominal hours as a compliance value; sufficiency is the reasoning field's burden (tas-00 §2 silences, held structurally)
individualiser_rules — the rules whose instances live on the intake spine (R6): placement_rule (how placement individualises progression, 1.1(2)(e)) and credit_rule (how a granted RPL/CT outcome adjusts pacing, Δ4). Rules are authored text + structured parameters (which blocks flex, what adjustment shape); no per-student instance is ever written here (§14)

4.4 Load model (tas-00 3.1-1)¶

rows[] — the demand function: per period × activity (the 1.1(2)(c) four), { expected_cohort (from premise), demand (designed contact/support quantum for that activity), basis (the stated derivation) }
product_mix_note — where the strategy shares its workforce with siblings, the stated overlap
Consumed by the org-level 3.1 composition (§10.2) — for named slots via the person, for unnamed slots via the slot's credential requirement (§2.2): the demand is real before the hire is

4.5 Access model (tas-00 2.3-1)¶

Per mode: channels[] (how students reach trainers/assessors/staff), windows (when), response_commitment (the "timely" design — RTO-authored content, not product config)
load_model_ref — the loop into §4.4 (promising access nobody is rostered to give fails 2.3 and 3.1 together; the composition surface renders the pair)

4.6 Assessment posture (tas-00 1.4-1, posture leg)¶

evidence_type_mix — per unit-group: the designed evidence types and their weighting
practical_setting_claims — where practical application happens (setting, simulation position)
authenticity_position_ref — the adopted authenticity position (§11) this posture applies
The per-judgement rules of evidence stay out of perimeter (tas-01 §1A) — no field here carries an assessor's judgement or a per-student anything

4.7 Provision design (tas-00 1.8-2, 1.8-3) — normalised into `tas_provision_entry` (§8.2)¶

4.8 Placement conditional sections (tas-00 1.1-5, 1.8-4) — surfaced only where¶

placement_required_flag (M8) - attainability_claim — the 1.1(2)(e) claim: skills attainable in the placement environment, reasoned - risk_document_ref — the documented placement risk strategies and procedures: QA1's only mandated document; the artefact itself is Record-custody (interim: §8.4), referenced here

4.9 Recognition connection statement (tas-00 Δ5)¶

sensor_actuator_statement — how this product's intake connects the 2.2(2)(a) review (sensor) to the 1.6 offer (actuator); authored text + refs to the intake seam
The recognition posture is NOT here — it is RPL-tile state, reference-rendered (§5.5, R8)

4.10 Wellbeing flag (tas-00 2.6-1)¶

flags[] — design-time identification of wellbeing needs by reference to the training product content (per unit-group where the content drives it), each { content_ref, identified_need, note }; support arrangements are operational, out of tile

4.11 Interpretive positions — adoption refs (§11 owns the mechanics; the section payload is¶

the set of adoptions in force for this strategy: the RTO-level adoptions cited + any strategy-level ones, incl. the guest-speaker line)

4.12 Expert justification (tas-00 3.3-2)¶

Per engagement class: justification — the by-reference-to-product-or-cohort, specific-need justification 3.3(2)(b) demands; engagement_record_ref → People (the record itself is People-held); guest_speaker_line_application — how the adopted line (§11) places this class inside or below the 3.3 threshold (M14)

5. The reference layer — read contracts¶

Every claim about another tile's domain is a live reference, never a copy (R1). Reads are live on working surfaces and pinned at render time (§9). No read below ever writes to the peer, and none reaches through a peer's tables.

5.1 People — through the contract¶

canDeliver(person, product, activity) at the ratify-block and naming gate (§3.3, §3.4); verdict snapshots seal, the live verdict shows on working surfaces
Director CP §1E eligibility at keyhole record time (§2.2), snapshotted
Trainer industry currency (3.3(2)(a)(ii) state) — one leg of the 1.2(2)(c) composition (§10.1)
Expert engagement records (§4.12); validator credential state for the validation seam read (§5.4)

5.2 Studio — version-true content state¶

Tool/content versions per unit (the 1.1(2)(d)/1.3 reference legs) and the 1.3(2)(b)–(c) pre-use review ledger state per tool version. A strategy citing an unreviewed tool renders that state truthfully — the render says "review: not recorded", it never blocks and never invents (tas-01 §4). Build-time confirm: the review-ledger read exists at a consumable shape; where Studio does not yet expose it, the render states "review state unavailable" — truthfully — and the gap is a Studio work item, not a TAS fiction (§14)
Consultation-loop dispositions (R7) — consumed as register inputs (§6)
Authorship records (M1) — the expansion co-developer's collaboration record, cited by the 4.2(a) evidence surface (§9.2)

5.3 Pith — machine-checkable conformance¶

Product identity, composition/packaging (the 1.1(2)(a)/1.3(2)(a) conformance reads — claimed by reference, never restated), assessment_conditions (the §8.1 floor), supersession lineage (the §3.7 watch). Read-only always; KN sacred.

5.4 Record — the evidence shelf (phasing-aware)¶

Validation cycle position per product — the five-year clock (1.5(2)(b), C5 applied): rendered as a schedulable per-product state with cycle position; risk-based scope (1.5(2)(c)) referenced as validation-system state; TAE independent-validation conditional (1.5(2)(d)) surfaced only for TAE scope; validators' collective competence/credential (1.5(2)(e)) via People; the not-solely-determined rule (1.5(2)(f)) as a structural check on the validation record — never a judgement
The strategy's validation-scope claim includes RPL by definition (Δ2/Δ3, s 4) — the rendered scope statement is generated with RPL inside it; no configuration can draw it narrower (a structural impossibility, not a validation rule)
Assurance evidence clocks (§8.4) — Record custody when deployed; interim in-tile
Until Record deploys: validation-state reads render "validation records: not yet held on platform" truthfully; the interim custody (§8.4) covers assurance artefacts only, not validation outcomes — the RTO's off-platform validation records are cited by note, not ingested (custody discipline over convenience)

5.5 RPL tile — recognition posture¶

Posture per product (RPL via X; CT available/restricted because Y, the 1.7(2)(b) licensing parenthetical) — reference-rendered, never re-bound (R8); granting-pattern reads for the Δ6 composition (§10.3). RPL builds before TAS in the ruled draw order; confirm the read shape at build (§14)

5.6 The intake spine¶

The cohort premise is published to the seam as the tested hypothesis; per-student overlays (placement, credit) are generated intake-side from the §4.3 rules — instances never land in this tile (R6/M12). Intake signals (2.2 review outcomes contradicting the premise) arrive as register inputs (§6). The seam is named and consumed; overlay generation is intake-side work, wired when the intake consumers build (§14)

6. The review register (R2)¶

The tile's accretion surface; the closure home of 1.2(2)(b) and 1.5(2)(g). Substrate: tas_review_input (§2.2). Semantics are the model's (tas-01 §8); this section binds mechanics.

6.1 Inputs (e6)¶

Five types, five sources: advice dispositions from the Studio loop (adopted / adapted / rejected-with-reasons arrive as Studio state; the register holds the strategy-side disposition); validation outcomes (Record state; interim: recorded by note, §5.4); variance patterns (promoted from tas_variance rows by the operator — a variance is a record, a pattern is a review input); intake signals (premise-contradicting 2.2 outcomes, via the seam); product version events (the §3.7 watch), each carrying its comms_flag — students informed as soon as practicable is 2.1(2)(e); the flag and its disposition are tile state, execution is operational.

6.2 Closures (e7)¶

Every input closes with a disposition and a reason; reasoned no-change is valid closure — the instrument's own logic (1.2's), applied to ourselves. An input may close into the working sections (its adoption becomes an edit riding toward vN+1) or close standing (noted, no change, reasons recorded).

6.3 Register close → revision¶

A register close is the operator-initiated act that sweeps open inputs to dispositions and produces either a new draft (reasoned change → ratify → vN+1) or a reasoned no-change re-seal (vN+1 with closure_kind = reasoned_no_change, carrying the closure reasoning). Close is prompted by: the configured cadence (§12.7 — a configured default, not law: the instrument prescribes no cadence); any open product_version_event; or the operator's own judgement. Aging surfaces show open inputs by age and type; an open product-version event escalates visually (its comms flag is live law's "as soon as practicable"). Nothing auto-closes — closure is authored, always.

7. The variance surface¶

"Planned X, delivered Y, because Z" (tas-01 §9). Substrate: tas_variance (§2.2).

Capture surfaces (launch): the trainer delivery brief (§9.2) — the model's lean, honoured: the person who made the call enters the variance where they work — and the operator strategy surface. Both write the same record; authored_by is the person who made the call, not the person who typed it — where an operator records on a trainer's behalf, the surface captures both (author vs recorded-by).
The drift reference is the RTO's own documented rationale — the variance form presents the cited baseline block and its reasoning, never a nominal-hours comparison.
No automated capture, stated in the surface's own copy: the variance record is authorship, not telemetry (§12.8). This spec makes no promise the substrate doesn't have.
Variance rows accrete; the operator promotes recurring shapes to a variance_pattern register input (§6.1) — the loop from drift to reasoned revision.

8. The resource register (R9)¶

Three legs, three governance regimes, one surface, no new substrate beyond the interim custody the phasing rider licenses.

8.1 Leg 1 — the requirement floor (derived, never authored)¶

Read from unit assessment_conditions (Pith) for every unit in scope of the strategy; rendered as the floor the RTO reasons up from (1.8(2)(a)). Identification below the floor is non-conformance on the face of the documents — the register surface renders any provision gap against the floor loudly (a truthful state, not a block). The floor re-derives on supersession events (§3.7) and the delta is part of the product-version review input.

8.2 Leg 2 — provision design (strategy-original) — `tas_provision_entry`¶

strategy_ref, leg — { rto_provided | third_party | student_disclosed }
covers[] — which floor items / cohort-quantity reasoning this entry answers, + quantity_reasoning (floor → cohort quantities × mode, authored)
premises_or_platform — the facility identity; for an online product the platform is the facility (doctrine §6) and enters here with the same continuing-suitability clock as a workshop
provider_ref — third-party leg: who; the disclosure leg of the arrangement renders in the public-info render (2.1(2)(c)(i)) — the 4.2(c) information surface, which is the whole of this tile's third-party reach (tas-01 §19: oversight mechanics are out of tile, Record/ops)
fallback_design — student-disclosed leg only: the designed fallback or intake-time test (the access-gap position, §11); the student leg carries no 1.8(2)(b) assurance — it discharges as disclosure under 2.1(2)(c)(iv) (a §9.3 render obligation) and as the intake-time test (seam, §5.6)
Entries seal into the baseline (§3.2); evidence items reference entries.

8.3 Leg 3 — assurance evidence (clocked; Record custody; interim §8.4)¶

Certificates of currency, third-party agreements, walkthrough records: expiring evidence with clocks — the People expiring-credential pattern applied to premises. 1.8(2)(b)(i) is honoured as written: the clock is the answer to "and will continue to be"; the field's point-in-time audit practice stays posture (the layer divergence tas-00 surfaces and does not resolve).

8.4 The phasing rider, made mechanical¶

Record is specced, not deployed. If Record is deployed when the TAS build slot arrives, §8.3 binds to Record and this subsection is dead on arrival — confirm at build (§14). Otherwise: - Custody: tas_evidence_item (D1 metadata, Record-shaped: item, clock, ID — §2.2) + rtopacks-tas-evidence-* (R2 bytes, digest-sealed, immutable) - Clock events mint in the Record-shaped form; they are Record's events, reserved — the TAS ledger does not absorb them (tas-01 §17) - Handoff is a migration, not a redesign: rows and objects move wholesale; refs from tas_provision_entry re-point. If the interim proves wrong in the builder, plan B is ratified with reasons (R9 rider — reasoned change is valid closure, our own doctrine applied to ourselves)

8.5 The register surface¶

One surface composing all three legs per strategy: floor items → provision entries answering them → evidence items with clocks (state: current / expiring within the configured horizon / expired). The operator never leaves the surface (the R9 debate, settled: surface composes, custody stays disciplined). Clock-horizon warnings are configured defaults (§12.7), not law.

9. The renders — three faces, one substrate (R5 residue; tas-01 §11)¶

Structurally incapable of disagreeing: all three generate from the same sealed baseline + live reference reads, pinned at issue to (baseline version, substrate read time). Issued renders seal as bytes with their pins (§2.1 design call); every historical render is reproducible from custody.

9.1 The auditor view (e9)¶

The strategy render: substrate sections with their reasoning, reference states as read at issue (each stamped with its read time and truthful state — including "review: not recorded" and "validation records: not yet held on platform" where true), composed claims (§10), review register position (open inputs, closure history), variance record. This is what the gate's "describe the rationale" questions are answered from (tas-00 §1) — and what makes the CEO statutory declaration cheap to sign truthfully. Export: HTML/PDF; sealed on issue.

9.2 The trainer delivery brief (e10 on first-read)¶

A live working surface per assigned person: their slots and units, the current sequence (§4.3 blocks), version-true resources and tools with review state (§5.2), their own canDeliver state (live, truthful, amber/red per §12.8), and the variance capture affordance (§7). On a person's first read of each baseline version, the surface seals a pin (what they read, byte-true) and writes the tas_first_read ledger row — the close-to-literal 4.2(2)(a) discharge at trainer level. Subsequent reads are live and unledgered; a new baseline version invites a fresh first-read.

9.3 The student/public information render (e9)¶

The 2.1(2)(c)(i) accessible-information list — duration, modes, location, commencement, scheduling, requirements to commence/complete (incl. assessment requirements), licensing implications, third-party arrangements — plus the 2.1(2)(c)(iv) student-obligations disclosure (the student-provided resource leg lands here, §8.2). Generated from the same substrate as the other two faces; marketing-vs-strategy divergence is a breach in its own right before anyone enrols (2.1(2)(a)), and one-substrate-three-faces is the structural answer.

[DESIGN CALL — publication path] Launch: the render is an exportable artefact (HTML/PDF/copy-block) the RTO publishes through its own channels, sealed on issue with its pin. Day-two: a hosted public feed/embed (2.1(2)(a) accuracy stakes cut both ways — a live feed can't go stale, but a public customer-facing surface is its own channel-discipline and naming/routing question, and this tile should not mint a public web surface as a side effect). Staleness is the launch-time answer to the accuracy stake: if the ratified baseline moves past the last issued public render, the tile surfaces "published render is N versions / M days behind" against the configured horizon (§12.7) and nudges re-issue. Ratify the launch/day-two split.

10. Composed claims — pattern visibility, no custody (tas-01 §5)¶

All three are computed at read, rendered with their reference reads, never stored as facts.

10.1 Currency of training — `1.2(2)(c)`¶

Per strategy: named persons' industry currency (People 3.3(2)(a)(ii) reads) × product currency (Pith supersession state) × the outreach record (loop dispositions in the register). Rendered in the auditor view; each leg carries its read time.

10.2 Staffing adequacy — `3.1(2)(a)` (org-level by construction)¶

The composition surface: People roster vs the summed load models of every active strategy (§4.4) — named slots resolve to persons, designed-but-unnamed slots contribute their credential requirement as demand (the demand is real before the hire is). The org staffing story (§2.2) renders beside the composition — the honest small-RTO answer as a stated reasoning line over the same numbers. The tile carries only the T&A staffing story (the services perimeter note, tas-00 §8).

10.3 Aggregate recognition integrity — Δ6 (`1.6(2)(c)` / `1.7(2)(c)`)¶

Granting patterns over RPL tile state at product level, rendered against the stated posture — reconciling with it, or indicting it. Pattern visibility only; no RPL fact is copied. Launch scope: the per-product grant-rate view against posture; richer analytics are day-two (§14).

11. Interpretive positions — template packaging and adoption (tas-01 §3 adoption model)¶

The four registered positions (authenticity; access gap; 1.2 localisation; guest-speaker line — tas-00 §10) are RTOpacks product doctrine. They enter a customer RTO's tile as position templates the RTO adopts by ratification; the adopted position is the RTO's own, signed by its named signer, versioned in its baseline. Signature is the source of the authority (doctrine §8.4), applied to interpretation itself.

[DESIGN CALL — template packaging] Spec default: templates ship as versioned, code-carried product content (structured text + clause traces, versioned with the worker release), NOT as a -ref database — four positions do not earn a substrate store, and code-shipping versions them with the product exactly as doctrine should be. Adoptions (tas_position_adoption, §2.2) are Peel rows binding (position_id, template_version, sealed adopted text, scope, signer, date). A diff surface shows an RTO's adopted copy against the current shipped template version — divergence is information (the RTO adapted the stance, or the product's doctrine moved on), never auto-updated. New RTOpacks positions and template revisions reach RTOs as available to adopt, nothing more. Ratify.
Two scopes: RTO-level (adopted once, cited by every strategy — authenticity, access gap, 1.2 localisation) and strategy-level (the guest-speaker line, drawn per product; §4.12 applies it).
Adoption, revision, retirement are ledgered (e5) and carry the doctrine-§3 lifecycle. An adopted position seals into every baseline that cites it (§3.2) — the auditor render shows the position as the RTO's stance, clause-traced.

12. Deferred calls resolved¶

The model deferred nine structural/presentation calls (tas-01 §21). Each resolves here as a launch answer + a named day-two seam. §12.0 collects the design calls for the redline.

12.0 The design-call register — all six RATIFIED 2026-07-09 as spec defaults¶

§2.1 store naming — rtopacks-tas-* default vs rtopacks-strategy-*.
§2.1 render sealing — issued renders seal as bytes (adds the renders R2 pair).
§2.2 org staffing story — the one org-level authored entity.
§3.8 Accreting Review not consumed — the rider-11 stitch, argued.
§9.3 public render publication — export at launch; hosted feed day-two; staleness surface.
§11 position templates code-carried — no -ref store; adoptions as Peel rows; diff surface.

12.1 Strategy granularity mechanics (tas-01 §21.1)¶

One product ↔ many strategies: no uniqueness constraint beyond (rto, product, cohort_label) distinctness; sibling strategies for one product render side by side on the product's strategy list; a strategy spanning two modes is one row with per-mode §4.2 reasoning. Creation flow asks product → cohort → mode-set. The granularity decision is recorded by the shape itself (the cohort premise + mode reasoning are the record — tas-01 §1); no synthetic "granularity note" field is invented.

12.2 Store and surface naming (tas-01 §21.2) — §2.1; bind-at-build checks §14.3.¶

12.3 Substrate section schemas (tas-01 §21.3) — §4.¶

12.4 Render presentation (tas-01 §21.4) — §9; the publication-path call §9.3.¶

12.5 Review-register cadence (tas-01 §21.5) — §6.3; the cadence is a configured default¶

(§12.7), close is always authored.

12.6 Ratify-block UX (tas-01 §21.6)¶

The semantics are §3.3's and do not move. Presentation: the block presents as a pre-flight checklist at the signing surface — every named slot with its live verdict (green permitted / amber incomplete / red not-eligible / keyed with its record), every keyhole record's completeness, unresolved items enumerated with their two exits (resolve, or unname). The signer sees exactly what the seal will contain (§3.2) before signing. Planning surfaces carry the amber nudge; the signing surface carries the gate.

12.7 Configured policy values (deliberately not model constants; the people-02/rpl-02¶

pattern) - register_close_cadence — default: 12 months, configured; the instrument prescribes no cadence; the prompt is product hygiene, not law - render_staleness_horizon — public-render staleness nudge (§9.3); configured - evidence_clock_warning_horizon — assurance-evidence expiry warning (§8.5); configured; mirrors People's staleness-flag pattern (a flag, not a gate) - first_read_grace — how long after ratification the delivery-brief first-read may remain outstanding before the aging surface escalates; configured; the ledger itself is never gated - Attestation-free: this tile mints no candidate-facing attestations; no token surfaces; no intake config is duplicated here

12.8 Copy constraints — the surface-copy invariants¶

Amber ≠ red, everywhere (§3.3/§3.5): insufficient_data → amber "profile incomplete"; not_permitted → red "not eligible". Never collapsed.
The keyhole copy asserts structural truth only: "supervision arrangement recorded — named director, judgement block, dated". No surface renders the system as having assessed the arrangement (no "approved", no "verified adequate"). The lock never judges the key.
Reasoned no-change is offered as a first-class closure at register close — never framed as "skip" or "dismiss".
Variance copy is authorship, not surveillance: the capture surface says "record what you delivered and why" — never "deviation detected"; nothing implies automated monitoring.
No nominal-hours compliance framing anywhere: pacing surfaces never render hours-sums as a compliance state (tas-00 §2 silences, held in copy as in schema).
Render staleness states facts: "published render is behind the ratified baseline" — a truthful state, the RTO's to act on.
Unnamed slots are never rendered as vacancies-in-breach: a designed-but-unnamed slot is a design fact (and a gate-context virtue), not a red flag.

13. The clause-bound field register¶

Every regulated field carries a stored, instrument-qualified clause trace authored at build time (CLAUSE-BOUND FIELDS), never generated at runtime. Citation convention per tas-00 §0: clause / F2025L00354; Act pinpoints s N / NVETR Act. The tas-00 internal row IDs (1.1-2, Δ4, …) are obligation-map cross-references, never themselves qualified as clauses (the rpl-02 §10.3 discipline, inherited).

13.1 The obligation-ID → clause key (from the ratified tas-00 tables)¶

tas-00 row	Real clause	One line
1.1-2	1.1(2)(b) / F2025L00354	mode enables attainment — cohort-aware reasons vs the ES factors
1.1-3	1.1(2)(c) / F2025L00354	structure/pacing with sufficient time for the four named activities
1.1-5	1.1(2)(e) / F2025L00354	placement conditional: skills attainable in that environment
1.2-2	1.2(2)(b) / F2025L00354	advice informs changes — the closed loop
1.2-3	1.2(2)(c) / F2025L00354	training reflects current industry practice (composed)
1.5-2	1.5(2)(b) / F2025L00354	every product validated at least once every five years (C5)
1.5-7	1.5(2)(g) / F2025L00354	how validation outcomes inform changes — closure
Δ4	1.1(2)(c) × Div 3 / F2025L00354	credit-adjusted pacing rule
Δ5	1.6(1) × 2.2(2)(a) / F2025L00354	the intake sensor–actuator statement
Δ6	1.6(2)(c), 1.7(2)(c) / F2025L00354	aggregate recognition integrity (composed)
1.8-1/-2/-3	1.8(2)(a), (b)(i), (b)(ii) / F2025L00354	floor / continuing suitability / student access
1.8-4	1.8(2)(c) / F2025L00354	documented placement risk strategies (QA1's one mandate)
2.1-1/-2/-3/-4	2.1(2)(a), (c)(i), (c)(iv), (e) / F2025L00354	accuracy; the information list; obligations disclosure; change comms
2.2-1	2.2(2)(a) / F2025L00354	the premise the suitability review tests
2.3-1	2.3(2)(b)–(d) / F2025L00354	access, how-and-when, timely
2.6-1	2.6(2)(a) / F2025L00354	wellbeing needs by reference to product content
3.1-1	3.1(2)(a) / F2025L00354	number of trainers/assessors/staff appropriate (composed)
3.2-1/-2	3.2(2)(a), (b) / F2025L00354	credentialled delivery; the under-direction keyhole
3.3-2	3.3(2)(b)–(c) / F2025L00354	expert justification + oversight record
4.2-1/-2	4.2(2)(a), (d) / F2025L00354	staff supported to understand; roles documented

13.2 The field register (per entity; operational scaffolding inherits its entity's anchor)¶

tas_strategy

Field	Anchor	Obligation	Consequence if wrong / absent
`target_tga_id`	1.1(2)(a) / F2025L00354	conformance claimed by reference to the Pith	designed against a wrong/absent product — conformance fails on the face
`mode_set[]`	1.1(2)(b) / F2025L00354	the modes the reasoning must cover	a delivered mode with no authored reasons — the keystone claim is empty
`placement_required_flag`	1.1(2)(e) + 1.8(2)(c) / F2025L00354	gates the conditional sections	the placement conditionals silently absent where the product requires them

tas_baseline

Field	Anchor	Obligation	Consequence
`sealed_snapshot` + `seal_digest`	G-2 (s 17(2) / NVETR Act; mirrored s 5(2) / F2025L00354) + 1.1(2)(b)–(c)	the citable "planned X"; testimony reproducible as at a date	divergence-as-information incoherent; testimony indefensible
`assignment_seal`	3.2(2)(a) / F2025L00354 via People	named-person claims sealed with their verdict snapshots	"was the trainer credentialled at the time" unanswerable
`ratified_by` / `ratified_at`	4.2(2)(d) / F2025L00354	the accountable signing act	no accountable decision-maker on the record
`closure_kind`	1.2(2)(b) + 1.5(2)(g) / F2025L00354	reasoned change / reasoned no-change as valid closures	loop closure unprovable

tas_section payloads (§4) — each section anchors per its §4 heading (the §13.1 key rows); the load-bearing consequences:

Section	Anchor	Consequence if absent/hollow
Cohort premise	2.2(2)(a) / F2025L00354	the suitability review has nothing to test — the sensor is a form with no question
Mode reasoning	1.1(2)(b) / F2025L00354	the keystone obligation undischargeable; the gate's "describe the rationale" unanswerable
Pacing baseline	1.1(2)(c) / F2025L00354	sufficiency unreasoned; four named activities unaccounted
Individualiser rules	1.1(2)(e); 1.1(2)(c) × Div 3	placement/credit individualisation is fiction squared — cohort pacing where reality individualises
Load model	3.1(2)(a) / F2025L00354	the staffing composition has no demand function — 3.1 tested against nothing
Access model	2.3(2)(b)–(d) / F2025L00354	access promised nobody is rostered to give — fails 2.3 and 3.1 together
Assessment posture	1.4(2)(a) / F2025L00354	system-level posture unstated; authenticity weighting invisible
Placement conditionals	1.1(2)(e) + 1.8(2)(c) / F2025L00354	QA1's only mandated document missing
Recognition connection	1.6(1) × 2.2(2)(a) / F2025L00354	sensor and actuator unconnected
Wellbeing flag	2.6(2)(a) / F2025L00354	design-time identification undone
Expert justification	3.3(2)(b) / F2025L00354	expert use without the specific-need justification the law demands

tas_signer_naming

Field	Anchor	Obligation	Consequence
`person_ref` / `named_at` / history	4.2(2)(d) / F2025L00354	roles and responsibilities documented, accountable decision-making	the naming IS the evidence; absent = 4.2(d) undischarged

tas_assignment_slot / tas_keyhole_record

Field	Anchor	Obligation	Consequence
`credential_requirement`	3.2(2)(a) / F2025L00354 via People	what a naming will be tested for; the unnamed slot's demand	load model blind; naming gate untestable
`verdict_snapshot`	3.2(2)(a) via People	credentialled-at-the-time, sealed	the auditor's actual question unanswerable
`slot_state`	3.2(2)(a)/(b) / F2025L00354	supported vs keyed vs unnamed — the claim's true state	a contradiction rendered as support — the system lies
`director_ref` (+ CP §1E snapshot)	Credential Policy §1E (via People); 3.2(2)(b) / F2025L00354	the named-director leg — CP state, not 3.2(2)(b) text (the Layer-2 precision)	keyhole incomplete; the exception path unfounded
`judgement_block` / `quality_delivery_design`	3.2(2)(b) / F2025L00354 (verbatim limbs)	the documented systems the clause demands	the key does not exist; the lock cannot pass it
`documented_at` / `recorded_by`	3.2(2)(b) + doctrine §8.3	named, dated, falsifiable — the attestation import	the lie stays fog instead of a signed artefact

tas_review_input

Field	Anchor	Obligation	Consequence
`input_type` / `closure`	1.2(2)(b) + 1.5(2)(g) / F2025L00354	the loops close somewhere — here	closure homeless; drift-is-information inoperative
`comms_flag`	2.1(2)(e) / F2025L00354	students informed as soon as practicable of product changes	the comms leg silently dropped

tas_variance

Field	Anchor	Obligation	Consequence
`planned_ref` / `delivered` / `reason` / `authored_by`	doctrine §4 (testimony integrity); supports 1.1(2)(b)–(c) demonstrability	planned X / delivered Y / because Z, authored	unexplained drift — the sin the surface exists to prevent

tas_render_pin / tas_first_read

Field	Anchor	Obligation	Consequence
`baseline_version` + `read_at` + `reference_snapshot`	2.1(2)(a) / F2025L00354 + R3	renders reproducible as at a date; accuracy by construction	testimony unreproducible; marketing-vs-strategy divergence invisible
`artefact_digest`	R3 (custody)	the issued face is byte-true	"what did the auditor/student actually see" unanswerable
`tas_first_read` row	4.2(2)(a) / F2025L00354	staff supported to understand their components — ledgered	the near-literal discharge lost

tas_position_adoption

Field	Anchor	Obligation	Consequence
`adopted_text` / `adopted_by` / `template_version`	tas-00 §10 (Layer-2-derived positions); doctrine §3	the RTO owns the stance; signed, versioned, diff-able	the moat becomes unowned product boilerplate — authority unrooted

tas_provision_entry / tas_evidence_item

Field	Anchor	Obligation	Consequence
`covers[]` + `quantity_reasoning`	1.8(2)(a) / F2025L00354	reasoning up from the derived floor	identification below the floor — non-conformance on the face
`premises_or_platform`	1.8(2)(b)(i) / F2025L00354 (platform-is-facility, doctrine §6)	the facility named, clocked	the online facility escapes the register
`fallback_design`	1.8(2)(b)(ii) × 2.2(2)(a) / F2025L00354	the access-gap answer for the student leg	mode rests on an untested assumption
`provider_ref` (renders at 2.1(2)(c)(i))	2.1(2)(c)(i) / F2025L00354	third-party arrangements disclosed — the 4.2(c) information surface	disclosure absent; the tile's one third-party obligation missed
`expires_at` (the clock)	1.8(2)(b)(i) / F2025L00354 ("and will continue to be")	continuing-state honoured as written	evidence rots silently; the continuing claim is a point-in-time snapshot
`digest`	1.8(2)(c) + custody discipline	sealed, tamper-evident artefacts	evidence integrity unprovable

tas_org_staffing_story

Field	Anchor	Obligation	Consequence
`story_text` / `signed_by`	3.1(2)(a) / F2025L00354	the stated reasoning line over the composition	the small-RTO answer has no home; the composition renders numbers without reasons

tas_event — the referenced field's anchor (§13.1); the clause rides the field, never copied onto the event (NO ORPHAN GRAINS); discharge unprovable or a clause orphaned = method breach.

14. What hands to the build gates¶

This spec is move 4 — the buildable surface, behind LLND and RPL in the ruled draw order. It is not itself a build brief: each buildable unit derives its own brief and runs the five-gate pattern (standing-rules). Dependency assertions are load-bearing and confirmed at build, not taken from memory.

14.1 The launch spine¶

§2 the data domain · §3 the lifecycle, ratify-block, keyhole, events, supersession watch · §4 the substrate sections · §5 the reference reads (phasing-aware) · §6 the register · §7 variance · §8 the resource register (+ interim custody if Record is still undeployed) · §9 the three renders + first-read ledger · §10 the composed claims · §11 positions + adoption.

No engine seam exists in this tile — the engine is the instrument of the validator and the generation substrate upstream in Studio (tas-01 §15); nothing here crosses the fence, and no cross-fence commissioning hand-off is named. The tile ships whole, house-side.

14.2 Consumed dependencies — confirm at build¶

Dependency	Consumed at	State to confirm
People — `canDeliver` contract; CP §1E director-eligibility read; currency state; engagement records	§3.3/§3.4 gates; §2.2 keyhole; §10.1; §4.12	Deployed (Phase 1). Confirm the contract shape incl. `activity` semantics for deliver-vs-assess legs, and that a CP §1E eligibility read is exposed (the keyhole needs it; if not yet exposed, it is a People work item prior to the TAS gate wiring)
Studio — versions; the 1.3(2)(b)–(c) pre-use review ledger; loop dispositions; authorship records	§5.2; §6.1	Deployed. Confirm the review-ledger read exists at a consumable shape; where absent, renders state it truthfully and the gap is Studio's work item — TAS never fakes the read
RPL tile — posture + granting-pattern reads	§5.5; §10.3	Builds before TAS (ruled draw order). Confirm read shapes against the built tile, not rpl-02 alone
Record	§5.4; §8.3	Specced, not deployed. The phasing fork (§8.4) resolves at build: Record deployed → bind it, interim dead; not deployed → interim custody ships
Intake spine — overlay seam; intake signals	§5.6; §6.1	Rules ship in §4.3 regardless; overlay generation and signal wiring land with the intake consumers — the seam is named, TAS does not block on it
Pith (`nrt-corpus-ref`) — incl. `assessment_conditions`, supersession	§5.3; §8.1; §3.7	Live. Confirm `assessment_conditions` readable at floor-derivation shape (verified for the model at column level; re-verify at build)

14.3 Bind-at-build substrate checks (SUBSTRATE-NAME-MATCHES-SHAPE)¶

rtopacks-tas-prod/-dev (D1), rtopacks-tas-renders-prod/-dev (R2), rtopacks-tas-evidence-prod/-dev (R2, only if the phasing fork lands interim) — verify against cloudflare-resource-inventory.md; none minted without the check; naming design call §2.1 resolves first
The tas_event ledger home — tile-domain table vs shared audit store (the rpl-02 §9.3 open call: resolve once, for both tiles, at whichever build arrives first)
The supersession-watch worker — named per worker canon at build; prod-only (sync-class, canon: no dev counterpart without reason)

14.4 Build order within the tile (each a five-gate unit)¶

Stores + strategy/baseline/section substrate (§2, §4)
Signer naming + ratification machinery + ratify-block/keyhole (People integration) (§3)
Reference reads + supersession watch (§5, §3.7)
Review register + variance (§6, §7)
Resource register (+ phasing fork) (§8)
Renders + first-read ledger (§9)
Composed-claims surfaces (§10)
Position templates + adoption + diff surface (§11)

Order rationale: the seal must exist before anything renders it; the gates must exist before the seal means anything; the register and renders consume both. 7 and 8 are parallel-safe after 6.

14.5 The day-two register handed forward¶

Hosted public-render feed/embed (§9.3) — its own channel-discipline brief
Overlay generation wiring on the intake spine (§5.6) — lands with intake consumers
Record migration of interim custody (§8.4) — a migration brief, data not design
Δ6 richer pattern analytics (§10.3)
Named as NOT promised (not day-two): automated delivery capture (§7) — the substrate does not exist; any future capture integration is a new model conversation, not a deferred feature
Out of tile, held so: third-party oversight mechanics (Record/ops — tas-01 §19); CRICOS / National Code Std 6 (parked, Landscape); s 231A horizon watch; per-assessor judgements (1.4(2)(b), out of perimeter, §4.6)

14.6 Coverage — every tas-00 row homed in a spec section¶

tas-00 rows	Spec home
G-1–G-5	§9.1 auditor render; §3.3's design-time discipline (the stat dec cheap to sign truthfully)
1.1-1, 1.3-1/-2/-3, 1.4-1 (reference legs)	§5.2, §5.3
1.1-2/-3/-4, Δ4	§4.2, §4.3; technique/tool references §5.2
1.1-5, 1.8-4	§4.8; custody §8.4
1.2-1/-2/-3	§6 (closure); §5.2 (loop); §10.1 (composed)
1.5-1…-7	§5.4 (clock, scope, conditionals); §6 (closure)
Δ1–Δ6	§3.3/§3.4 (Δ1-shaped claims); §5.5 (posture); §4.3 (Δ4); §4.9 (Δ5); §10.3 (Δ6); §5.4 (Δ2/Δ3 in the rendered scope)
1.8-1/-2/-3	§8.1–§8.3
2.1-1/-2/-3/-4	§9.3; §6.1 (comms flag)
2.2-1	§4.1; seam §5.6
2.3-1	§4.5
2.6-1	§4.10
3.1-1	§4.4; §10.2
3.2-1/-2	§3.3–§3.5; §2.2 keyhole
3.3-1/-2	§10.1 (currency leg); §4.12
4.2-1/-2	§9.2 + `tas_first_read`; `tas_signer_naming`
1.4-2	Out of perimeter, held so (§4.6; tas-01 §1A/§18)

14.7 The spec's exit¶

Tim's redline — done (2026-07-09; approval on full-bytes read, no change).
Ratification — done (2026-07-09; six design calls + the §3.3 precision confirmed).
The filing brief — Gate-1 digest anchor; single docs-only commit; nav registration alongside the TAS siblings (Research → Doctrine → Obligations → Model → Spec); METADATA-RECONCILIATION-AT-COMMIT for pointers (tas-01's pairs_with "not yet drafted" note; the draw-order ruling reference).
Build briefs — §14.4 order, each five-gate, behind LLND and RPL per the ruled draw order.

The TAS spec. Move 4 of the Legislation-to-Tile Method. Derives from tas-01-model (ratified 2026-07-09, pin 20b810f9… / 36,516 B) and answers tas-00-obligations (ratified 2026-07-09, pin 90e337a6… / 33,124 B); rulings R1–R9 canon; corrections C1/C4/C5/C6 inherited as applied at source. Instrument citations follow tas-00 §0 (clause / F2025L00354); byte-anchors to sources/… at repo HEAD 7d7fbbfb, paths re-verified against the working tree 2026-07-09 (post-6cf3242a). accreting-review-01-model read in full at draft and deliberately not consumed (§3.8). Drafted under the 2026-07-09 draw-order ruling: drafting pulled forward; ratification, filing, and build in their ruled slots.