Skip to content

RTOpacks Record — Product Specification

Document ID: RECORD-SPEC-01
Version: 0.2
Status: Living document — foundational thinking captured; briefs scoped separately
Location: docs/docs/workspace/apps/record.md
Last updated: 14 April 2026

Changelog

Version Date Changes
0.1 14 Apr 2026 Initial — product framing, architecture, data model, surfaces, phasing, open questions
0.2 14 Apr 2026 Module renamed from Documents to Record. Icon concept documented.

How to Use This Document

This spec is the full-picture reference for the Record module. Like STUDIO-SPEC-01 and PC-SPEC-01, it is deliberately comprehensive — built from a full analysis of the competitive landscape (NovaCore, Newbery Consulting forms and policies), the legislative requirements of the Standards for RTOs 2025, and the architectural decisions already made in Studio and People.

This document does not constitute a brief. Briefs are scoped, sequenced, and issued separately. Each brief references this document as its source of truth.

Alex: read this document before picking up any Record brief. The briefs will tell you what to build. This document tells you why, and what it needs to eventually become.

The Module Name

The module is called Record.

The name works on two levels simultaneously. The noun: the official record, the evidence, the documentary proof of what happened. The verb: to record, to capture, to preserve. This double meaning is deliberate and load-bearing — Record is both the act of capturing compliance evidence and the artefact that results from it.

This is the only one of the three spine module names that carries this duality. Studio is a place. People are people. Record is both a thing and an action.

The launcher tile displays the name Record only. No subtitle. The name earns the tap. Exploration happens inside.

The Module Icon

The icon is a reel-to-reel tape recorder, reduced to its essential geometry.

Three elements: two equal circular spools (left and right), connected by an implied tape path, with a recording head centred between them. The recording head — a small rectangle or trapezoid — sits at the point where tape meets head, the moment of inscription. Mechanically correct. Symbolically exact.

The reel-to-reel is old enough that it carries no modern consumer association — nobody sees it and thinks Spotify or podcasts. The object has been evacuated of its original meaning and is available for reuse as pure symbol. Like the floppy disk for save, or the film reel for video, the reel-to-reel sits at exactly the right tipping point: old enough to be abstract, distinctive enough to carry weight.

Rendered in single-colour line style, consistent with the other workspace app icons. No gradients. No texture. The geometry does the work. At tile size the three-element composition — spool, head, spool — reads as precision, archive, capture. Something important was preserved here.

The Trust Bridge

Record exists because paperwork is how compliance has always been demonstrated, and that is not going to change overnight. Large RTOs, TAFEs, and universities have decades of investment in document-based compliance systems — NovaCore, SharePoint folders, filing cabinets full of Newbery forms. Their staff know what a policy looks like. They know what a TAS looks like. They know how to put something in a folder and find it again.

RTOpacks does not ask them to abandon that. Record is the trust bridge — the module that makes RTOpacks legible to people who need to see familiar artefacts before they trust an unfamiliar system. The RTO manager who has been doing this for twenty years can still see their Assessment Policy, check its version number, print it, and put it in a folder. The system has not done something mysterious. It has produced something they recognise.

But behind that familiar surface, something fundamentally different is happening. The policy did not get typed into a Word template and filed. It was generated from live system data — or if it was authored manually, it is connected to the live system data that validates it. The policy is the stereo mixdown. Behind it are thirty-two tracks of source data, decisions, verifications, and timestamps that make it evidentially defensible rather than just administratively present.

This is the core product proposition of Record, stated plainly: the paperwork you've always needed, grounded in the reality the system already knows.

What Record Is

Record is the compliance evidence layer for the RTOpacks Workspace. It has three jobs, which must be held simultaneously without collapsing into each other.

Job One — The Policy and Procedure Library

