RTOpacks Studio — Product Specification¶

Document ID: STUDIO-SPEC-01 Version: 0.6 Status: Living document — captures current product thinking, not a finished design Location: docs/workspace/apps/studio.md Last updated: 17 April 2026

Changelog¶

Version	Date	Changes
0.1	13 Apr 2026	Initial — entry flow, gate model, import flow, trainer assignment, core principles
0.2	13 Apr 2026	Canvas structure, qual tree visualisation, elective selection interaction, real-time validation, RTO card enrichment
0.3	13 Apr 2026	Clustering — declaration, definition, three integration levels
0.4	15 Apr 2026	Entry flow expanded — scope setup, sequential qual configuration, unit-in-isolation path, clone framework, gate language finalised
0.5	15 Apr 2026	Collaborative editing model — presence, concurrency, timeout, canary flag, audit trail shape
0.6	17 Apr 2026	Entry model rewritten — prompt/gate removed, replaced with two-column canvas home (On Scope vs Proposed Scope), TGA-generated skeletons, eye-toggle visibility filter, scope-size threshold rule, RTO context header, RTO card Studio activity stub. Supersedes v0.4 entry flow and relevant parts of v0.1.

How to Use This Document¶

This spec is the full-picture reference for Studio. Every build brief that touches Studio references it as source of truth.

It is not a technical brief. Briefs reference this document; this document does not constitute a brief.

v0.6 is a clean-slate rewrite of the entry flow and home surface. Earlier entry/gate/prompt models from v0.1–v0.5 are explicitly superseded. The canvas structure, collaborative editing model, clustering, import flow, and pipeline sections from earlier versions remain current and are retained below.

Alex: read this document before touching any Studio code. The briefs tell you what to build. This document tells you why, and what "Studio" actually is.

What Studio Is¶

Studio is the course design and content production environment for RTOs. It is where a trainer or RTO manager designs, maps, audits, and produces training content for nationally recognised training (NRT) programs.

But Studio is more than a course builder. It is the hub of the entire Workspace. Every other application — People & Culture, Radar, Market Data, Document Manager, Trainer Mapper — either feeds into Studio or is fed by it. When a trainer assigns a person to a unit, Studio reaches into People & Culture. When an elective mix is selected, Radar knows which competitors offer the same combination. When content is built, it feeds the Audit Folder automatically.

The integration should be felt, not seen. No "click here to go to People & Culture." No "import from Radar." The data flows, the connections exist, and the user experiences it as the system being smart.

What Studio Is Not¶

Studio is not a PowerPoint builder. It is not a document editor. It is not a compliance checkbox exercise. It is a tool that covers every compliance surface on every pass — and tells the user exactly what they need to fill in to make their content bulletproof before ASQA does.

The value proposition in plain English: we'll tell you what you're missing before ASQA does.

Core Design Principles¶

1. Never block, always nudge¶

Studio cannot require other Workspace modules to be populated before it works. An RTO will come in cold and start building — that has to work. If People & Culture has no trainers, Studio doesn't stop. It collects what it can, creates stubs in the background, and flags what's incomplete. Progress is never gated on completeness elsewhere.

2. The integration should be felt, not seen¶

Studio is the place where everything converges. But the user should never feel like they're switching between tools. When they type a trainer's name, the system knows who that is. When they select a qual, the system already knows their scope. The intelligence is invisible.

3. Ask questions like a consultant¶

Studio doesn't blindly accept what's put in. It asks the questions a good compliance consultant — one who's been through a hundred ASQA audits — would ask. "Does this trainer have the industry currency to deliver this unit?" "Does this elective combination meet the packaging rules?" "Have you mapped this content to the 2025 Standards?" Every pass adds another layer of coverage.

4. Every app gets a first-run video¶

The first time a user opens Studio, a short video plays (one minute maximum) explaining what Studio does and how it works. Three options: Skip, Re-watch (available persistently via a help icon), Never show again (stored in their profile). This pattern applies to every app in the Workspace, not just Studio.

