Boundary Agreement¶

RTOpacks Pty Ltd ↔ UCCA Inc¶

Document type: Inter-company boundary agreement (technical and commercial)
Status: Working document — not yet executed as formal contract
Version: 1.0
Date: 2026-04-06
RTOpacks author: Tim Rignold, Founder
UCCA counterpart: UCCA Inc, Delaware

Purpose¶

This document defines the boundary between RTOpacks Pty Ltd (Australian proprietary limited company) and UCCA Inc (Delaware corporation). It answers one question from every angle: where does UCCA end and RTOpacks begin?

It serves three purposes simultaneously: 1. Architectural reference — whose code, whose data, whose responsibility at every point 2. Commercial prototype — the shape of what a formal inter-company services agreement will look like when this relationship is formalised 3. Due diligence foundation — any acquirer, investor, or auditor can read this and understand exactly what RTOpacks is, what it is not, and what it depends on

This document is not a legal contract. It captures commercial intent and technical reality with sufficient precision that a lawyer can draft from it and an engineer can build from it.

The Entities¶

RTOpacks Pty Ltd - Australian proprietary limited company - Product: RTOpacks — a VET sector intelligence and management platform for Australian Registered Training Organisations - Domicile: Australia - Operates: rtopacks.com.au, my.rtopacks.com.au, admin.rtopacks.com.au - Identity: Standalone product. Not a sub-product of UCCA. Not a module. A product.

UCCA Inc - Delaware corporation - Product: UCCA Engine — a multi-tenant platform infrastructure for regulated-industry intelligence products - Domicile: United States (Delaware) - Operates: ucca.online, ops.ucca.online, auth infrastructure - Identity: Infrastructure provider and platform engine. Not a consumer-facing product.

The Relationship¶

RTOpacks is a customer of UCCA. Specifically, RTOpacks is a Level 3 operator on the UCCA platform — an independent operator that connects to UCCA's infrastructure in the same way it connects to any trusted external service.

RTOpacks connects to UCCA's authentication backplane. That is the current and complete extent of the operational relationship.

Nothing flows up. UCCA has no visibility into RTOpacks data, users, or operations.
Nothing flows down. UCCA does not push data, configuration, or policy into RTOpacks.
No credentials are shared. RTOpacks operates entirely under rtopacks.com.au identity.

This relationship is structurally identical to RTOpacks' relationship with TGA, ASQA, or NCVER — a trusted external service that RTOpacks connects to for a specific purpose. The difference is that UCCA also provides the authentication infrastructure rather than just data.

What UCCA Provides¶

Current (live)¶

Authentication backplane - Identity assertion infrastructure — the mechanism by which RTOpacks establishes who a user is - Session layer architecture — the RTPSession schema, tier model, and session lifecycle - Tier model specification — the L1/L2/L3/L4/L4A layer definitions and their meaning - Security architecture reference — the constitutional documents that define how a compliant operator must behave

What UCCA does NOT provide (currently): - Hosting — RTOpacks runs on its own Cloudflare account (e5a9830215a8d88961dc6c80a8c7442a) - Data — all RTOpacks data sources are independently connected (TGA, ASQA, NCVER, ABS, etc.) - User management — RTOpacks manages its own users, allowlists, and access control - Monitoring — RTOpacks operates its own logging, anomaly detection, and alerting - Support infrastructure — RTOpacks operates its own admin panel, CRM, and ops console

Future (not yet built)¶

Federation / Step-down access (FEDERATION-HOOK-01) - A mechanism by which UCCA L1/L2 can enter a connected L3 operator's environment for support and compliance purposes - Will be implemented as a UCCA-issued signed assertion token - RTOpacks will validate and honour the token; it will not embed UCCA identity - The implementation placeholder is FEDERATION-HOOK-01 in lib/tier-resolution.ts - L4/L4A users are invisible to UCCA until this is built; they remain invisible to UCCA after it is built except during an active step-down session

OAuth server (B-AUTH-OAUTH-01) - auth.ucca.online as a formal OAuth 2.1 server - RTOpacks will connect to it as an OAuth client - Until this is built, the auth backplane connection is via shared architectural specification, not a live API call

What RTOpacks Provides to Itself¶

Everything not listed above is RTOpacks' responsibility:

All application code (workspace, admin, site, internal-api, pipeline Workers)
All data infrastructure (Cloudflare D1, R2, KV under UCCA CF account — RTOpacks' own account)
All data source connections (TGA, ASQA, NCVER, ABS, JSA, CRICOS, TEQSA, yourcareer.gov.au)
User identity and access management (access_allowlist, magic link delivery via Resend)
Anomaly detection and session security (SEC-02)
Operational logging and audit (api_access_log, anomaly_log, platform_audit_log)
Admin and CRM infrastructure
Public site and marketing
Transactional email (Resend, noreply@rtopacks.com.au)
DNS and domain management (rtopacks.com.au zone)
Legal compliance (Australian Privacy Act, consumer law, VET sector obligations)

The Seam — Where They Touch¶

The boundary is not a wall. There is a seam. It is narrow and precisely located.

The seam is the auth event.

When a user requests a magic link: 1. RTOpacks checks its own allowlist (RTOpacks' responsibility) 2. RTOpacks sends the magic link via its own Resend account (RTOpacks' responsibility) 3. The user clicks the link and a session is created 4. The session is typed against the UCCA tier model (shared architecture — both parties) 5. Tier resolution determines what the user can access (RTOpacks' implementation of UCCA's spec) 6. The session is logged to RTOpacks' own audit infrastructure (RTOpacks' responsibility)