Standing documents that an RTO maintains over time: policies, procedures, codes of practice, handbooks, forms. These are authored by humans, version-controlled, mapped to Standards clauses, and subject to review cycles. This is the NovaCore model, done properly and natively in the browser. Every item in the library has a status (current, under review, superseded), a version history with full audit trail, a review interval, and a mapping to one or more Standards clauses in the SRTO 2025 framework.

The traffic light system — the core insight from NovaCore that is worth keeping — derives from this mapping. When a policy linked to Standard 3.2 is current and approved, the light for Standard 3.2 moves toward green. When it lapses, it moves toward red. The light is not manually set. It is derived from document status and Standards mappings.

Job Two — The Generated Artefact Layer

Compliance artefacts produced by the system itself, not authored by humans. The Training and Assessment Strategy is the most significant example — a completed document, not a template, produced from Studio's qual tree decisions, People's trainer data, the TGA unit corpus, and the clustering and assessment design decisions made during a Studio session. Other generated artefacts include the Staff Compliance Matrix (from People), the Audit Folder export (from Studio), and the Continuous Improvement Log (from the self-assurance system).

Generated artefacts are not filed into Record. They are written to Record by the originating module. The distinction matters: a generated artefact carries provenance — it knows where every data point came from, when it was verified, and by whom. That provenance is stored in the artefact record, not in the file itself.

Job Three — The Evidence Repository

External documents and records that are linked to, not stored in, other modules. PD certificates linked from People CPD records. Credential documents linked from People credential records. Supervision agreements linked from People supervision records. Assessment tools linked from Studio sessions. These items live in Record but are referenced from elsewhere. Record is the storage layer. The other modules are the context layer.

The critical principle: evidence is linked, not duplicated. A PD certificate exists once in Record. People links to it. If the certificate is superseded, the link updates. There is never a situation where the same document exists in two places with two different versions.

What Record Is Not

It is not a word processor. Record does not edit files. It version-controls them, stores them, and publishes them. Editing happens in the user's own tools — or in Studio for generated content.

It is not a forms system. Web forms that collect student data, enrolment applications, complaints — these belong to other modules or to the SMS. Record holds the blank form template and the policy that governs the process. It does not process form submissions.

It is not a student records system. Student files, enrolment records, results — these have their own data domain. Record holds the policies that govern how student records are managed, not the records themselves.

It is not the source of truth for anything. People is the source of truth for workforce compliance. Studio is the source of truth for training design. Record is where that truth gets expressed as evidence. The artefact is downstream of the reality, not the definition of it.

It is not a search engine for the whole workspace. Record has its own search — find a policy, find a form, find a generated TAS. It does not search across modules. Observatory is where cross-module intelligence surfaces.

The Competitive Landscape

NovaCore is the current gold standard for document management in the Australian RTO sector. Understanding what it does well — and where it stops — is essential context for this spec.

What NovaCore does well: Version control with a complete audit trail. Standards-to-document mapping with a visual traffic light. Pre-built regulatory frameworks (SRTO, CRICOS, AQTF, TEQSA, ISO). A document portal for staff access to approved documents. Configurable review cycles with email alerts. A document register report suitable for ASQA audit evidence.

What NovaCore cannot do: It has no connection to live system data. Every document is manually created or imported. Every Standards mapping is manually made. The traffic light turns green when a document exists and is current — not when the underlying compliance reality is sound. A policy can be green in NovaCore while the practice it describes is completely non-compliant. NovaCore does not know and cannot know the difference.

The architectural gap we fill: Our traffic light derives from live system data, not just document status. When People confirms that all trainers delivering SIT30122 have verified industry currency, that Standard 3.3 clause moves toward green — whether or not the policy document has been reviewed this quarter. The document is evidence. The data is truth. NovaCore only has documents. We have both.

The MS Office dependency: NovaCore's fatal limitation is its Word integration model. Every document lives in Word. NovaCore wraps Word — it does not own the document. This is why "migrated to the cloud" for NovaCore means a terminal server running Windows with Word installed. We have no such constraint. Our artefacts are native web objects. Generated artefacts are produced programmatically. Authored documents are uploaded in any format and stored as-is.

