UCCO / UCCA — The Protocol Pivot Master Brief¶

Working document · March 2026 · For Tim + Jimmy Consolidated from recent revelations and next-step planning

This document captures the full "quantum shift" from building a proprietary platform moat to proposing an open protocol (UCCO) with a commercial reference implementation (UCCA). It is designed to be read end-to-end first, then split into smaller documents later (RFC-0001, Governance v0, Incorporation pack, Site IA, etc.).

Preamble for Jimmy (2–3 minute read)¶

UCCA's opportunity may be bigger than an education platform: AI and automation lack a universal way to verify and trust capability across humans, AI agents, and machines. Historically, when a coordination gap like this appears, a protocol layer emerges (TCP/IP, SSL, payments rails). The pivot is to publish an open capability certification object and verification semantics — UCCO — so anyone can implement it, while UCCA becomes the best reference implementation and trusted operator. Authority is not claimed; it emerges when third parties rely on verification. The near-term goal is to publish an RFC and a minimal verifier that attracts serious contributors and real adopters.

1. Overview¶

1.1 The core shift¶

Old framing: build a moat (platform-first), compete on features, lock in customers.

New framing: define the missing capability protocol (protocol-first), invite critique, enable others to implement, and become the default trust substrate for "permission to act."

1.2 One-sentence strategy¶

UCCO must become the default way systems describe, verify, and trust capability across humans, AI agents, and machines — like a TCP/IP layer for capability — while UCCA monetizes operation, reliability, compliance, and integrations.

2. Core Concepts¶

2.1 The missing layer: capability trust¶

The internet solved identity (who you are), secure communication (can we talk securely), and payments (can value move). AI introduces a new unsolved question: can this entity safely perform a task? Today there is no universal capability certification layer.

2.2 Platform vs protocol¶

Platforms compete. Protocols persist. A protocol wins when it is neutral, minimal, adoptable, and becomes a dependency for third parties.

2.3 Authority emerges from verification dependency¶

UCCO "wins" when others rely on verification. The control point is the external verification plane, not internal admin dashboards.

2.4 UCCO, UCCA, and the Foundation: three distinct identities¶

UCCO: The open protocol / object / standard (neutral, boring, adoptable).
UCCO Foundation: The stewardship body for RFC process, governance, trademarks, and neutrality.
UCCA: The reference implementation + commercial operator (hosted verification, enterprise tooling, SLA, integrations).

3. Naming and Domain Strategy¶

3.1 Why UCCO works¶

UCCO feels independent of UCCA — exactly what protocol names need. It is memorable, technical, and not startup-coded.

3.2 Domain approach¶

Primary stewardship home should feel institutional and global. Recommended: ucco.foundation as the foundation's anchor domain. Use short subdomains so nobody types long URLs.

Domain	Purpose
`ucco.foundation`	Foundation homepage + governance
`rfc.ucco.foundation`	RFC index and process
`spec.ucco.foundation`	Spec docs (UCCO v1, registries)
`verify.ucco.foundation`	Public verifier endpoint (later)
`ucca.online`	Commercial reference implementation (member / implementer)

4. Architecture Note (Control Plane vs Protocol)¶

Your control plane architecture reflects an authority system: layered visibility and permissions, world tenancy, and containment/economics. This remains valuable for UCCA (commercial ops) but is not the core of UCCO. UCCO should stay minimal and independent of multi-world SaaS mechanics.

5. Governance: the "soil" that attracts contributors¶

5.1 The culture you're recreating¶

Egalitarian entry + earned responsibility. Open doors; ownership is earned through sustained high-quality contributions. No "battle the master" dynamic; the spec and tests are the authority.

5.2 Governance v0 principles (minimal)¶

Open to all; responsibility is earned.
Neutral stewardship; no capture by any one vendor (including UCCA).
Compatibility is sacred; breaking changes are rare and explicit.
Decisions are written down (decision log), contestable, and timeboxed.
Security considerations are first-class, not an afterthought.

5.3 Role model (lightweight)¶

Contributors: anyone can propose and comment.

Reviewers: earned through consistent, helpful review.

Maintainers: earned through sustained contributions; can merge changes.

Steering group (tiny): protects process integrity; does not micromanage technical work.

6. UCCO Protocol: what it should be (and not be)¶

6.1 The "disappointingly small" rule¶

UCCO v1 must be small enough to be implementable in a weekend and boring enough to be trusted. Do not fold billing, multi-tenant worlds, UI, or domain overlays into the core spec.

