Skip to content

Frozen Launch Scope — Decision Record

Status: RULING (Tim, 2026-07-06). Scope line CLOSED — all placements made. Settles follow-on #1 of launch-motion.md. Proposed repo path: product/decisions/frozen-launch-scope.md. Staged for Tim to move. Feeds the WS-PRODUCT-01 canon refresh (see Downstream).

Principle

The lightest fortress that still lands the "this changes everything" moment. Speed is the binding clock (not runway — Tim self-funds indefinitely), so every module past the line is time handed to a competitor. Inclusion test: does removing it drop the spine back into the competitor pack, or leave a mandated/universal gap an incumbent fills?

Governing distinction (Tim, this session): depth, not scope. The fortress ruling governs breadth — the module set must be complete. 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 the depth floor rises: you must be visibly deeper than the incumbent, or you concede the only argument that matters on the surface where it is compared.

In scope — the launch fortress

  • Studio — DEPLOYED. The workshop; where content and assessment are produced (training + assessment are sub-modules of Studio). Not an audit or delivery surface — the place things are made.
  • People P1 — DEPLOYED. Workforce compliance; the verified data the spine grounds content in.
  • Radar — DEPLOYED (both expressions, closed 2026-07).
  • UCCA engine — operative on Cloudflare, doing test runs. NOT yet proven under production load, and no human eyes on output. Launch gate is a trust proof, not a technical one: output survives a mock audit, at load, human-read. For a compliance product, wrong-but-confident output is worse than none.
  • TAS convergence — Studio's crowning output artefact and the document the auditor homes straight in on ("you said X, I see Y"). Converges People + course + assessment + resources + delivery + schedule + clustering, UCCA-grounded, human-readable-and-deployable. The single biggest build-time driver — the tall pole.
  • Record P1 + P2 — the trust-bridge compliance-document library (P1) plus the loop-close that receives the generated TAS with provenance and drives the Standards Map (P2). This is the audit §1.1 "live Studio↔People connection." Record P3 (continuous-improvement, regulatory-change intelligence) is day-two.
  • LLND gate — one tile, two products, two cadences:
  • LLN (language, literacy, numeracy) — stable skill, slow clock (near one-time gate), ACSF-aligned pre-enrolment assessment. Incumbents live (LLN Robot, eSkilled LLN AI Assess, Precision) — beat on integration + quality.
  • Digital — 2025-mandated, greenfield (no entrenched incumbent), naturally recurring (currency lapses as "digital" is redefined), saleable standalone. Subscription-native; likely the cleanest standalone acquisition wedge in the portfolio.
  • Delivered together or separately, at different frequencies.
  • RPL (Attest) — IN, at comprehensive depth. Dual-mode, both modes at launch (pattern proven in Studio):
  • Build order: human-mode shell first (student intake → evidence upload → assessor dashboard → side-by-side review → decision → audit-export), then the engine cognition layer on top. Human-mode-only at launch is the clone trap — it concedes depth on the one surface where a prospect compares you to Red Velvet. Both modes ship.
  • The switch is the demo: "RPL as everyone does it — now watch the engine anchor every mapping to competency logic instead of text-matching." Depth proven by live contrast, not asserted.
  • Workflow bar: must clear the complete incumbent loop (Red Velvet's body is polished even though its brain is shallow), not just the mapping. Leans on existing spine substrate — assessor identity in People, audit artefacts in Record, evidence handling — which is what makes the estimate (~4 days, whole loop) plausible.
  • FLAG (substrate, load-bearing): the RPL engine is evaluative (evidence → judgment), the inverse of the standing UCCA engine, which is generative (qual → content). "Flick a switch, cognition arrives" may assume a capability the current engine does not have. Whether the engine can be pointed at evaluative RPL cheaply is a Gate-1 question — the estimate rides on it.

    Superseded 2026-07-06: capability confirmed by UCCA crossing — sizing (b), new mode on existing core; adapter our-side. See RTOP-RECEIVED-CROSSING-RPL-CAPABILITY-01.

  • FLAG (regulatory): ASQA actively hunts AI-driven high-volume RPL ("RPL mills" is a named enforcement priority). The engine must always anchor the human assessor, never decide. Human stays legally load-bearing on sufficiency and authenticity; engine makes them faster and better-grounded. Never "AI does RPL."

Day-two — fast-follow, not launch-critical

  • InstaLearn + Campus / Creator / Marketplace + the General-Learning library (non-regulated micro-learning LMS). Separate LMS+Stripe build plus ~300 courses still to produce; own data domain (rto-micro-db); every spine integration is Phase 3 in its own spec. Architecturally detachable.
  • Record P3 — intelligence layer.
  • Intelligence-row extensions — Landscape, Market Data, Marketer.
  • Connectors — SMS Connect, LMS Connector.
  • Documents — merges into Record.
  • Library-as-regulated-LMS — the long game (the Moodle-killer for AI-rich regulated delivery).

Build-time drivers (the speed clock, in order)

  1. UCCA output-trust proof — mock audit, at load, human-read. Gates everything downstream; nothing ships on unproven output.
  2. TAS convergence engine — the tall pole; where the whole spine meets.
  3. RPL engine cognition — evaluative, net-new; the Gate-1 substrate question above sizes it. Human shell is cheap; the differentiating layer is not.
  4. LLND gate — lighter but net-new. LLN has incumbents to beat on quality; Digital is greenfield.
  5. Record P2 loop-close — receive + provenance + Standards Map.

Competitive-window note (feeds launch-motion follow-on #2)

The contested surfaces — RPL and LLND — carry financial-year-timing urgency. Incumbents (Red Velvet via the Catapult channel) are pitching FY-start buying season; RTOs budget for these tools in July. The threat on these surfaces is distribution, not depth — Red Velvet rides an established content vendor's RTO base as a bolt-on. Winning the product fight (depth) does not auto-win the market (channel). This is a GTM/partnership question for launch-motion #2, not a scope question — flagged so "we're deeper" never becomes false comfort.

Flags for build-time (recorded, not blocking scope)

  • LLND and RPL handle learner (student) data — data-domain placement is a Gate-1 question under HARD SEPARATION (not rto-nrt-db, not rto-ops-db; likely its own domain). This is pre-enrolment / recognition assessment the RTO runs, not student management (which stays outside the fence). Customer surfaces MAY read the Pith (rto-nrt-db) read-only, per the 2026-07-04 amendment.
  • Names — Attest / Foundation / Capability are placeholders. LLND ratified as the combined-tile descriptor. Final individual tile names are a Tim sign-off item ("names earn the tap"), paired with the spec rewrite.
  • Superseded same session, 2026-07-06 (later ruling): tile names RULED — RPL (over "Attest") and LLND; Attest / Foundation / Capability retired as placeholders, filed as a names-earn-the-tap refinement. The ruling stands in positioning.md and rpl-00/llnd-00; this note annotates the snapshot above. The RPL (Attest) heading parenthetical is retired by the same ruling.

Downstream

  • Positioning ruling (closes audit §1.1) — now UNBLOCKED; the finished scope was its only dependency. Says in one page what RTOpacks is and what the first customer buys. Next artefact.
  • "Depth not scope" principle — coined this session; governs every module's launch-depth call and the spec rewrite. Home undecided (WS-PRODUCT-01 principle vs standing-rule candidate) — Tim's call.
  • Canon rewrite — specs describe a six-module world; the launcher has nine tiles with placeholder names (audit §2 drift meeting the live product). Sequence: refresh WS-PRODUCT-01 first (it governs the module specs) → rewrite the in-scope module specs to real descriptors → day-two specs later. Do not rewrite nine specs when six are in the fortress. The session's strategy artefacts (launch-motion, frozen-launch-scope, positioning) are the rewrite's source material.