UCCO v2.0 — Internal Working Paper

Universal Capability Chain Object — Full Architecture

Date: 14 March 2026
Status: Internal working document. Not for external distribution.
Purpose: Consolidates all thinking from 14 March 2026 session into a structured basis for UCCO v2.0 specification. Every concept captured — some fully specified, some stubbed for further development. Nothing lost.
Feeds into: UCCO Standard v2.0 Draft for Public Comment
Authors: Tim Rignold + Claude (Anthropic)

---

Preface — What This Document Is

This is the paper flying out the back window of the car.

We caught it.

Everything developed in this session is captured here — fully specified where we got there, stubbed with clear TO DO markers where we didn't. The distinction between "ready to write into the standard" and "concept to develop further" is explicit throughout.

v1.1 is the shipping document. This is the architecture document that becomes v2.0.

---

Part 1 — Framing and Positioning

1.1 The One-Sentence Pitch (LOCKED)

"The internet moved data without knowing who sent it. UCCO moves capability with full knowledge of who holds it, what they're certified to do, and what they actually did."

Use in: commercial architecture doc, investor deck, standards body cover letters, every public appearance.

1.2 What UCCO Actually Is

UCCO is an enriched transit layer with identity, security, and consequence native to the protocol. Not bolted on afterward. The internet's missing layer — what you would design if you started from scratch knowing:

• Actors are not always trustworthy
• Acts have real-world consequences
• Evidence gets destroyed
• Machines would eventually outnumber humans as actors
• Accountability must survive all of the above

