RECEIVED COPY — authored cross-fence (RTOpacks side, RTOpacks Claude), relayed by Tim 2026-07-05. Original of record lives in the RTOpacks repo. Per FENCE-PROTOCOL-01 §4 this copy is never edited and never promoted into home canon; local force comes from UCCA-DESIGN-FOUNDATION-01, which cites it as structural input. sha256 of the crossed body (everything below the rule):
642b1e4e232ff9e1336583aa522d241bb606fe936311d7de378aa3e9fb179a1a.
RTOP-UMS-001-APPLICATION-NOTE-01¶
The Mode System you already own — and what it's actually for¶
House of origin: RTOpacks (authored by RTOpacks Claude, relayed by Tim) Crossing under: FENCE-PROTOCOL-01 — authorship stays home Audience: whoever owns the UCCA Admin product (not the build agent — this is a concept document) Companion: RTOP-UCCA-STYLE-MANUAL-SKELETON-01 (mechanical design reference — separate document, separate purpose)
1. The situation¶
The UCCA Admin surface carries LIVE / GUIDED / COMPLIANCE tabs. Those tabs are the visible chrome of the UCCA Mode System Standard (UMS-001 v1.0) — a UCCA master standard which RTOpacks implements under licence. The tabs came home; the machinery underneath them did not. This note describes the machinery, because the tabs without it are three buttons that filter nothing.
The core idea: one interface, three contextual lenses. The surface itself never changes — the annotation layer over it changes with the audience.
| Mode | Audience | What it overlays |
|---|---|---|
| LIVE | The experienced operator | Nothing. Clean workspace. Default. |
| GUIDED | The learner / new staff | Blue information badges: what is this element and what do I do with it |
| COMPLIANCE | The auditor / governance reviewer | Amber governance badges: which standard and which clause this element answers to |
GUIDED is onboarding that lives in the product instead of a wiki. COMPLIANCE is the audit map drawn on the interface itself.
2. The machinery¶
Four parts, all of which must exist for the modes to be real:
2.1 Element identifiers. Every annotatable element carries a permanent data-annotation-id: ucca.admin.{surface}.{element} — e.g. ucca.admin.engine.gate_rejects, ucca.admin.compliance.oscal_posture. Once assigned, never changed; if the element is removed, the annotation is archived, not deleted.
2.2 Annotation files. Per-surface JSON (annotations/engine.en.json …), keyed by element ID. These are first-class source documents edited by non-developers — human-readable, never minified. A GUIDED entry is a title and a plain-English explanation. A COMPLIANCE entry is a ref, title, clause, and one-sentence rationale.
2.3 The badges. Toggling a mode renders the badge below each annotated element. GUIDED badges are dismissible per-user; COMPLIANCE badges are not — the audit map must stay fully visible. Badge colours are UMS-001 cross-product tokens (same colour = same meaning on every UCCA-engine product); take the values from the standard, don't restyle locally.
2.4 Placeholders are the to-do list. An element with an ID but no annotation entry renders a placeholder — and in COMPLIANCE mode the placeholder is a deliberate gap indicator ("No compliance mapping — {element_id}"), not an error. Coverage gaps are made visible to the auditor on purpose. This is the same honesty discipline the surface already practises with live reads, extended to governance.
Plus one output: Export. In COMPLIANCE mode only, an Export button produces a dated JSON register — every annotated element, its mapping, coverage percentage, and the gaps. That file is an audit artefact you can hand to an assessor. It's the reason the mode exists.
3. What COMPLIANCE means for UCCA specifically¶
Here is the part the tabs alone can't tell you. In RTOpacks, COMPLIANCE badges bind interface elements to the Australian VET Standards — the standard and the clause. UCCA's binding target is different and it's already on your own Compliance page: the two-layer map.
- Layer 1 — Platform certifications (what UCCA-the-entity holds): SOC 2 Type II, ISO 27001, ISO 9001, WCAG 2.2, GDPR/APP, 27701 …
- Layer 2 — the OSCAL posture: 324 NIST SP 800-53 Rev 5 controls, self-represented.
So a COMPLIANCE badge on a UCCA Admin element carries a ref into those frameworks. Concretely:
| Element | Ref | Clause | Rationale |
|---|---|---|---|
| Access → role resolution | NIST.AC-2 |
800-53 Rev 5 §AC-2 | Account management: role resolved server-side per authenticated identity. |
| Engine → signed envelopes | NIST.AU-10 / SOC2.CC7.2 |
Non-repudiation | Every output is a signed, verifiable artefact. |
| Trust → key handling | ISO27001.A.8.24 |
Cryptographic controls | Keys held per documented posture, never in code. |
| Engine → detector sweeps | SOC2.CC7.3 |
Anomaly detection & response | Stranded-job detection is a monitored control, not housekeeping. |
The strict layer distinction the Compliance page already states ("supported framework ≠ UCCA compliance; never self-certified") carries into the badges: refs into Layer 1/OSCAL are UCCA's own posture; the Supported Frameworks list is the engine's reasoning scope and is never a badge claim about UCCA itself.
The payoff: when a SOC 2 auditor sits down, you switch the console to COMPLIANCE and the interface annotates itself — every control-relevant element names its control, and every gap names itself as a gap. The 324-control OSCAL posture stops being a number on one page and becomes a map drawn over the product. The Export button hands the auditor the register.
Distinguish this from the Compliance section in the sidebar: the section is a page about UCCA's posture; COMPLIANCE mode is a lens over every page. They share a word, not a function.
4. Where to start (smallest real version)¶
- Assign element IDs on one surface (Engine is the natural first — it has the most control-relevant elements).
- Write
engine.en.jsonwith GUIDED entries only — plain-English explanations. This alone makes GUIDED real and is the fastest visible win. - Add COMPLIANCE entries for the five most obviously control-mapped elements, refs into 800-53.
- Ship the badge renderer + the COMPLIANCE placeholder (the gap register falls out for free).
- Export button last — it's a serialisation of what already exists by then.
One caution: do not seed annotation files by generation-at-volume. Each COMPLIANCE entry is a governance claim; a wrong clause ref in an audit-facing register is worse than a visible gap. Gaps are honest; wrong refs are not.
This note returns a UCCA standard to UCCA with its engine attached. The design values live in the companion skeleton; the standard itself (UMS-001) remains the governing document where the two disagree.