UCCA Identity, Layer & Capability Specification v1.0¶

Classification: INTERNAL — Architecture
Owner: Tim Rignold
Status: Draft for Review
Date: 2026-03-22
Companion Documents: - Control Plane Architecture v1.0 - World Container Specification v1.0 - Ops Console UI Specification v1.1

1. Purpose¶

This document defines the canonical identity model, permission layer structure, token architecture, seat model, role template system, and layer-switching mechanics for the UCCA platform.

It is the authoritative source of truth for:

Who the actors are at every layer and what they can see
How they authenticate
What tokens are issued, what they contain, and how long they live
How an operator at L1 steps down through layers to see what any user sees
How enterprise clients connect their own identity systems without UCCA owning their auth
How role templates are defined, shipped, and customised per world
How the seat model works commercially and architecturally

Every brief that touches auth, identity, permissions, or the layer switcher references this document. No implementation in this domain proceeds from assumption. If the spec does not cover a case, the spec is updated before the build begins.

2. The Definitive Layer Model¶

UCCA operates a five-tier access hierarchy. Visibility is determined entirely by credentials. One codebase renders different views depending on who is authenticated. The layers are not separate applications — they are permission windows onto the same engine.

Layer 1 — UCCA God Mode (Platform Operator)¶

Attribute	Value
Operators	Tim Rignold, Alex (UCCA engineering)
Surface	`ops.ucca.online`
Scope	Full platform. All worlds, all clients, all infrastructure, aggregate financials, system health, Terraform state, authority catalogue, cross-world telemetry
Auth	Cloudflare Access — OTP to authorised UCCA email addresses
Token type	`ucca_platform_token`

Tim and Alex only. No client, no subscriber, no user below this layer ever knows it exists. L1 is the platform operator surface — never exposed to the outside world.

Layer 2 — UCCA Superuser Overlay (Internal CRM)¶

Attribute	Value
Operators	UCCA staff, scoped to one specific client
Surface	`ops.ucca.online/clients/[client-id]/...`
Scope	Internal view of one client — billing, support notes, cost-to-serve, world configuration, engine logs, triumvirate state, enrichment status. The client never sees this layer.
Auth	Derived from an active L1 session via step-down token
Token type	`ucca_su_token` — scoped to `client_id`

L2 is UCCA's private view into a client's world. The client has no visibility that this layer exists. UCCA uses it for support, configuration, cost monitoring, and operations scoped to that client.

Layer 3 — World Operator (The Subscriber — Bill)¶

Attribute	Value
Operators	The organisation that subscribed to the product (e.g. the RTO that purchased RTOpacks)
Surface	`my.rtopacks.com.au` (standard) or `[client-slug].ucca.online` or client's own domain (white-label)
Scope	Bill's complete commercial world. His clients (L4 organisations), their members (L4A), role template management, billing and seat administration, compliance configuration, world analytics, branding
Auth	UCCA-managed (standard) or federated via external IdP (enterprise — see Section 6)
Token type	`ucca_world_token` — scoped to `world_id` + `client_id`

Bill is the top of his own world. He does not see L1 or L2. He cannot see other subscribers' worlds. He administers everything below him — his clients, their users, their permissions, his billing. He can step down into L4 to see exactly what his clients see.

Layer 4 — Bill's Clients (The Client Organisations)¶

Attribute	Value
Operators	The organisations that Bill serves — a corporate group, a TAFE, a single RTO, an enterprise compliance team
Surface	Same domain as L3, session-scoped. May be white-labelled to the client's own domain.
Scope	Their own organisational data, their own members (L4A), their own compliance records and capability evidence. Cannot see other L4 organisations. Cannot see L3 administration.
Auth	UCCA-managed by default. Federated to the L4 organisation's own IdP for enterprise clients (see Section 6).
Token type	`ucca_org_token` — scoped to `world_id` + `client_id` + `org_id`

A L4 entity is always an organisation, never a bare user. A sole operator is a L4 organisation with exactly one member — themselves. This is not an edge case — it is the standard model applied at minimum scale.

Layer 4A — Organisation Members (The Users)¶

Attribute	Value
Operators	Individual people within a L4 organisation — staff, trainers, auditors, managers, students
Surface	Same as L4
Scope	Determined entirely by the role template assigned by their L4 admin. Defined at L3 (by Bill), administered at L4, experienced at L4A.
Auth	Credential issued within the L4 organisation's auth model
Token type	`ucca_member_token` — scoped to `world_id` + `client_id` + `org_id` + `user_id` + `role_template_id`

