The Legislation-to-Tile Method¶

Where legislation meets activation.

Every RTOpacks tile that touches a regulated surface exists for one reason: to be the operational response to a piece of law. The law says what an RTO must demonstrate; the tile is how the RTO demonstrates it. This document is the harness that frames that work. It does not do the thinking — it sets the bars the thinking must clear, in the order it must clear them, before a regulated tile is specced.

This method runs front of build. It ends where the build gates begin. The thinking about what is in the tile happens inside this harness; the harness makes sure that thinking is framed by the legislation from the first move, not reconciled to it afterward.

The principle this serves¶

The whole system exists to serve the legislation. An RTO's business is to stay registered; to stay registered it must pass audit; to pass audit it must demonstrate compliance against the Standards. So RTOpacks is built as two layers with a fixed contract between them:

The law — the Act, the Outcome Standards, the Compliance Requirements, the Credential Policy. Verbatim, versioned, dated. Not ours. It changes on its own schedule.
The tile — fields, rules, evaluators, evidence artefacts. Ours. Each one exists because a specific obligation in the law requires it.

The relationship between the two layers is the asset. Because every field traces to a clause, when the law moves we can diff it and know precisely what the tile must grow. The law changing is not a threat we scramble against — it is a structured input with a defined response. That is the upgrade path, and it is built into how we develop, not bolted on after.

The four moves¶

A regulated tile is specced in four moves, in order. Each move produces an artefact. You do not proceed to the next move until the current move's artefact exists.

1. Research — read the law as primary source¶

Pull the governing instruments for this tile as primary sources — the verbatim text, not a summary of it, not memory of it, not last session's prose about it. Standards, clauses, sections, the Credential Policy where it applies. Read them in full.

Produces: confirmation of which instruments govern this tile, read against the bytes.

2. Obligations — extract the checklist¶

From the primary sources, extract every discrete obligation and every self-assurance question as a flat checklist of things the RTO must be able to demonstrate. One line per obligation. Named to its clause. This is the tile's acceptance surface — the tile is not done until it can answer every line.

Produces: the obligations checklist. This is the spec's acceptance criteria, written before the model.

3. Model — the tile as the law's response¶

