Object Model¶

Document: docs/product/object-model.md
Status: Canonical — all briefs referencing data objects must conform to this document
Last updated: 2026-04-06
Authority: Tim Rignold, UCCA Inc

Purpose¶

This document defines the five primitive objects of the RTOpacks platform. Every data brief, UI component, API endpoint, Worker, and database schema decision is measured against these definitions. Nothing gets built that contradicts this model without explicit sign-off from Tim and a recorded amendment to this document.

Governing Framework¶

RTOpacks operates within the Australian Vocational Education and Training (VET) sector, regulated by the Australian Skills Quality Authority (ASQA) under the VET Quality Framework. All NRT object definitions in this document are grounded in ASQA's published definitions and the Australian Qualifications Framework (AQF).

The Five Primitive Objects¶

1. Unit of Competency¶

Definition: The smallest component of a training package that can be formally assessed and recognised. Specifies the discrete knowledge and skills required to perform a particular work task to the standard expected in the workplace.

Status: Atomic primitive. The foundational building block of the NRT framework. Everything else is a pattern, container, or delivery mechanism built on top of units.

Key characteristics: - Identified by a unique TGA code (e.g. BSBWHS411) - Has elements of competency and performance criteria - Has a currency status (current, superseded, deleted) - Belongs to one or more training packages - Can be a member of qualifications and/or skill sets - Can stand alone as an assessable item - Has KN enrichment where kn_criteria_reasoning is populated (sacred count: 15,128 — never modified without Tim sign-off)

Source database: rtopacks-db (334ac8fb) — READ ONLY always
API access: via internal-api.rtopacks.com.au only — never direct DB access from any surface
Presentation: Chip / Card / Drawer / Page (see presentation-tiers.md)
Public URL: Gated — no public detail pages at launch (see routing-structure.md)

2. Qualification¶

Definition: A formal certification defined by the Australian Qualifications Framework (AQF), awarded when an individual has successfully completed a structured program of learning that meets the requirements of a specific training package or accredited course.

Status: A pattern that units of competency conform to. Not an independent data object — a qualification is defined by its unit membership rules (core units, elective groups, credit points where applicable).

Key characteristics: - Identified by a unique TGA code (e.g. BSB40120) - Has a defined set of core units and elective rules - Maps to an AQF level (Certificate I through Graduate Diploma) - Belongs to a training package - Has a currency status (current, superseded, deleted) - Has RTO delivery data (which RTOs are scoped to deliver it) - Has labour market data via stats-cache Worker

Relationship to units: In Workspace Studio, the user builds units to a pattern. The qualification is that pattern — it defines what units must be completed. The qualification does not contain units; units conform to the qualification's rules.

Source database: rtopacks-db (334ac8fb) — READ ONLY always
API access: via internal-api.rtopacks.com.au only
Presentation: Chip / Card / Drawer / Page (see presentation-tiers.md)
Public URL: Gated — no public detail pages at launch (see routing-structure.md)

3. Skill Set¶

Definition: A single unit or combination of units of competency from a training package that link together to meet a specific industry need, licence requirement, or legislative condition, without representing a full qualification.

Status: A pattern that units of competency conform to, at sub-qualification scope. A sibling of Qualification in the object hierarchy — not a child of it.

Key characteristics: - Identified by a unique TGA code (e.g. BSBSS00001) - Smaller in scope than a qualification — typically 1–6 units - Often tied to a specific licence, regulatory requirement, or industry need - Has a currency status - May or may not have significant RTO delivery data

Relationship to qualifications: Skill sets and qualifications are siblings. Both are unit patterns. A skill set is not a sub-qualification — it is a distinct object type with its own code series and its own presentation needs.

Source database: rtopacks-db (334ac8fb) — READ ONLY always
API access: via internal-api.rtopacks.com.au only
Presentation: Chip / Card / Drawer / Page (see presentation-tiers.md)
Public URL: Gated — no public detail pages at launch (see routing-structure.md)

