Skip to content

RTOpacks Workspace — Product Document

Document ID: WS-PRODUCT-01
Version: 0.6
Status: Living document — foundational product thinking; authoritative above all module specs
Location: docs/docs/workspace/product.md
Last updated: 5 June 2026


Changelog

Version Date Changes
0.1 14 Apr 2026 Initial — product thesis, module relationships, boundaries, governing principles
0.2 14 Apr 2026 Documents renamed to Record. Module name philosophy documented. Icon concept for Record captured.
0.3 17 Apr 2026 Module spec index updated to reflect all six app specs (Studio v0.6, People v0.2, Radar v0.2, Record v0.2, Documents v0.1, InstaLearn v0.1). Radar elevated from "market intelligence layer" mention to full module with deployed state. Build status section added.
0.4 14 May 2026 DOCS-SPEC-01 v0.1 archived (Documents → Record rename was incomplete at v0.2; this completes it). Documents fully retired as a module name; Record is canonical. Cross-references in product.md, index.md, and apps nav cleaned. Spec content preserved at docs/docs/archive/specs/docs-spec-01-v0.1.md.
0.5 3 Jun 2026 InstaLearn re-defined as the verifiable-but-unaccredited gen-ed microcredential (prior "credential issuance from compliant delivery" framing corrected). Non-regulated education stream documented (Creator, Campus, Marketplace) and Market Data added to the intelligence layer. External-validation note added (Newbery, cited not reproduced). Spine/above-spine thesis mapped onto the four shipped launcher groups.
0.6 5 Jun 2026 Four product/interaction principles added to The Governing Principles (WS-PRODUCT-PRINCIPLES-01): the production disappears; looked through, not at; theatre with purpose, never gamification; amplify, don't automate. The three disposition principles (reserved voice, amplify's thesis side, eccentricity-by-gaze) held for client-spine; colour-as-wayfinding shipped separately in Foundation §1.10/§1.11 (PALETTE-CANON-01).

How to Use This Document

This is the overarching product document for the RTOpacks Workspace. It sits above all module specifications and governs them. Where a module spec conflicts with this document, this document wins.

Module specifications (as of v0.4)

Spec Version Module Status
STUDIO-SPEC-01 v0.6 Studio Deployed — canvas home, qual tree, collab, clustering
PC-SPEC-01 v0.2 People Deployed — Phase 1 (Trainer Register + Compliance Matrix)
RADAR-SPEC-01 v0.2 Radar / Field Observer Deployed — crawl pipeline, Field Observer map, enrichment pipeline
RECORD-SPEC-01 v0.2 Record Spec only — not yet built
IL-SPEC-01 v0.1 InstaLearn Spec only — not yet built

It is not a technical brief. It does not tell Alex what to build. It tells everyone — including Alex, including Tim, including any future team member or partner reading the codebase for the first time — what RTOpacks is, why the three modules exist together, and what principles govern every decision made across the platform.

Read this document before reading any module spec. Read it before writing any brief. Read it when a design decision feels unclear and you need to know which direction is right.


The Module Names

The three spine modules are Studio, People, and Record.

These names are not descriptive labels. They are not subtitles. They do not explain what the module does — they earn the tap. The design language is tablet-first, Apple-influenced: icon plus single word, nothing more on the launcher tile. Exploration happens inside.

The names were chosen with this asymmetry in mind: Studio is a place. People are people. Record is both a thing and an action. That asymmetry is deliberate. It makes the launcher feel considered rather than formulaic, and it reflects the genuine difference in what each module is.

Studio — a place where work happens. Implies creativity, craft, production. Earns the tap without explanation.

People — direct, human, unambiguous. The module is about the humans in the system. The name is the thing.

Record — the noun and the verb simultaneously. The official record of what happened. And the act of capturing it. This double meaning is load-bearing. Record is where the compliance evidence is both made and kept. No other module name in the workspace carries this duality.


The Product Thesis