Model the tile as the answer to the checklist. What entities does it hold? What does it ingest, what does it hold as evidence, what does it derive? Where the law specifies a decision (e.g. the Credential Policy's mapping of activity + training product → acceptable credentials), the tile implements that decision as an evaluable function, not as stored prose. Where a tile depends on another tile, name the contract.

Produces: the model — entities, evidence, derivations, contracts.

4. Spec — bind every field to its clause¶

Write the spec. As each field is authored, it carries its trace (see CLAUSE-BOUND FIELDS below). The spec is complete when every line of the obligations checklist is answered by a modelled, clause-bound surface — or carries a principled out-of-scope or deferral decision.

Produces: the spec, ready to build. Hand off to the build gates here.

Artefact naming convention¶

Each regulated tile's moves produce a numbered document family sharing the tile's stem, ordered by move:

{tile}-00-obligations.md — move 2 (the acceptance surface)
{tile}-01-model.md — move 3 (the legislation-grounded reasoning — the why)
{tile}-02-spec.md — move 4 (the build — the what — derived from the model and pointing back to it) — canonical
{tile}-03-companion.md — post-spec (the operator's plain-English companion — what it is, how it works, where the build's at) — derived, not canonical

The number encodes both the dependency and the read order: the model derives from the obligations; the spec derives from the model; the companion derives from the spec and the build. The family travels as a set — legible as one family at a glance, which matters because the human holding continuity across sessions needs the linkage carried in the filenames, not only in the contents.

Research (move 1) produces no family member. Its output is the confirmation of which instruments govern the tile, read against the bytes — recorded in the obligations doc's provenance, not a separate file. The instruments themselves already live as the held reference reproductions (standards-outcome.md, credential-policy.md, etc.). The numbered moves are 2–4; the companion (-03) is the one family member that is not a move (see below).

The model (-01) is durable — it changes only when the law changes. The spec (-02) changes as the product evolves. Keeping them as two documents is what preserves the diff-against-the-law upgrade path: when the law moves, diff the model; when the product changes, revise the spec. They do not tangle.

The companion (-03) is born after the spec hands to the build gates — it is not a move of the method, it is the living-state record the build keeps. The spec says what the tile must be; the companion says what it currently is — what's built, what the operator can do today, where the gaps are. It is plain-English (no clause traces), derived, and makes no claim to canon: when companion and spec conflict, the spec wins and the companion is corrected. It is expected to move as the build moves — that motion is its job, not drift.

Scale note: twenty regulated tiles → eighty documents (four per tile: three numbered moves + the companion).

The one rule that binds: CLAUSE-BOUND FIELDS¶

Every field on a regulated surface carries a structured, stored trace to its legislative anchor:

the anchor — the named clause within its instrument (e.g. "Standard 3.2(a) / F2025L00354"). The instrument identity is always part of the anchor — never a bare clause number. See FOUNDATION SLOTS below;
the obligation — the plain-English statement of what it answers and why it matters;
the consequence — what fails in audit if it is absent or wrong.

The trace is authored as fact, in the same act as the field. Never generated at runtime. Never backfilled.

Stored-not-generated is the point. In audit, a fixed checkable claim anchored to a clause is evidence; a runtime explanation is chatter. The system shows its working, and the working is the same every time and traceable to the law. That is the posture auditors reward and the posture compliance software almost never holds.

Authored-now-not-later is also the point. The trace authored at the moment of building the field — when the architect holds the clause, the intent, the field, and the consequence in mind at once — is more truthful than any trace reconstructed later, regardless of effort. Deferring does not just cost more; it produces a worse, less trustworthy artefact. This is the cheapest the trace will ever be to author correctly.

One source, two consumers:

Knowledge Navigator reads the trace outward, to the user — tap a field, see the named clause and the plain-English why.
The upgrade path reads the trace inward, to the maintainer — bump the law version, diff it, and the anchors surface exactly which fields the change touches.

Knowledge Navigator is not a layer applied over the tile afterward. The trace is its content. Building the tile and building Knowledge Navigator are the same act.

A field on a regulated surface without its trace is incomplete and does not pass.

The grain over time: NO ORPHAN GRAINS¶

CLAUSE-BOUND FIELDS is the binding seen across the schema — every field anchored to a clause. The same binding seen across time is a stronger claim:

NO ORPHAN GRAINS — Nothing enters a regulated surface unanchored. Every field, every action, every artefact carries (or inherits) a trace to the obligation it discharges. A thing that cannot be matched to a clause has no place in the system.

A field's anchor is structural — true by design, the moment the field exists. An action's anchor is historical — a fact about what happened: on this date, this person did this thing, which discharged this obligation. The two combine to make the system its own audit trail: origin to end, every grain mapped to the law it answers.

The rendered proof of this is the audit ledger — the origin-to-end replay that establishes the veracity of an RTO's documentation before an auditor reads the content. But note what the ledger is: the system itself is the audit. The ledger is a report writer over data already captured. You do not build the report early. You build the capture correctly, and the report is a read over it, called when there is something to say. The only thing that must be certain is that the data is in there when the report writer is called.

Two non-negotiables make this scale instead of collapse into a warehouse of rice:

Events reference fields; fields carry clauses. Never copy the clause onto the event. One clause anchor per field (a few hundred), inherited by any number of events (millions, for free). Copying clauses onto events creates stale historical references the moment the law changes, and destroys the provenance the ledger exists to provide.
Discharging events are chosen deliberately, per tile, at the modelling move — never by defaulting to "log everything." Which events discharge an obligation is itself legislative reasoning, and it is small: a handful per tile. Entering a credential discharges an obligation; toggling a panel does not. An over-emitted ledger is noise, and noise destroys the product's value faster than silence — an auditor distrusts a ledger of ten thousand meaningless lines.

The set of discharging events for a tile is not guessed. It falls out of the obligations checklist (move 2): the checklist says what must be demonstrated; the discharging events are how each obligation is demonstrated over time. The ledger is the time-axis of the checklist.

FOUNDATION SLOTS — cast now, cannot be retrofitted¶

Most of this method can be deepened later. Three things cannot be added after the fact and must be present from the first field. These are foundation slots: cheap to cast now while the concrete is wet, impossible to chip in once it sets.

1. Instrument-qualified anchors¶

A clause reference always carries its instrument. The anchor is never "3.2(a)" — it is "3.2(a) within F2025L00354." A bare clause number is a pointer with no address: instruments change, clauses renumber, and "3.2" under one instrument is not "3.2" under another. The instrument identity is part of the anchor, always.

This is the one slot that genuinely sets in the pour. If fields are anchored to bare clause numbers now, the corpus of anchors has no instrument identity and no honest way to recover which law it meant — untangling it retroactively is guesswork. Carrying the instrument costs a slightly longer string now and nothing later. It is non-negotiable from the first field.

2. The obligation as the stable primitive (named now, built later)¶

What persists across instruments is not the clause number — it is the obligation. "A trainer must hold the credentials specified for their activity" survives renumbering, rewording, and restructure; only its clause expression changes. The robust model is three layers, not two:

Instrument — versioned, dated, legal ID (e.g. F2025L00354). The verbatim law.
Obligation — the stable concept. Persists across instruments.
Clause — the obligation's expression in a specific instrument. What a field anchors to. Historically true forever.

A field anchors to a clause (instrument-specific). The clause belongs to an obligation (stable). This three-layer model is named now, not built now — the instrument-qualified anchor (slot 1) is what makes it buildable later. Do not build the obligation layer in this session.

3. Concordance (named now, built later)¶

When the law transitions, historical anchors are never mutated — a field built against the 2017 instrument was built against the 2017 instrument, and that is a fact about history that must stay true forever. Instead, a concordance records how each obligation carried forward: old clause X maps to new clause Y; one clause split into two; this new clause about digital delivery has no predecessor. The past stays true; current governance is derived forward through the concordance.

The concordance is itself the migration audit trail — the defensible answer to "your evidence is from 2024; how does it satisfy the 2025 Standards?" The answer: here is the artefact, anchored to the law as it stood when created, and here is the concordance showing the obligation's lineage to today's instrument. This is named now, built when a transition actually occurs — and it is only buildable because slot 1 put the instrument on every anchor.

The tax, named honestly¶

This method makes every field on a regulated surface cost more. You cannot sketch a schema and backfill meaning; every field arrives with its clause, its why, and its consequence before it is done. For most software this would be overkill. For this product — whose entire value is the legislative grounding — it is the product being built correctly the first time. It is the right tax, and pre-revenue, neck-deep in the legislation, is the cheapest it will ever be to pay.

Where this hands off¶

This method ends at spec ready to build. From there the work enters the existing build discipline — the gates, the brief drip, one cut at a time — defined in standing-rules.md. The method is the front half that frames the thinking; the gates are the back half that controls the build. The two meet at the spec.

The companion (-03) is a product of that back half — the build's plain-English running record, written once a tile has enough built to describe and kept current as the build moves (see the artefact naming convention above). The tile document-family lifecycle is also recorded as a standing doc-pattern in standing-rules.md (Documentation discipline) so no future tile reinvents it.

Deferred work register — named now, built later¶

Surfaced during the forging of this method. None built this session. Each is foundation we benefit from manually today (the instruments are already held as structured reference docs and are already in use), and must be tied together programmatically up ahead. Marked here so nothing is lost.

#	Item	Status	Note
1	Instruments as held objects	TO BUILD	Versioned, structured, addressable instrument objects in the system — the address space anchors resolve into, and the precondition for concordance. Already exist as structured reproduction docs (e.g. `standards-outcome.md`, `credential-policy.md`); the deferred work is making them first-class runtime objects. Source from authoritative legislation text — never OCR; transcription error in the law corpus is a baked-in compliance defect.
2	Obligation layer	TO BUILD	The three-layer instrument / obligation / clause model. The obligation is the stable primitive that persists across instruments. Buildable only because slot 1 (instrument-qualified anchors) is cast from the first field.
3	Concordance	TO BUILD	Maps obligations across instruments when the law transitions. Historical anchors never mutate; current governance derived forward. Hybrid authority: regulator-published mappings are authority; RTOpacks-authored mappings are marked as interpretation, dated and attributed — never presented as regulatory fact.
4	Instrument library surface	TO REVIEW	Browsable reference of held instruments for admin L4 / T3 / T4 / T4A. A render over slot 1, not foundation. Valued (esp. for users who still reference source material directly); built after the substrate holds instruments as objects. Verbatim law, marked as verbatim.
5	Audit ledger report	TO BUILD	The origin-to-end rendered replay. A read over captured discharging events (NO ORPHAN GRAINS); built when the substrate has enough to say, not early.

Canon placement¶

This document is the method. It is canonical and sits peer to standing-rules.md.
CLAUSE-BOUND FIELDS and NO ORPHAN GRAINS are filed as standing rules (build standards, checked at review).
Instrument-qualified anchors (foundation slot 1) is filed as a standing rule — non-negotiable from the first field.
The decisions behind these — stored-not-generated, one-binding-two-consumers, events-reference-fields, the three-layer instrument/obligation/clause model, concordance-not-mutation — are filed as ADRs (the reasoning, so settled questions stay settled).
The obligation layer and concordance are named foundation, deliberately deferred — built when needed, buildable only because the instrument is on every anchor.
The method refers to canon; canon refers back to the method. The People tile is its first worked example.