5. Units are the work. Qualifications are the reason.¶

The atomic unit of work in Studio is a unit of competency. But the atomic unit of sale and delivery for an RTO is a qualification. Studio reconciles this by making qualifications the entry point and units the work that happens inside them. Unit-in-isolation mode exists but is a secondary path.

6. The workspace is the home¶

Studio does not have a separate landing page, gate overlay, or setup prompt. When a user opens Studio, they arrive directly on the canvas. The canvas is both the home and the workspace — there is no "where to start" screen to dismiss. Everything the user needs is visible on the canvas from the first moment.

7. The system knows what's on scope. The user doesn't declare it.¶

Scope is authoritative and system-known via TGA sync. The user never tells Studio what's on their scope — Studio tells them. Skeletons for every on-scope qualification are generated automatically from TGA data and present on the canvas from the moment the RTO is onboarded.

Scope Model — Educational Asset vs Regulatory Status¶

Studio separates two concepts the rest of the VET software world conflates:

The educational asset — the qualification as a thing you design, contextualise, build content for, iterate on. An asset you own and work with.
The regulatory status — whether ASQA has approved you to deliver that qualification.

These are genuinely different. An RTO can be working on a qualification (asset exists, content in progress) without yet being approved to deliver it (regulatory status pending). Conversely, an RTO can be approved to deliver a qualification (on scope) but have never touched it in Studio (no asset built yet).

Three buckets¶

Every RTO has three categorisations of qualifications and units in Studio:

On Scope — Qualifications Qualifications the RTO is legally approved by ASQA to deliver. Sourced from TGA via rtopacks-db. This is the authoritative list. Includes variations (clones) of on-scope qualifications with different electives — these remain On Scope because elective variation within packaging rules does not require ASQA re-approval.

On Scope — Units Individual units of competency the RTO is working on in isolation, where the unit falls within their existing on-scope qualifications. These appear under On Scope as a sub-bucket, visually distinct from full qualifications. Secondary path — not the primary mode of working.

Proposed Scope Qualifications the RTO is preparing to add to their scope but has not yet received ASQA approval for. Includes qualifications at new AQF levels, from new training packages, or otherwise requiring a formal "Change of Scope" application to ASQA. These are legitimate work-in-progress assets that exist in Studio but are not yet legally deliverable.

Movement between buckets¶

Movement is driven by regulatory action, not user action:

A qualification in Proposed Scope moves to On Scope when ASQA approves the change-of-scope application. This happens automatically via the next TGA sync — the user does not move it.
A qualification can leave On Scope if it is removed (ASQA action, voluntary withdrawal, training package superseded). The Studio work is preserved, flagged as "no longer on scope," but never destroyed — RTOs often need to finish teach-out cohorts after scope is removed.

Users never manually move things between buckets. The buckets reflect regulatory reality; Studio surfaces that reality, it does not set it.

Why this matters¶

Separating educational asset from regulatory status gives Radar and Market Data a richer signal. "This RTO has Proposed Scope for Certificate IV in Travel" is itself valuable competitive intelligence — it indicates direction and intent, not just current state. The RTO card in admin (and eventually in Radar) gains a Proposed Scope facet that did not exist before.

The Canvas Home¶

When a user opens Studio, they arrive on a two-column React Flow canvas. There is no prompt, no overlay, no setup screen. The canvas is the home.

Header context banner¶

A persistent header sits at the top of every Studio surface. It is part of the Studio chrome, not part of the canvas, and it is never dismissed.

The header displays:

Studio — the product name
The RTO context — the name of the RTO whose workspace the user is currently operating in, with the RTO code. For example: "United Central Colleges of Australia (RTO 45329)"
The currently-focused qualification — when a qual node is selected or opened, its code and name appear to the right of the RTO context. For example: "BSB50420 Diploma of Leadership and Management"
Step-down indicator — if the current user is a UCCA/L2 operator who has stepped down into an RTO's workspace to assist, the banner is treated visually differently (amber accent or explicit "Assisting [RTO Name]" text) so there is no ambiguity about whose data is being edited.