RTOpacks exists to solve one problem: an Australian RTO must be able to demonstrate, at any moment, that it can deliver nationally recognised training compliantly — and produce the evidence to prove it.

That problem has three inseparable components.

The content problem. The RTO must design and produce training and assessment content that genuinely satisfies the requirements of the units of competency on its scope — not content that mimics their structure, but content that is mapped to their performance criteria, knowledge evidence, and assessment conditions, contextualised to the industry context and student cohort the RTO actually serves.

The people problem. The RTO must demonstrate that the humans delivering that content are qualified to deliver it — credentialled against the Credential Policy, competent in the industry area of the units they teach, current in both their training and assessment practice and their vocational knowledge, and supervised appropriately where they are not yet fully qualified.

The evidence problem. The RTO must maintain the policies, procedures, and documentary evidence that surround that delivery — demonstrating that it operates within the Standards for RTOs 2025, that its systems are sound, that it monitors and improves continuously, and that it can produce a complete evidence package when ASQA arrives.

These three problems are not independent. Content without qualified people is undeliverable. Qualified people without compliant policies are unsupported. Policies without content are ungrounded. The three exist as a system or they do not work at all.

That system is the RTOpacks Workspace.


What the Workspace Is

The Workspace is a compliance spine — three modules that together constitute the operational and evidential infrastructure of a compliant RTO.

Studio is where training and assessment content is designed. It is where an RTO manager or trainer builds the qualification tree, selects electives, designs the clustering approach, maps content to unit outcomes, and produces the Training and Assessment Strategy. Studio is the source of truth for what the RTO delivers and how it has designed that delivery.

People is where the workforce is managed. It is where the RTO maintains the authoritative record of every person involved in training and assessment delivery — their credentials, their industry competency, their professional development, their supervision arrangements, and their compliance status against the Standards. People is the source of truth for who delivers the training and whether they are qualified to do so.

Record is where the evidence lives. It is the policy and procedure library, the repository for generated compliance artefacts, and the Standards mapping layer that connects all of it to the regulatory framework. Record is where Studio's outputs and People's data become the documentary evidence that satisfies ASQA's requirements. Record is not the source of truth for anything — it is where the truths held by Studio and People are expressed as evidence.

Together, these three modules answer the seven self-assurance questions ASQA uses to assess an RTO's compliance. Not by producing paper that claims compliance, but by maintaining the live system state that demonstrates it — and generating the evidence from that state on demand.


What Makes This Different

Every existing product in the VET sector solves part of this problem.

Generic authoring tools — Articulate, Captivate, iSpring — produce learning content. They follow the sequence of a unit's assessment documentation. They produce something that looks like training material. But the content is authorless in the compliance sense — there is no verification that the person who wrote it is qualified to teach it, no connection to the regulatory framework it is supposed to satisfy, no evidence infrastructure surrounding it. It is content without a spine.

Document management systems — NovaCore, SharePoint, Google Drive with a folder structure — manage policies and procedures. They version-control documents, track review dates, and in the better implementations, map documents to Standards clauses. But they are disconnected from the training design and the workforce. A policy can be green in NovaCore while the practice it describes is completely non-compliant. The system does not know and cannot know the difference because it has no connection to reality — only to documents about reality.

Workforce management forms — the Newbery Consulting training matrix, the supervision agreement template, the PD register — capture point-in-time snapshots of trainer compliance. They are manually completed, manually filed, and manually retrieved. They are paper logic inside Word documents, sold for $4,000 a set and obsolete the moment they are printed.

None of these products are wrong. They solve real problems for real RTOs. But they solve them in isolation, and isolation is the problem. An RTO using all three of these products still has to manually connect them. The connection is a human task performed at audit time under pressure.

RTOpacks makes the connection automatic, live, and permanent. The trainer assigned to a unit in Studio is the same person whose credentials are verified in People. The TAS generated from Studio's qual tree carries the provenance of both. Record's traffic light reflects the live state of People's workforce compliance data, not just the review date of the policy that describes it. The system is always connected. The evidence is always current. The audit preparation is always already done.

