USR/CoreFab Formal Specification v0.1.0

Preamble

This document is the formal specification of USR (Universal Sovereign Runtime) and CoreFab (Constitutional Fabrication). It defines how UWA components are orchestrated and how UCN networks are coordinated to produce sovereign constitutional execution.

USR does not define what a component is (that is UWA). USR does not define how components communicate across a network (that is UCN). USR defines how validated components are orchestrated into deterministic constitutional action — the runtime that makes components execute, attests to their behavior, and enforces sovereignty.

The v0.1.0 implementation proved that constitutional execution is possible. This specification proves that it is definable, verifiable, and sovereign.

This specification answers the constitutional question: How is meaning executed? It defines the invariants that execution must satisfy — the properties that hold true regardless of implementation. Mechanisms (Rust, WIT, SHA-256) are implementation choices; invariants are constitutional law.

UWA + UCN → USR/CoreFab (orchestration engine)

Section 1: Foundational Axioms

Every runtime capability must trace to these axioms. Nothing exists in USR/CoreFab that these axioms do not authorize.

1.1 The Five Runtime Axioms

1.2 Axiom Sufficiency

All six USCP primitives are represented across the axioms:

These axioms are invariants. They define what must always be true. The mechanisms below (WIT interfaces, Rust modules, SHA-256) are implementation choices that satisfy these invariants — they could be replaced by any conforming implementation.

Section 2: The USR Model

2.1 Definitions

2.2 The Relationship Between USR and CoreFab

USR is the constitutional runtime environment. CoreFab is the constitutional execution engine operating within that environment.

Neither is complete without the other. Neither pretends to be the other.

USR (environment):
  ├── Identity system     — declares who exists
  ├── Isolation system    — governs what is accessible
  ├── Orchestration system — manages lifecycle and communication
  └── CoreFab (engine):
       ├── Execution engine  — runs operations
       └── Attestation engine — proves what happened

The environment wraps the engine. The engine operates within the environment. A component is registered by the environment, then executed by the engine, then attested by the engine, then managed by the environment.

2.3 Constitutional Layer

Section 2.5: The Doctrine Position

USR occupies a specific position in the constitutional doctrine:

Section 3: The Constitutional Contract Model

3.1 WIT as Constitutional Law

The WebAssembly Interface Types (WIT) interfaces defined in wit/constitutional.wit are not merely APIs — they are constitutional execution contracts. Their stability is more important than any Rust implementation.

A WIT interface is the execution-level equivalent of a USCP primitive: it defines the irreducible surface area through which constitutional execution occurs.

3.2 The Six Contracts

3.3 Contract Completeness

Every contract answers one of the six USCP constitutional questions:

Section 4: The Identity Contract (C1)

4.1 Specification

4.2 Identity Invariants

4.3 Identity Verification Protocol

A component identity is verified if and only if:

1. The name is non-empty (I1)
2. The layer is valid (I2)
3. Pre-constitutional components have no parents (I3)
4. Non-pre components have at least one parent (I4)
5. A constitutional question is answered (I5)
6. The ID matches the derivation SHA-256(name:layer:version:parents) (deterministic)

Section 5: The Execution Contract (C2)

5.1 Specification

5.2 Execution Invariants

5.3 Determinism Requirement

Determinism (E2) is the hardest and most important invariant. It means:

• No external state is read during execution (no network, no filesystem, no randomness)
• No global mutable state affects the output
• The same serialized input always produces the same serialized output
• The function f(operation, input) → output is pure

5.4 Registered Operations (v0.1.0)

Section 6: The Constraints Contract (C3)

6.1 The Six Constitutional Questions

Every claim, component, or operation must answer the six constitutional questions:

6.2 The Ten Verification Tests

The runtime enforces the Kernel's 10 constitutional tests as execution constraints:

6.3 Claim Validation

The constraint engine validates claims against the six questions:

6.4 Derivation Rules Enforcement

The constraint engine enforces the five derivation rules from Part II:

Section 7: The Isolation Contract (C4)

7.1 Specification

7.2 Governed Resources

7.3 Isolation Invariants

7.4 The Sovereignty Boundary

The network resource is governed but constitutionally restricted. The sovereignty axiom (RA5) means:

• A runtime may grant network capability to a component
• But the grant must be constitutionally justified
• Network access is the one capability that can violate sovereignty
• UCA (the adapter layer) is the proper boundary for external communication, not individual component capabilities

Section 8: The Attestation Contract (C5)

8.1 Specification

8.2 Attestation Invariants