The header solves a compliance-grade problem: in a multi-user, multi-workspace environment, the user must always know which RTO's educational asset they are editing. A misattributed edit to the wrong RTO's qualification is a compliance incident. The banner prevents it.

Two-column layout¶

The canvas is divided into two visually distinct columns:

Left column — On Scope The RTO's approved educational assets. Each qualification renders as a node showing qual code, full name, AQF level, and a status indicator (empty skeleton / in progress / complete). Clones appear as child or adjacent nodes grouped under the parent qualification. Units-in-isolation appear in a sub-section, visually separated from full qualifications.

Right column — Proposed Scope Qualifications being prepared for an ASQA change-of-scope application. Each renders as a node with the same structure as On Scope nodes, plus a status indicator showing where in the application lifecycle it sits (draft / evidence gathering / submitted / under assessment). Empty state shows a single "Add proposed qualification" action.

The two columns are visually and colouristically distinct. The user should be able to tell at a glance whether they are looking at something they can legally deliver or something they are preparing to deliver.

Skeletons exist automatically¶

Every qualification on the RTO's scope has a skeleton node on the canvas from the moment the RTO is onboarded. The user does not create these — they are generated automatically from TGA data via rtopacks-db.

A skeleton shows: - Qualification code and full name - AQF level - Visual "empty" state — a ghost outline, soft greyscale, indicating the asset has not been built yet

Clicking a skeleton opens it into the existing qual-tree canvas model (see Qualification Canvas below). From the user's perspective, clicking a skeleton is how they start building. There is no separate "create" action required for on-scope qualifications — the system has already pre-created the asset; the user is completing it.

Scope-size threshold rule¶

For small RTOs, everything loads automatically. For large RTOs, the user filters.

Under 5 qualifications on scope — all quals (and proposed) auto-populate on the canvas when Studio opens.
5 or more qualifications on scope — the canvas opens with a selector: "You have N qualifications on scope. Load all, or select which to work on?" The user chooses. Their selection persists for the session.

The threshold (5) is a default, subject to tuning once real usage data emerges. The principle is that simple cases get simple UX — a small RTO doesn't need a filter — while complex cases get the filter their complexity demands.

Eye-toggle visibility¶

Every qualification node on the canvas has an eye icon in its corner. Clicking the eye hides the node from the canvas (graceful fade-out animation). Hidden nodes do not disappear — they return to a visible drawer accessible from the canvas edge, and can be re-loaded at any time.

This is visibility, not deletion. The eye icon is chosen deliberately — it carries the correct semantic weight. An X or close icon would imply destruction. The eye implies "I am not looking at this right now," which is the actual user action.

The drawer sits at the right edge of the canvas (collapsed by default). Clicking the drawer opens a side panel showing hidden qualifications. Clicking one returns it to the canvas with a graceful fade-in.

Interactions¶

Click a skeleton → opens the qualification canvas (existing qual-tree model — core units locked, elective groups to configure)
Click a populated qualification node → opens the qualification canvas with the existing configuration loaded
Click the eye icon on a node → node fades out, returns to the drawer
Click the drawer → side panel opens, hidden quals visible, click one to restore
Click "Add proposed qualification" in the right column → opens a qualification search UI scoped to the TGA corpus. User selects a qualification, it creates a new Proposed Scope node with an empty skeleton.
Right-click or context menu on a node → actions: Open, Hide, Clone, View history, Delete (Delete is destructive, confirmation required, reserved for user-initiated cleanup — not the default path).

Graceful degradation¶