That is what no other product in the VET sector does.


External Validation — The Non-Accredited Demand Shift

The non-regulated education stream is not RTOpacks reasoning alone. An independent, respected sector voice describes the same demand shift: Joe Newbery (Newbery Consulting), "VET in the Age of AI and Automation" (25 Feb 2026), argues that AI and automation are changing the task mix inside jobs faster than the national framework (Jobs and Skills Councils, units of competency) can keep pace, and that short, non-accredited training — including verifiable microcredentials — is a credible bridge while the accredited system catches up. That independently supports the Creator / InstaLearn / Campus / Marketplace stream and InstaLearn's verifiable-but-unaccredited positioning. (Cited as external evidence, not reproduced. Disclosure for accuracy: Newbery discloses an ownership interest in one of the AI platforms his article references; the conflict is on the AI-tools side, not the gen-ed-training thesis we draw on.)


The Contextualisation Argument

There is a deeper argument for why this combination is not just convenient but necessary.

The 2025 Standards for RTOs are not primarily about paperwork. They are about self-assurance — the RTO's ability to demonstrate that its systems work, not just that its documents exist. ASQA's enforcement philosophy has moved decisively away from document auditing toward system auditing. The question is no longer "do you have an Assessment Policy?" The question is "how do you know your assessment system is working?"

That question cannot be answered by a document management system. It can only be answered by a system that knows what is actually happening — who is delivering, what they are qualified to deliver, how the assessment is designed, whether the content has been contextualised to the actual industry environment, whether the validation cycle is on track.

Contextualisation is the word that matters here. A unit of competency describes generic requirements. The RTO's job is to contextualise those requirements to its specific delivery environment — the industry sector, the student cohort, the workplace context, the available resources. Generic authoring tools produce generic content. RTOpacks produces contextualised content, because it knows the RTO's scope, their trainer base, their industry focus, and the specific elective mix they have chosen to deliver.

Without People and Record alongside it, Studio is a sophisticated content authoring tool — better than its competitors, but the same category of product. With them, it is something categorically different: a compliance engine that happens to produce learning content, grounded in verified workforce data and connected to the documentary evidence framework that makes the content auditable.

Strip either People or Record away and the product loses its argument. Content plus people without evidence is unregulated delivery. Content plus evidence without people is policy without practice. People plus evidence without content is administration without purpose. All three together is an RTO compliance system.


What the Workspace Is Not

The Workspace is not a student management system. Students have their own data domain — enrolment, results, completions, AVETMISS reporting, USI, fee management. That domain is owned by the RTO's SMS. RTOpacks does not replace the SMS. It connects to it, via SMS Connect, for the specific data points that are compliance-relevant. The student record stays in the SMS. The compliance infrastructure that governs how that student is taught lives in RTOpacks.

The Workspace is not an LMS. Learning delivery — content hosting, student access, progress tracking, completion recording — is owned by the LMS. RTOpacks produces content that is delivered through an LMS. It connects to the LMS, via LMS Connector, for delivery confirmation and completion data. It does not host learning for students.

The Workspace is not a marketing platform. Course brochures, website copy, student-facing marketing materials, and social content are produced by a different team with different skills and different system access requirements. The Marketer module — which sits above the compliance spine, not within it — consumes the outputs of Studio and People to produce accurate, system-grounded marketing content. But marketing is not compliance, and the compliance spine does not govern it.

The Workspace is not a generic compliance platform. RTOpacks is built specifically and exclusively for the Australian VET sector, governed by the Standards for RTOs 2025, the Credential Policy, and the CRICOS framework. That specificity is a strategic choice. The depth of compliance intelligence RTOpacks provides is only possible because the product is not trying to be general. General products are shallow. RTOpacks is deep.


The Module Relationships