L4A members see a product. They do not see an engine, a platform, or UCCA infrastructure unless the L4 organisation has explicitly chosen to surface UCCA branding. All layers above are invisible by design.

3. The Team Construct Is Universal and Atomic¶

There are no naked users in UCCA.

This is a foundational architectural rule with no exceptions.

Every user belongs to an organisation. Every organisation has at least one user. A sole operator running a small RTO is a L4 organisation (org_id: rto-jones-001) with exactly one L4A member — themselves. They are not a special case. They are the universal model at minimum scale.

Why This Matters¶

Multi-tenancy is structural, never retrofitted. The organisational boundary exists from the first user. Adding a second user is a seat addition, not an architectural change.
Permissions are always role-scoped within an org. No user-specific permission one-offs. Permissions attach to role templates; role templates attach to users.
Billing, reporting, and audit always have a natural boundary. The L4 organisation is the unit of commercial relationship.
Enterprise corporate groups are the same model at scale. A group with 50 subsidiary RTOs is 50 L4 organisations under one L3 subscriber. No architectural difference — only scale.

Seat Model¶

Each L4 organisation operates under a plan that determines its seat entitlement. Seats are purchasable as an add-on within a tier — headcount growth does not force a tier upgrade. However, the per-seat pricing is structured so that at a certain headcount, upgrading to the next tier becomes the rational commercial choice even if features alone would not justify it.

Indicative structure (numbers to be confirmed commercially):

Plan	Seats included	Additional seats	Practical ceiling
Starter	1	$35/user/month	~4 users before Pro is more economical
Pro	5	$X/user/month	~20 users before Enterprise is more economical
Enterprise	100	Custom	No hard ceiling

Architectural enforcement:

Seat limits are enforced at token issuance, not in the UI. When a L4A member attempts to authenticate, the token issuer checks active_member_count < org.seat_limit. If the check fails, authentication is rejected with error code SEAT_LIMIT_REACHED. The surface renders this as an upgrade prompt. Seat enforcement cannot be bypassed via UI manipulation because it does not live in the UI.

The org entity carries seat state:

{
  "org_id": "tafe-nsw-001",
  "plan_tier": "starter",
  "base_seats": 1,
  "purchased_seats": 3,
  "active_members": 3,
  "seat_limit": 4
}

4. Token Architecture¶

4.1 Core Principle: Capability Authority, Not Identity Provider¶

UCCA is the capability authority. UCCA is not necessarily the identity provider.

Every UCCA token asserts two things:

Who this is — the identity claim. May originate from UCCA's own credential store or from an external IdP. UCCA accepts the assertion and wraps it.
What they are permitted to do — the capability claim. Always sourced from UCCA. This is the product.

These two concerns are cleanly separated in every token. This separation is what makes enterprise federation possible (Section 6) — UCCA accepts an identity assertion from a TAFE's Azure AD and wraps it in a UCCA capability token without re-authenticating the user. The TAFE owns the identity. UCCA owns the capability.

4.2 Token Structure¶

All UCCA tokens are signed JWTs. Signing keys are world-scoped — each world has its own signing secret managed in Cloudflare KV. Platform-level tokens (L1/L2) use a separate platform signing key.

Standard claims (all tokens):

{
  "iss": "auth.ucca.online",
  "iat": 1742600000,
  "exp": 1742686400,
  "jti": "unique-token-id-uuid"
}

UCCA capability claims:

{
  "ucca_layer": 4,
  "world_id": "au-vet",
  "client_id": "bill-rto-001",
  "org_id": "tafe-nsw-001",
  "user_id": "user-abc123",
  "role_template_id": "internal-auditor",
  "permissions": [
    "qualifications:read",
    "scope:read",
    "audit:export"
  ],
  "identity_source": "ucca_managed",
  "impersonation": false,
  "impersonating_layer": null,
  "impersonating_user_id": null
}

Identity source values:

Value	Meaning
`ucca_managed`	User authenticated directly with UCCA-managed credentials
`federated`	Identity assertion received from an external IdP (Azure AD, Okta, SAML 2.0, OIDC)
`stepdown`	Token issued as part of a step-down impersonation session from a higher layer
`vcc`	Identity asserted via VCC dual-custody key + UCCA Authenticator (biometric unlock)