The Standards Framework

The SRTO 2025 framework is pre-built into Record. RTOs do not configure it — it is shipped. Every Standards clause is present in the system from day one, structured as a queryable hierarchy:

  • Outcome Standards → Standard → Element → Sub-element
  • Compliance Standards → Requirement
  • Credential Policy → Section

Record ships with suggested mappings for common document types. An Assessment Policy is pre-suggested as mapping to Standard 3.2, Standard 1.1, and Standard 4.2. The RTO confirms, adjusts, or extends these mappings — they do not build from scratch.

This is the key improvement over NovaCore's model, where RTOs either use pre-built frameworks with pre-built mappings that may not match their documents, or build their own from scratch. We ship the framework and the suggested mappings. The RTO customises from a sensible default, not from nothing.

The framework is also live — when ASQA updates the Standards, the framework updates. RTOs do not need to rebuild their mapping. Record flags which existing mappings may need review in light of the change.

The Vault Architecture

Behind the surface is the vault — the complete record of every artefact in the system, its provenance, its version history, and its relationships.

The artefact record (stored in rto-docs-db, content in R2):

  • Artefact ID
  • Title
  • Type: Policy / Procedure / Form / Manual / Generated / Evidence / Template
  • Source: Authored / Generated
  • If generated: source module, source session ID, generation timestamp, data snapshot reference
  • If authored: upload timestamp, uploaded by, source file format
  • Current version number (Major.Minor)
  • Version history: array of version records, each with version number, date, changed by, revision notes, change type (Major/Minor), approval status, approved by, approved date
  • Review interval
  • Next review date
  • Status: Draft / Pending Approval / Current / Under Review / Superseded / Archived
  • Standards mappings: array of clause references with mapping confidence (Confirmed / Suggested / Auto-derived)
  • Related records: links to People records, Studio sessions, or other Record artefacts that reference this item
  • Storage location (R2 path — abstracted to support future storage tier migration)
  • Search index metadata

The activity log (the stub bus — Phase 1):

Every significant event across the workspace emits a minimal activity record to Record:

  • Event ID
  • Source module
  • Event type
  • Source record or session ID
  • Timestamp
  • User
  • Status

In Phase 1, Record stores these and does nothing else with them. They are the beginning of the provenance chain. By the time generated artefacts are being produced in Phase 2, the vault already has a timeline of workspace activity to attach them to.

The provenance chain (Phase 2):

For generated artefacts, every field in the output traces to a source event in the activity log. The TAS field "Trainer: Jane Smith — SITHCCC023" traces to a People credential verification event on a specific date, approved by a specific user. This chain is stored in the artefact record metadata, not in the file itself. The file is the mixdown. The metadata is the tape.

The Traffic Light System

The traffic light is the primary compliance status surface in Record. It maps directly to the SRTO 2025 Standards framework and derives its state from two sources simultaneously.

Source one — Artefact status: Is the document linked to this Standard current, approved, and within its review interval? This is the NovaCore model. It is necessary but not sufficient.

Source two — Live system data: Does People confirm that the workforce compliance reality behind this Standard is sound? Does Studio confirm that the training design decisions satisfy this Standard's requirements? This is our addition. It is what makes the traffic light meaningful rather than merely administrative.

Light states:

  • Green: All linked documents current and approved; live system data confirms underlying compliance
  • Green (document only): Documents current; live system data not yet available or not applicable
  • Amber: Documents approaching review date (configurable threshold, default 30 days); or live system data showing warning state
  • Red: Document lapsed, unapproved, or missing; or live system data showing non-compliant state
  • Grey: Standard not applicable to this RTO's scope
  • Blue: Standard satisfied by generated system output — no manual document required; compliance is demonstrated by the system record itself