The three modules share vocabulary, share data, and share events. The connections are not integrations bolted on after the fact — they are designed in from the start.

The shared vocabulary is the TGA unit code. Every unit of competency in the sacred corpus in rto-nrt-db has a code — SITHCCC023, BSBWHS411, TAEDES502. That code is the thread that runs through all three modules. In Studio, it identifies the unit in the qual tree. In People, it identifies the unit competency record that a trainer must hold to deliver it. In Record, it identifies the Standards clauses that govern its delivery. When Studio assigns a trainer to a unit, it queries People using that code. When Record generates a TAS, it references that code throughout. The code is the shared language. Without it, the modules cannot speak to each other.

The shared data flows in specific directions with specific ownership.

Studio → Record: generated artefacts (TAS, Audit Folder, clustering documentation, assessment mapping records). Studio writes, Record stores.

People → Record: credential documents, PD evidence, supervision agreements. People references, Record stores.

People → Studio: trainer compliance status, credential verification results, industry currency status. People owns, Studio queries.

TGA corpus → Studio and People: unit data, packaging rules, assessment conditions. The corpus is read-only for both.

Record → Observatory: Standards mapping status, traffic light state, artefact register data. Record owns, Observatory reads.

People → Observatory: workforce compliance status, expiry calendars, self-assurance signals. People owns, Observatory reads.

The shared event substrate is the activity log — the stub bus that begins in Record Phase 1 as a minimal heartbeat from each module, and evolves in Phase 2 into a full provenance chain for generated artefacts. Every significant action across the workspace emits an event. Record accumulates those events. The vault grows from day one, even before generated artefacts exist.


What Sits Above the Spine

The compliance spine — Studio, People, Record — is the foundation. Above it sit modules that consume its outputs and extend the platform's value without being part of the core compliance infrastructure.

Observatory is the intelligence layer. It reads across all three spine modules and surfaces the compliance picture — what is red right now, what expires in 30 days, what actions are outstanding, what the self-assurance system shows. Observatory does not own any data. It reads from the spine and presents.

Marketer is the market-facing layer. It consumes Studio's qual tree data and the TGA corpus to produce accurate, system-grounded course marketing content. It is operated by a different user tier to the compliance spine — the marketing team, not the compliance team — with different permissions and no access to People or the compliance layer of Record.

SMS Connect is the integration layer for student management. It pulls compliance-relevant signals from the RTO's existing SMS without replacing it or duplicating its data.

LMS Connector is the integration layer for learning delivery. It connects RTOpacks content outputs to the LMS environment, and pulls delivery confirmation and completion data back into the compliance picture.

Radar, Landscape, and Market Data are the market intelligence layer. Radar and Landscape use the RTO's scope and delivery configuration — drawn from Studio — to surface competitive intelligence, sector trends, and market positioning; Market Data surfaces macro labour-market context (ABS, NCVER, TGA).

InstaLearn is the verifiable-microcredential layer for the non-regulated (general education) stream. A short course authored in Creator issues, on completion, a verifiable but non-accredited microcredential under the RTO's white-label brand. The verification is the value — a genuine, checkable credential a step above an ordinary general-education course. It is deliberately not a nationally recognised AQF qualification; accreditation belongs to the regulated spine. Verifiable, not accredited — and that is correct, because this is GenEd.