4.3 Token Lifetimes¶

Token type	Layer	Lifetime	Refresh
`ucca_platform_token`	L1	8 hours	Re-auth via Cloudflare Access
`ucca_su_token`	L2	4 hours	Derived from active L1; expires when L1 expires
`ucca_world_token`	L3	24 hours	Sliding window, refreshed on activity
`ucca_org_token`	L4	24 hours	Sliding window, refreshed on activity
`ucca_member_token`	L4A	8 hours	Re-auth or SSO refresh from IdP
Step-down token	Any	2 hours	Manual re-initiation from parent layer only

4.4 Token Storage¶

Layer	Storage
L1 / L2	`httpOnly`, `Secure`, `SameSite=Strict` cookie. Never accessible to JavaScript.
L3	`httpOnly`, `Secure` cookie scoped to the world domain
L4 / L4A	`httpOnly`, `Secure` cookie scoped to the org domain. For federated sessions, the IdP manages the primary session; UCCA token is stored identically alongside it.
Step-down	Short-lived `httpOnly` cookie with explicit expiry. Cleared on exit or timeout.

Tokens are never stored in localStorage or sessionStorage. Tokens are never passed in URL parameters. Token refresh is silent and automatic where the session is still valid.

4.5 Token Issuance Authority¶

All tokens are issued by a single authoritative endpoint:

POST auth.ucca.online/v1/token

This is the OAuth 2.1 authorisation server for the UCCA platform. Building it is B-AUTH-OAUTH-01. Until it exists, individual surfaces use their own JWT signing as a temporary measure (rtp_session on my.rtopacks.com.au). Migration path: surface-specific JWT → UCCA-issued token via auth.ucca.online.

The endpoint accepts: - Direct credential authentication (email + OTP) - External IdP assertion (OIDC id_token or SAML assertion) - Step-down request (parent layer token + target context) - VCC key assertion (from UCCA Authenticator)

And returns a signed ucca_*_token appropriate to the authenticated layer and context.

5. Step-Down Mechanics (Layer Switching)¶

5.1 Concept¶

A step-down is a session context switch. It is not a URL change, not a separate login, and not a new browser tab. An operator at a higher layer enters a lower layer's context to see exactly what that layer's users see.

Step-down sessions are always: - Initiated explicitly — the operator selects a target context (client, org, or user) - Visually indicated — a persistent banner appears at all times during the session - Time-limited — step-down tokens expire after 2 hours regardless of activity - Audited — every initiation, action, and exit is written to the audit log - Exitable — a single click always returns the operator to their native layer

5.2 Step-Down Chain¶

L1 (Tim at ops.ucca.online)
  └─ steps into L2 → selects client from account switcher
       └─ steps into L3 → views as Bill (the subscriber)
            └─ steps into L4 → selects a client organisation
                 └─ steps into L4A → selects a specific member

Each step is explicit. Layers cannot be skipped — L1 cannot jump directly to L4A without passing through L2, L3, and L4 selections. This forces the operator to build context at each layer before going deeper.

5.3 Step-Down Token Issuance¶

When an operator initiates a step-down:

The operator's current token is verified as valid
A step-down token is issued with identity_source: "stepdown", impersonation: true, impersonating_layer, impersonating_user_id, all permission claims of the target context, and hard expiry at now + 2 hours
The step-down token is stored as a secondary cookie alongside the operator's primary token
The surface renders the target layer's view using the step-down token's claims

The operator's primary token is never replaced. On exit, the step-down token is deleted and the primary token resumes.

Non-dismissable. Appears at all times during a step-down session.

┌──────────────────────────────────────────────────────────────────────┐
│  👁  Viewing as: [Layer name] — [Context name]      [Exit]  1:47:23  │
└──────────────────────────────────────────────────────────────────────┘

Element	Specification
Position	Fixed top of viewport, above all content
Colour	Amber (`amber-500`) — distinct from any normal UI element
Height	36px
Left	Eye icon + "Viewing as:" + layer name + context name
Right	Exit button + live countdown (HH:MM:SS)
Timer	Counts down from 2:00:00. Turns red at 5 minutes. On expiry, session exits automatically and operator returns to native layer.
Exit	Single click, no confirmation dialog

Example states:

L1 → L3: 👁 Viewing as: World Operator — Bill's RTO (bill-rto-001)
L1 → L4: 👁 Viewing as: Client Organisation — TAFE NSW (tafe-nsw-001)
L1 → L4A: 👁 Viewing as: Member — Sarah Chen [internal-auditor]
L3 → L4: 👁 Viewing as: Client Organisation — Jones Consulting (jones-001)

5.5 Cross-Surface Step-Down Handoff¶

The step-down from ops.ucca.online into my.rtopacks.com.au requires a cross-domain token handoff. Session cookies from ops.ucca.online cannot be read by my.rtopacks.com.au.

Handoff mechanism:

Operator initiates step-down from ops console
auth.ucca.online issues a short-lived (60 seconds), single-use handoff token
Operator is redirected to my.rtopacks.com.au/auth/stepdown?token=[handoff-token]
my.rtopacks.com.au exchanges the handoff token with auth.ucca.online for a full step-down session token
auth.ucca.online validates the exchange, confirms the handoff token is unused, issues the step-down session token, and invalidates the handoff token immediately
my.rtopacks.com.au stores the step-down token as a cookie and renders the L3 view with the impersonation banner

The handoff token is a single-use redirect mechanism, not a bearer credential. It expires in 60 seconds and cannot be reused.

5.6 White-Label Domain Step-Down¶

When a L4 organisation runs on their own domain (e.g. compliance.theirtafe.edu.au), the same handoff mechanism applies. The TAFE's domain must be registered as a trusted redirect target in world.config.json:

"trusted_stepdown_domains": [
  "compliance.theirtafe.edu.au"
]

Step-down sessions to unregistered domains are rejected by auth.ucca.online.

6. Enterprise Federation (External IdP Integration)¶

6.1 The Model: Consumptive, Not Invasive¶

UCCA does not insert itself into an enterprise client's authentication flow. UCCA is called as a capability service when capability verification is needed. The enterprise client owns and operates their own identity infrastructure.

This means:

A TAFE with 10,000 staff continues to authenticate against their own Azure AD
Their application calls the UCCA capability API: "what is this person certified to do?"
UCCA returns a signed capability assertion
The TAFE application gates access to compliance-sensitive features based on the assertion
UCCA never touches the TAFE's session, never stores TAFE passwords, never sits in the critical login path

If UCCA's API is unavailable, the TAFE's staff can still log in. Capability-gated features degrade gracefully.

6.2 Supported Identity Protocols¶

Protocol	Phase	Use case
OIDC (OpenID Connect)	1	Azure AD, Google Workspace, Okta, Auth0
OAuth 2.0 token exchange	1	Modern SaaS platforms
API key (machine-to-machine)	1	LMS systems (Moodle, Canvas), server-side integrations
SAML 2.0	2	Legacy enterprise IdPs, university SSO systems

6.3 Federation Registration¶

Federation is configured at L3 by Bill or at L2 by UCCA for large enterprise onboarding. Configuration lives in world.config.json under the federation block:

"federation": {
  "enabled": true,
  "providers": [
    {
      "provider_id": "tafe-nsw-azure",
      "protocol": "oidc",
      "issuer": "https://login.microsoftonline.com/[tenant-id]/v2.0",
      "client_id": "[azure-app-client-id]",
      "jwks_uri": "https://login.microsoftonline.com/[tenant-id]/discovery/v2.0/keys",
      "claim_mapping": {
        "user_id": "sub",
        "email": "email",
        "display_name": "name",
        "groups": "groups"
      },
      "default_role_template": "course-writer",
      "group_role_mapping": {
        "Auditors-AD-Group-ID": "internal-auditor",
        "Managers-AD-Group-ID": "department-manager",
        "Admins-AD-Group-ID": "org-admin"
      }
    }
  ]
}

When a federated user authenticates, auth.ucca.online:

Receives the OIDC id_token from the enterprise IdP
Validates the token signature against the IdP's JWKS endpoint
Extracts the configured claims
Looks up or creates the UCCA user record (keyed on email)
Applies the group-to-role-template mapping
Issues a ucca_member_token with identity_source: "federated"
Returns the token to the calling application

UCCA's involvement ends at token issuance. The enterprise client's session management takes over.

6.4 Machine-to-Machine (LMS Integration)¶

LMS systems authenticate via API key. The integration pattern:

Bill registers an API key for his LMS at L3
The LMS calls POST auth.ucca.online/v1/m2m/token with the API key
UCCA issues a scoped machine token (ucca_m2m_token) bound to org_id and permitted endpoints
The LMS calls UCCA capability endpoints using the machine token
Machine tokens are short-lived (1 hour) and automatically refreshed by the integration layer

