Skip to content

UCCA Engine: Domain Onboarding Specification

Version: 1.0 Draft Classification: Pre-Commercial Working Document

Purpose

This document and its three companion templates define the input specification for the UCCA Engine. Any regulated domain seeking to utilise the engine for deterministic compliance processing must express its regulatory framework in the structure defined here.

The engine does not interpret domain content. It does not assess the quality, accuracy, or adequacy of a domain's regulatory framework. It validates structural completeness and processability. If the input conforms to the specification, the engine can ingest and process it. If it does not, the engine will return a structural gap analysis identifying exactly what is missing or malformed.

The Three Primitives

Every regulated domain operates under a governance framework that answers three fundamental questions. The engine requires each answer expressed as a structured document conforming to the templates provided.

Primitive 1 — Outcome Specification "What does good look like in this domain?"

A set of measurable standards, each comprising an outcome statement and performance indicators. This document defines the quality benchmarks that regulated entities must meet. It is the "what" of compliance — the target state against which all outputs are verified.

Template: TEMPLATE_01_Outcome_Specification.md

Primitive 2 — Compliance Ruleset "What must operators do to maintain compliance?"

The administrative, procedural, record-keeping, and transparency requirements that govern operational conduct. This document defines the "how" of compliance — the rules that must be followed regardless of domain-specific quality outcomes.

Template: TEMPLATE_02_Compliance_Ruleset.md

Primitive 3 — Credential Map "Who is authorised to perform which functions?"

A deterministic decision tree that maps credentials to permissions. Input: an individual's qualifications. Output: what they are authorised to do, under what conditions, with what supervision requirements. This document defines the "who" of compliance.

Template: TEMPLATE_03_Credential_Map.md

Structural Requirements

The engine validates each submitted primitive against the following structural requirements. All three must pass validation before ingestion can proceed.

Cross-Referencing

Each primitive must explicitly reference the other two. The Outcome Specification must reference the Credential Map (who is qualified to deliver against these standards) and the Compliance Ruleset (what operational rules support these standards). The Compliance Ruleset must reference the Outcome Specification and the Credential Map. The Credential Map must reference the standards and rules it enables performance against.

Hierarchical Addressing

Every element must have a unique, hierarchical identifier that enables deterministic referencing. Standards must be numbered. Sub-sections must be numbered relative to their parent. No element may exist without an addressable identifier.

Measurability

Outcome statements must be accompanied by performance indicators that define observable, assessable evidence of compliance. Indicators that cannot be assessed against evidence are structurally invalid.

Determinism

The Credential Map must resolve deterministically. Given a set of input credentials, the output permissions must be unambiguous. If the map contains conditional logic, all conditions must resolve to binary outcomes.

Submission and Validation

Process

  1. Domain owner completes all three templates using their regulatory framework.
  2. Templates are submitted to the engine for structural validation.
  3. The engine returns one of two outcomes per template:
  4. Structurally Valid — the template conforms to the input specification and is ready for ingestion.
  5. Structurally Incomplete — the template does not conform. A gap analysis is returned identifying every structural deficiency, its location, and the requirement it fails to meet.
  6. Domain owner remediates identified gaps and resubmits.
  7. When all three templates pass structural validation, the domain is cleared for ingestion.

What the Engine Validates

  • Structural completeness (all required sections present)
  • Hierarchical addressing (all elements uniquely identifiable)
  • Cross-referencing integrity (all references between primitives resolve)
  • Deterministic resolution (credential map produces unambiguous outputs)
  • Measurability (outcome standards have assessable indicators)

What the Engine Does Not Validate

  • Domain accuracy (whether the content is correct for the domain)
  • Regulatory adequacy (whether the framework meets the domain's actual legal requirements)
  • Content quality (whether the standards, rules, or credential requirements are well-written or appropriate)

The quality and accuracy of domain content is the sole responsibility of the domain owner. The engine processes what it receives, deterministically, with full traceability. The provenance chain records exactly what was submitted, by whom, and when.

Reference Implementation

The engine's reference implementation was validated against the Australian Vocational Education and Training (VET) regulatory framework, comprising three interconnected legislative instruments effective 1 July 2025:

  • Outcome Specification: National Vocational Education and Training Regulator (Outcome Standards for NVR Registered Training Organisations) Instrument 2025 — 18 standards across 4 Quality Areas
  • Compliance Ruleset: National Vocational Education and Training Regulator (Compliance Standards for NVR Registered Training Organisations and Fit and Proper Person Requirements) Instrument 2025
  • Credential Map: Credential Policy — Standards for Registered Training Organisations

This reference implementation is available for review as a worked example of what completed templates look like for a complex, government-audited regulatory domain.

Notes

  • Templates may be completed using existing regulatory documentation, legislation, or domain standards as source material. The domain owner is responsible for accurate translation of their framework into the template structure.
  • Where a domain's regulatory framework does not naturally decompose into three distinct documents, the domain owner should consult the structural requirements above and determine how their framework maps to the three primitives. Most regulated domains, upon analysis, will find the three-primitive pattern already exists in their governance structure — it may simply not be articulated as three separate documents.
  • The engine is content-agnostic. It processes any domain whose regulatory framework passes structural validation. The domain content, its interpretation, and its fitness for purpose remain the domain owner's responsibility at all times.

Version History

Version Date Change Author
1.0 2026-03-11 Converted from UCCA_Domain_Onboarding_Specification.md Claude Code