Creator, Campus, and Marketplace are the non-regulated education stream, sitting beside InstaLearn. Creator is Studio with the regulated scaffolding removed — general-education authoring with no TGA unit reference. Campus is RTOpacks' own white-labelled LMS, gen-ed only, provisioned per-RTO on the RTO's domain and fed from the core via LTI; regulated delivery never touches it (that goes out through LMS Connector to the RTO's existing LMS). Marketplace licenses created courses on to other producers. This stream is non-regulated and lives in rto-micro-db — the HARD SEPARATION line runs between it and the compliance spine.

None of these modules are part of the compliance spine. All of them depend on the spine being sound before they are useful. An Observatory with no data from Studio, People, and Record has nothing to surface. A Marketer with no qual tree has nothing to describe. The spine is the foundation. Everything else is built on top of it.

Mapping to the launcher. The shipped workspace presents four groups — Intelligence, Course Creation, Learning, Integrations. This thesis is unchanged by that presentation: Course Creation is the compliance spine (Studio, People, Record); Intelligence, Learning, and Integrations are the above-the-spine extensions distributed across three groups. The spine/above-spine distinction is the architectural fact; the four groups are how it is presented. The glossary (WS-GLOSSARY) is organised by the four groups; this document keeps the spine framing.


The Gaps the Spine Does Not Yet Fully Own

Three compliance obligations exist in the Standards that the current three-module design does not fully resolve. They are not missing modules — they are surfaces that need design decisions before Phase 2 begins.

Validation. Standard 1.5 requires assessment system validation on a five-year cycle. Validators must hold specific credentials (tracked in People). Validation records are documentary evidence (stored in Record). But the validation process itself — scheduling cycles, recording outcomes, assigning validators to training products — has no dedicated surface yet. This likely belongs as a surface within Record, drawing on People's credential data to confirm validator eligibility. It must be resolved in Record Phase 2 design.

Third-party arrangements. Standard 4.2 requires ongoing monitoring of third parties delivering on the RTO's behalf. Third-party trainers are in People. Third-party agreements are in Record. But the monitoring process — site visits, performance reviews, agreement renewals — spans both without a clear owner. This also likely resolves as a Record surface with People integration. It must be designed before the third-party trainer workflow is built in People Phase 2.

The unified review and scheduling system. Every compliance obligation has a cadence. Policy review cycles in Record. Trainer currency checks in People. Validation cycles. Third-party agreement renewals. TGA scope changes. These schedules are currently distributed across modules. There is no unified "what is due when" surface that looks across the whole spine and tells the RTO manager what they need to do this month. This belongs in Observatory. It must be designed in Observatory Phase 1.


The Governing Principles

These principles apply across all three modules. They are stated once here and not repeated in module specs. Where a design decision is unclear, these principles are the tiebreaker.

Never block, always nudge. No module requires another module to be complete before it works. An RTO can start in Studio before People has a single trainer. They can start in Record before Studio has a single session. Incomplete data is collected, flagged, and surfaced as a task — never as a barrier. Progress is always possible.

Integration felt, not seen. The three modules are one system in the user's experience. There are no "import from People" buttons, no "sync with Studio" confirmations. The data flows silently. The trainer assigned in Studio is the same trainer whose credentials are verified in People. The RTO manager experiences this as the system being smart, not as a technical integration.

Truth before paperwork. The artefact is downstream of the reality. People is the source of truth for workforce compliance — not the policy that describes it. Studio is the source of truth for training design — not the TAS that records it. Record derives its authority from the live system state, not the other way around. A green traffic light means the underlying reality is compliant. A document that says the right things while the underlying reality is non-compliant is not evidence — it is liability.

The trust bridge. Record exists partly to make the system legible to people who need to see familiar artefacts before they trust an unfamiliar system. The policy document, the version number, the review date, the printable audit report — these are not legacy concessions. They are the interface between a new compliance system and the humans who have spent twenty years in the old one. Respect that interface. Do not discard it.

Depth without overwhelm. The system holds extraordinary depth — provenance chains, event logs, Standards mappings, version histories, cross-module relationships. That depth must be surfaced progressively. The day-to-day view is the mixdown. The audit view is the tracks. The system always maintains the full depth. It reveals it only when the context demands it.

The spine is specific. RTOpacks is built for the Australian VET sector and nowhere else. The depth of compliance intelligence it provides is only possible because the product has refused to be general. Generality is the enemy of depth. Every time a design decision tempts the product toward generality — another framework, another sector, another country — this principle is the reason to say no.

Names earn the tap. The launcher tile is an icon and a word. Nothing more. The name does not describe the module — it invites entry. Studio is a place. People are people. Record is both a thing and an action. If a name needs a subtitle to be understood, it is the wrong name.

The production disappears. The interface stages, then recedes. A surface can be the most beautiful thing in its category precisely because its job is to carry the user in and then get out of the frame. A production the user is still admiring while they work has failed — it has stolen the scene from the person it was meant to hand it to. Measure any staging by how completely it vanishes once the user is working.

Looked through, not at. A tool that keeps demanding attention — alerts, "you should", streaks, nudges — is insisting on being the protagonist. RTOpacks wants the user to forget it is there and watch their own work fill the screen. Wanting to be looked through rather than looked at is the opposite of capture, and it is the test for any feature that asks for the user's notice.

Theatre with purpose, never gamification. Serious software has been drab because engagement was expensive to build, so it was rationed to products where engagement was the point. That cost has collapsed. RTOpacks brings staging, tension and resolution to a category allergic to it — but always in service of purposeful output, never entertainment for its own sake. Spotlight the moments that matter; stay plain and fast on the surfaces a user touches a hundred times a day. The skill is timing, not spectacle on demand.

Amplify, don't automate. A tool empowers when it removes the incidental difficulty — operating it, scaffolding a compliant structure from nothing — and hands back the essential difficulty, the user's own judgment, amplified. The failure mode of AI tooling is the reverse: doing the thinking and leaving the human to clean up after it, which demotes the author to a reviewer. The judgment calls stay the human's. This is why the output stays ownable — and ownable is what makes it real, which is what makes it auditable. (Reads with "Truth before paperwork".)


The Product in One Sentence

RTOpacks is the compliance spine for Australian RTOs — the system that makes training and assessment content legitimate by grounding it in verified workforce data and connecting it to the evidence record that makes it auditable.


Build Status (as of session 63, 17 April 2026)

Deployed and functional

Studio — Two-column canvas home (On Scope / Proposed Scope) with TGA-generated skeleton nodes. Persistent RTO context banner. Click-to-create session flow. Qual tree canvas with core units, elective selection, real-time validation, clustering, collaborative editing via Durable Objects. Scope API reads TGA registration data via internal-api service binding. Proposed Scope workflow with TGA search. Old entry gate removed.

People — Trainer Register with four compliance dimension indicators (Credential, Vocational Competency, Industry Currency, T&A Currency). Person detail with credential records, vocational competency table (TGA unit search), CPD log (TA/VC/VET types), supervision placeholder. Compliance Matrix (persons × qualifications) with cell states and CSV audit export. Stub receiver for Studio integration. UCCA test client wired end-to-end with magic link auth.

Radar / Field Observer — Crawl worker (sitemap-first: robots.txt → sitemap → URL classification → platform detection). Field Observer React Flow topology map on admin RadarTab with progressive disclosure. Enrichment pipeline for bulk Layer 2/3 capture (screenshots, SSL, fingerprints, compliance signals, third-party domains, link resolution, HTML archive). 80+ signal taxonomy across 5 layers. Three screenshot lifecycle modes (bulk local, monthly refresh, ad-hoc per-RTO via CF Browser Rendering).

Specced but not yet built

Record — Policy and procedure library, compliance artefact generation, Standards mapping, audit evidence infrastructure. Spec at v0.2.

InstaLearn — Credential issuance. Spec at v0.1.

Infrastructure modules (deployed, not user-facing)

Observatory — Admin sync monitoring dashboard with per-worker cards, ingestion log, watchdog. Deployed since session 55.

Sync pipeline — TGA sync (queue-chain), CRICOS sync, TEQSA sync, enrich-sync (Saturday cron). All deployed with SENTINEL-02 volume/structural checks.


WS-PRODUCT-01 v0.5 — RTOpacks — 3 June 2026
Living document. Add to it, don't replace it.
Module specs reference this document. This document governs them.