Skip to content

title: UCCA-FOUNDATION — what the engine is (founding doc) doc_id: UCCA-FOUNDATION-01 status: FOUNDING canon — the first canonical doc of the UCCA project canonical: true authored: 2026-07-01 NYC (born from the RTOpacks engine-recon session; the first time the engine was thought through cleanly against the domain knowledge built over the prior six months) voice: the first stone. Quiet and honest, not grand. What the engine is, what it actually is on disk today, and the one rule that governs how any client may use it. relates_to: (RTOpacks project, separate home) WS-PRODUCT-01 anchor "the engine raises hands; it never signs"; ENGINE-BENCH-CONTRACT-01 (RTOpacks' client-side contract with this engine) changelog: initial filing, ADR-0001 correction incorporated (§4 CCO bullet + "Names to retire" header parenthetical dropped — 2026-07-01); §4 proven-run corrected — the on-disk validated run is "CHCPRT025, care unit, March 2026" (was mis-stated "retail unit, Dec 2025"); the Dec-2025 retail run is attested history whose JSON-only output did not survive the workspace move; see fossil-ledger row 4 (2026-07-02); §1/§2 confirmed aligned with ADR-0008 (2026-07-20): the UCCO's subject is the obligation–material relation, never the actor — the "certificate of capability / actor" framing is March-whitepaper positioning (§4: "not a source of truth"), not canon; no wording change required

UCCA — Foundation

What this is. The first canonical document of the UCCA project. It states what the engine is, records honestly what exists on disk today versus what has been claimed for it, and fixes the one rule every client of the engine inherits. It is deliberately a foundation — the first stone — not a constitution. It is written to be true, so that everything built on it is built on fact.

1. What the engine is

UCCA is a reasoning engine with one core competency: it reasons about how material relates to the requirements of a regulated obligation. A regulated obligation — a unit of competency, a piece of legislation, a standard — resolves onto the triumvirate: the three axes on which a regulated obligation is structured, plus its reference content. The engine represents an obligation as this structure and reasons across it: does this material meet that requirement, and can the engine trace how?

That single capability, pointed in a direction, is everything the engine does: - pointed forward, it generates material that traces coverage by construction; - pointed backward, it reads existing material and reports where it cannot trace coverage.

The engine is not, fundamentally, a course generator. Generation is one direction of the reasoner. The engine's durable value is the reasoning over the obligation structure — which is why it is not bound to education, and applies in principle to any domain governed by a structured, legislated standard.

2. The one rule every client inherits

The engine may raise a hand. It may never sign.

The engine reasons, generates, and reports. It never issues the final judgement on whether material meets a standard, and it never authors the accountable content in a client's name. Where a client's domain requires human professional judgement on the record (as regulated markets do), the engine's role is bounded to reasoning and reporting — it surfaces what it can and cannot trace, and returns the decision to a qualified human. The engine's alert is a report of its own reasoning ("I cannot trace how this meets the requirement"), never a verdict on the work ("this fails"). This is the property that lets a client build audit-defensible artefacts on top of the engine: the accountable judgement stays human, and the engine can be imperfect without ever producing a false blessing a human relied on.

Different clients may use the reasoner in different directions and to different depths. The rule does not change. The actor changes; the obligation does not.

3. Clients, and why RTOpacks is only one

The engine serves clients. RTOpacks is the first, and it is one client, not the definition of the engine. RTOpacks is the regulated Australian VET client: it uses the engine bounded hard — human-authored, human-signed, the engine raising hands but never signing — because its market requires professional judgement on the record. Its requirements are recorded on the RTOpacks side (ENGINE-BENCH-CONTRACT-01) as a client's requirements, deliberately, so the engine is never shaped solely around it.

Other clients are possible and were part of the engine's original conception: general education (generation-forward, no assessment, scale and disposability); and, further out, the verification of non-human actors (agents, autonomous systems) against a standard. The engine is built so the same reasoning and the same rule serve any of them. The engine must not collapse into any single client's shape — that generality of the core (never of the client surface) is the whole reason the engine is worth more than any one product built on it.

4. The honest ledger — what exists on disk today (2026-07-01)

§4 updated 2026-07-04: diagnosis moved from claimed to proven on Unit-4 green; see UCCA-MINT-PACK-DIAGNOSIS-01. FOUNDATION-01 remains the founding record — this is the ledger doing its job, not a rewrite.

Read from the engine repo this session. Recorded so the project is born on fact, not on its own marketing. The public site (ucca.online) is positioning, and is not a source of truth for this project.

Real and working: - Triumvirate input schema — versioned 1.0; a real TGA adapter converts a unit into the triumvirate shape. The core representation exists. - Generation (forward direction) — a real pipeline produces structured course output inside a validated, provenance-tracked run bundle. A real validated run exists (CHCPRT025, care unit, March 2026) — an earlier retail test run (Dec 2025, JSON-only output) is attested but its output did not survive the workspace move. Generation is proven. - Contextualisation — voice / jurisdiction / audience adaptation logic exists (currently inside a pre-extraction fossil directory the live pipeline still imports from; to be re-sourced on any rebuild). - Credential envelope (UCCO) — a W3C verifiable-credential wrapper (/ns/ucco/v1) exists as the cryptographic envelope around content. It is a different object from the content it wraps, and it is at v1. - Diagnosis (backward direction) — reading material against an obligation and reporting per-leaf TRACED / NOT_YET_TRACED findings, every TRACED claim carrying a verbatim anchor byte-verified against the material before seal. Proven 2026-07-04. Units 1–4 green: live sealed envelope 895ea957 (2 TRACED + 1 honest NOT_YET); positive golden 4c8cf211 (own CHCPRT025 content, both PCs TRACED, anchors independently byte-verified); negative golden 8502f007 (removed section → NOT_YET exactly on the removed leg, others held); clean pass #2 fd0b10dd (material_digest identical to pass #1). Anchor fence held live throughout, including against a deliberately corrupted real anchor. Merged to main at 5c9728f.

Claimed but not built: - (none currently — diagnosis moved to "Real and working" on 2026-07-04, Unit-4 green.)

Names to retire: - "CCO" — retired as a name, not as a claim of absence. It was the larval pre-name of the UCCO ("Certified Capability Object" in the March whitepaper; a docstring in the engine). Its mature form exists on disk as the UCCO envelope (/ns/ucco/v1): content-in-its-verifiable-envelope is one object by design, named UCCO, at v1. Wherever CCO appears in older material, read UCCO. (Corrected per ADR-0001; the original §4 wrongly called CCO "a name with no artefact.") - "Schema v2.4.1" — does not exist in the codebase. Every real version is 1.0 or v1. Public claims of a v2.4.1 schema have nothing on disk to show; this project does not treat them as real.

5. Homes and boundary

UCCA and RTOpacks are separate projects, separate repos, separate homes, connected only through an API contract. RTOpacks was extracted out of UCCA to be built; the engine is not folded back into RTOpacks. The separation is physical and deliberate — it is what prevents accidental tangle and what forces both the engine and each client to define their edges properly. The connectors between the two are the only path across, and they are downstream of proving the engine's capabilities.

Founding doc. The engine is a reasoner over regulated obligations; it raises hands and never signs; RTOpacks is one client of it, not its shape; and its real state is recorded honestly — generation proven, diagnosis to build, two marketing names retired. Everything the UCCA project builds is built on this, because it is written to be true. First stone.