4. Registered Training Organisation (RTO)¶

Definition: A training provider registered by ASQA (or a state regulator) to deliver VET qualifications and/or units of competency and to issue nationally recognised certification to students.

Status: A delivery organisation. Entirely different data shape from the three NRT content objects above — an RTO is not a training content object, it is an entity that delivers training content.

Key characteristics: - Identified by a unique 5-digit ASQA RTO code (e.g. 45678) — always used as the primary identifier - Has a registration status (active, cancelled, suspended) - Has a scope of registration — the specific qualifications and units it is approved to deliver - Has a physical and/or online delivery footprint - Has contact and governance information - Has Radar intelligence data (screenshot, competitive profile) where captured

Relationship to other objects: RTOs deliver qualifications and units. They do not own or define them — TGA owns the NRT framework. The RTO-to-qual relationship is a scope mapping, not a containment relationship.

Source database: rtopacks-db (334ac8fb) for NRT scope data — READ ONLY always. Radar data in radar-db (d5e88e32). Ops/CRM data in ops-db (00daba3d).
API access: via internal-api.rtopacks.com.au only for NRT data
Presentation: Chip / Card / Drawer / Page — own stack, different data shape from NRT content objects (see presentation-tiers.md)
Public URL: Gated — no public detail pages at launch (see routing-structure.md)

5. General Education Unit¶

Definition: A component of an accredited course — often found in foundational or "Course in..." programs — designed to improve basic skills such as literacy, numeracy, or social participation rather than specific occupational or technical job skills.

Status: A non-NRT primitive. Parallel to Unit of Competency in function (an atomic, assessable, deliverable component) but from a different regulatory lineage and a different source system. Cannot be treated as a variant of Unit of Competency.

Key characteristics: - Identified by a UCCA-generated code (format TBD — see gen-ed brief, to be written) - Not part of the TGA training package framework — from accredited courses - Not nationally recognised training in the same sense as NRT units - Scoped to foundational and general skills: literacy, numeracy, digital literacy, social participation - Generated and managed by UCCA — RTOpacks is the authoritative source for these records, not TGA - May be delivered alongside NRT units in blended programs

Relationship to NRT objects: General education units float across the NRT framework — they can be contextualised alongside qualifications or units but they are not part of any training package. They are a parallel primitive, not a subordinate one.

HARD SEPARATION RULE: General education units live exclusively in microcredentials-db (3924412d). They must never be mixed with NRT data in rtopacks-db. This is an architectural absolute.

Source database: microcredentials-db (3924412d) — separate from all NRT data
API access: via dedicated endpoint — not shared with NRT internal-api
Presentation: Chip / Card / Drawer / Page — own stack, borrows Unit of Competency visual language with clear non-NRT distinction (see presentation-tiers.md)
Public URL: Gated — no public detail pages at launch (see routing-structure.md)

Object Hierarchy Summary¶

Nationally Recognised Training (NRT) — rtopacks-db (READ ONLY)
├── Unit of Competency       ← atomic primitive, the real building block
├── Qualification            ← pattern of units (AQF-level, formal certification)
├── Skill Set                ← pattern of units (sub-qual, licence/regulatory)
└── RTO                      ← delivery organisation (different data shape)

Non-NRT — microcredentials-db (HARD SEPARATION)
└── General Education Unit   ← parallel primitive, UCCA-generated codes

Database Separation Rules¶

These rules are absolute. No deviation without Tim sign-off and a recorded amendment.