8.3 Attestation Verification Protocol

To verify an attestation record:

1. Recompute signing_data from the record fields: component_id:operation:input_hash:output_hash:timestamp:result
2. Recompute signature from "attestation:" + signing_data
3. Compare the recomputed signature with the stored signature
4. Verify the record exists in the runtime's attestation chain

8.4 Upgrade Path

The v0.1.0 attestation uses SHA-256 as a simplified signature. Production implementations should upgrade to asymmetric cryptography (Ed25519 or similar) through the UCA adapter boundary. The WIT interface is designed to accommodate this — the signature field is a string, not a fixed algorithm.

Section 9: The Orchestration Contract (C6)

9.1 Specification

9.2 Lifecycle State Machine

┌────────────┐
                  │ Registered │ ← initial state after identity verification
                  └─────┬──────┘
                        ↓
                  ┌────────────┐
                  │Initialized │ ← capabilities granted, constraints loaded
                  └─────┬──────┘
                        ↓
                  ┌────────────┐
            ┌────→│  Running   │ ← executing operations, producing attestations
            │     └──┬─────┬──┘
            │        ↓     ↓
            │  ┌──────┐  ┌─────────┐
            └──│Paused│  │ Stopped │
               └──────┘  └─────────┘
┌────────────┐
                  │   Error    │ ← terminal fault state (unrecoverable)
                  └────────────┘

9.3 Valid Transitions

9.4 Orchestration Invariants

Section 10: The Blueprint Model

10.1 Blueprint Structure

A constitutional blueprint is a JSON document describing a component and its intended execution:

{
  "name": "component-name",
  "id": "optional-explicit-id",
  "layer": "impl",
  "operation": "validate-identity",
  "input": "{...}",
  "parents": ["parent-component-id"]
}

10.2 Blueprint Validation Rules

10.3 Blueprint Execution Lifecycle

Blueprint (JSON) → Validate → Register Identity → Register Orchestration
  → Request Capabilities → Initialize → Start → Execute Operation
  → Attest Result → Return

Every step is constitutional. If any step fails, the execution returns a ConstitutionalError and the runtime remains consistent.

Section 11: The Constitutional Error Model

11.1 Error Taxonomy

11.2 Error Properties

Section 12: Runtime Composition

12.1 The Six Engines

The USR runtime is composed of six engines, each implementing one contract:

12.2 Runtime Initialization

A new USR runtime initializes with:

1. Empty identity registry
2. Four registered operations: validate-identity, check-derivation, enforce-constraint, compute-hash
3. Empty constraint validator
4. Empty capability store
5. Empty attestation chain
6. Empty orchestration state

12.3 Runtime Verification

The runtime provides a verify() method that checks global consistency:

1. identity.verify_all() — all registered components pass identity verification and D1 layer ordering
2. isolation.verify_all() — all granted capabilities are non-expired
3. attestation.verify_chain() — every attestation record verifies cryptographically
4. orchestration.verify_all() — no component is in an Error state

Section 13: Conformance Criteria

13.1 Runtime Conformance Tests

An implementation conforms to the USR/CoreFab Formal Specification if and only if:

13.2 Conformance Levels

13.3 Conformance Protocol

1. Declarate scope: Implementation declares which contracts (C1-C6) it implements.
2. Apply tests: Run all applicable tests (USR-01 through USR-15).
3. Record evidence: For each test, record what was checked, what was found, pass/fail.
4. Determine level: Count Critical and Major failures. Apply level rules.
5. Archive: Conformance Record stored as a constitutional artifact.

Section 14: Self-Verification

14.1 Against the 10 Constitutional Tests

USR/CoreFab Formal Specification v0.1.0 verified against the Kernel's 10 constitutional tests:

Section 15: Relationship to v0.1.0 Implementation

This formal specification captures what v0.1.0 demonstrated and makes it normative:

1. Normative axioms — the five runtime axioms (RA1-RA5) are constitutional law, not code comments
2. Invariant completeness — 31 named invariants across all contracts (I1-I6, E1-E6, S1-S6, A1-A6, O1-O5, B1-B4, EP1-EP4)
3. Conformance tests — 15 formalized tests (USR-01 through USR-15) with severity levels
4. Determinism requirement — formalized as the hardest invariant (Section 5.3), not just a code pattern
5. Sovereignty boundary — the network resource restriction (Section 7.4) is constitutional law
6. Error model — classified, transparent, non-destructive, traceable (Section 11)

Appendix: Implementation Module Reference

Originator Attribution

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

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