← All Specifications

UCA

The constitutional boundary — where the sovereign interior meets the external world. Every interaction across this boundary is mediated, declared, and enforced.

L3 — Constitutional Adapters 8 Invariants 536 Lines ❄️ Frozen

UCA Formal Specification v0.1.0

The universal adapter that maps constitutional interfaces to external systems — the constitutional boundary between the sovereign interior and the external world.

Preamble

This document is the formal specification of the Universal Constitutional Adapter (UCA) — Layer 6.1 of the ICore ecosystem. UCA is the last constitutional layer: everything beyond UCA is external, never part of the constitution itself.

UCA does not implement anything constitutionally new. UCA is the boundary condition that makes sovereignty possible in a world of external systems. Without UCA, the constitution is isolated. With UCA, the constitution is sovereign everywhere.

Classification: Constitutional — defines the adaptation boundary for all of ICore. Derivation:
USR/CoreFab → UCA (adapter boundary)
Depends on: USR/CoreFab (adapters bridge the runtime, not raw abstractions). Depended on by: UCD (derivatives compose from UCA capabilities), all external integrations.

Section 1: Foundational Axioms

1.1 The Four Adapter Axioms

#AxiomStatementDerived From
AA1The constitution never depends on an adapter.The direction of dependency is absolute and non-negotiable: adapters depend on the constitution; the constitution never depends on an adapter. Remove any adapter and the constitution remains complete.Constraint (USCP)
AA2Adapters are replaceable.Any adapter may be replaced by any other adapter that fulfills the same constitutional purpose, without any constitutional change. The constitution is adapter-agnostic.Transformation (USCP)
AA3The boundary is absolute.UCA is the last constitutional layer. Everything beyond UCA is external. No external system has constitutional standing. No external system may alter the constitutional stack.Existence (USCP)
AA4Adapters are constitutional only when bridging.An adapter exists only to bridge a specific constitutional capability to a specific external system. An adapter that does not bridge — that exists for its own sake — is not a constitutional adapter.Identity (USCP)

1.2 Axiom Sufficiency

PrimitivePresent InRole
ExistenceAA3 (boundary)External systems exist beyond the constitutional boundary
IdentityAA4 (bridging purpose)Adapters are identified by what they bridge, not by what they are
RelationshipAA1 (dependency direction)The only permitted relationship is adapter → constitution, never the reverse
ConstraintAA1 (never depended upon)Adapters are constrained from becoming constitutional dependencies
TransformationAA2 (replaceability)Adapters may change freely; the constitution does not
VerificationAA3 (boundary enforcement)The boundary is verified by checking that no constitutional component references an external system
The four axioms cover all six primitives. The foundation is complete.

Section 2: The Boundary Model

2.1 The Constitutional Boundary

┌═══════════════════════════════════════════════════════════════┐
║  CONSTITUTIONAL INTERIOR                                     ║
║                                                               ║
║  USCP → USC → Sciences → Reference → Execution               ║
║                                    (USR/CoreFab)             ║
║                                          ↓                   ║
║  ┌──────────────────────────────────────────────────────┐    ║
║  │  UCA — THE BOUNDARY                                   │    ║
║  │  ┌────────────┐ ┌────────────┐ ┌────────────┐       │    ║
║  │  │   Naming   │ │ Serialization│ │  Execution │  ... │    ║
║  │  │  Adapter   │ │   Adapter   │ │  Adapter   │       │    ║
║  │  └─────┬──────┘ └─────┬──────┘ └─────┬──────┘       │    ║
║  └────────┼───────────────┼───────────────┼──────────────┘    ║
║           ↓               ↓               ↓                    ║
║     ┌──────────┐   ┌──────────┐   ┌──────────┐              ║
║     │   DNS    │   │  JSON-LD │   │  WASM    │              ║
║     │  ENS     │   │  CBOR-LD │   │  Rust    │              ║
║     │ Handshake│   │  RDF     │   │  Deno    │              ║
║     └──────────┘   └──────────┘   └──────────┘              ║
║                                                               ║
║  EXTERNAL WORLD — no constitutional standing                 ║
╚═══════════════════════════════════════════════════════════════╝

2.2 Boundary Properties

