STUDIO-V2-SCOPE-01 — Studio v1 was the instrument that found the questions. This is what it found, and what it makes mandatory.¶
Kind: ruling and scope. Filed 2026-09-09 at docs/docs/workspace/apps/studio-v2-scope.md; ratified in conversation with Tim, 2026-09-09. Supersedes nothing; governed by WS-PRODUCT-01.
⛔ One half of this document is owed and is NOT here: the workflow capture (§6). Nothing in Studio v2 is scoped as complete until that exists.
1 · WHAT STUDIO v1 ACTUALLY WAS¶
Studio v1 was built top-down, against an assumption of what the data looked like — an assumption taken from how training.gov.au presents qualifications on screen. It rendered: click a qualification, see its units, see them split into core and elective; then the elective rules; then, in the electrical training package, a weighting model where units carry points and a valid selection has to total correctly under group rules.
That last step is where it stopped, and it stopped for a reason that was not a bug. You cannot compute a points rule against a rendering of a web page. There was no machine-readable, manipulable substrate underneath — the surface was a display of another display.
Studio v1 therefore posed the questions this project is now answering, rather than being a product with unmet needs. It was a discovery instrument and it worked: it found the wall, and the wall was that the data was not held, the ingestion had gone to the wrong place, and nothing was checked.
This document exists so that no future reader mistakes Studio v1 for a deployed product with a backlog. It is not. Its display layer is a provisional artefact of a top-down attempt that has been ruled a dead end.
2 · THE TRAY — and the technical consequence inside the metaphor¶
Tim's framing, recorded because it is the clearest statement of the requirement anyone has produced:
Building training and assessment is weaving. It is surgery — when I say retractor, the substrate says yes, retractor, here. Scalpel: yes, here. Suction: yes, here. What we did not have was the tools on the tray beside the patient. When we went to get one it was: we have a photo of it — I'll run down the hall — bad news, the storeroom doesn't have it — I'll go to the manufacturer — they have it but not in the size we need.
Mapped: the photo is TGA's rendered HTML. Running down the hall is fetching at request time. The storeroom not having it is not holding the data. Not in the size we need is holding it in a shape that cannot be manipulated.
The technical consequence, which is the load-bearing part:
If the surgeon has to wait, it is not the same operation performed more slowly. It is a different operation. A different approach is chosen, steps are simplified, the move that needs the unavailable instrument is avoided.
So it is in authoring. A trainer who waits for a unit's elements, or receives them partial, does not weave more slowly — they stop weaving. They work around it, hold state in their head, simplify the mapping, and avoid the move that needs the thing that is not there.
Therefore: the design of the surface is downstream of the tray's completeness and latency, not merely of its correctness. Studio v1 was designed against a photograph of the instruments, and so it became a product about looking at instruments — fetch-on-click, loading states, display of a display. That was not a design failure. It was the honest expression of what was on the tray, and no better surface was available to be designed at that time.
The substrate is now the tray: neat, aligned, sterile. The build is the craft, with the technology.
3 · THE WALLS, AND WHAT EACH MAKES MANDATORY¶
Studio v1's failures are not a write-off. They are the requirements specification for Studio v2, discovered the only way they could have been — by building something that failed usefully.
| the wall v1 hit | what it makes mandatory |
|---|---|
| Could not compute the electrical package's points/weighting rules | The substrate expresses RULES, not only hierarchy — a selection can be validated, not merely displayed |
| No machine-readable substrate; only rendered HTML | A held, provable, rebuildable mirror of the national data |
| Ingestion landed in the wrong place, unchecked | A reproducible build with controls — pinned inputs, fixture comparison, containment proof |
| One college could edit another college's work | Tenancy in the predicate at every surface, front door and socket alike (ADR-089) |
| Two people in one qualification | A real collaboration room — presence, locking, live broadcast |
| The companion turned out to belong inside Studio, not beside it | One door — the Interaction Layer (SUPPORT-FABRIC-01 §2) |
Read this way, the foundation work of the past ten days is not a detour from the product. It is the product's specification, being satisfied.
4 · WHAT IS PROVISIONAL AND WHAT IS DURABLE¶
A future window must not treat a Studio component as settled law without checking which side of this line it sits on.
PROVISIONAL — subject to total ratification and redeployment: the display layer as built. Qualification tree, unit lists, the elective breakdown as currently drawn, and any component whose behaviour was designed against the assumed data shape. The rebuild is bottom-up, from the substrate.
DURABLE — survives the rebuild: the multi-tenancy machinery, the collaboration room (the Durable Object, broadcast, presence, slot locking), the tenancy rulings and their ADRs, and the access/storage decisions that hang off them.
Why the machinery comes first, and it is structural rather than stylistic: tenancy is not a feature added later. It determines where data may live and where output may be written — which store a surface may bind, whose row an edit lands on, what the evidence record says. Every surface built above inherits those decisions permanently. The HARD SEPARATION RULE and the ops-db invariant are expressions of the same fact.
The tenancy rulings are architecture, not implementation. ADR-089 and tenant-in-the-predicate survive a rewrite because any replacement must satisfy them. The ADR is the durable artefact; the current lines of index.ts are one expression of it.
⚠ The line is not clean, and this is flagged rather than resolved. Points-model and elective handling already appear inside the collaboration worker's own message set (elective_add, elective_import, points-group totals). If a material amount of rule logic lives in the layer called durable here, the boundary runs through the collaboration worker rather than cleanly beneath it. Measure this before the rebuild is planned; do not assume either answer.
5 · HOW THE V2 WORK IS DONE — and the precondition on starting it¶
Studio v2 is micro-stitching. Highly collaborative, small increments, looking closely at what is held and assembling in short passes — not long autonomous runs. It is a different kind of code work from the substrate briefs, and the working method has to match it.
RULING · ONE-PROBLEM-IN-THE-ROOM-01
Studio v2 work does not begin against an unclosed substrate. When both parties have their heads at the microscope, there must be exactly one problem in the room — the Studio problem. Not the Studio problem and the question of whether the data underneath is sound.
The rationale is not comfort, it is cost. In micro-increment collaborative work, every "is this a Studio fault or a data fault?" costs a full cycle to resolve, and — worse — it erodes confidence in whichever layer turns out to be innocent. A substrate that is mostly closed is not closed: it leaves a second guess in the room, and a second guess is exactly what micro-stitching cannot carry.
The precondition, stated so it can be checked rather than felt: the substrate work is closed and certified, its stores pinned, its rebuild reproducible, its controls passing — before the first Studio v2 increment is cut. Where a substrate question remains open, it is named and its scope bounded, so that a fault in the room can be attributed without investigation.
6 · ⛔ WHAT IS OWED — the workflow capture, and it is the largest unwritten dependency in this project¶
Tim, in his own words: "I hold that in my head, it's not written, it's workflow."
The sequence of instrument calls — what is reached for, in what order, under what conditions, and what "no, not that one, the other size" means each time — exists in one place, and it is not the repository.
And it is not merely a documentation gap. It is a blocker on the data model. The soft and hard linkages can only be expressed once the actions are defined: which relationships must be ENFORCED and which are merely ADVISORY cannot be known until the workflow demands something of them. Capturing the workflow therefore does not follow the data model — it tells the data model what it has to enforce.
Method — and the method matters. The workflow is not to be written as a specification by its holder. A written spec would be the tidied version, which is the same failure as the top-down surface one layer up. It is captured by transcript: Tim builds one real unit of assessment aloud, at whatever pace suits, and every instrument reached for is written down — what was asked for, what was expected back, what was done with it, and every point of correction. The requirements are derived afterwards.
Tacit craft surfaces only when the hand reaches for it.
⚠ One unit is probably not enough. The interesting demands live in the awkward cases — electro was found by hitting it, not by planning for it. The second capture is a qualification already known to be difficult.
7 · LEAST SURE¶
- Where the provisional/durable line actually runs (§4). It is drawn here from the collaboration worker's message set and not from a measurement of how much rule logic sits behind those messages. If a material amount does, the rebuild is messier than this document says.
- Whether the substrate can express the rules at all. §3 makes it mandatory. Nobody has yet confirmed that the data as now held can compute a points/weighting selection rather than describe one. That is the measurement to take before a surface is built against it — otherwise the same wall is met from the other side.
- Whether one workflow capture yields a representative instrument list. A clean unit may produce a tidy list that omits everything difficult. Hence the second, deliberately awkward, capture.
— Advisory seat, 2026-09-09. Ratified in conversation with Tim; the §6 capture is owed and unscheduled.