Database	ID	Purpose	Security tier	Rule
`rtopacks-db`	334ac8fb	All NRT data	Highest integrity	READ ONLY always. No writes ever. NRT content only — no ops, no gen-ed, no business data.
`microcredentials-db`	3924412d	Non-accredited / gen-ed	Standard	Non-NRT only. Never mix with rtopacks-db content.
`ops-db`	00daba3d	UCCA business operations	Highest confidentiality	Billing, CRM, commercial client records. Never NRT content. Never client workspace data. L4 clients have no path to this database — direct or indirect.
`workspace-db`	fb6ddc43 (D1: engine-db-oc)	Client workspace	Standard — client-scoped	All client-side activity: users, teams, groups, sessions, dockets, composer, documents. Never billing data. Never NRT content.
`radar-db`	d5e88e32	Radar intelligence	Standard	RTO competitive intelligence only.
`landscape-db`	dd355937	Landscape intelligence	Standard	VET sector vendor intelligence only.

Security tier principle: ops-db is the most confidentially sensitive database in the stack — it contains billing data, Stripe records, and UCCA's commercial relationships with clients. workspace-db contains client activity data which is sensitive to the client but not UCCA-confidential. These must never be mixed. A client workspace session must never have any path — direct or indirect — to ops-db.

Identity and Access Model¶

Every human user in RTOpacks exists within a defined structure. There are no naked users — no user exists outside a team, and no team exists outside an org.

The Universal Team Principle¶

Every user belongs to a team. Even a solo operator who signs up alone is automatically placed in a team of one. The team construct is universal and non-negotiable. On signup the system automatically creates:

An org record in ops-db (the commercial relationship)
A team in workspace-db
A default admin group within that team
Places the new user in that group with full permissions

The user never sees this machinery — they land in their workspace. But structurally they are always in a team, always in a group, always have defined permissions.

Schema¶

ops-db
└── rto_clients
    - id
    - org_name
    - rto_code (5-digit ASQA code)
    - stripe_customer_id
    - subscription plan and status
    - billing details
    (L4 clients have NO path to this database)

workspace-db
├── users
│   - id
│   - email
│   - display_name
│   - avatar_url
│   - email_verified
│   - org_id          ← links to rto_clients in ops-db
│   - created_at
│   - last_seen_at
│
├── teams
│   - id
│   - org_id
│   - name            ← defaults to org name, L4 customisable
│   - created_at
│
├── groups
│   - id
│   - team_id
│   - org_id
│   - name            ← e.g. trainers, assessors, admin, compliance
│   - permissions     ← defines what this group can see and do
│   (L4 admins create and name groups — see l4-customisation.md)
│
└── user_groups
    - user_id
    - group_id
    - team_id
    - added_at
    - added_by

Key principles¶

Billing is at org level, not user level. The RTO pays — not individual staff. Subscription and billing columns belong on the org record in ops-db, never on a user record.
Groups unlock functionality. A user's permissions derive from their group membership, not their individual user record. L4 admins create groups, assign permissions to groups, then add L4A members to groups.
Groups are L4-nameable. What RTOpacks calls "groups" an RTO might call "teams", "departments", or "roles". The L4 customisation layer allows renaming. The underlying structure is fixed.
Forward flag — role definitions: The specific permissions model for groups (what each group type can see and do) is to be defined in a dedicated brief before the first L4 client onboarding. The schema above is forward-compatible with that work — it does not need to be redesigned when roles are formalised.
Auth flows through workspace-db. Magic link auth writes to users in workspace-db. ops-db is never touched during an auth flow.

KN Sacred Rule¶

The kn_criteria_reasoning column in rtopacks-db contains enriched content for 15,128 units of competency. This is the canonical KN corpus. The count of 15,128 is sacred — it is never modified, overwritten, or re-ingested without explicit Tim sign-off documented in writing. Any brief that touches KN data must reference this rule.

API Access Rule¶

No surface — public site, Workspace Studio, admin panel, Worker, or external integration — ever queries rtopacks-db directly. All NRT data access flows through internal-api.rtopacks.com.au. This is the security boundary. Direct DB access from any application layer is an architectural violation.

Amendment Log¶

Date	Change	Authority
2026-04-06	Initial document created from Session 41/42 architectural sprint	Tim Rignold
2026-04-06	Added workspace-db, database security tiers, identity and access model, universal team principle	Tim Rignold