#PropertyStatement
BP1UnidirectionalInformation flows from the constitutional interior through UCA to external systems, and from external systems through UCA to the interior. But authority flows only inward — external systems never authorize constitutional action.
BP2CompleteEvery interaction between the constitutional stack and the external world must pass through UCA. There are no constitutional backdoors.
BP3TransparentThe boundary is visible and auditable. Every adapter is declared, named, and versioned. Nothing crosses the boundary untracked.
BP4ThinUCA adds no constitutional theory. It adds no primitives, no rules, no axioms. UCA is the thinnest possible layer — a membrane, not a wall.

2.3 What Crosses the Boundary

DirectionWhat CrossesWhat Doesn't
Interior → ExteriorSerialized constitutional data, resolution requests, execution requestsConstitutional meaning, derivation chains, verification results
Exterior → InteriorRaw data, resolved names, execution resultsAuthority, constitutional standing, governance power
The constitution uses external systems. It never trusts them.

Section 3: The Adapter Contract Model

3.1 Adapter Definition

TermDefinition
AdapterA constitutionally declared, interface-bounded bridge between a specific constitutional capability and a specific external system or protocol.
Adapter DomainThe category of constitutional capability the adapter bridges (naming, serialization, execution, storage, communication).
Adapter ProfileThe external system or protocol the adapter bridges to (DNS, JSON-LD, WASM, Syncthing, etc.).
Constitutional FootprintThe minimum surface area through which the adapter contacts the constitution. Adapters should have the smallest footprint that fulfills their bridge purpose.

3.2 Adapter Structure

Every adapter must declare:

FieldRequirementPurpose
NameHuman-readable adapter nameUnique identification
DomainOne of the adapter domains (see Section 4)Categorization
ProfileThe external system/protocol bridgedWhat this adapter connects to
VersionSemVerVersion tracking
Constitutional LayerAlways "execution" (ordinal 5)Layer position
DependenciesUSR/CoreFab (always) + any adapter-layer peerDerivation chain
FootprintThe specific constitutional interface consumedMinimal contact surface
ReplaceabilityHow to swap this adapter for anotherProves AA2

3.3 Adapter Invariants

#InvariantStatement
AI1One-directional dependencyThe adapter depends on the constitutional stack. The stack never depends on the adapter.
AI2Interface-boundedThe adapter contacts the constitution only through declared interfaces (WIT contracts or equivalent). No direct internal access.
AI3ReplaceableAny adapter can be removed and replaced by another adapter fulfilling the same domain purpose. The constitutional stack must not notice the difference.
AI4Non-authoritativeAn adapter never generates constitutional meaning. It only translates between constitutional meaning and external formats.
AI5Explicitly declaredEvery adapter must be registered and declared. Unknown adapters are constitutionally invisible and therefore inaccessible.
AI6VersionedAdapters carry a version. The constitutional stack may depend on a version range, not a specific adapter instance.

Section 4: Adapter Domains

4.1 The Five Domains

#DomainWhat It BridgesConstitutional Purpose
AD1NamingConstitutional identity → external namesResolve "who is this" in external systems
AD2SerializationConstitutional meaning → external formatsTransmit constitutional data in external formats
AD3ExecutionConstitutional operations → external runtimesExecute constitutional code on external platforms
AD4StorageConstitutional state → external storagePersist constitutional data on external systems
AD5CommunicationConstitutional messages → external channelsDeliver constitutional messages through external infrastructure

4.2 Domain Sufficiency

Every interaction between a constitutional system and the external world falls into exactly one of these five categories:

No sixth domain is needed. Any new adapter category would be a specialization of one of these five.

Section 5: Reference Adapter Specifications

5.1 Naming Adapters

AdapterProfileConstitutional RoleReplaceable
DNS AdapterDomain Name SystemUniversal naming. Maps constitutional identity to domain names.Yes
ENS AdapterEthereum Name ServiceDecentralized naming. Maps constitutional identity to Ethereum addresses.Yes
Handshake AdapterHandshake ProtocolCensorship-resistant naming. Maps constitutional identity to HNS names.Yes
Future NamingAny naming protocolBy definition replaceable.Yes

Naming Adapter Contract

OperationInputOutputDescription
resolveConstitutional entity IDExternal name(s)Map constitutional identity to external names
registerConstitutional entity ID + external nameConfirmationRegister an external name for a constitutional entity
verifyExternal nameConstitutional entity ID (or null)Resolve an external name back to a constitutional entity

Naming Invariants

