Skip to content

TAS — Model

The legislation-grounded reasoning for the TAS tile — the why. Move 3 of the Legislation-to-Tile Method: the obligations map (tas-00-obligations, move 2) said what the RTO must demonstrate; this models the tile as the answer. The spec (tas-02-spec, move 4) derives from this document and points back to it; it does not restate it.

The single load-bearing fact, carried whole from move 2: no standard in F2025L00354 names a training and assessment strategy. The document is testimony, not compliance (doctrine §4). The obligations attach to outcomes; the tile exists because a residue of strategy-original obligations has no other home (R1); and everything else the strategy asserts is a live reference to another tile's state, never a copy.

The tile's formula, ruled at R1 and inherited by every section below:

The strategy tile is the author of reasons and composer of claims — never a custodian of facts held elsewhere.

Rulings R1–R9 are stated here, not re-argued; the arguments live in tas-research-01 Checkpoint 3. Reasoning cites tas-doctrine-01. Obligation anchors cite the instrument in tas-00's convention (clause / instrument), with byte-anchors to sources/… at repo HEAD 7d7fbbfb.


1. The strategy surface in one line

Strategy = (training product × cohort × mode) as delivered by this RTO → sealed, reasoned, signed baseline vN → live references + accreting review → reasoned revision → vN+1.

