L4 Customisation Layer¶
Document: docs/product/l4-customisation.md
Status: Canonical — all briefs touching RTO-facing customisation must conform to this document
Last updated: 2026-04-06
Authority: Tim Rignold, UCCA Inc
Purpose¶
This document defines what RTO clients (L4) can customise within their RTOpacks environment, what they cannot customise, where customisations are stored, and how they propagate through the system. The L4 customisation layer is the boundary between what RTOpacks controls and what the RTO owns.
The Principle¶
RTOpacks provides the platform, the data, and the intelligence. The RTO provides the operational context. The L4 customisation layer allows RTOs to make the platform speak their language and reflect their processes — without compromising the integrity of the underlying data, the compliance framework, or the platform's security posture.
What RTOpacks always controls: - The underlying NRT data (read from TGA via rtopacks-db — immutable) - Standards references and compliance mapping - The universal print footer - KN base content - Security, logging, and audit trail behaviour - The mode system architecture
What the RTO can own: - How the platform speaks to their staff in guided mode - Their print header and branding - Annotations and context layered on top of KN and guided content - Their own terminology preferences - Their activity and access governance for their L4A members
Customisation Categories¶
1. Guided Mode Content¶
What it is: RTO-specific language, examples, and context layered over the KN-generated and platform-generated guided mode content.
What RTOs can do: - Rewrite guided step descriptions in their own terminology - Add references to their own internal policies, procedures, and documents - Add contextual examples specific to their delivery context (e.g. referencing their open day format, their specific learner cohort, their industry sector) - Annotate KN content with their own observations and notes - Relabel platform concepts to match their internal language (e.g. "Program" instead of "Course")
What RTOs cannot do: - Replace or remove KN base content — they annotate on top - Remove standards references in compliance mode - Change underlying unit or qualification data
Storage: L4 customisation data stored in ops-db against the org record. Never in rtopacks-db.
Propagation: Customisations apply to all L4A members within the org. L4 org owners manage customisations via the customisation settings surface.
2. Print Header and Branding¶
What it is: The configurable upper portion of all printed and exported documents generated within the RTO's environment.
What RTOs can configure:
- Organisation logo (uploaded asset — stored in rtopacks-client-media R2 bucket)
- Organisation name as it appears on print output (may differ from legal name in some contexts)
- Contact details on print header (address, phone, email, website)
- RTO number display format preference
- Optional: training package or scope reference in header
What RTOs cannot configure: - The universal print footer — this is a compliance element, fixed, non-negotiable - Document classification or numbering systems that would conflict with the uncontrolled document notice
Output: The configured print header is applied to all print and PDF output generated within the RTO's L4 environment. It does not apply to output generated by UCCA staff in L2/L3 mode when viewing the RTO's data.
3. Terminology Preferences¶
What it is: A mapping of RTOpacks platform terms to the RTO's preferred internal terminology.
Examples: | RTOpacks term | RTO might prefer | |---|---| | Course | Program / Qualification Program / Training Plan | | Unit | Module / Subject / Component | | Learner | Student / Participant / Trainee | | Trainer | Facilitator / Instructor / Educator | | Assessment | Task / Activity / Evidence |
Scope: Terminology preferences apply to UI labels, guided mode content, and generated document text within the RTO's environment. They do not affect TGA-defined terms (unit codes, competency names, AQF level names — these are fixed regulatory terminology).
Storage: Terminology mapping stored as a JSON config against the org record in ops-db.
4. KN Content Annotation¶
What it is: The ability for RTO staff (at L4 with appropriate permissions) to add annotations to Knowledge Navigator content within their environment.
What RTOs can do: - Add notes visible to their L4A members alongside KN content - Flag KN content for internal review - Add internal context (e.g. "In our delivery context, this performance criterion is assessed via...") - Mark KN content as reviewed and approved for their context
What RTOs cannot do: - Edit or replace KN base content - Suppress KN content from appearing - Represent their annotations as KN content
Annotation attribution: All RTO annotations are clearly attributed to the annotating user and displayed distinctly from KN content. There is no visual ambiguity between KN-generated content and RTO annotation.
Storage: Annotations stored in ops-db against the unit/qual code and the org ID.
5. Member Access and Governance¶
What it is: L4 org owners' ability to manage their L4A members' access, roles, and permissions within the platform.
What L4 org owners can do: - Add and remove L4A members - Assign roles within their org (trainer, assessor, compliance, admin) - Set mode access permissions — e.g. restrict compliance mode to designated compliance staff - View full activity logs for all L4A members - View print and export logs for all L4A members - Set session timeout preferences for their org - Enable or disable specific platform features for their members
Activity visibility — the staff engagement dashboard:
L4 org owners have a dedicated activity view (/settings/activity) showing:
| Metric | Description |
|---|---|
| Last login | Per member — when they last authenticated |
| Login frequency | Sessions per week/month |
| Features used | Which surfaces and tools each member has accessed |
| Print events | What each member has printed, when, and what object |
| Export events | What each member has exported, format, timestamp |
| Guided mode progress | For members in onboarding/guided context |
| Compliance mode activity | For compliance-designated staff |
This is a management tool, not just a security feature. RTO principals have a legitimate operational need to know whether staff are engaging with compliance tools, whether new staff have logged in since onboarding, and whether documentation is being generated appropriately.
The payroll analogy: A staff member who was onboarded to a system and never logged in again is a risk — operationally and from a compliance standpoint. The activity dashboard makes this visible without requiring the principal to audit manually.
6. Compliance Mode Standards Mapping¶
What it is: The ability for RTOs to add their own compliance context on top of the platform's standards mapping.
What RTOs can do: - Add internal policy references alongside ASQA standards references - Tag content with their own internal audit cycle references - Add notes linking compliance content to their specific ASQA audit history - Mark items as internally reviewed with a date and reviewer
What RTOs cannot do: - Change or remove the ASQA standards references — these are fixed - Alter the compliance status indicators that reflect actual compliance state
What Is Not Customisable¶
To be explicit — the following are platform-controlled and cannot be modified at L4:
| Element | Reason |
|---|---|
| Universal print footer | Compliance element — must remain consistent across all print output |
| Uncontrolled document notice | Regulatory — once printed a document is uncontrolled, this notice is non-negotiable |
| ASQA standards references | Fixed regulatory content |
| TGA data (codes, titles, competency elements) | Read-only, sourced from TGA |
| KN base content | Sacred corpus — see object-model.md |
| Audit and print logs | Security — logs cannot be suppressed or modified by any tier |
| The mode system architecture | UMS-001 — platform IP |
Storage Architecture¶
All L4 customisation data lives in ops-db. It is never written to rtopacks-db (read-only) or microcredentials-db. Customisation data is always stored with:
- org_id — the L4 organisation it belongs to
- created_by — the L4 user who created or last modified it
- created_at / updated_at — timestamps
- version — for any content that may be revised over time
Media assets (logos, uploaded images) are stored in the rtopacks-client-media R2 bucket, referenced by URL in ops-db.
Customisation Interface¶
The L4 customisation interface is accessible via Workspace Studio settings. It is not a separate surface — it lives within the authenticated Studio environment. Access requires L4 org owner role or a designated customisation admin role within the org.
The interface is to be specified in a dedicated brief (CUSTOM-01 — not yet written) when the customisation layer is prioritised for build.
Amendment Log¶
| Date | Change | Authority |
|---|---|---|
| 2026-04-06 | Initial document created from Session 42 architectural sprint | Tim Rignold |