#InvariantStatement
NI1Constitutional identity precedes all namingThe constitutional entity ID is the source of truth. External names are aliases, never authorities.
NI2Multi-bindingOne constitutional entity may have many external names. Many external names may not claim to be one constitutional entity.
NI3RevocabilityExternal names may be released. The constitutional entity persists.

5.2 Serialization Adapters

AdapterProfileConstitutional RoleReplaceable
JSON-LD AdapterJSON-LD 1.1 (W3C)Primary serialization. Human-readable, web-native.Yes
CBOR-LD AdapterCBOR-LDCompact binary serialization. Android-first, bandwidth-constrained.Yes
Future SerializationAny semantic formatBy definition replaceable.Yes

Serialization Adapter Contract

OperationInputOutputDescription
serializeConstitutional data (UCL canonical form)External format bytesConvert constitutional meaning to external representation
deserializeExternal format bytesConstitutional dataConvert external representation back to constitutional meaning
verify_roundtripOriginal databoolVerify that serialize → deserialize preserves meaning exactly

Serialization Invariants

#InvariantStatement
SI1Meaning preservationdeserialize(serialize(data)) ≡ data. Round-trip fidelity is absolute. If a serialization format cannot guarantee this, it is not a constitutional serialization adapter.
SI2Format independenceThe same constitutional data produces equivalent representations regardless of which serialization adapter is used. Formats differ in syntax, never in meaning.
SI3Lossless mappingNo constitutional field is dropped during serialization. All fields survive the round-trip.

5.3 Execution Adapters

AdapterProfileConstitutional RoleReplaceable
WASM AdapterWebAssemblyPortable, sandboxed execution. Primary compilation target.Yes
Rust AdapterRust runtimeSystems-level execution. CoreFab internals.Yes
Deno AdapterDeno runtimeJavaScript/TypeScript execution. Primary application layer.Yes
Local AI AdapterOllamaOn-device inference. Sovereign AI execution.Yes

Execution Adapter Contract

OperationInputOutputDescription
executeConstitutional operation + inputExecution resultExecute a constitutional operation on the external runtime
sandbox_checkComponent IDboolVerify the component is sandboxed and cannot escape
resource_reportExecution IDResource consumptionReport CPU, memory, and time consumed

Execution Invariants

#InvariantStatement
EI1SandboxedAll execution adapters must run constitutional code in a sandbox. No execution adapter may grant unrestricted access to the host system.
EI2DeterministicThe execution adapter must preserve CoreFab's determinism guarantee. Same input → same output, regardless of the external runtime.
EI3Provenance-preservingAttestation records generated by CoreFab must survive execution through the adapter. The adapter must not strip, modify, or forge attestation data.
EI4Bounded resourceExecution adapters must report resource consumption. Constitutionally bounded execution prevents denial-of-service.

5.4 Storage Adapters

AdapterProfileConstitutional RoleReplaceable
Syncthing AdapterSyncthingPeer-to-peer storage. Sovereign, decentralized, offline-capable.Yes
IPFS AdapterIPFSDistributed content-addressed storage.Yes
Local Storage AdapterFilesystem / IndexedDBOn-device storage. Android-first.Yes
Future StorageAny storage systemBy definition replaceable.Yes

Storage Adapter Contract

OperationInputOutputDescription
storeConstitutional data + keyStorage referencePersist constitutional data externally
retrieveStorage referenceConstitutional dataRetrieve previously stored data
verify_integrityStorage referenceboolVerify stored data has not been corrupted or tampered with

Storage Invariants

#InvariantStatement
STI1Integrity-verifiableStored data must be verifiable against attestation hashes. Tamper detection is mandatory.
STI2Locally resilientThe constitutional stack must function when external storage is unavailable. Storage adapters are a convenience, not a dependency.
STI3Sovereign dataConstitutional data stored externally must be encrypted or access-controlled. External storage systems may hold data; they may not read it without constitutional authorization.

5.5 Communication Adapters

AdapterProfileConstitutional RoleReplaceable
HTTP AdapterHTTP/HTTPSWeb communication. REST/GraphQL.Yes
WebSocket AdapterWebSocketPersistent bidirectional communication.Yes
Future CommunicationAny protocolBy definition replaceable.Yes

Communication Adapter Contract