At step 4 — that is the seam. UCCA's architecture makes a claim about what tiers mean and how they should be resolved. RTOpacks implements that claim in its own code. Neither party is running the other's code at this point — it is a specification compliance relationship, not a runtime dependency.

When FEDERATION-HOOK-01 is built, the seam expands slightly: UCCA will issue a token, RTOpacks will validate it. The seam remains narrow. It is not an integration — it is a handshake.

Responsibilities at the Seam¶

Responsibility	UCCA	RTOpacks
Tier model specification	✓ owns	implements
Session schema definition	✓ owns	implements
Identity assertion (current)	specification only	✓ owns implementation
Identity assertion (future OAuth)	✓ owns runtime	connects as client
Step-down token issuance	✓ owns (future)	honours (future)
Step-down token validation	specifies	✓ owns implementation
User data	no access	✓ owns
Allowlist management	no access	✓ owns
Anomaly detection	no access	✓ owns
Audit logs	no access	✓ owns

What RTOpacks Can Expect of UCCA¶

Specification stability — UCCA will not silently modify the tier model, session schema, or auth architecture in ways that break RTOpacks' implementation. Changes will be communicated with reasonable notice.
No silent data access — UCCA will not access RTOpacks data, users, or operational systems without RTOpacks' knowledge and consent.
Federation notice — when FEDERATION-HOOK-01 is built, RTOpacks will be consulted on the token format and validation mechanism before it is finalised.
Exit support — if RTOpacks terminates this relationship or is acquired, UCCA will provide reasonable assistance in detaching from the auth backplane and replacing it with an independent implementation.

What UCCA Can Expect of RTOpacks¶

Tier model compliance — RTOpacks will implement the UCCA tier model faithfully and will not circumvent tier restrictions.
No identity impersonation — RTOpacks will not use UCCA identity, domain, or branding in any user-facing context.
Federation hook preservation — RTOpacks will maintain the FEDERATION-HOOK-01 placeholder and will not implement a competing step-down mechanism that conflicts with the future OAuth design.
Security minimums — RTOpacks will maintain the security posture defined in its own constitution documents (invite-only access, anomaly detection, NRT data gating).
Honest representation — RTOpacks will not represent itself as UCCA or suggest to customers that they are dealing with UCCA.

The Buffer Zone¶

Between UCCA's specification and RTOpacks' implementation sits a necessary grey area. Decisions made in this grey area belong to RTOpacks but are informed by UCCA's architecture.

Current grey area decisions made by RTOpacks: - L4A sentinel value — using 4.5 as the numeric sentinel for L4A tier. UCCA's spec defines L4A; RTOpacks chose the implementation detail. - Magic link as primary auth — UCCA's spec allows multiple auth mechanisms; RTOpacks chose magic link. This is a valid implementation choice. - bootstrapSession() default — defaulting to L4A for unknown users. Conservative. Consistent with UCCA's principle of least privilege. - KN gating at L4 — stripping kn_criteria_reasoning from L4A responses. RTOpacks' product decision implemented within UCCA's tier framework.

These decisions are documented here so that if UCCA's specification evolves, RTOpacks can assess whether its implementation choices remain compliant.

Exit — What Clean Separation Looks Like¶

If RTOpacks is acquired, merges, or terminates its relationship with UCCA:

Auth backplane replacement — the FEDERATION-HOOK-01 seam is the only runtime dependency. Replace with an independent auth implementation (e.g. standalone magic link with no tier model, or a third-party auth provider).
Tier model — RTOpacks owns its implementation. The tier labels (L4/L4A) can be renamed or restructured without UCCA involvement.
Data — all RTOpacks data is in RTOpacks' own Cloudflare account. No data migration required.
Code — all RTOpacks code is in RTOpacks' own repositories. No UCCA code is embedded.
Domain — rtopacks.com.au is RTOpacks' domain. No UCCA involvement.

An acquirer gets: the product, the data, the code, the customer relationships, the domain.
An acquirer does not get: UCCA's engine, UCCA's platform, UCCA's other operators, UCCA's IP.

The separation is clean by design. This was intentional.

Document History¶

Version	Date	Notes
1.0	2026-04-06	Initial working document — Session 44

Next Steps¶

Legal review — convert to formal inter-company services agreement when relationship is formalised
Add schedule: Service SLAs when UCCA OAuth server (B-AUTH-OAUTH-01) is live
Add schedule: Federation terms when FEDERATION-HOOK-01 is built
Data Processing Agreement — when UCCA auth backplane processes any RTOpacks user PII at runtime