7. Role Template System¶

7.1 Purpose¶

Role templates are UCCA's pre-built permission profiles for common organisational roles within a regulated domain. They are the mechanism by which L3 (Bill) governs what L4A members can do.

Templates are: - Pre-built by UCCA per world, based on real-world role patterns in the regulated domain - Adjustable by the L4 organisation — any template can be forked and customised. Forks are not affected by UCCA template updates. - Creatable from scratch by the L4 organisation if no template fits - Mappable to external IdP groups for enterprise federation

7.2 AU VET World — Default Role Templates¶

Template ID	Display Name	Description
`org-admin`	Organisation Admin	Full access to the L4 organisation. Manages members, billing, role templates. The "Bill" of the L4 level.
`department-manager`	Department Manager	View and manage staff capability records within their scoped department. Approve enrolments. No billing or org settings access.
`internal-auditor`	Internal Auditor	Read-only across all compliance records and capability evidence. Can export evidence chains. Cannot modify records.
`course-writer`	Course Writer	View units and qualifications. Draft and edit scope rows. No sign-off authority. Cannot view other members' records.
`trainer-assessor`	Trainer/Assessor	View assigned units and qualifications. Record assessment outcomes. View own capability record.
`compliance-viewer`	Compliance Viewer	Read-only access to the organisation's compliance status dashboard only. No access to individual records.

7.3 Permission Taxonomy¶

Permissions follow a resource:action naming convention.

Resources: qualifications, units, scope, audit, members, billing, org-settings, evidence, assessments

Actions: read, write, export, approve, manage

Example permission sets:

{
  "internal-auditor": {
    "permissions": [
      "qualifications:read",
      "units:read",
      "scope:read",
      "audit:read",
      "audit:export",
      "evidence:read",
      "evidence:export"
    ]
  },
  "course-writer": {
    "permissions": [
      "qualifications:read",
      "units:read",
      "scope:read",
      "scope:write"
    ]
  }
}

7.4 Template Customisation Rules¶

Fork — copy a UCCA-provided template and adjust permissions. The fork is org-owned. UCCA updates do not propagate to forks.
Create — build from a blank permission set.
Assign — one template per member at a time.
Map to IdP groups — for federated orgs, group membership determines template assignment automatically.

Template changes take effect at next token issuance. For security-sensitive permission reductions, L4 admins can force immediate session revocation from the member management panel.

8. The Demo Journey¶

The specific journey Tim walks a prospect through to demonstrate the integrated platform. Every step maps to built or to-be-built infrastructure.

Scenario: Tim is showing a prospective RTO operator how the platform works end to end, in a single browser window.

Step	Actor	Surface	What happens	Infrastructure status
1	Tim	`ops.ucca.online`	L1 platform dashboard. All worlds, system health. Tim selects RTOpacks world.	Live
2	Tim	`ops.ucca.online`	Clicks "Step down → View as subscriber". Selects demo subscriber (Bill).	To build — B-OPS-SWITCHER-01
3	Tim	`my.rtopacks.com.au`	Amber banner appears. Tim sees `my.rtopacks.com.au` exactly as Bill sees it. RTOpacks branded, no UCCA fingerprinting.	To build — cross-surface handoff
4	Prospect	Watching Tim's screen	Sees a real subscriber workspace — search, saved qualifications, intelligence tiles, account.	Live — B-UX-WORKSPACE-01
5	Tim	`my.rtopacks.com.au`	Clicks "Step down → View as client org". Selects a demo L4 organisation.	To build — B-OPS-SWITCHER-01
6	Prospect	Watching Tim's screen	Sees the L4 org view — compliance dashboard, members, capability records.	To build — B-UX-L4-01
7	Tim	`my.rtopacks.com.au`	Clicks "Step down → View as member". Selects the Internal Auditor demo user.	To build — B-OPS-SWITCHER-01
8	Prospect	Watching Tim's screen	Sees exactly what an internal auditor sees — read-only compliance records, export capability, nothing else.	To build — B-UX-L4A-01
9	Tim	Anywhere	Clicks "Exit" on the amber banner. Returns to L1 in one click.	To build — step-down exit