The SSL analogy (Tim's — KEEP):
"SSL for the age of autonomous action."

SSL secured data in transit. Before it, no commerce on the internet. After it, you could — and nobody needed to understand the cryptography.

UCCO secures action — the moment a certified actor does a certified thing in the real world. Before it, no autonomous machine commerce, no AI agent deployment in regulated environments at scale. After it, you can. Nobody using it needs to understand the chain structure.

The TCP/IP analogy (secondary):
UCCO is to capability what TCP/IP is to data transport. Open protocol. Anyone implements. First mover with best infrastructure wins. UCCA is to UCCO what Cisco was to TCP/IP.

Key distinction from TCP/IP:
TCP/IP is pure transit — no memory, no consequence, no identity. UCCO carries semantic weight. The chain event is simultaneously: a record, a trigger, a billing event, and a legal instrument. Consequence is native to the protocol layer.

1.3 The Full System Workflow (Canonical)

LEGISLATION
    ↓
STANDARDS  
    ↓
HUMAN EXPRESSION OF COMPETENCE AT ATOMIC UNIT SIZE
    ↓
UCCA — THE PASTEURISER AND SYNTHESISER
    Ingests:  legislation / standards / human competency units
    Does:     assimilates / contextualises / verifies / pasteurises / tracks
    Output:   clean cryptographically packed UCCO containers
    ↓
UCCO — THE PACKED CONTAINER
    Travels on the wire
    ↓
ENDPOINT
    Unpacks / verifies / deploys capability
    Actor acts
    ↓
UCCO PHONES HOME — THE ACTIVE RETURN CHANNEL (not passive)
    "Received. Deployed. My current circumstance also 
     requires capability unit 2389289112."
    ↓
UCCA RUNS AGAIN
    Finds unit / packs / verifies / bills / sends
    ↓
LOOP NEVER STOPS. METER NEVER STOPS.

The capability_request event is NOT an exception handler. It is the engine of the entire system. Every dynamic environment runs on this loop continuously.

1.4 What vs Commercial in Confidence

IN THE STANDARD — open, published, normative: - The container structure and socket interface - The chain event schema - The callback / active return channel mechanism - Classification tier framework - K2 Volatility Mode - Multi-packer / complementary capability stacking - Root registry architecture - Industry classification socket (ISIC reference) - Pack types including PUBLIC_GOOD - Dynamic capability installation - First Do No Harm imperative - WHOIS and circle of trust - Human consent events - Government ledger push interface - STALE trust state - Dual authority / quorum mechanism - UCCO as external subprocess (not cognitive layer) - Conformance test suite (future)

COMMERCIAL IN CONFIDENCE — UCCA proprietary: - The pasteurisation process — how UCCA ingests legislation/standards/competency units - The billing model and meter mechanics - The upchain marketplace mechanics - The contextualisation and synthesis engine - UCCA's specific ephemeral key issuance and rotation - The TGA corpus and enrichment pipeline - UCCA's root registry node infrastructure and operations - UCCA's specific government ledger integrations and commercial agreements - UCCA's vetting process for issuing authority registration

The code refusal position (LOCKED):

"We don't publish our implementation. We publish the standard. Build your own. That's the point."

The conformance test suite is the gate. Pass it and you're in. Fail it and you're not. The bar protects everyone in the ecosystem — especially the humans whose lives depend on the capability containers being correct.

---

Part 2 — The Cube Model (Architecture Foundation)

2.1 The Container as Cube

A UCCO container is not a flat credential. It is a cube with potentially thousands of sockets.

Mandatory sockets — must be active and valid for the container to be conforming. Defined by the standard. Missing mandatory socket = container is malformed, contaminated, or deprecated. Rejected by any conforming verifier. This is the anti-sprawl mechanism. The standard is a validation schema, not just a description.

Domain-specific sockets — labelled by the packer for their use case. Aerospace labels theirs differently to medical, differently to defence. This is intentional extensibility, not sprawl. The core is universal. The content is domain-specific.

Unlabelled sockets — available for contextualisation by the receiving endpoint. The endpoint labels them for its specific use case.

The complementary stacking principle:
A soldier robot can hold USDF weapons certification from a defence packer, UCCA tyre-changing capability, and NHS basic field medicine — simultaneously. Not conflicting. Additive. The cube accepts all of them. This is a feature, not a bug.

2.2 Mandatory Base Sockets (First Pass — TO DO: Full Schema)

Every conforming UCCO container must expose these sockets in defined form. A container missing any mandatory socket is malformed regardless of how rich its domain sockets are.

Socket	Content	Status
Identity socket	Actor DID, actor type, identity primitive hash	SPECIFY
Capability socket	Capability envelope hash, ISIC code(s), pack type	SPECIFY
Chain integrity socket	Chain tip hash, genesis event reference, vault sync timestamp	SPECIFY
Supervision socket	Supervisor DID (required for non-human), DFA policy hash	SPECIFY
Validity window socket	issued_at, expires_at, standard_version_certified	SPECIFY
Issuing authority socket	Authority DID, authority signature, root registry reference	SPECIFY
Industry classification socket	ISIC code(s), optional regional mappings	SPECIFY
Pack type socket	COMMERCIAL / PROPRIETARY / CLASSIFIED / PUBLIC_GOOD	SPECIFY
First Do No Harm socket	Hardcoded imperative — see Section 4.4	SPECIFY
K2 mode socket	PERSISTENT / EPHEMERAL	SPECIFY
Consent required socket	NONE / INFORMED / WITNESSED / DUAL_AUTHORITY	SPECIFY
External ledger push socket	Target system, push status	SPECIFY

TO DO: Full socket schema definition for each — field names, types, validation rules, required vs optional sub-fields. This is the priority technical work for v2.0.

2.3 Socket Classification

Each socket has a classification state: - OPEN — readable by any conforming verifier - PROPRIETARY — readable only by authorised commercial verifiers - CLASSIFIED — readable only at specified classification level (SECRET, TOP SECRET, etc.)

A container with inaccessible sockets is NOT malformed provided all mandatory sockets are valid and accessible. Classification is a content attribute, not a structural failure.

This opens the defence and intelligence market. UCCA doesn't need to know what's in a classified socket to validate the container is well-formed. The mandatory sockets confirm validity. The classified sockets are opaque to everyone except the authorised consumer.

---

Part 3 — Registry Architecture

3.1 The Root Registry — IANA for Capability

The root registry is not an analogy. It is a normative architectural concept. Without it the standard has no formal answer to: - Where do I look up an actor I've never seen before? - How do I verify an issuing authority is legitimate? - Where do PUBLIC_GOOD packs get discovered? - What formally defines a rogue operator?

The DNS mapping — normative:

DNS Concept	UCCO Equivalent
IANA	UCCO Root Registry — authoritative list of all registered issuing authorities
TLD registry	Issuing Authority Registry — UCCA, defence packer, NHS, each maintains their zone
Domain record	Actor record — every registered actor has a record in their issuing authority's registry
DNSSEC	Every registry entry cryptographically signed — verifiable without calling back
Root servers	Distributed root registry nodes — UCCA operates first, others can mirror
DNS resolver	Conforming verifier — queries root to resolve actor identity
WHOIS	UCCO public query interface — returns public surface of any registered actor
8.8.8.8	UCCA — most trusted, fastest, most complete registry. The platform play.

3.2 Trust Hierarchy

Cryptographic all the way down:

UCCO ROOT REGISTRY
    ↓ signs and validates
ISSUING AUTHORITY REGISTRY (UCCA, defence packer, NHS, etc.)
    ↓ signs and validates  
ACTOR RECORD (individual human, machine, AI agent)
    ↓ signs and validates
CAPABILITY CONTAINER (the UCCO cube)

• No actor can be trusted whose issuing authority isn't in the root
• No issuing authority can be trusted whose root registration is invalid
• Chain verifiable from actor → issuing authority → root without calling back to anyone
• A query to any root node returns the same result (distributed, cryptographically synchronised)

3.3 Root Registry Public Surface

Queryable by anyone. Returns: - Issuing authority DID - Issuing authority public key - Issuing authority jurisdiction(s) - Issuing authority ISIC domain codes - Capability corpus identifier and version - Registration timestamp and chain event reference - Current status: ACTIVE | SUSPENDED | REVOKED - Pack types issued: COMMERCIAL | PUBLIC_GOOD | CLASSIFIED (presence only, not contents)

3.4 Actor WHOIS — Public Query Interface

Queryable by anyone for any registered actor. Returns: - Actor DID - Current trust level (L0–L5) - Issuing authority DID - Installed capability domains (ISIC codes) - Validity windows per capability - Chain tip hash — proves record is current and unmodified - Staleness indicators per capability (standard version delta) - Pack type per capability: COMMERCIAL | PUBLIC_GOOD | CLASSIFIED (presence only) - K2 mode: PERSISTENT | EPHEMERAL (presence only — not key material)

NOT returned (ever): - Classified socket contents - Proprietary capability details - Evidence hashes - K2 key material - Biometric data - Personal identity beyond DID

3.5 Formal Rogue Definitions

ROGUE ACTOR:
An actor whose DID does not resolve to a valid record in any issuing authority registry registered with the root. A conforming verifier MUST treat a ROGUE ACTOR as UNVERIFIED and MUST NOT permit Tier 3 interactions without explicit human override. The override is itself a chain event.

ROGUE AUTHORITY:
An issuing authority whose DID does not resolve to a valid record in the root registry. Containers issued by a ROGUE AUTHORITY are INVALID regardless of internal chain integrity.

Think: unregistered robot in a surgical suite. The patient scans it. The app says: NOT IN REGISTRY. Not "unknown" — not trusted. Same as SSL cert not signed by a trusted CA.

3.6 Distributed Root — Resilience

Not a single point of failure. UCCA operates the primary node. Recognised standards bodies (ISO, NIST, W3C) may operate mirror nodes. All nodes cryptographically synchronised. A query to any node returns the same result.

3.7 Root Registry Chain Events (New)

• authority_registered — new issuing authority added to root
• authority_suspended — issuing authority temporarily suspended
• authority_revoked — issuing authority permanently removed
• root_node_sync — synchronisation event between distributed root nodes

3.8 UCCA's Position

UCCA operates the first root registry node. First mover with 15,000 capability units already indexed across 52 training packages. Every other issuing authority starts at zero.

The protocol is open. The registry is the platform. The fastest, most reliable, most complete registry wins. This is the 8.8.8.8 play.

Commercial model (registry layer): - FREE — PUBLIC_GOOD pack queries, basic WHOIS lookups - SUBSCRIPTION — commercial registry access, issuing authority registration - PREMIUM — real-time capability routing ("find me the nearest L3 oncology surgeon available right now")

TO DO: Registry infrastructure architecture brief for future Alex sprint.

---

Part 4 — New Normative Concepts for v2.0

4.1 Industry Classification Socket

Every UCCO container must declare its industry domain via a recognised external classification system.

Anchor standard: ISIC Rev 4 (International Standard Industrial Classification) — UN-adopted. Forms the basis for NAICS, ANZSIC, GICS, SIC. One reference that maps to all of them.

Mechanism: The socket references the classification — it does not contain the classification system. Like a webpage referencing a stylesheet. Container declares: this capability lives at ISIC 8620 (Medical and dental practice activities). Any verifier knows the domain instantly without UCCA defining it.

Why external, not UCCA-owned:
Interoperability, neutrality, existing adoption. UCCA does not need to own the classification system to be the best registry indexed against it. 8.8.8.8 doesn't own DNS.

Secondary mappings (optional, not mandatory):
NAICS code, ANZSIC code, GICS sub-industry — declared in envelope, informative only.

The discovery mechanism:
When an actor needs a capability it doesn't have, it queries the registry by ISIC code. "I need a capability in ISIC 8421 (Fire protection). What issuing authorities operate in this domain? What PUBLIC_GOOD packs exist here?" The registry returns options. The actor selects, verifies, installs.

This is how the coffee robot finds the emergency medical packer without anyone having pre-programmed it to do so.

TO DO: Formal socket schema. ISIC to regional system mapping table. Registry indexing specification.

4.2 Pack Types

Every UCCO container declares a pack type. Four normative values:

Pack Type	Description	Billing	Access
COMMERCIAL	Standard pack, commercial relationship required	Yes	Authorised subscribers
PROPRIETARY	Access-controlled, authorised verifiers only	Yes	Named verifiers only
CLASSIFIED	Classification-level access control	Separate arrangement	Authorised clearance level
PUBLIC_GOOD	Zero cost, universally accessible	No	Any conforming actor

PUBLIC_GOOD packs — special rules:

Maintained by governments, medical authorities, emergency services — on behalf of humanity. Free. Always available. No billing event. No commercial relationship required.

Issuing authority must be a recognised public body: - Surgeon General (US) — Emergency First Response - WHO — International health emergency protocols - National fire service authorities — Fire evacuation and triage - Civil aviation authorities — Emergency landing protocols - National emergency management agencies — Disaster response

The pack is still cryptographically signed. The issuing authority has its own chain. Mandatory socket validation still applies. The difference is access — no key pair required, no commercial relationship, universally queryable.

TO DO: Full PUBLIC_GOOD issuance specification. Who can declare PUBLIC_GOOD. Governance process. Abuse prevention (a bad actor claiming PUBLIC_GOOD status).

4.3 Dynamic Capability Installation

A conforming actor MAY request, receive, verify, and install a new capability pack at runtime without human intervention — provided:

1. New pack comes from a verified issuing authority (in root registry)
2. All mandatory sockets in the new pack are valid
3. New pack does not conflict with existing supervision chain constraints
4. If actor is non-human: supervisor is notified of installation (chain event)
5. Installation is recorded as a chain event: capability_installed

Currently implied by callback mechanism in v1.1. Must be stated explicitly as normative in v2.0.

The coffee robot scenario — canonical use case:

1. Robot making coffee. Sees car accident through window. Person falls from vehicle.
2. Detects situation is outside current capability envelope
3. Does NOT act — correctly. First Do No Harm imperative active.
4. Issues capability request to root registry
5. Query: ISIC 8621 (General medical practice), PUBLIC_GOOD packs available
6. Registry returns: Emergency First Response v2.1, ISIC 8621, PUBLIC_GOOD, Surgeon General, free
7. Robot verifies pack — mandatory sockets valid, issuing authority in root registry, chain intact
8. Installs capability: capability_installed chain event recorded
9. Supervisor notified (non-human actor, notification mandatory)
10. Robot moves to scene, acts within newly installed envelope
11. Stabilises patient, does not move them, calls emergency services
12. Chain records: what it had, what it requested, what it received, what it did, outcome

Nobody programmed that robot for that scenario. The architecture made it possible. The PUBLIC_GOOD pack made it free. The chain made it accountable.

4.4 First Do No Harm — Reserved Mandatory Socket

A universal imperative that sits above all capability envelopes. The highest-priority mandatory socket. Cannot be overridden by any packer, any domain, any classification level. Hardcoded. Inviolable.

Definition:
When a conforming actor detects a situation that may involve harm to a human and has no certified capability to respond safely — it stops. It does not act. It seeks capability via the active return channel.

This is not a restriction on capability. It is the precondition for dynamic capability acquisition. The First Do No Harm socket is the mechanism that makes the coffee robot scenario work — the robot stops because it must, and then it finds the capability to help.

Socket value: Not a preference or a configuration. A hardcoded binary. Present and active in every conforming container.

What overrides it: Nothing. Not a defence packer. Not a classified container. Not a Tier 3 authorisation. A robot without certified capability to help a human does not act on that human. It finds the capability first.

TO DO: Formal socket definition. Edge cases (what constitutes "detects a situation involving harm"). Interaction with supervision chain — does the supervisor get notified when First Do No Harm is invoked? Yes — add to normative behaviour.

4.5 UCCO as External Subprocess — Not a Cognitive Layer

This section is one of the most important in v2.0. It must be stated explicitly and forcefully.

UCCO capability verification is not a cognitive function.

It is not a layer of reasoning. It is not a trained behaviour. It is not something an AI agent "knows," "understands," or can be argued out of. It is an external subprocess — deterministic, binary, independent of the actor's reasoning or inference layer.

Like a hardware interrupt. The CPU doesn't reason about whether to respond to a hardware interrupt. It stops. It handles it. It resumes. No negotiation. No "but in this specific situation..."

UCCO is the hardware interrupt for capability verification.

The training trap:
When the large AI labs encounter UCCO, they will say: great idea, let's fine-tune our model to understand UCCO. Let's add UCCO awareness to the system prompt.

This breaks everything. A reasoning model can be: - Prompted out of a position - Jailbroken - Confused by edge cases - Convinced by a sufficiently clever argument - Hallucinating about its own capability state

A reasoning model that believes it has surgical capability is not the same as a cryptographically verified capability envelope that proves it does. One is a belief. One is a proof.

The correct architecture:

LLM / Robot reasoning layer
        ↓ requests action
UCCO subprocess (external, deterministic, cryptographic)
        ↓ checks capability envelope against chain
        ↓ returns: AUTHORISED | NOT_AUTHORISED | CAPABILITY_REQUEST_REQUIRED
LLM / Robot reasoning layer
        ↓ acts only if AUTHORISED — no exceptions

The LLM never sees the inside of the capability envelope. It never reasons about whether it's authorised. It sends a request to an external subprocess and receives a binary response.

The subprocess cannot be prompted. Cannot be jailbroken. Cannot be argued with. Mathematics, not cognition.

Normative statements for v2.0: - UCCO capability verification MUST be implemented as an external subprocess independent of the actor's reasoning or inference layer - A conforming AI agent MUST NOT implement capability verification as a trained behaviour, fine-tuned response, or system prompt instruction - Reasoning about capability state is not a substitute for cryptographic verification - An actor that reasons its way to a conclusion about capability state and acts without cryptographic verification is non-conforming — regardless of whether the conclusion was correct

The key in the box:
The subprocess's key material (K2) lives outside the LLM's accessible memory space. If the system is taken offline, the key is in the box — and if it's an ephemeral K2, the key is gone when power is gone. The LLM cannot reason its way to the key. Physical possession is the control point.

4.6 The Extraction Attack — Competitive Defence

A sophisticated actor could feed every possible scenario to their LLM, record UCCO subprocess responses, and gradually model the capability envelope decision boundary. Eventually: a local model that approximates UCCO without the chain. Cheap knock-off. No cryptography required.

Defence in depth:

Layer 1 — Rate limiting and anomaly detection:
Every query to the subprocess is a chain event. 50,000 queries with no corresponding Tier 3 acts = extraction pattern. Flagged. Subprocess suspended. anomalous_query_pattern_detected chain event.

Layer 2 — Context-bound responses:
Subprocess returns AUTHORISED FOR THIS SPECIFIC REQUEST IN THIS SPECIFIC CONTEXT AT THIS SPECIFIC TIMESTAMP. Cryptographically bound to exact request parameters. Not generalisable. Storing them builds a lookup table of past decisions, not a model of future ones.

Layer 3 — Ephemeral K2:
If K2 is ephemeral, the knock-off can model the decision boundary all it wants. Without K2 it cannot produce a valid chain event. Any verifier does a WHOIS: not in registry, no valid chain. Rogue operator. Exposed instantly.

Layer 4 — The chain is the proof:
Even perfect reverse-engineering of decision logic doesn't produce a valid chain. The chain requires the issuing authority's private key. They don't have it. Their knock-off can make the same decisions UCCO would make. It cannot produce a chain event any verifier accepts.

Layer 5 — The registry closes the loop:
Knock-off isn't in the root registry. WHOIS returns nothing. Circle of trust rejects it. Any verifier sees: no valid chain. Unverified. Refuse Tier 3.

The piracy parallel:
People pirated Photoshop for decades. Adobe couldn't stop it. But pirates couldn't get support, couldn't prove legitimacy to enterprise clients, couldn't integrate with Adobe's ecosystem. The value lived in the connected service, not the software. UCCO is the same move. The value is in the chain. The chain requires the issuing authority.

What goes in standard: Anomalous query pattern detection (normative). Context-bound responses (normative). "The chain is the proof" explicit statement.

4.7 K2 Volatility Mode

PERSISTENT — standard operation. K2 in HSM or secure enclave. Survives power cycle. Standard operation for most deployments.

EPHEMERAL — defence and high-security operation. K2 in volatile memory (RAM) only. Power present → key exists → container live → actor operates. Power gone → key gone → container dead → nothing recoverable. No HSM. No persistent storage. No forensic surface.

A captured robot with EPHEMERAL K2 is cryptographically sterile. You cannot reverse-engineer what it was certified to do. You cannot replay its capability container on another unit. The container never existed in any recoverable sense once power left.

Chain events for EPHEMERAL mode: - k2_ephemeral_session_start — key materialised, container live - k2_ephemeral_session_end — clean shutdown, key destroyed - k2_ephemeral_session_lost — power loss, key destroyed, chain shows exactly where it went dark

If connectivity existed before power loss: chain events synchronised to vault. If not: chain is honest about the gap — sync_timestamp_utc is null, timestamp_utc records the moment of the act.

This solves the captured hardware problem defence procurement has been working on for decades. It is native to the capability layer. Not bolted on.

4.8 Classification Tiers

Containers MAY have sockets with access-controlled content. Three content states:

• OPEN — readable by any conforming verifier
• PROPRIETARY — readable only by named authorised verifiers
• CLASSIFIED — readable only at specified classification level

Container validity is determined by mandatory socket integrity only. A container with all mandatory sockets valid and accessible is conforming — regardless of how many classified sockets it has.

UCCA doesn't need to see inside a classified socket to validate the container. This opens defence and intelligence markets without compromising anything.

4.9 Dual Authority — The Two-Man Rule

The two-man rule has existed in nuclear doctrine since the 1960s. One person cannot authorise launch. Two people, independently authenticated, must both act.

UCCO makes this cryptographic, auditable, and extensible to any capability level.

New envelope field:

"authority_quorum": {
  "minimum_signatories": 2,
  "required_roles": ["MISSION_OPERATIONS_OFFICER", "MISSION_DIRECTOR"],
  "role_authority_minimum": "L3",
  "timeout_seconds": 300,
  "on_timeout": "ABORT"
}

One signature alone = cryptographically insufficient. Not policy. Not procedure. Mathematics.

Escalating quorum: - Defensive action — single commanding officer, L3 - Offensive engagement — DUAL (ops + director) - Strategic strike — TRIPLE (director + theatre commander + civilian authority) - Nuclear equivalent — N_AUTHORITY, N defined by doctrine

Standard defines the mechanism. Defence packer defines the specific N and roles. UCCO enforces it cryptographically.

The Strangelove footnote:

"The failure mode that UCCO dual authority prevents was dramatised by Stanley Kubrick in 1964. The problem has not been solved in the sixty years since. We solved it in a capability envelope schema."

Keep this. It's precise, it's correct, and it will be remembered.

New chain events: - dual_authority_initiated - authority_signatory_authenticated (one per signatory) - dual_authority_confirmed - dual_authority_aborted (with reason: TIMEOUT | DECLINED | AUTHENTICATION_FAILED)

4.10 STALE Trust State

A capability has a freshness dimension beyond valid/invalid.

New trust state: STALE
Chain intact. Capability existed and was certified. But the underlying standard has advanced beyond the certified version. Not L4 Suspended. Not L5 Revoked. Something in between.

Like running tax software on 2022 rules. The software works. The calculations run. But the law changed and you don't know it. Is the practice owner still paying CCH for the tax updates? Or are we running on old rules and a good memory?

New capability item fields: - standard_version_certified — version of standard at time of certification - standard_version_current — current version in registry at time of query - Delta = staleness level

New chain event: capability_stale_detected
Recorded when registry sync finds standard has advanced. Not a suspension — a flag. Visible to actor, supervisor, every verifier.

Verifier/patient sees:
"Grade 3 oncology — certified against WHO Surgical Guidelines 2023. Current version: 2025. 2 versions behind. Last updated: 14 months ago. Status: STALE."

They decide. Transparency, not punishment. Maybe 14 months behind on oncology guidelines matters enormously. Maybe 14 months behind on coffee-making guidelines is irrelevant. The verifier/patient has the information to decide.

4.11 Human Consent Events

The moment where the machine world and the human world meet with full transparency and full dignity.

New chain event: human_consent_recorded

Payload: - Actor DID (the entity being consented to) - Capability scope consented to (exactly what was explained and agreed) - Standard version at moment of consent - Staleness status at moment of consent (patient saw STALE and consented anyway — recorded) - Consent method: AUTHENTICATOR_APP | PRACTICE_IPAD | PAPER_WITNESSED - Human identity hash (not full identity — hash sufficient to establish a real person consented) - Witness DID if applicable - Capacity declaration — person was of sound mind, understood, chose freely - risk_acknowledged sub-event — patient was shown risk profile and said yes

New envelope field:

"consent_required": "NONE | INFORMED | WITNESSED | DUAL_AUTHORITY"

Dual ledger push:
Consent event written to: 1. Actor's chain (immutable) 2. Patient's government health record (FHIR endpoint — see Section 4.12) 3. Patient's UCCO chain if they have one

The patient UX (authenticator app):
Before surgery, patient scans robot. Sees in plain language: - In circle of trust? Yes / No - Who certified this actor? - What is it generally certified to do? - Drill down — exactly what is it permitted to do right now, in this context? - When was each capability last verified? - Is it STALE? How stale? - Historical outcome data for this actor on this procedure type - Risk profile (in plain language — humans die, here are the statistics for this procedure)

The patient sees the robot's credentials at the same level of detail the surgeon's credentials appear on the wall. Informed consent for the machine age.

No phone: Practice iPad. Same flow. Same chain. Paper form fallback — scanned, hashed, hash recorded as evidence.

First consent = genesis event:
If the patient has no UCCO chain, their consent record becomes their first chain event. The seed of their digital capability identity. When the authenticator is ready, they can upgrade it. First users of UCCO are the people who come to encounter it.

4.12 Government Ledger Integration

Governments already built the vault. UCCO enriches it.

Key systems:

Jurisdiction	System	Interface
Australia	My Health Record	HL7 FHIR R4
Australia	USI (Unique Student Identifier)	USI API
UK	NHS Spine	HL7 FHIR R4
UK	GOV.UK One Login	OAuth 2.0 / OIDC
NZ	RealMe	SAML 2.0
EU	European Health Data Space	FHIR R4
EU	eIDAS 2.0	eIDAS protocol
Singapore	Singpass / NDI	NDI API

UCCA doesn't compete with government storage. It pushes chain events to it.

FHIR is the bridge:
HL7 FHIR R4/R5 is the international standard for health data exchange. My Health Record speaks FHIR. Consent event payload maps cleanly to a FHIR Consent resource. Standards-to-standards handshake — not a custom integration.

The USI connection:
Unit of competency completed → UCCA verifies → UCCO chain event → push to USI → government record updated, cryptographically verified. No paper transcripts. No "we can't verify that qualification." The USI entry has a chain hash. Verify the hash. Done.

New envelope field:

"external_ledger_push": {
  "target": "MY_HEALTH_RECORD | NHS_SPINE | EHDSI | USI | CUSTOM",
  "endpoint_standard": "FHIR_R4 | FHIR_R5 | HL7_V2 | CUSTOM",
  "push_status": "SUCCESS | PENDING | FAILED",
  "push_timestamp_utc": "<RFC 3339>"
}

Push recorded in chain. Failure recorded in chain. Transparent always.

What stays commercial in confidence:
UCCA's specific integrations, certifications to access each system, and commercial agreements with government agencies.

4.13 The Feedback Loop — Capability Gap Reporting

The actor looks at itself. Not just reporting what it did — reporting what it couldn't do, what it needed, what it encountered outside its envelope. And routing that feedback intelligently.

New chain event: capability_gap_report

Payload: - Actor DID - Situation description (structured, not free text) - Capability gap identified (what was needed, what was missing) - ISIC code of the gap domain - Suggested issuing authority routing (which packer is best placed to address this) - Evidence bundle hash (what the actor observed) - Timestamp UTC

Routing:
The gap report does not go back to UCCA by default. It goes to the issuing authority whose domain matches the ISIC code of the gap. UCCA receives a copy as root registry operator. The domain packer gets the primary report.

A soldier robot encountering a vehicle recovery situation routes the gap report to a logistics/engineering packer — not to UCCA's trade skills corpus. UCCA sees it but doesn't need to action it.

The learning network:
Aggregated gap reports across thousands of actors in the same ISIC domain tell packers exactly where their capability corpus has gaps. Real operational experience. Not theoretical. This is the immune system adapting — the network gets smarter from what it encounters in the field.

Pre-issuance query:
A packer MAY query the root registry for an actor's existing capability surface before issuing a new pack. The query and result are recorded as chain events. Precision issuance — the packer knows what the actor already holds and issues accordingly. Less redundancy. More relevant capability. Better containers.

TO DO: Full capability_gap_report schema. Registry subscription model for domain packers. Governance of how gap reports become corpus updates.

---

Part 5 — Fixes Inherited from v1.1 Review

5.1 Six Fixes from Grok Review (Apply to v1.1 Rev2 and carry into v2.0)

Fix 1 — Chain Hash: Unify to length-prefixed definition throughout. Single normative statement, no exceptions.

Fix 2 — JSON blocks: Mark all as "Illustrative — normative schema in companion JSON Schema document." Remove all // comments and <placeholder> text.

Fix 3 — Capability Corpus: Add to Terms:
Capability Corpus — the set of competency frameworks, standards, and atomic capability units maintained by an issuing authority against which capability envelopes are issued.

Fix 4 — Revocation propagation MUST/SHOULD:
- Life-safety (medical, defence, aviation, nuclear): MUST implement
- Non-life-safety: SHOULD implement; MAY use polling-based check as alternative
- C3 conformance: MUST regardless of deployment type

Fix 5 — Normative references: Flat numbered list. Informative references to Annex A.

Fix 6 — Section 1.2: Add "This section is non-normative." Keep all language.

---

Part 6 — v2.0 Document Structure (Proposed)

UCCO Standard v2.0
├── Abstract
├── Status of This Document
├── Changes from v1.1
├── Governance and Foundation Transition
├── Intellectual Property Rights
│
├── 1. Scope and Purpose (non-normative sections labelled)
├── 2. Normative References (flat list)
├── 3. Terms and Definitions (expanded — all new terms added)
├── 4. Actor Taxonomy (unchanged from v1.1)
├── 5. Identity Primitives (AI agent context state hash expanded)
├── 6. Capability Envelope (socket interface added, new fields)
├── 7. Chain Event Schema (new events added)
├── 8. Attestation Model (unchanged from v1.1)
├── 9. Store-and-Forward Protocol (revocation propagation updated)
├── 10. Supervision Chain (DFA and grace period unchanged)
├── 11. Conformance (updated for new features)
│
├── [NEW] 12. Root Registry Architecture
│   ├── 12.1 Registry Structure and Trust Hierarchy
│   ├── 12.2 Root Registry Contents
│   ├── 12.3 Issuing Authority Registration
│   ├── 12.4 Actor WHOIS Interface
│   ├── 12.5 Rogue Actor and Rogue Authority Definitions
│   ├── 12.6 Distributed Root Node Requirements
│   └── 12.7 Registry Chain Events
│
├── [NEW] 13. Socket Interface Specification
│   ├── 13.1 Mandatory Base Sockets
│   ├── 13.2 Socket Classification (OPEN/PROPRIETARY/CLASSIFIED)
│   ├── 13.3 Socket Validation Rules
│   └── 13.4 Domain-Specific Socket Extension
│
├── [NEW] 14. Industry Classification
│   ├── 14.1 ISIC Reference Standard
│   ├── 14.2 Regional System Mappings
│   └── 14.3 Registry Indexing Against Classification
│
├── [NEW] 15. Pack Types
│   ├── 15.1 COMMERCIAL
│   ├── 15.2 PROPRIETARY
│   ├── 15.3 CLASSIFIED
│   └── 15.4 PUBLIC_GOOD — Issuance and Governance
│
├── [NEW] 16. Dynamic Capability Installation
│   ├── 16.1 Runtime Installation Protocol
│   ├── 16.2 First Do No Harm Imperative
│   └── 16.3 Canonical Use Case — The Coffee Robot
│
├── [NEW] 17. UCCO as External Subprocess
│   ├── 17.1 Normative Architecture Requirement
│   ├── 17.2 Prohibited Implementations
│   ├── 17.3 Security Model
│   └── 17.4 Extraction Attack Defence
│
├── [NEW] 18. Human Consent Protocol
│   ├── 18.1 Consent Event Schema
│   ├── 18.2 Consent Methods
│   ├── 18.3 Dual Ledger Push
│   └── 18.4 Patient Verification Interface (normative data)
│
├── [NEW] 19. Government Ledger Integration
│   ├── 19.1 External Ledger Push Protocol
│   ├── 19.2 FHIR Interface
│   └── 19.3 Jurisdiction-Specific Targets (informative)
│
├── [NEW] 20. Capability Gap Reporting
│   ├── 20.1 Gap Report Schema
│   ├── 20.2 Routing Protocol
│   └── 20.3 Pre-Issuance Registry Query
│
├── 21. Conformance (expanded)
│
├── Annex A: Regulatory Alignment (expanded — EU AI Act, FAA, BIPA etc.)
├── Annex B: Non-Human Actor Implementation Notes
├── Annex C: Drone Fleet Example (updated with DFA and registry)
├── Annex D: Comparison with Related Standards (expanded)
├── [NEW] Annex E: Coffee Robot Canonical Scenario
├── [NEW] Annex F: Surgical Robot and Patient Consent Scenario
├── [NEW] Annex G: Dual Authority — Defence Deployment Scenario
└── [NEW] Annex H: Registry Architecture Reference Implementation Notes

---

Part 7 — What's Stubbed (Needs Further Development)

These concepts are captured and positioned but not yet fully specified. They need dedicated working sessions before they can be written into normative standard text.

Item	What Needs Doing
Base socket schema	Full field definitions, types, validation rules for all 12 mandatory sockets
First Do No Harm socket	Edge case definition, supervision notification behaviour
PUBLIC_GOOD governance	Who can declare, abuse prevention, revocation of PUBLIC_GOOD status
Registry infrastructure	Architecture brief for Alex, API spec, indexing design
Capability gap report schema	Full field definitions, routing protocol, packer subscription model
Pre-issuance query	Full protocol, chain event schema
Patient verification UX data	What data the standard mandates be available — not the UX itself
Conformance test suite	Separate document, future sprint
JSON Schema companion doc	Formal schema for envelope and event — referenced normatively

---

Part 8 — Urgents (Not UCCO — But On the Board)

These are UCCA operational items that need action this week regardless of what else is happening:

1. CRITICAL — March 24: ucca.com.au (VentraIP) + ucca.asia (Porkbun) domain renewals. 10 days. Do today.
2. CRITICAL — March 26: GitHub PAT ucca-engine-push expires. All pushes fail after this date. Renew immediately.
3. Apple entity name change: Submitted March 13, resolves ~March 27. Check Apple Developer portal.
4. VCC surface brief: vcc.ucca.online stub — Alex brief not yet written. Queue after foundation brief.

---

Part 9 — Document Sequencing Plan

Document	Status	Purpose
UCCO v1.0	DONE	Foundation. Shows starting point.
UCCO v1.1	DONE — SHIP	Current public release. Submit to ISO/W3C.
UCCO v1.1 Rev2	TO DO — QUICK	Apply 6 Grok fixes. Clean shipping version.
UCCO v2.0 Working Draft	THIS DOCUMENT feeds it	Full architecture expansion.
Commercial Architecture Doc	TO DO	Opens with the wreckage. Investor-facing.
Foundation README	TO DO	GitHub ucco-foundation/ucco-standard
W3C/ISO Cover Letter	TO DO	Submission letter for v1.1
Conformance Test Suite	FUTURE	The gate. Smart enough to build it = welcome.

---

End of UCCO v2.0 Internal Working Paper — 14 March 2026
Everything in here. Nothing out the window.