6.2 Minimum viable UCCO (concept)¶

At v1, UCCO should express a single capability claim with verifiable provenance and lifecycle status.

Field	Description
`subject`	The entity (human / agent / machine) being certified
`capability`	What can be done (task or capability id)
`scope`	Constraints / environment / operating envelope
`standard`	The benchmark or definition (versioned)
`evidence`	References to proof artifacts
`assessment`	Method summary (how it was evaluated)
`issuer`	Who attests (authority)
`valid_from` / `expires_at`	Lifecycle window
`status` + `revocation_ref`	Active / revoked / expired
`signature`	Cryptographic verification (detached or embedded)

6.3 Relationship to existing credential envelopes¶

UCCO can ride inside existing credential containers (e.g., verifiable credential envelopes). UCCO focuses on the content schema + verification semantics for capability.

7. Day-Zero Execution Plan¶

7.1 Phase 0: decide and register¶

Lock naming: UCCO (protocol) / UCCO Foundation (steward) / UCCA (commercial).
Register the anchor domain: ucco.foundation (plus 1–3 backups).
Create GitHub org: UCCO-Foundation (or similar).
Create initial repos: ucco-spec, ucco-verify, ucco-site (or docs).

7.2 Phase 1: publish the RFC seed¶

Write RFC-0001 (UCCO v1): abstract, problem statement, goals/non-goals, schema, verification model, examples, security considerations.
Publish an issues-first workflow: invite critique and edge cases.
Add a minimal contributor guide (CONTRIBUTING.md) and a code of conduct.

7.3 Phase 2: reference implementation (tiny)¶

Build the equivalent of "ping" for UCCO.

CLI: ucco verify <file.json>
API: POST /verify (returns valid/invalid + reasons)
API: GET /status/<id> (active/expired/revoked)

7.4 Phase 3: public site¶

The site should be boring and useful.

What is UCCO (one page, neutral tone)
RFC index + how to participate
Spec docs + schema versions
Governance v0 + decision log
Security and disclosure policy
Reference implementations (including UCCA)

8. Incorporation: a practical starter pack¶

8.1 The day-zero requirement¶

You need a registrant and an entity capable of holding domains, trademarks, and governance responsibilities. Nonprofit compatibility is desired; IRS exemption can come later.

8.2 Minimal entity (conceptual)¶

Form a nonprofit-compatible corporation (e.g., a nonprofit/nonstock corporation depending on state) to serve as the UCCO Foundation shell. This creates credibility and a clean container for governance, while avoiding the overhead of immediate IRS exemption filings.

8.3 What to prepare (inputs)¶

Legal name: "UCCO Foundation, Inc." (or similar)
Mission sentence (neutral): "To steward an open specification for capability certification and verification."
Initial board: you + (optional) 1–2 trusted directors (can expand later)
Registered agent (service)
Banking plan (if taking funds): EIN + basic account
IP plan: spec published under permissive license; foundation holds trademark

8.4 What not to do on day zero¶

Do not overbuild bylaws and committees before contributors exist.
Do not rush full IRS exemption paperwork unless you need donations/grants immediately.
Do not tie the protocol to UCCA product mechanics.
Do not publish grand claims; publish a draft and invite critique.

9. Relationship Between UCCO Foundation and UCCA¶

9.1 Clean separation¶

Foundation: steward the spec, process, and neutrality.

UCCA: commercial operator, reference implementation, enterprise services.

Anyone may build alternative implementations; UCCA aims to be the best operator.

9.2 Your role¶

You are the named originator and founding steward. The protocol is stewarded in public, and must remain useful even if UCCA disappears. Your credibility comes from openness, clarity, and willingness to be wrong — classic RFC posture.

10. First 30 Days Checklist¶

Week 1: anchor

Register ucco.foundation (+ backups)
Create GitHub org + repos
Publish a short founder note (humble, technical, invite critique)

Week 2: RFC seed

Draft RFC-0001
Add governance v0 + decision log template
Open issues for critique (security, versioning, abuse cases)

Week 3: verifier

Ship minimal verifier (CLI + API)
Add 3 canonical examples and tests

Week 4: outreach (protocol-style)

Post draft RFC invitation to critique (HN/communities)
Invite implementers, not customers
Collect feedback; iterate publicly

Version History¶

Version	Date	Change	Author
1.0	2026-03-11	Converted from UCCO_UCCA_Protocol_Pivot_Master_Brief.docx	Claude Code