The tile's primitive is not a document — it is the Strategy: the RTO's designed delivery of a training product to a cohort in a mode, versioned as sealed baselines (R2's lifecycle, R3's seal). Its unit of state is product × cohort × mode as delivered by this RTO (R1's state axis): a distinct axis with a distinct lifecycle — it versions when a local decision changes, not when the training package does. A package version event is an input to review (§8), never an edit to a baseline.

Granularity is the RTO's design decision, recorded not prescribed: one product may carry one strategy spanning two modes with mode reasoning covering both, or two strategies where the cohorts genuinely differ. The tile records the decision; the spec binds the mechanics.

1A. The foundational rule: structural truth only

The tile asserts what it can know: that a claim is grounded in substrate, that an arrangement exists and is documented, named and dated, that a digest matches, that a signature was given. It never asserts what it cannot know: that an arrangement is adequate, that a judgement is sound, that testimony is honest (doctrine §8.1). Every element below carries exactly one of four roles, tas-00's vocabulary:

  • Original — authored reasons and design, owned here, versioned here, signed here.
  • Reference — a live read of another tile's state; never a copy, never re-bound.
  • Composed — pattern visibility over references; no new custody.
  • Out of perimeter — named and left where the law puts it (the 1.4(2)(b) judgement is personally the assessor's; the tile never carries it).

There is no code path in this tile that asserts a substantive judgement. The signer's ratification (§6) is the RTO's act; the keyhole (§7) demands a key exist and never judges it. This is the M6 hard line applied to governance, and it is what keeps "the system doesn't lie" true.


2. What the tile reads

  • rto-nrt-db (Pith, read-only always). Product identity (TGA code), composition and packaging, the component classes — including assessment_conditions, the machine-readable seed of the resource floor (§10) — and supersession lineage (supersedes / superseded_by), per the columns verified for the People and RPL models. The strategy authors none of it. The 1.1(2)(a) and 1.3(2)(a) conformance claims are reads against this substrate, which is why they are machine-checkable and why the strategy claims them by reference, never restates them.
  • People — through the contract, never the tables. People.canDeliver(person, training_product, activity) → { verdict, evidence, dimension_states }. Assignment claims (§7), validator credentials (§15), expert engagement records (§3).
  • Studio — version-true content state. Tool versions and their pre-use review ledger (1.3(2)(b)–(c)), techniques/activities/resources (1.1(2)(d)), the consultation-loop substrate (§14), authorship records (M1-amended: authorship as induction).
  • Record — the evidence shelf. Validation outcomes (1.5), clocked assurance artefacts (§10), placement risk documents (1.8(2)(c)). Subject to the phasing rider (§17).
  • RPL tile — recognition posture state (§12). Reference-render, never re-bind.
  • The shared candidate/intake spine — per-student pacing overlays (placement, credit) live there, not here (R6, M12).

3. The substrate — what the strategy authors (Original)

The residue R1 ruled homeless elsewhere. Each section is first-class authored content: versioned inside the baseline, ratified with it, signed by the named signer. Anchors are the obligation rows each section answers (tas-00 row numbers).

Substrate section What it holds Anchor (tas-00)
Cohort premise Who this delivery is designed for, stated concretely enough that the 2.2(2)(a) review has something to test against 2.2-1
Mode reasoning Cohort-aware reasons the mode enables attainment, argued against the ES factors (cohort; mode/resources/technology/facilities; industry expectations; breadth/complexity). Structurally entangled: references the provision design beneath it (§10) and the assessment posture above it (1.1(2)(b) ⇄ 1.8 ⇄ 1.4(2)(a)(iii)) 1.1-2
Pacing baseline The designed structure and pacing with its sufficiency reasoning across all four named activities (instruction, practice, feedback, assessment) — reasoned sufficiency, never nominal hours as compliance (tas-00 §2 silences). Carries the individualiser rules: placement (1.1(2)(e)) and credit (Δ4). Rules here; instances on the intake spine (R6) 1.1-3, Δ4
Load model Cohort × mode × pacing × product mix as a demand function — the 1.1(2)(c) activities are the demand 3.1(a) is tested against. Feeds the org-level staffing composition (§5) 3.1-1
Access model How and when students reach trainers/assessors, per mode; loops into the load model (promising access nobody is rostered to give fails 2.3 and 3.1 together) 2.3-1
Assessment posture The product's evidence-type mix and practical-setting claims — the system-level authenticity-weighting position included. The per-judgement rules of evidence stay out of perimeter 1.4-1 (posture leg)
Provision design Which resource legs (RTO / third-party / student-disclosed), which premises, which fallback for the student-provided leg — R9's middle leg, delivery design proper (§10) 1.8-2, 1.8-3
Placement conditional sections Surfaced only where the product requires placement (M8): the attainability claim (1.1(2)(e)) and the documented risk strategies and procedures — QA1's only mandated document 1.1-5, 1.8-4
Recognition connection statement How this product's intake connects the 2.2(2)(a) sensor to the 1.6 offer actuator (Δ5) Δ5
Wellbeing flag Design-time identification of wellbeing needs by reference to the training product content; support arrangements are operational, out of tile 2.6-1
Interpretive positions Reasoned, clause-traced positions where the instrument is open — first-class authored content with a lifecycle (doctrine §3) tas-00 §10
Expert justification Where 3.3(2)(b) experts are used: the by-reference-to-product-or-cohort, specific-need justification the law demands. The engagement record itself is People-held. The guest-speaker line is drawn here per product (M14) 3.3-2

The interpretive-position adoption model (new ruling, this draft — flagged for redline). The four registered positions (authenticity, access gap, 1.2 localisation, guest-speaker line) 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; adoption is a ledgered event. The product supplies the reasoning; the RTO owns the stance — signature is the source of the authority (doctrine §8.4), applied to interpretation itself. Positions carry two scopes: RTO-level (adopted once, cited by every strategy) and strategy-level (the guest-speaker line drawn per product).


4. The reference layer (Reference)

Every claim about another tile's domain is a live reference, never a copy (R1). The render therefore cannot say what the substrate contradicts — it holds no copy to contradict with. The reference classes:

Claim Referenced state Contract
Assignment claims (named person delivers/assesses) People canDeliver state People.canDeliver(person, product, activity); verdict snapshots seal at ratification (§7)
Tool and content claims Studio versions + the pre-use review ledger (1.3(2)(b)–(c)) Version-true read; a strategy citing an unreviewed tool renders that state truthfully
Product conformance (1.1(2)(a), 1.3(2)(a)) Pith Machine-checkable read
Validation state Record evidence (interim: §17 custody) Cycle position with a clock (§15)
Assurance evidence (1.8(2)(b)(i)) Record clocked artefacts Expiring-evidence pattern (§10)
Recognition posture RPL tile state Reference-render (§12)
Consultation dispositions Studio loop substrate Consumed as review inputs (§14)
Trainer industry currency People (3.3(a)(ii)) One leg of the 1.2(2)(c) composition (§5)

References are read live for working surfaces and pinned at read time for renders (§11) — the reference layer is what makes a render reproducible without making it a copy.


5. Composed claims (Composed)

Three obligations no single tile can own; the strategy composes them from references, holding no new facts:

  • Currency of training (1.2(2)(c)) — trainer industry currency (People) × product currency (Pith supersession) × the outreach record (Studio loop). Composed view, cited by the auditor render.
  • Staffing adequacy (3.1(2)(a)) — People roster × the load models of every live strategy. This composition is org-level by construction: the demand function sums across the strategy set; the honest small-RTO answer ("me, all hats, and here is why that carries this cohort") is a stated reasoning line over the same composition. The tile carries only the T&A staffing story (the services perimeter note, tas-00 §8).
  • Aggregate recognition integrity (Δ6; 1.6(2)(c)/1.7(2)(c)) — granting patterns over RPL tile state, reconciled against the stated posture at product level, or indicting it. Pattern visibility, no custody.

6. Lifecycle — sealed baselines, timestamped renders, the named signer (R3)

  • The baseline is the sealed artefact: the designed delivery including its reasoning, ratified and versioned. Divergence-as-information is incoherent unless "planned X" is citable at a version.
  • Renders are never sealed. They are generated, pinned to (baseline version, substrate read time), and therefore reproducible as at a date — which is what makes testimony defensible testimony (R3, R5 residue).
  • The RTO names its signer; the product records the naming. Ratification authority is not a fixed product role — a TAFE names a department head; a two-person RTO names the director who is also trainer and author. The naming record is itself 4.2(d) evidence (roles and responsibilities documented, accountable decision-making): the product generates compliance evidence from the accommodation.
  • The lifecycle is R2's loop: baseline vN → live record + accreting inputs (§8) → reasoned revision → vN+1, with reasoned no-change a valid closure — the instrument's own closure logic, applied to ourselves (doctrine §8.5).

7. The ratify-block and the keyhole (R4)

A strategy scheduling a named person asserts in writing that their People canDeliver state supports it (Δ1). The mechanism, ruled at R4:

  • Reality is recordable. Assignments can always be entered — denying the record of a real assignment doesn't prevent the assignment, it loses the record (the trainer-authorship finding generalised).
  • The contradiction is surfaced loudly. Working surfaces show assignment status truthfully; a strategy contradicted by its own trainer register is divergence-draws-findings at its sharpest, and the tile makes the divergence visible before an auditor does.
  • A baseline cannot ratify with an unsupported assignment except through the instrument's own exception path: the 3.2(2)(b) keyhole. The documented under-direction design — named director, assessment-judgement-block, dated — is the key. (Verbatim verified this draft: 3.2(2)(b) / F2025L00354 demands "systems in place that ensure the person does not make assessment judgements and is delivering quality training and assessment"; the named-director leg is Credential Policy state — director eligibility per CP §1E — read from People, not 3.2(2)(b) text.) The lock demands the key exist; it never judges the key. Veracity lies with the keyholder — the RTO and its named signer — because that is where the law itself puts it (doctrine §8.2).
  • The attestation import. A hollow key still costs the dishonest operator: the lie becomes a discrete, signed, dated, falsifiable artefact with a name attached, where before it was ambient fiction spread across rosters (doctrine §8.3). The honest operator fills the keyhole honestly at near-zero cost.

Two mechanics fixed at model level (both flagged for redline as new precision on R4):

  1. Named and designed-but-unnamed slots. The gate context (tas-00 §1) means a pre-delivery RTO ratifies a strategy for delivery it has not yet staffed. An assignment slot may therefore be designed-but-unnamed — carrying the credential requirement it will demand (which is exactly what the load model needs) — and a claim exists only when a person is named. Naming a person into a slot after ratification is a ledgered event tested against People at that moment; the baseline does not re-ratify for a naming that its design already provided for.
  2. insufficient_data is not a third path. At ratification, a named assignment is either supported (permitted) or keyed (documented 3.2(2)(b) arrangement) or the person is unnamed from the slot. An unevaluable verdict cannot ratify as "supported" — the system would be asserting what it cannot know. This is stricter than Never Block for the same reason RPL's signing gate is (rpl-01 §9): ratification is a signing act, not a planning canvas. Planning surfaces inside the tile inherit the amber nudge; the signature does not.

8. The accreting review register (R2)

The instrument's drafting signature is closed loops; all of them need somewhere to close. The register is the tile's accretion surface:

  • Inputs: industry-advice dispositions from the Studio loop (adopted / adapted / rejected-with-reasons — §14); validation outcomes (§15); variance patterns (§9); intake-sensor signals (2.2 review outcomes testing the cohort premise); product version events from Pith supersession (each carrying its 2.1(2)(e) comms-leg flag — students informed as soon as practicable; execution is operational, the flag and its disposition are tile state).
  • Closures: each input closes with a disposition; reasoned no-change is valid closure (1.2's own logic). The 1.2(2)(b) and 1.5(2)(g) loop-closure obligations discharge here — this is their modelled home.
  • Revision: the register periodically closes into a new baseline version — the reasoned-revision half of the lifecycle. Without the register the tile is a static document with better plumbing; with it, drift-is-information becomes operational.

9. The variance surface

"Planned X, delivered Y, because Z." The baseline is X at a citable version; the variance record captures Y and Z. Drift is not the sin — unexplained drift is (doctrine §4). The drift reference is the RTO's own documented rationale (the ES factors), never nominal hours.

The capture seam, stated honestly: the tile owns the variance record; the operational sources of "delivered Y" (session records, trainer surfaces, delivery systems) are outside it. The trainer is the actual author of delivered reality; the model's posture is authorship-capture, not surveillance — a variance entered by the trainer who made the call, with the reason, is first-class authorship (doctrine §8.4), and the trainer delivery brief (§11) is the natural surface for it. What the spec may not do is silently promise automated delivery capture the substrate doesn't have.


10. The resource register (R9)

Three legs, three governance regimes, one surface, no new substrate:

  1. The requirement floor — derived, never authored. Read from unit assessment_conditions (Pith). Identification below the floor is non-conformance on the face of the documents; the RTO reasons up from the floor to cohort quantities and mode (1.8(2)(a)).
  2. Provision design — strategy-original (§3). Which legs provide what (RTO / third-party / student-disclosed), which premises, the access position, and the designed fallback or intake-time test where the mode assumes student-provided equipment (the access-gap interpretive position). The student-provided leg is not governed by 1.8(2)(b) — it discharges as disclosure under 2.1(2)(c)(iv), which is a render obligation (§11), and as the intake-time test, which is an intake-spine seam (§13).
  3. Assurance evidence — Record custody, clocked. Certificates of currency, third-party agreements, walkthrough records: expiring evidence with clocks, the People expiring-credential pattern applied to premises. The 1.8(2)(b)(i) continuing-state obligation is honoured as written — the clock is the model's answer to "and will continue to be" — while the field's point-in-time audit practice is treated as posture (the layer divergence tas-00 surfaces and does not resolve).

The register surface composes all three legs so the operator never leaves it (Tim's pragmatic instinct, satisfied by the surface); custody stays uniform under the claim discipline (an assignment references People, a resource claim references Record — same law, same shape). Weaving-room formula: Studio is the content loom; the strategy tile is the delivery-design loom; Record is the evidence shelf.

For an online product, the platform is the facility (doctrine §6): the LMS enters the register as a provision-design entry with the same continuing-suitability clock as a workshop.


11. The three renders (R5 residue)

One substrate, three generated faces, structurally incapable of disagreeing; each pinned to (baseline version, substrate read time), each reproducible as at a date:

  1. The auditor view — the strategy render: substrate sections, reference states as read, composed claims, review register position, variance record. What the gate's "describe the rationale" questions are answered from.
  2. The trainer delivery brief (working label, ours) — assigned units, current sequence, version-true resources and tools, the trainer's own canDeliver state. Its ledgered first-read is close to a literal discharge of 4.2(2)(a) at trainer level (staff supported to understand the instrument components relevant to their role); the expansion co-developer's Studio collaboration record is the same evidence by authorship (M1 as re-anchored — the phantom 3.1 induction anchor is dead).
  3. The student/public information render — the 2.1(2)(c)(i) accessible-information list (duration, modes, location, commencement, scheduling, requirements to commence/complete, licensing implications, third-party arrangements) plus the 2.1(2)(c)(iv) student-obligations disclosure, 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)); one substrate, three faces is the structural answer.

12. The recognition seam (R8)

The posture itself — RPL via X; CT available/restricted because Y, the 1.7(2)(b) licensing parenthetical as a design-level fact — is RPL-tile state, reference-rendered, never re-bound. The strategy's original contributions are exactly two: the credit-adjustment rule in the pacing baseline (Δ4, feeding R6's overlays) and the sensor-actuator statement (Δ5: how this product's intake connects the 2.2(2)(a) review to the 1.6 offer). Aggregate integrity (Δ6) is composed (§5). The one-system statement (Δ2) and the validation-scope consequence (Δ3) are carried in the validation section (§15) — the strategy states the system's unity; the RPL arc holds the process.


13. The intake seam (R6)

The strategy owns the rules; the intake spine owns the instances. The cohort premise (§3) is what the 2.2(2)(a) suitability review tests per student; the individualiser rules (placement, credit) generate per-student pacing overlays living on the shared candidate/intake spine (M12) — student-record state, not strategy substrate. The tile stays clean of per-student churn; "fiction squared" (cohort-level pacing where placement individualises) is impossible because the overlay is the record.


14. The consultation-loop seam (R7)

The outreach mechanism is unit-anchored Studio substrate (M4): questions travel with the course, regenerate on package version; the generation record substantially discharges 1.2(2)(a)'s "demonstrates how it identifies and seeks." The strategy tile consumes dispositions (adopted / adapted / rejected-with-reasons) as review-register inputs and renders the closed loop — the 1.2(2)(b) discharge is the register's closure record (§8). Seeking advice, never outsourcing judgement.


15. The validation seam

  • The five-year ceiling is live law with a clock (C5, applied at source in tas-00): every product on scope validated at least once every five years, more frequently on risk, product change, or relevant feedback (1.5(2)(b) / F2025L00354). The strategy's validation section renders the product's cycle position by reference — a schedulable, per-product state read from Record. Risk-based scope (components, sample size — 1.5(2)(c)) is validation-system state, likewise referenced; accreted 1.2 feedback is already in the file when the validator opens it.
  • The perimeter includes RPL by definition (Δ2/Δ3): the s 4 definitions put RPL inside the assessment system, so the strategy's validation scope claim cannot be drawn around ordinary assessment only. The strategy states the system's unity; rpl-01 §14 supplies the sample from the RPL side.
  • Conditionals surfaced, not assumed: TAE products carry the independent-validation requirement (1.5(2)(d)); validators' collective competence and the Credential Policy §3 credential are People reads (1.5(2)(e)); the not-solely-determined rule (1.5(2)(f)) is a structural check on the validation record, not a judgement.
  • 1.5(2)(g) closure lands in the review register (§8).

The engine at this seam (the fence, stated once): the Credential Policy's credentials are held only by humans — the engine is never assessor, never validator-of-record, never signer. It is the instrument of the validator (analytical file preparation, sampling, mapping checks) and the generation substrate upstream in Studio. Engine-capability claims cite home-side receipts per FENCE-PROTOCOL-01; authorship stays home.


16. The data-domain ruling

Per the MANDARIN taxonomy and the HARD SEPARATION RULE:

Store Class Holds
TAS Peel pair (name binds at spec per cloudflare-naming-canon) Peel (per-env pair) Strategies, baselines (sealed, versioned, with reasoning), substrate sections, signer naming records, keyhole records, review register, variance records, render pins, first-read ledger, interpretive-position adoptions
rto-nrt-db Pith The bar: products, composition, component classes (incl. assessment conditions), supersession. Read-only always; KN sacred
People / Studio / Record / RPL Peer tiles Consumed through contracts and state reads, never through their tables

Customer-facing strategy surfaces read the Pith and the tile's own Peel stores; ops-db is never bound (customer surfaces bind ops-db never — standing rule, amended 2026-07-04).

The phasing rider (R9, settled). Record is specced, not deployed. If the TAS tile reaches build first, assurance-evidence custody is in-tile interim with a Record-shaped schema (evidence item, clock, ID — the People expiring-credential shape), so handoff is a migration, not a redesign. If that proves wrong in the builder, plan B is ratified with reasons — reasoned change and reasoned no-change are both valid closures, our own doctrine applied to ourselves.


17. The discharging events (the audit ledger)

Per NO ORPHAN GRAINS, chosen deliberately — read off the move-2 map, refined by this model. Events reference fields; fields carry instrument-qualified clauses; the clause is never copied onto the event.

  1. Signer named / changed — the RTO's naming of ratification authority; itself 4.2(2)(d) evidence (§6).
  2. Baseline ratified — the signing act — seals the substrate sections and their reasoning; captures assignment verdict snapshots and any keyhole records; blocked per §7 (discharges the demonstrability of 1.1-2/-3, 2.2-1's premise, 2.3-1, 3.1's story at design level).
  3. Keyhole recorded — the documented 3.2(2)(b) under-direction design: named director, judgement-block, dated (discharges 3.2-2 structurally).
  4. Person named into a slot — post-ratification naming, tested against People at that moment; verdict snapshot attached (Δ1's claim, dated).
  5. Interpretive position adopted / revised — the RTO's signed adoption of a stated position (§3; doctrine §3's lifecycle).
  6. Review input received — advice disposition, validation outcome, variance pattern, intake signal, product version event (with comms-leg flag) (§8).
  7. Review closed — disposition recorded; reasoned change or reasoned no-change (discharges 1.2-2 and 1.5-7 at closure).
  8. Variance recorded — planned X / delivered Y / because Z, authored by the person who made the call (§9).
  9. Render issued — auditor or student/public face, pinned to (baseline version, substrate read time) (2.1 accuracy by construction).
  10. Trainer delivery brief first-read — ledgered; close to a literal 4.2(2)(a) discharge at trainer level (§11).

Ten launch events. Reserved, named, not launch: resource evidence clock events (expiry/renewal — Record's events, referenced here; in-tile interim per the phasing rider mints them in the Record-shaped schema so they migrate as data, not design).


18. Answering the map — coverage

Every tas-00 row lands in a modelled home; none is silently dropped:

tas-00 rows Model home
G-1–G-5 (the gate) §11 auditor render (the "describe" answers); §7's design-time discipline is what makes the stat dec cheap to sign truthfully
1.1-1, 1.3-1/-2/-3, 1.4-1 (reference legs) §4 reference layer
1.1-2/-3, 1.1-4 (technique mix per cohort), Δ4 §3 substrate (mode reasoning, pacing baseline); §4 (technique/tool references)
1.1-5, 1.8-4 (placement conditional) §3 conditional sections; evidence Record-side (§10, §16)
1.2-1/-2/-3 §14 seam; §8 closure; §5 composition
1.5-1…-7 §15 seam; §8 closure
Δ1–Δ6 (recognition delta) §12 seam; §3 (Δ4/Δ5); §5 (Δ6); §15 (Δ2/Δ3)
1.8-1/-2/-3 §10 resource register (three legs)
2.1-1/-2/-3/-4 §11 student/public render; §8 (comms-leg flag)
2.2-1 §3 cohort premise; §13 seam
2.3-1 §3 access model
2.6-1 §3 wellbeing flag
3.1-1 §3 load model; §5 composition
3.2-1/-2 §7 ratify-block and keyhole
3.3-1/-2 §4 (currency reference); §3 (expert justification, guest-speaker line)
4.2-1/-2 §17 events 1 and 10 (generated evidence)
1.4-2 (assessor judgements) Out of perimeter, held so (§1A)

19. Deferral rulings carried (named so they are never silently assumed)

  • Third-party delivery oversight (4.2(c)) — argued now, as tas-00 §12 required: the strategy touches third parties only through the information surface (third-party arrangements disclosed at 2.1(2)(c)(i); the third-party provision leg and its clocked evidence at §10). Oversight mechanics — monitoring a third party's conduct of services — are an organisation-level obligation with no strategy-original residue; they belong to Record/ops surfaces, out of this tile. The tile renders that third parties exist and what they provide; it does not police them.
  • CRICOS / National Code Std 6 support staffing — parked (Landscape), unchanged.
  • s 231A horizon watch — carried; never our instruments' hook.
  • Detector arms race — the tile never rests any claim on AI detection (doctrine §9 watch, inherited).

20. What hardens from this model

  • Entity spine: the Strategy — (product × cohort × mode) as delivered by this RTO; versions on local decisions, never on package events (§1).
  • Structural truth only; four claim roles; no substantive assertion path (§1A).
  • Substrate = the authored residue: cohort premise, mode reasoning, pacing baseline + individualiser rules, load model, access model, assessment posture, provision design, placement conditionals, Δ5 statement, wellbeing flag, interpretive positions (adoption model), expert justification (§3).
  • Reference layer live, pinned only in renders; composed claims own no facts (§4–§5).
  • Sealed baselines with reasoning; renders pinned to (baseline version, substrate read time); RTO names its signer, naming = 4.2(d) evidence (§6).
  • Ratify-block with the 3.2(2)(b) keyhole; named vs designed-but-unnamed slots; insufficient_data blocks a named assignment; keyhole never judged, attestation import priced in (§7).
  • Accreting review register is the closure home for 1.2(2)(b) and 1.5(2)(g); reasoned no-change valid (§8).
  • Variance = authorship capture, not surveillance (§9).
  • Resource register: derived floor / original provision design / Record-custody clocked evidence; one surface; platform-is-facility (§10).
  • Three renders, one substrate, incapable of disagreement; first-read ledger = 4.2(a) evidence (§11).
  • Recognition reference-rendered; strategy adds only Δ4 + Δ5 (§12).
  • Rules here, instances on the intake spine (§13).
  • Loop Studio-home, closure here (§14).
  • Five-year validation ceiling rendered as a clock; perimeter includes RPL; engine = instrument of the validator, never signer (§15).
  • TAS Peel pair; Pith read-only; peers by contract; ops-db never; Record-shaped interim custody per the phasing rider (§16).
  • Ten launch discharging events; resource clock events reserved to Record (§17).
  • Coverage: every tas-00 row homed; 1.4(2)(b) held out of perimeter (§18).

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

  • Strategy granularity mechanics — how one product ↔ many strategies binds in data and UI (§1).
  • Store and surface naming — per cloudflare-naming-canon; boundaries fixed here, names bound there (§16).
  • Substrate section schemas — the structured shape of mode reasoning against the ES factors, the load model's arithmetic, the pacing baseline's calendar representation. The model fixes what each section must hold and reason; the spec fixes fields.
  • Render presentation — the auditor view's layout, the delivery brief's surface, the 2.1(2)(c)(i) public render's publication path (and whether it feeds the RTO's website directly — a spec question with 2.1(2)(a) accuracy stakes).
  • Review-register cadence — periodic-close scheduling, aging surfaces; the model fixes accretion and closure semantics only.
  • Ratify-block UX — how the block, the keyhole prompt, and the amber planning nudges present; the semantics are §7's and do not move.
  • Interpretive-position template packaging — how registered positions ship, version, and diff against an RTO's adopted copies (§3).
  • Variance capture surfaces — where the trainer enters Y-and-Z (delivery brief is the model's lean); no silent promise of automated capture (§9).
  • Configured policy values, deliberately not invented as model constants — review-close cadence defaults, render staleness warnings, clock-warning horizons for referenced assurance evidence.

The TAS model. Move 3 of the Legislation-to-Tile Method. States rulings R1–R9 (tas-research-01 Checkpoint 3, argued 2026-07-09); answers tas-00-obligations (ratified 2026-07-09); reasoning per tas-doctrine-01 (ratified 2026-07-09). Instrument text read at Layer 2 throughout: F2025L00354 per the project verbatim reproduction verified against the authorised PDF, with byte-anchors to sources/… at repo HEAD 7d7fbbfb (paths verified against the working tree at that HEAD, 2026-07-09). Corrections C1/C4/C5/C6 inherited as applied at source in tas-00 §9. The spec (tas-02-spec, move 4) derives from this document and points back to it — and sits behind LLND and RPL in the ruled draw order.