The UCCO¶
Universal Credentialling and Compliance Object — Canonical Statement v1.2 — 2026-03-07
The Distinction¶
A credential answers the question: what does this entity know?
A UCCO answers the question: is this entity certified to act?
Canonical Statement¶
The distinction is the foundation of the UCCA platform. Knowledge without authorisation is inert. In human systems, the gap between knowing and acting is managed by institutional trust — a licence, a registration, a certificate. In agentic systems, that gap has no manager. An AI agent may possess complete knowledge of a procedure and remain unauthorised to execute it under the governing regulatory instrument.
The UCCO closes that gap. It is a deterministic, versioned, hashed object that binds a defined capability to a specific legislative instrument, at a specific point in time, for a specific entity — human or machine. It is not issued by UCCA. It is derived by UCCA from the legislative instrument itself, making the instrument — not the platform — the source of authority.
This makes the UCCO the primitive unit of the agentic compliance economy. Every regulated AI deployment — in healthcare, aviation, defence, laboratories, finance, education — requires a mechanism to certify not capability, but authorised action. The UCCO is that mechanism.
The Architecture¶
UCCA creates UCCOs. Worlds deliver them. Agents consume them. The record is immutable.
The Engine's Role — Shape Validator, Not Compliance Officer¶
The engine at L1 is not a compliance system. It is a shape validator.
The UCCO defines what a compliant object looks like — its shape. When a world presents data back to the engine, the engine checks that shape and returns one of two responses: pass, or reject and try again. That is the full extent of the engine's compliance role. It does not make a world compliant. It cannot. Compliance belongs to the client — their world, their primitives, their responsibility.
This is a filter at the gate. Data does not flow into the engine freely. Every submission passes through the shape validator on entry. A structurally non-conforming object is rejected before it can corrupt the record. What passes through is sound by definition. This is deterministic compliance — not probabilistic, not AI-inferred, deterministic.
RTOpacks is the proof of concept. RTOpacks holds world-level primitives — TGA taxonomy, qualification codes, unit mappings, RTO registrations. These live in the RTOpacks world at L1, not in the engine. The engine does not know what a Certificate IV in Project Management is. RTOpacks knows. The engine knows only whether the shape is right. Shape check. Pass or reject. That is the gate.
OSCAL — The Sleeve¶
OSCAL is the sleeve. Pull it and the engine log is exposed.
OSCAL — Open Security Controls Assessment Language — is the US Government's open standard for machine-readable compliance documentation. Developed by NIST, it defines security controls, system security plans, assessment results, and audit evidence in XML, JSON, or YAML. It is free, open, and rapidly becoming the lingua franca of enterprise and government compliance.
UCCA stores its own compliance posture natively in OSCAL. Every SOC 2 control, every evidence item, every version of every policy — stored as OSCAL JSON in R2, git-backed, cryptographically provable. The engine that certifies others is itself certified using the same machine-readable standard it promotes. That is not a design choice. That is proof of concept.
When an auditor pulls the OSCAL sleeve, what is exposed is not a Word document, not a spreadsheet, not a manually maintained register. What is exposed is the engine log — every primitive, every version, every hash, every decision that produced the compliance posture, in order, traceable to the legislative instrument it was derived from.
The recursive integrity is the proof. The OSCAL document is validated by the same engine that produced the compliance claim it describes. The sleeve and the arm are the same material. You cannot tamper with one without invalidating the other.
The origins of the species — visible, immutable, machine-readable, and already running.
UCCA Certification Policy — Root vs World¶
UCCA maintains certifications at the platform root where they provide collective value across the entire customer base. Global standards — SOC 2, ISO 27001, FedRAMP, ASDEFCON, GoBD — are root certifications. Every client inherits them by building on UCCA.
Client-specific standards live in the client's world. The client owns them, maintains them, polices them. UCCA provides the engine and the primitives. Compliance to the client's specific regulatory instrument is the client's responsibility — and their competitive advantage.
UCCA adds a standard at root only when it sees collective value across the customer base. That decision is made by UCCA. A client who wishes to fund a root-level certification for collective benefit enters an enterprise partner conversation.
The Agentic Imperative¶
For robots and AI agents, a credential is insufficient. Knowledge is not the gate — authorisation is. An agent must be certified to act in order to initiate, to execute, to be trusted with consequence. The UCCO is the enabler of that trust. Without it, capability is latent. With it, capability becomes licensed action — and licensed action is where economic value is created and where regulatory liability is managed.
Design Principle — The System Is the Argument¶
The console is built to be left alone with. Every page answers the question it raises without anyone in the room.
The posture is not demonstration. It is evidence. A visitor can be handed access and left to explore. LIVE mode for operations. COMPLIANCE mode for diligence. The system surfaces what it is without narration.
The system is the argument. We don't stand between the observer and the evidence.
Version History¶
| Version | Date | Change | Author |
|---|---|---|---|
| 1.2 | 2026-03-07 | Current version | Tim Rignold |
| 1.3 | 2026-03-11 | Filed to knowledge site with frontmatter | Claude Code |