The Blue state is new to the market. It represents the case where the system's own data is sufficient evidence for a Standard clause — a generated Staff Compliance Matrix satisfies the documentary requirement for Standard 3.2 without a separate policy needing to exist. The RTO may still choose to maintain a policy, in which case both the Blue and the policy's own status combine. But the clause is never Red simply because a manual document doesn't exist, if the system data already satisfies it.

The Surfaces

Surface 1: The Library

The primary surface. A filtered, searchable list of all artefacts in the system. Default view groups by type (Policies, Procedures, Forms, Manuals, Generated, Evidence). Columns: Status indicator, Title, Type, Version, Last Revised, Next Review, Standards Mappings count.

Clicking an artefact opens its full record: current version, version history, Standards mappings, related records, provenance summary (for generated artefacts).

Filter and search: By type, by status, by Standards clause, by review date range, by source (authored/generated). Full text search across titles and metadata. Not full text search of file content in Phase 1 — this is a forward constraint requiring a search index.

Version control actions: Revise (create new version), Review (mark reviewed without version change), Approve, Archive. These match the NovaCore workflow verbs because they are correct and familiar.

Surface 2: The Standards Map

The traffic light view. The SRTO 2025 framework displayed as a hierarchy with live status at every level. Selecting a clause shows: the clause text, the artefacts mapped to it, the live system data signals contributing to its status, and any outstanding actions.

The Standards Map is the RTO's answer to the audit question: "Show me your compliance system." It is printable as a Summary Pack — an overview of status across all Standards, suitable for ASQA evidence.

This surface also shows the Intent / Key Actions / Responsible Person fields per clause. The RTO records how they intend to meet each Standard, what actions they are taking, and who owns it. This is the self-assurance narrative, not just the document list.

Surface 3: The Audit Folder (Phase 2)

A curated, point-in-time export of evidence for a specific audit scope. The RTO selects which Standards they are being audited against, the date range, and the evidence types to include. The system assembles the export: document register, version histories, Standards mappings, generated artefacts, People compliance data, Studio session records. Output is a structured PDF package or a zipped folder of files.

The Audit Folder is not a manually assembled collection. It is generated from the vault on demand. Every element is timestamped. Every generated artefact carries its provenance summary. The export is audit-ready, not audit-preparatory.

Surface 4: The Portal (Phase 2)

A read-only web view of approved, published documents for staff access. Replaces the SharePoint folder, the Google Drive share, the email attachment. Staff see only current, approved documents — never drafts, never superseded versions. Navigation follows the framework structure: Standards → document type → document.

Publishing is controlled per artefact. A document can be published to the portal, to a public URL, or kept internal. The RTO controls access by role.

Integration with Other Modules

Module Relationship
Studio Studio writes generated artefacts to Record on session completion. The TAS, Audit Folder outputs, and clustering definition documents are generated artefacts in the vault. Studio session records are referenced in provenance chains.
People People links credential documents, PD evidence, and supervision agreements to Record artefacts. The Staff Compliance Matrix is a generated artefact produced from People data. People CPD and credential records contribute live system data signals to the Standards Map traffic light.
Observatory Observatory surfaces cross-module compliance status. Record provides the Standards Map data that feeds Observatory's self-assurance dashboard. The relationship is read-only from Observatory's perspective — Observatory queries, Record holds.
Radar Phase 3. An RTO's documented scope and training design decisions inform their profile in Radar.
InstaLearn Phase 3. Credential documents verified through InstaLearn are stored in Record and linked to the relevant People records.

The Activity Log — Stub Bus Design

The activity log is the Phase 1 implementation of what will become a full event bus in Phase 2. Its purpose is to begin accumulating the workspace activity record from day one, even before generated artefacts exist.

Every module emits a minimal event on significant actions:

{
  event_id: uuid,
  source_module: 'studio' | 'people' | 'observatory' | 'record',
  event_type: string,  // e.g. 'session_completed', 'credential_verified', 'document_approved'
  source_record_id: string,
  timestamp: ISO8601,
  user_id: string,
  status: 'completed' | 'in_progress' | 'failed'
}