OperationInputOutputDescription
sendConstitutional message + destinationDelivery confirmationDeliver a constitutional message externally
receiveListener IDConstitutional messageReceive an external message into the constitutional stack
verify_sourceExternal message sourceAuthenticityVerify the source of an incoming message is constitutionally recognized

Communication Invariants

#InvariantStatement
CI1Source verificationIncoming messages must be verified against a recognized source. Unknown sources are treated as untrusted.
CI2No constitutional authority outwardCommunication adapters deliver constitutional data; they never authorize external systems to act.
CI3Sovereignty-preservingThe constitution may communicate through external channels but must not become dependent on any single channel.

Section 6: The Extension Protocol

6.1 How New Adapters Are Added

Adding a new adapter is an Extension amendment — the fast-track pipeline in Part IV:

StepActionGovernance
1Propose: Declare the adapter domain, external profile, and constitutional footprint.Proposal
2Verify: Confirm the adapter does not create a constitutional dependency (AA1), is interface-bounded (AI2), and is replaceable (AA3).Verification (no review gate — Extension)
3Publish: Register the adapter in the constitutional record.Publication
No ratification required. No kernel change. The constitution does not know the adapter exists — only the adapter knows the constitution exists.

6.2 How Adapters Are Removed

Removing an adapter is a Removal amendment:

StepActionGovernance
1Propose: Declare the adapter to be removed and the reason.Proposal
2Verify: Confirm no constitutional component directly depends on the adapter.Verification
3Remove: Remove the adapter from the constitutional record.Removal
If any constitutional component directly depends on the adapter, the removal is blocked. This is the only safety check — and it exists to protect AA1.

6.3 Adapter Upgrade Path

Adapters evolve freely as long as they maintain their contract:

Change TypeRequires GovernanceExample
Profile change (new external system)ExtensionAdding a new naming system
Contract enhancement (new operations)ExtensionAdding encrypt to a storage adapter
Bug fix (internal correction)NoneFixing a serialization edge case
Contract breaking changeRemoval + ExtensionChanging the resolve operation signature

Section 7: The Sovereignty Guarantee

7.1 Formal Sovereignty

The sovereignty guarantee is the constitutional promise that UCA enforces:

For all operations O, all external systems E, and all constitutional components C:
C may use E through UCA. E may never alter C.
C may remove E through UCA at any time. E may never prevent C from doing so.
C may be fully verified without E. E may never be required for C's verification.

7.2 Sovereignty Tests

#TestPass Criterion
SV1IndependenceThe constitutional stack can be fully loaded, verified, and operated without any adapter registered.
SV2RevocabilityAny adapter can be removed at runtime. The runtime continues to function after removal.
SV3Non-influenceNo adapter may modify constitutional data, derivation chains, or verification results.
SV4AuditabilityEvery adapter is declared and its operations are traceable. No hidden adapters.
SV5Offline operabilityThe constitutional stack is fully functional with zero adapters active (offline-first).

7.3 The D4 Rule Formalized

D4 ("Adaptation is the boundary") is the constitutional rule that UCA operationalizes:

∀ layer L ∈ {USCP, USC, UCE, UCC, UCM, UCL, UCRS, UCModels, URS, UVS, USR}:
    L depends only on other layers in the set above.
    L never depends on any adapter or external system.

∀ adapter A ∈ UCA: A depends on some layer L ∈ {USR}. No layer L depends on A.

D4 is not a policy — it is a structural property of the derivation graph. Violating D4 would create a cycle or an upward dependency, both of which are already forbidden by D1 and D2.


Section 8: Conformance Criteria

8.1 UCA Conformance Tests

An implementation conforms to the UCA Formal Specification if and only if:

#TestPass CriterionSeverity
UCA-01Boundary DeclarationAll adapters are registered with name, domain, profile, version, layer, dependencies, footprint, and replaceability. No unregistered adapters.Critical
UCA-02Dependency DirectionNo constitutional component (Layers 0-5) has a compile-time or runtime dependency on any adapter. Verified by dependency graph analysis.Critical
UCA-03Interface-BoundedEvery adapter contacts the constitutional stack only through declared interfaces (WIT contracts or equivalent API). No direct internal access.Critical
UCA-04ReplaceabilityAny adapter can be removed and replaced by another adapter of the same domain. The constitutional stack operates identically before and after replacement.Critical
UCA-05Meaning PreservationSerialization adapters pass verify_roundtrip: deserialize(serialize(data)) ≡ data for all constitutional data.Critical
UCA-06Offline OperabilityThe constitutional stack loads, verifies, and operates with zero adapters registered. No adapter is a load-time dependency.Critical
UCA-07Sandbox EnforcementExecution adapters run constitutional code in a sandbox. No execution adapter grants unrestricted host access.Major
UCA-08Tamper DetectionStorage adapters verify data integrity against attestation hashes. Corrupted data is rejected, not silently returned.Major
UCA-09Source VerificationCommunication adapters verify the source of incoming messages. Unknown sources are flagged as untrusted.Major
UCA-10AuditabilityEvery adapter operation is logged with adapter name, version, timestamp, and result. Operations are traceable.Major
UCA-11No Constitutional Authority OutwardAdapters deliver constitutional data but never authorize external systems to act. No adapter can grant external systems governance power.Critical
UCA-12Version TrackingAdapters carry semver versions. The constitutional stack can determine which version of an adapter is active.Minor

8.2 Conformance Levels

LevelNameRequirementsCertification
A0Non-ConformantFails any Critical test.None. May not claim UCA conformance.
A1Core ConformantPasses all Critical tests (A01-A06, A11) + ≤2 Major failures.May operate as a constitutional adapter boundary.
A2Fully ConformantPasses all 12 tests (12/12).May enter the canonical reference.

Section 9: Relationship to the Existing Stack

9.1 How UCA Connects to Part V (Standards Alignment)

Part V of the Kernel defines the advisory alignment between constitutional concepts and W3C external standards. UCA formalizes this relationship:

Part V AlignmentUCA FormalizationRelationship
JSON-LD → UCLSerialization AD2: JSON-LD AdapterPart V is advisory; UCA makes the adapter contract normative
CBOR-LD → UCLSerialization AD2: CBOR-LD AdapterSame
DNS → IdentityNaming AD1: DNS AdapterSame
ENS → IdentityNaming AD1: ENS AdapterSame
Handshake → IdentityNaming AD1: Handshake AdapterSame
WASM → ExecutionExecution AD3: WASM AdapterSame
RDF → UCLAdvisory alignment (not yet an adapter)Part V notes the mapping; an adapter can be created through Extension
PROV-DM → AttestationAdvisory alignment (not yet an adapter)Same
VC Data Model → AttestationAdvisory alignment (not yet an adapter)Same
DID Core → IdentityNaming AD1: potential DID adapterSame

9.2 How UCA Connects to USR/CoreFab

USR/CoreFab executes constitutional operations. UCA is what allows those operations to interact with the world:

USR/CoreFab                    UCA                     External World
─────────────                  ─────                   ──────────────
┌───────────┐                  ┌─────────┐             ┌──────────┐
│ Execute   │ ──serialize──→  │ JSON-LD │ ──HTTP──→   │ Web API  │
│ Attest    │ ──identity──→   │ DNS     │ ──resolve→  │ DNS      │
│ Store     │ ──persist──→    │ Syncth. │ ──sync──→   │ Peers    │
│ Verify    │ ──hash──→       │ IPFS    │ ──pin──→    │ Network  │
└───────────┘                  └─────────┘             └──────────┘

USR/CoreFab never knows which specific adapter is in use. It knows only the constitutional contract (serialize, resolve, persist). UCA maps those contracts to concrete adapters at runtime.

9.3 How UCA Connects to UCD

UCD (Universal Constitutional Derivatives) composes building blocks from UCA capabilities:

UCA → specific adapter capabilities → UCD → composed derivatives

UCD does not re-derive from the kernel (D5). It composes from what UCA makes available. If UCA provides a naming adapter, UCD can compose an identity verification derivative. If UCA provides a storage adapter, UCD can compose a persistence derivative.


Section 10: Self-Verification

10.1 Against the 10 Constitutional Tests

UCA Formal Specification v0.1.0 verified against the Kernel's 10 constitutional tests:

