RTOpacks Workspace — Product Document¶
Document ID: WS-PRODUCT-01
Version: 0.8
Status: Living document — foundational product thinking; authoritative above all module specs
Location: docs/docs/workspace/product.md
Last updated: 6 July 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). |
| 0.8 | 6 Jul 2026 | Reconciled to the frozen launch scope and the three 2026-07-06 rulings (launch-motion, frozen-launch-scope, positioning). Added What the First Customer Buys — closes audit §1.1: the whole-product "fortress" launch motion, the SMB-RTO first customer, the displacement proposition, the closed-loop core, and the honest flag that the loop is a promise until the trust-proof is done. Added the regulated Course-Creation surfaces RPL and LLND to the module map and launcher mapping (LLN + digital-readiness merged into a single LLND tile; RPL takes its industry term; Attest / Foundation / Capability placeholders retired). Added Depth, not scope to the Governing Principles, and the regulated-surface refinement to Names earn the tap. Module-spec index de-versioned (points to module-specs/; the repo is truth). Build Status stanza retired for a live-truth pointer + a dated snapshot (it had gone three months stale — the exact currency-drift the audit flagged). Day-two set marked in What Sits Above the Spine. Exact launcher tile geometry left as a live-verify, not asserted. |
| 0.7 | 1 Jul 2026 | Governing principle added — "The engine raises hands; it never signs" (the canon anchor for the RTOpacks ↔ UCCA-engine relationship, filed immediately after "Amplify, don't automate", which it makes mechanical): RTOpacks is a client of the engine; the engine may raise a hand but never signs, authors, or blesses; the bar is "good," not "pass"; two modes (self-authored / assistive), one reasoner, the human always holds the pen and the sign-off. Points to the transient charter ENGINE-BENCH-CONTRACT-01 (banked). |
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¶
Spec versions live in module-specs/ — the repo is the source of truth, and this document does not track them (a hardcoded version here only rots). This document governs what the specs must say; the specs hold the detail.
The launch fortress — the modules that ship in the single coordinated release (frozen-launch-scope.md). Build state is a point-in-time note; the live launcher is truth.
| Module | Surface | Build state (as at 6 Jul 2026 — see live launcher) |
|---|---|---|
| Studio | Course design + assessment production | Deployed |
| People | Workforce compliance (Phase 1) | Deployed |
| Radar | Sector + competitor intelligence | Deployed (both expressions) |
| Record | Evidence layer (P1 library + P2 loop-close) | Specced — in build |
| RPL | Recognition of prior learning (dual-mode) | In launch scope — spec pending |
| LLND | LLN + digital-readiness learner gate | In launch scope — spec pending |
| the engine | Qual → content reasoning (UCCA) | Operative — trust-proof pending |
Day-two — fast-follow, not launch-critical: InstaLearn, the Creator / Campus / Marketplace general-learning stream, Record P3, the intelligence-row extensions (Landscape, Market Data, Marketer), the connectors (SMS Connect, LMS Connector), and Documents (merges into Record).
The exact launcher tile inventory and row layout are truth on the launcher, not here — verify against it before relying on any count (the LLN + digital-readiness merge into one LLND tile changed it).
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 modules exist together as one spine, 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 the First Customer Buys¶
This document has always said what the Workspace is. This section says what the first customer buys, and how it goes to market — the questions the canon previously left unanswered.
The launch is the whole product — "the fortress" — in a single coordinated release. Not a thin launch, not a staged drip of individual modules as small apps. The spine is conjoined by design: the modules consume each other, and stripping one drops the flagship surface back into the competitor category. The value is the totality — one integrated platform replacing several disconnected subscriptions — so the correct motion is to land high with the whole product, not to enter cheap and hope to upstack. (Full reasoning: launch-motion.md.)
The first customer is the small-to-medium Australian RTO (~3,000 in market). They feel compliance pain hardest — least dedicated compliance staff, most personal exposure at audit — and they already carry a stack of disconnected subscriptions (an LMS, an LLN tool, maybe an RPL bolt-on, a compliance-document system) that don't talk to each other. That stack is what RTOpacks displaces. There is no procurement wall; a founder can reach a decision-maker directly. TAFEs and universities are genuinely interested, but they are a 6–12 month procurement sale — deferred, not ignored.
What they buy is the complete fortress, integrated — displacement, not addition. Design and produce audit-defensible content (Studio + the engine); ground it in verified workforce compliance (People); gate the learner before training with LLN and digital readiness (LLND) and recognition of prior learning (RPL); evidence all of it in a live compliance record that produces the audit-ready artefacts (Record); and see the field (Radar). One platform replacing several bolt-ons. RTOpacks is not a new line on the card — it is the thing that deletes four others. The one deliberate boundary is student management: the SMS stays outside the fence (see What the Workspace Is Not).
The core proposition is the closed loop. A decision made in Studio, grounded in the RTO's real trainer data, the unit corpus and the engine, lands in Record as an audit-defensible artefact carrying full provenance — the Training and Assessment Strategy generated from the work already done, rather than typed into a template. The TAS is the document the auditor homes straight in on: "you said you'd do X, I see Y." When it is generated from the RTO's actual course, trainer and unit data, the auditor finds alignment, not gaps. No competitor has the loop — they have pieces; this is the piece that makes the pieces one thing. (Full reasoning: positioning.md.)
Honest flag — the loop's credibility is not yet proven. The engine is operative, but it has carried no production load and no human has yet read its output at scale. Until the trust-proof is done — output survives a mock audit, at load, human-read — the central proposition is a promise, not a demonstration. For a compliance product, wrong-but-confident output is worse than none. This gates when present-tense selling can begin, and it is one of the two tall poles the launch is built around; the other is TAS convergence, the artefact where the whole spine meets.
Two registers — do not blur them. The launch proposition above is what RTOpacks sells once the fortress is whole and the trust-proof is done. Pre-launch outreach — now — cannot sell a live product it does not yet have; its honest job is pipeline, pitch-validation and design-partner recruitment ("we're building this, want to shape it?"), never "buy this today." A present-tense claim the trust-proof has not yet earned is a promise the product cannot keep. The buyer persona above is reasoned, not field-tested; early replies are the test, and they are allowed to correct this document.
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.
Launch vs day-two. Of the above-spine modules, only Radar is in the launch fortress (deployed). Observatory is deployed infrastructure, not user-facing. The rest — Marketer, SMS Connect, LMS Connector, Landscape, Market Data, InstaLearn, and the Creator / Campus / Marketplace general-learning stream — are day-two: fast-follow, not launch-critical (frozen-launch-scope.md). They are described here because the thesis is unchanged by their timing; only their scheduling is.
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 workspace presents its modules in grouped rows — Intelligence, Course Creation, Learning, Integrations. Course Creation carries the compliance spine (Studio, People, Record) and the regulated learner-gating surfaces (RPL, LLND); Intelligence, Learning and Integrations carry the above-the-spine extensions. The spine/above-spine distinction is the architectural fact; the grouped rows are how it is presented. The exact live tile inventory and row layout are truth on the launcher, not here — verify against it before relying on a count (the merge of the LLN and digital-readiness tiles into a single LLND tile changed it). The glossary (WS-GLOSSARY) is organised by the 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.
Depth, not scope. The fortress governs breadth — the module set ships complete, because completeness is the proposition. It does not require every module at maximum depth on day one. Launch the complete set at launch-credible depth, then deepen in place. On contested, visible ground — a surface where a prospect compares us directly to an incumbent — the depth floor rises: be visibly deeper than the incumbent there, or concede the only argument that matters on that surface. Breadth is frozen (frozen-launch-scope.md); depth is earned, and it widens over time — which is the moat.
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.
Refinement for regulated surfaces. Where a tile names a compliance function the RTO already performs under a standard industry term — Recognition of Prior Learning (RPL), or the combined LLN + digital-readiness gate (LLND) — that term is the tap-earning name. Inventing an evocative word there would pretend the function is novel and cost the expert buyer a beat of recognition. So the launcher carries invented words for RTOpacks-invented surfaces (Studio, People, Record, Radar) and industry terms for known regulated functions (RPL, LLND). The register split is deliberate: for this buyer, the name that earns the fastest tap wins.
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 engine raises hands; it never signs.¶
RTOpacks is a client of the UCCA engine — the reasoning engine that relates instructional and assessment material to the requirements of a unit of competency. We build and control that engine; we nonetheless specify our relationship to it as a client, because the boundary is what keeps both honest. RTOpacks' requirements of the engine are potentially different from any other UCCA client's — because RTOpacks serves the regulated Australian VET market, where a human's professional judgement must sit on the record and survive audit. Another client of the same engine (general education, agent verification, any non-regulated domain) may ask the engine to do more. RTOpacks asks it to do less, on purpose.
The rule, which "Amplify, don't automate" implies and this makes mechanical:
The engine may raise a hand. It may never sign. It reads the human's work against what the unit requires and surfaces where it cannot trace how the material meets the requirement — an honest report of its own reasoning, not a verdict on the work. It never blesses ("this is compliant, ship it") and never authors the compliance-bearing content. The human holds the pen and holds the sign-off, always. The engine flags; the human decides; the decision is the human's, on the record.
This is why the output stays ownable, and ownable is what makes it auditable. An assessment the engine authored is compliance theatre the moment an auditor asks the trainer to defend their professional judgement and the honest answer is "the machine made it." An assessment the human authored — with the engine having only ever pointed at gaps the human then closed — is defensible, because the judgement was theirs throughout.
The bar is "good," not "pass." The engine holds what good looks like for a unit: what must be taught so the assessment is genuinely earnable, aligned to the legislative outcome, with the student's actual competence as the target. It measures the human's work against that bar. We do not aim at passing audit; we aim at the work being genuinely good, and defensibility follows as the by-product. A document that looks okay and might pass is not the standard. The standard is a document that teaches what the student must actually be able to do.
Two modes, one reasoner, one rule. The workbench offers a declared stance — self-authored (the human writes; the engine reads backward over the work and raises hands where it can't trace coverage) and assistive (the engine drafts forward to the bar; the human takes the pen and owns the result). Same reasoning, pointed in two directions. In both, the human holds the pen and the sign-off. The mode is the user's explicit choice and is itself on the record — the tool never makes a suspicious buyer trust an AI they did not choose to trust.
Live working detail: ENGINE-BENCH-CONTRACT-01 (charter, open). The engine's own foundation is
UCCA-FOUNDATION-01, in the separate UCCA project — RTOpacks and the engine live in separate
homes and connect only through the API contract, by design.
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¶
This document does not track build status. A hardcoded status list here only rots — the audit found this section three months stale, describing an April state as though it were current. Live build status is the launcher and Observatory. They cannot lie about what is deployed. Read them, not this doc, for what is currently shipped.
Snapshot as at 6 July 2026 (point-in-time, not maintained — for the current state, see the launcher): Studio, People (Phase 1) and Radar are deployed; Observatory and the sync pipeline (TGA, CRICOS, TEQSA, enrich) are deployed infrastructure; the engine is operative but not yet trust-proven under load; Record (P1 + P2), RPL and LLND are in the launch fortress and in build or spec.
WS-PRODUCT-01 v0.8 — RTOpacks — 6 July 2026
Living document. Add to it, don't replace it.
Module specs reference this document. This document governs them.