The demo never leaves a single browser window. The amber banner makes impersonation visible and trustworthy — the prospect sees that UCCA can support any user in the system without those users sharing credentials. That is itself a compliance selling point.

9. Build Sequence¶

Briefs implement this specification in strict dependency order. No brief starts until its dependency is deployed and verified.

Brief ID	Title	Depends on	Delivers
`B-OPS-SIDEBAR-01`	Ops console sidebar restructure	B-UX-WORKSPACE-01 ✓	Sidebar per UI Spec Section 2. Active states, world context, stub policy. Makes ops console credible for demo.
`B-AUTH-OAUTH-01`	UCCA OAuth 2.1 authorisation server	B-OPS-SIDEBAR-01	`auth.ucca.online` — the token issuance spine. All subsequent auth work depends on this.
`B-OPS-SWITCHER-01`	L1→L2→L3 step-down mechanic	B-AUTH-OAUTH-01	Account switcher in ops console, cross-surface handoff to `my.rtopacks.com.au`, impersonation banner, exit mechanic. Enables demo journey.
`B-UX-L4-01`	L4 organisation surface	B-AUTH-OAUTH-01	Client organisation view — compliance dashboard, member list, basic capability records.
`B-UX-L4A-01`	L4A member surface	B-UX-L4-01	Individual member view, role-template-scoped. Capability records, personal compliance status.
`B-AUTH-FEDERATION-01`	External IdP federation	B-AUTH-OAUTH-01	OIDC federation support. Enables TAFE/enterprise clients to bring their own IdP.
`B-UX-ROLETEMPLATES-01`	Role template management UI	B-UX-L4-01	L4 admin panel for viewing, forking, and assigning role templates.
`B-UX-WHITELABEL-01`	White-label domain support	B-AUTH-FEDERATION-01	Custom domain registration, trusted step-down domain config, branded L3/L4 on client domains.

10. What This Specification Does Not Cover¶

The following are out of scope and addressed in separate documents:

VCC (Verified Contact Chain) — dual-custody key model, Merkle chain, UCCA Authenticator. See The Gate II.
Billing and subscription management — Stripe integration, seat purchase flows. Separate billing spec required.
White-label visual customisation — branding tokens per world. Addressed in B-UX-WHITELABEL-01.
The NDA-gated external integration guide — the document given to a TAFE IT architect post-NDA. Derived from this specification but written for an external engineering audience. Separate document.
World-specific permission taxonomies beyond AU VET — each new world defines its own role templates within the same framework.

10A. Surface UX Philosophy by Layer¶

Architectural decision locked 2026-03-22. Do not override without discussion.

Each layer has a distinct UX paradigm. These reflect who the actor is and what they are trying to accomplish — not stylistic preference.

L1 — Engineering console. Full density. Every control visible. Tim and Alex only. Optimised for speed and completeness, not learnability.

L2 — Operational console. Dense but scoped. UCCA staff managing a specific client relationship. Same console chrome as L1, different data bindings.

L3 — Product surface. This is where the commercial product lives. Bill is a domain expert running his business, not a platform operator. L3 must be excellent, not merely functional. Card-based dashboard, task-oriented navigation, guided workflows. The sidebar model is appropriate at L3 but density and language must reflect Bill's domain, not UCCA's engine. The feedback loop between UCCA and the market operates entirely in this stratum.

L4 — Client application. Bill's client organisations. Not technical users. The sidebar model is likely inappropriate. Card-based, app-like, minimal chrome. Guided workflows, not menus. When built, L4 will look substantially different from L1/L2/L3. Do not carry the console pattern forward.

L4A — Single-purpose views. Individual staff members arriving to do one specific task. Navigation nearly disappears. The surface recedes — only the task is visible.

Step-down to L4/L4A is a support and diagnostic act. When UCCA steps down to L4 or L4A it is because a support issue has been escalated. The only UCCA-specific chrome needed: the amber banner, a UCCA DIAGNOSTICS panel (session info, support notes, audit trail), and a single exit control back to L1. Nothing from the ops console bleeds into the L4/L4A experience.

11. Document Control¶

Version	Date	Author	Change
1.0	2026-03-22	Tim Rignold / Claude (Pace)	Initial specification. Five-layer model, token architecture, step-down mechanics, cross-surface handoff, enterprise federation, role templates, seat model, demo journey, build sequence.
1.1	2026-03-22	Tim Rignold / Claude (Pace)	Added Section 10A: Surface UX Philosophy by Layer