RTO has zero on scope — On Scope column shows empty state: "Your scope is clear. When you bring qualifications on scope with ASQA, they'll appear here automatically." Right column shows the "Add proposed qualification" action. User can work in Proposed Scope immediately.
RTO card has no TGA data yet — canvas shows a loading state with "Fetching your scope from TGA..." If after a reasonable timeout no data arrives, fallback error state with a contact-support action.
New qualification added to scope since last visit — next time the user opens Studio, the new qualification appears as a skeleton on the canvas with a subtle "new" indicator. No prompt, no modal — the user notices it naturally when they look at their canvas.

Session Model¶

Each qualification on the canvas maps to a Studio session. Sessions hold:

The qual-tree canvas state (core unit nodes, elective selections, cluster declarations)
Content production state (once Composer / Auditor pipeline is built)
Full edit history (who changed what, when — via the session event log)
Collaborative presence state (who's connected now, who last edited which node)

Sessions are addressed by ID. Routes: - /studio — home canvas (two-column view) - /studio/[sessionId] — individual qualification canvas - /api/studio/session/[id] — session API

The home canvas (/studio) is not a session. It is a view of the RTO's scope and proposed scope assets. Individual sessions live at their own URLs.

Multiple sessions per qualification — clones¶

An RTO may have more than one session per qualification. These are clones — different contextual versions of the same qualification code, all legitimately on scope.

Examples: - BSB50420 "Default" - BSB50420 "Airline Catering Contextualisation" - BSB50420 "Corporate Sector Contextualisation"

A clone copies the qualification framework (qual code, core units, elective configuration) but starts with fresh content. Clones carry a free-text context label that is internal to RTOpacks — it does not appear in the TGA corpus.

On the canvas, clones appear grouped under their parent qualification (visual treatment TBD — likely stacked or clustered nodes). Clicking a specific clone opens that session. Creating a new clone is a right-click/menu action on an existing qualification node.

Content clone (copying actual built content between clones) is a future capability, dependent on the Composer pipeline being built. Phase 1 clones copy framework only.

The Qualification Canvas (per-session)¶

Clicking a qualification from the home canvas opens the qualification canvas — the existing qual-tree model from v0.2 onwards.

The Qualification Tree¶

When a qual session opens, the canvas is pre-populated with the qualification's structure. The user does not drag anything to get here — the skeleton is already drawn. The tree has a fixed shape:

             [Qualification Block]
                      |
          ┌───────────┴───────────┐
          │                       │
    [Core Units]            [Electives]
 [auto-populated]      [to be configured]

The Qualification Block sits at the top. It shows the qualification code, full name, AQF level, and TGA registration status.

Core Units branch down the left. These are fixed and mandatory — pulled directly from TGA, fully labelled, locked. No interaction required. They are simply present.

Elective Groups branch down the right. These are the hollow spaces — visually present as placeholder blocks, but empty until the user fills them. Each group already knows its own rules from TGA packaging data.

Elective Group Nodes¶

Each elective group on the canvas shows:

The group name or identifier
The rule — e.g. "Choose 3 from 5" or "Choose 2 from any TGA unit at this AQF level"
The required number of empty slots, shown as hollow placeholder nodes

The user clicks an empty slot. A panel slides in from the right showing the available units for that group. They select one. The slot fills with that unit's node — labelled, coloured, real.

They work through the hollow slots until the tree is complete. For open-ended groups ("any TGA unit"), the panel includes a search interface into the full TGA corpus, filtered to the correct AQF level and any packaging constraints.

This is not a form that produces a canvas. The canvas is the form. The act of selecting electives and the act of building the tree are the same action.

The Baseline Nudge¶

When the elective configuration panel opens for the first time on a first-build of an on-scope qualification, a warm plain-English message appears at the top:

"Before you start — the more accurately this reflects what you actually deliver right now, the more useful everything else becomes. Radar, your trainer mapping, your market position — all of it is based on this. If you want to model a different version later, clone this qualification and build that version separately. For now, just tell us what you've got."

This is not a warning. It is honest advice. The user can ignore it if they choose — the system does not block them.

Real-Time Validation¶

Validation happens continuously as the user builds — never at the end.

Per-slot validation — immediate. The moment a unit is selected for a slot, the system checks whether it has already been selected elsewhere in the same group, or violates any packaging rule. Amber inline message appears immediately if so.

Group-level status indicator — live. Each elective group block carries a running status indicator: - Red — group rule not yet satisfied - Amber — partially complete - Green — group rule fully met

Cross-group awareness. If a unit appears in multiple elective groups and has already been used in one, it appears greyed out in others — visible but unselectable, with a note explaining why. Units are never silently hidden.

No submit button. When all group indicators are green, the elective configuration is complete. The user moves on naturally.

RTO Card Enrichment¶

When the elective configuration is saved, the data writes silently to the RTO's profile in the database. No fanfare, no interruption to Studio.

This enrichment is significant. TGA data tells RTOpacks that an RTO has a qualification on scope. The elective configuration tells RTOpacks exactly which version of that qualification they deliver. No other platform has this data — the RTO provided it directly.

This enriches: - The RTO's card in Radar — competitors can now be filtered to matching elective combinations - Market Data — their elective mix can be benchmarked against sector patterns - Trainer Mapper — unit assignments can be assessed against their actual trainer base - The Scenario Player (future) — the confirmed baseline is the starting point for all scenario modelling

Clustering¶

Clustering is the practice of delivering multiple units of competency together — either grouped on the timetable, partially integrated in content, or deeply blended into a single unified learning experience. It is legitimate when documented correctly. It is a compliance risk when used as a shortcut without the evidence to back it up.

Studio supports clustering explicitly. It is declared at the qual tree stage — before any content is built — because the clustering decision shapes everything that follows: how content is structured, how assessment is designed, and what audit evidence is required.

When Clustering Is Declared¶

After the qual tree is complete — core units locked in, electives selected — Studio prompts:

"Before you start building, are any of these units typically delivered together? Marking clusters now will shape how your content and assessment are structured."

This is optional. An RTO that doesn't cluster simply skips it and moves on. An RTO that does cluster marks the relationships on the canvas now.

Declaring a Cluster — Light Touch¶

On the canvas, the user draws a connection between two or more unit nodes to declare a cluster. That's all this step requires. No content decisions, no mapping, no rationale. Just: these units go together.

The canvas updates immediately — a soft visual grouping appears around the clustered units. A bracket, a shared background tint, something that makes the relationship instantly readable without cluttering the tree.

Multiple clusters can be declared. A unit can only belong to one cluster.

Integration Level — The Critical Question¶

The moment a cluster is declared, Studio asks one question:

"How integrated is this cluster?"

Three levels:

Level 1 — Grouped delivery These units are taught in the same time block, with the same trainer, to the same cohort. They are still completely separate — separate content, separate assessment, separate evidence. They simply run together on the timetable. Most common form of clustering. Lightest compliance requirement. Studio asks for a brief rationale statement.

Level 2 — Shared delivery Some content overlaps between these units, so certain activities are designed to address multiple units simultaneously. Each unit is still individually assessed and individually evidenced, but some delivery activities serve more than one unit. Studio asks for a mapping of shared activities to the units they address.

Level 3 — Deeply integrated Content and assessment are fully woven together. The units cannot be separated in delivery. Every activity, every assessment task is designed to address multiple units simultaneously. Highest compliance scrutiny. Studio asks for full performance criteria mapping across all clustered units.

What Never Changes Regardless of Level¶

Clustering affects how content is delivered and how evidence is structured. It does not change the unit requirements themselves. Every unit in a cluster still has its own full set of performance criteria, knowledge evidence, and assessment conditions from TGA. Studio keeps each unit node individually intact in the qual tree regardless of cluster level.

Compliance Output¶

Regardless of level, every declared cluster generates an entry in the Audit Folder: the units in the cluster, the integration level chosen, the rationale or mapping documentation (depending on level), the date declared and who declared it. For Level 2 and Level 3, this becomes a formal cluster definition document.

Collaborative Editing¶

Studio is a multi-user environment. Large RTOs will have compliance managers, trainers, and subject matter experts working on the same qualification simultaneously — each contributing their domain expertise to different units. The platform must support this from day one.

The unit is the work surface. The qualification is the container. Presence, locking, and attribution all operate at the unit/slot level, not the session level. Two people working on different units within the same qual tree is the normal collaborative case and must be completely frictionless. The system only becomes visible when two people are near the same unit.

Presence Model¶

Each connected user has a live presence state held in a Cloudflare Durable Object — one DO per studio session. The DO is the single authority on who is connected, which slot each person has active, and whether writes can proceed.

Display name format: First name + last initial. "Sarah C." Space is at a premium on the canvas — this is enough to be unambiguous in any realistic RTO team.

Green pill — active presence. Shown on the unit node a user currently has selected or is actively working on. Live while their heartbeat is current.
Amber pill — last touched. Persists on a node after a user leaves it. "Last edited by Sarah C." Stays visible until another user touches that node. Sourced from the session event log.
No pill — untouched. Clean node, no attributed history in this session.

Concurrency and Write Serialisation¶

All slot mutations route through the DO, not directly to the D1 write path. The DO serialises writes — if two users fill the same slot simultaneously, first write wins. The second user receives a gentle response: "That slot was just filled by Sarah C."

Concurrent editors cap: 5. The 6th user attempting to join an active session receives: "This session already has 5 active editors. Ask someone to close their tab to join."

Timeout Model¶

The client sends a heartbeat to the DO every 30 seconds while the tab is open. If a user's heartbeat goes stale — 90 seconds without a ping — they are automatically evicted from the presence map.

The default 90-second timeout is not fixed. Users can override it per-session.

The Canary Flag¶

Once a session has ever had more than one user connected simultaneously, has_been_collaborative is set to true on the session record. This flag never resets. From that point on, every time any user opens the session, a one-time contextual prompt appears before they begin editing offering three options: keep current timeout, set a custom timeout, or lock to me (solo editing until manual unlock).

Connection to People¶

The user editing a unit is not just a user_id. They are a person in the People module — with credentials, a compliance role, and a supervision status. The display name (first name + last initial) is sourced from People. Future pipeline stages (Auditor, Trainer Mapper) will use the same identity to assess whether the person who made a design decision was qualified to make it.

Session Event Log¶

Every significant action in a Studio session is logged with full attribution: who, when, what changed, before state, after state. This is the source of the amber pill, the QA surface, and the compliance evidence that "this decision was made by this person at this time."

Trainer Assignment — The Never Block Principle in Practice¶

When a user assigns a trainer to a unit in Studio, the system checks People & Culture. Three states:

Trainers exist in People & Culture — Dropdown populated with existing trainers. Select and continue.

No trainers exist — Gentle prompt, not an error: "You haven't added any trainers yet. Type a name to get started, and we'll remind you to fill in their details later." A stub record is created in People & Culture in the background. Studio keeps moving.

Trainer exists but profile is incomplete — Soft amber indicator on the trainer assignment. Not blocking. A nudge: "[Name]'s profile needs a bit more detail to complete their trainer mapping."

In all cases, Studio never stops. Incomplete items are collected into a persistent to-do list visible in the Workspace — but they never block progress in Studio.

The Credentials Check¶

When a trainer is assigned, Studio can check whether their qualifications and industry currency map to the unit's delivery requirements against the 2025 Standards.

The prompt: "Do you want us to check [Name]'s credentials against this unit? We'll pull what we have and tell you if anything needs attention for compliance."

If credentials are incomplete, the system tells the user exactly what's missing — not as a failure, but as a checklist. This maps directly to ASQA audit evidence requirements.

The Pipeline (to be designed)¶

Studio contains four tools operating as a left-to-right pipeline:

Composer — the free canvas
Contextualiser — one AI observation per canvas
Auditor — maps content to unit outcomes and ASQA standards
Trainer Mapper — verdicts on trainer-to-unit mapping

Full pipeline design to be documented in a subsequent spec pass.

RTO Card — Studio Activity Stub¶

The RTO card (in admin and Radar surfaces) gains a new Studio Activity facet in v0.6. The facet is a stub in this version — the data model is defined, surfaces are marked, but live data population is a follow-up brief.

The facet will eventually show:

On Scope — Studio status — for each on-scope qualification, whether it has a Studio session, how complete it is (empty skeleton / in progress / complete), last edited by, last edited when
Proposed Scope — Studio status — for each proposed-scope qualification, its application lifecycle state, Studio build progress, target ASQA submission date (if set)
Active collaborators — people currently working in the RTO's Studio sessions
Recent activity — last 10 significant Studio events from the session event log (decisions made, trainers assigned, clusters declared)

For v0.6 the RTO card just needs a placeholder section reading "Studio activity — stub" with a brief note that this will be wired in a subsequent brief. The admin UI should render the section heading so there is a clear landing point for the data once it flows.

This connects the RTO card to the Studio session event log architecture described in the Collaborative Editing section — Studio emits, the platform activity bus accumulates, the RTO card consumes.

Route Architecture¶

/studio — home canvas (two-column view: On Scope | Proposed Scope)
/studio/[sessionId] — individual qualification canvas
/studio/new-proposed — flow for adding a new Proposed Scope qualification (TGA search + scope application draft)
/api/studio/session/[id] — session API
/api/studio/scope — returns current RTO's scope state (On Scope qualifications, Proposed Scope qualifications, unit-in-isolation list, all keyed by org ID and RTO code)

Sessions are addressed by ID. The home canvas is not a session — it is a view over the RTO's scope assets.

Open Questions¶

The exact visual treatment of clones on the home canvas (stacked? clustered? offset?)
How "Units-in-isolation" renders in the On Scope column — a separate sub-column? A collapsible group? A tab within On Scope?
The drawer UI — does it live at the right edge of the canvas (collapsible panel) or somewhere else?
The "new qualification on scope" indicator — what does "subtle" look like exactly? Pulsing dot? Highlighted border? Banner ribbon?
When a qualification is removed from scope (ASQA action), how does Studio communicate this? Banner on the node? Colour change? Modal on first notice?
The Proposed Scope lifecycle states — what are the exact states, and who progresses them? (Likely: draft → evidence gathering → submitted → under assessment → approved | rejected. Progression driven by user action for first three; ASQA/TGA sync for last two.)
How does the header context banner behave when an operator has multiple RTO workspaces available (L2 step-down case)? Dropdown? Switcher?
Does the first-run video play before the canvas loads, or on first visit only, or per-user across all workspaces?

What Is Not in This Document Yet¶

What happens when the user clicks into an individual unit node — does it expand in place or open a new view?
The Composer modes (Blank / Shell Fill / Shell Fill + Edit)
The Contextualiser — how it works, what it produces
The Auditor — self-audit vs AI audit modes
The Fill It handoff to Mavis
Credit metering and the Price It tally
Save/autosave behaviour (implicitly continuous; details TBD)
Export and SCORM warning
Session record architecture (the audit trail of every decision made in a session)
Content contextualisation for different markets
The Scenario Player in detail
Cluster definition screen — the detailed mapping UI for Level 2 and Level 3 clusters
How clustering affects the content build stage downstream
The Inspector panel — what it shows when a node is selected
Skill set canvas structure (different from the qual tree)
Proposed Scope lifecycle UI — the ASQA application flow in detail

STUDIO-SPEC-01 v0.6 — RTOpacks — 17 April 2026 Living document. Add to it, don't replace it. Briefs reference this document. This document does not replace briefs. Supersedes v0.1–v0.5 for the entry flow and home surface. Canvas, collaboration, clustering, import, trainer assignment, pipeline sections retained from earlier versions.