#TestResultEvidence
1Reality✅ PASSThe specification addresses a real need: the constitution must interact with the external world without being contaminated by it. Every adapter domain maps to a real-world integration point.
2Origin✅ PASSDerived from USR/CoreFab (Layer 6.0). All four axioms trace to USCP primitives. D4 (Part II) is the constitutional basis for the boundary model. Part V (Standards Alignment) is the advisory foundation that UCA formalizes.
3Necessity✅ PASSWithout UCA, the constitution is either isolated (cannot interact with the world) or coupled (must depend on specific external systems). UCA resolves this paradox: maximum interaction through minimum, replaceable coupling.
4Derivation✅ PASSFollows D1 (derived from USR/CoreFab, the layer below). Follows D4 (UCA is the adaptation boundary). No upward mutations.
5Consistency✅ PASSNo axiom contradicts another. The five adapter domains are orthogonal and complete. The sovereignty tests are consistent with the axioms.
6Verification✅ PASSEvery adapter invariant is independently checkable. The 12 conformance tests provide a concrete verification protocol. D4 is a structural property, not a policy — it can be verified by graph analysis.
7Simplicity✅ PASSFour axioms, five adapter domains, twelve conformance tests. No adapter domain can be removed without creating an integration gap. No adapter domain can be added without overlapping an existing one.
8Sovereignty✅ PASSUCA is the sovereignty guarantee itself. The five sovereignty tests (SV1-SV5) prove that no adapter can compromise constitutional independence.
9Replaceability✅ PASSReplaceability is the core property of UCA (AA2, AI3). The specification is defined in terms of what adapters do, not what they are. Any implementation satisfying the contract is conforming.
10Evolution✅ PASSAdapters can be added (Extension), removed (Removal), upgraded (maintain contract), or replaced (AA2) without constitutional change. The constitutional stack evolves freely while the boundary remains stable.
Result: 10/10 PASS. UCA Formal Specification v0.1.0 is constitutionally sound and enters the constitutional record.

Section 11: Implementation Status

11.1 What Exists Today

ComponentStatusLocation
Part V Standards Alignment✅ Complete (advisory)Part-V-Standards-Alignment.md
UCA Atlas Entry✅ Complete (descriptive)Constitutional-Atlas/Atlas-04-Expression-Execution.md
UCA Self-Verification✅ Complete (6/6 questions)CONSTITUTIONAL-SELF-VERIFICATION.md
Studyo PWA (JSON-LD in-browser)✅ DeployedStudyo-PWA/
USR/CoreFab (WASM contracts defined)✅ FormalizedUSR-CoreFab/

11.2 What This Specification Adds

AdditionDescription
Normative axiomsFour adapter axioms (AA1-AA4) — constitutional law, not advisory notes
Formal boundary modelThe structural D4 rule expressed as a mathematical property (Section 7.3)
Five adapter domainsNaming, Serialization, Execution, Storage, Communication — complete and orthogonal
Adapter contracts15 operation specifications across 5 domains with inputs, outputs, and invariants
Extension/Removal protocolStep-by-step governance for adapter lifecycle (Section 6)
Sovereignty guaranteeFormal proof that the constitution cannot be compromised by adapters (Section 7)
12 conformance testsUCA-01 through UCA-12 with severity levels and A0/A1/A2 certification

11.3 What Remains

ItemDependencyPriority
WIT interface for UCA adapter contractsWIT for CoreFab v0.1.0High
Rust trait definitions for adapter domainsWIT interfaceHigh
Reference implementation: JSON-LD adapterRust traitsMedium
Reference implementation: DNS adapterRust traitsMedium
Reference implementation: Local Storage adapterRust traitsMedium
UCA extension CLI (hermes uca add/remove/list)Reference implementationsMedium

Appendix: Adapter Catalog Summary

DomainAdapters DefinedAdapter Domain
NamingDNS, ENS, Handshake, FutureAD1
SerializationJSON-LD, CBOR-LD, FutureAD2
ExecutionWASM, Rust, Deno, Local AI (Ollama)AD3
StorageSyncthing, IPFS, Local Storage, FutureAD4
CommunicationHTTP, WebSocket, FutureAD5
Total13 named adapters + extensibility for future

Originator Attribution

This UCA Formal Specification v0.1.0 is originated, created, and concept-pioneered by:

Originator: Sir Collins — Creator and Concept Pioneer of ICore (access1@tutamail.com) Date of origination: July 16, 2026 Scope: All axioms, boundary models, adapter contracts, domain definitions, sovereignty guarantees, extension protocols, conformance criteria, and verification protocols presented in this specification.

This attribution is a constitutional artifact. It establishes provenance — the lowest and most fundamental layer of trust.


UCA is the Constitution's handshake with the world. It ensures that the constitution can talk to anything without being changed by anything. The adapter is controlled by the constitution, never the reverse.