In Phase 1, Record receives these events and stores them. No further processing. The log is queryable but not yet wired to provenance chains or Standards Map signals.

In Phase 2, the event schema is extended per module as artefact generation matures. The bus evolves from a heartbeat to a full provenance substrate without a schema rewrite, because the core fields are established from day one.

The stub bus is not a separate Worker. It is a lightweight ingest endpoint in the Record Worker that accepts POST requests from other modules. Modules call it on completion. Record stores the event.

Build Sequence and Phasing

Phase 1 — Foundation

  • Library with full CRUD: create, upload, version, approve, archive
  • Version control with audit trail (revision history, revision notes, Major/Minor distinction)
  • SRTO 2025 framework pre-built with suggested document mappings
  • Standards Map with traffic light derived from document status only (live system data signals in Phase 2)
  • Intent / Key Actions / Responsible Person fields per Standards clause
  • Filter and search on artefact metadata
  • Activity log stub bus: ingest endpoint, event storage, basic query
  • Evidence repository: upload and link external documents to People and Studio records
  • Basic portal: internal staff access to approved documents

Phase 2 — Generated Artefacts and Live Signals

  • Staff Compliance Matrix generated from People data
  • TAS generated from Studio session data (requires Studio and People Phase 1 data to be mature)
  • Traffic light live system data signals wired from People and Studio
  • Provenance chain: field-level traceability for generated artefacts
  • Audit Folder export: curated, point-in-time evidence package
  • Public portal with framework-based navigation
  • Full text search (requires search index decision — see Open Questions)

Phase 3 — Intelligence

  • Continuous Improvement Log: systematic record of issues identified, actions taken, outcomes
  • Regulatory change management: Standards framework updates flagged with affected documents highlighted
  • Cross-RTO benchmarking: what does a complete document set look like for an RTO of this scope and size?
  • Storage tiering: hot/warm/cold based on artefact age and access frequency

Open Questions

  • Search index: Full text search of file content requires an external index (Algolia, Typesense, or similar) or a native D1 FTS implementation. This decision has cost and architecture implications. Deferred to Phase 2 design.
  • Storage scale and tiering: R2 is appropriate for Phase 1 volumes. At scale across many RTOs with years of version history, a tiered storage strategy will be required. The schema must accommodate this from Phase 1 — storage_tier and storage_location fields must not be hardcoded to R2. The specific cold storage solution is deferred.
  • The Blue light state: The concept of a Standards clause satisfied by system data alone (without a manual document) is novel and requires ASQA validation thinking. Does ASQA accept a generated Staff Compliance Matrix as standalone evidence for Standard 3.2, or does a human-authored policy also need to exist? This affects how the Blue state is surfaced and whether it can ever be the sole basis for a green traffic light.
  • In-browser editing: Phase 1 does not include native document editing. Users upload files. Whether a future phase includes a native editor is unresolved.
  • Multi-tenancy and the portal: When licensed seats are introduced (L4 staff access), the portal needs role-based access at the document level. Must be designed before Phase 2 portal build begins.
  • The event bus evolution: The stub bus schema defined in Phase 1 must be designed with Phase 2 extension in mind. The event_type field must be extensible without migration. The source_record_id must be globally unique across modules.

Relationship to the Broader Architecture

Record is the only module in the Workspace that spans every other module's output. Studio produces content. People produces compliance records. Observatory surfaces intelligence. Record holds the evidence of all of it.

This makes Record architecturally central without being architecturally dominant. It does not control the other modules. It does not own their data. It receives their outputs and holds them in a form that is legible, defensible, and retrievable. It is the vault, not the engine.

The engine is distributed across the workspace. The vault is here.

RECORD-SPEC-01 v0.2 — RTOpacks — 14 April 2026
Living document. Add to it, don't replace it.
Briefs reference this document. This document does not replace briefs.