Universal Application Model — UAM v0.1.0
A constitutional doctrine for building applications on ICore: application-first, capabilities optional, constitutional invariants never optional.
Status: Doctrine Constitutional dependencies: USCP (six primitives) · USC · URS v0.1.0 (specs.initialcore.net/urs.html) · CORE-LD v0.1.0 (specs.initialcore.net/core-ld.html) Scope: All ICore applications — PWA, native, WASM, and any future runtime Registry prefix: UAM
1. The Doctrine
Application-first. The application is the unit of constitutional governance. Capabilities serve applications; applications never serve capabilities. A capability is adopted only when it advances the application's constitutional purpose, and replaced without ceremony when a better one appears. ICore does not chase technologies — it absorbs them.
The ladder. Every application element occupies exactly one rung, and every rung derives from the one above it:
| Rung | Definition | ICore expression |
|---|---|---|
| Truth | Reality as the ground of all derivation | The six USCP primitives: Existence, Identity, Relationship, Constraint, Transformation, Verification |
| Principles | Invariant rules derived from Truth | USC; the derivation chains through UCE, UCM, UCC |
| Constitution | The governing contract, frozen | URS v0.1.0 (23 invariants); CORE-LD foundational profile (23 invariants) |
| Architecture | Structural layers instantiating the constitution | UWA, UCN, UAS layers; CORE-LD §6 composition rules |
| Capabilities | Environmental provisions — always optional | PWA, WASM, WebGPU, native packaging, future runtimes |
| Preferences | Canonical defaults — opinionated, replaceable by constitutional process | PWA manifest; CBOR-CORE-LD wire + JSON-CORE-LD human view; Ed25519Signature2020; IndexedDB sovereign-local storage |
| Implementations | Concrete adapters of preferences | JSON-CORE-LD / CBOR-CORE-LD bindings; any future codec, transport, store |
2. Invariants vs Capabilities — the Split
Constitutional invariants are never optional. Identity, trust, verification, and policy grounding are not features of an application — they are what the application is. An application without WebGPU degrades gracefully; an application without verifiable identity is a different entity. "Progressive everywhere" must never degenerate into "nothing guaranteed anywhere."
Capabilities are always optional. Every capability may be absent, degraded, or substituted, provided every constitutional invariant is preserved. The absence of a capability is a degraded experience, never a constitutional violation.
3. Canonical Defaults vs Compatible Alternatives
Canonical defaults are the opinionated choices of the ICore constitution — the current set:
| Domain | Canonical default |
|---|---|
| Application shell | PWA manifest (offline-first, sovereign-local) |
| Wire / storage encoding | CBOR-CORE-LD (deterministic, compact) |
| Human-readable encoding | JSON-CORE-LD (audit, presentation) |
| Signature / proof | Ed25519Signature2020 (linked data proof) |
| Local persistence | IndexedDB (device-sovereign) |
Compatible alternatives are conforming if and only if: (a) they preserve every UAM and CORE-LD invariant; (b) they declare their compatibility profile (CCA §4 interop rules); (c) the substitution is reversible. A default changes only by constitutional process — never by convenience.
4. The Triad
Strict about outcomes, opinionated about defaults, tolerant about compatible methods.
Outcomes are constitutional and strict: invariants hold or the application does not conform. Defaults are opinionated: the canonical choices above. Methods are tolerant: anything that preserves the invariants is a compatible method.
5. Invariants
| # | Invariant | Mechanical verification |
|---|---|---|
| UAM-1 | **Application primacy.** Every application element traces to a ladder rung; no element exists solely to serve a capability. | Derivation table present in the application's constitutional record; each element mapped to a rung |
| UAM-2 | **Invariant preservation.** A conforming application preserves every CORE-LD invariant it touches. | CORE-LD conformance suite passes on the application's data |
| UAM-3 | **Invariants never optional.** Identity, trust, verification, and policy grounding are present in every conforming application, in every environment. | Attestation (TRUST-LD) required for the application identity; verification check present in the build |
| UAM-4 | **Capabilities always optional.** No capability may be a precondition for constitutional function. | A capability-free execution path exists and satisfies UAM-2 |
| UAM-5 | **Canonical defaults.** The §3 defaults are the reference choices; deviations are compatible alternatives, not new defaults. | Defaults registry (this document) is the sole authority |
| UAM-6 | **Compatible alternatives.** A non-default choice is conforming iff it preserves all invariants, declares its profile, and is reversible. | Compatibility profile declared (CCA §4); reversibility demonstrated |
| UAM-7 | **Absorbs, never chases.** Technology adoption is justified by application need and derivation, never by fashion. | Adoption record traces each technology to the rung it serves |
6. Four-Question Stress Test
Each doctrine claim is verified by the four constitutional questions before it enters force:
| Claim | Why constitutional | What invariant | How verified | If absent |
|---|---|---|---|---|
| Application-first | USCP Verification — applications are the governed unit of constitutional computing | UAM-1 | Ladder trace in the application record | Applications become vehicles for capabilities; governance inverts |
| Invariants never optional | USCP Identity + Verification — unverifiable applications cannot be governed | UAM-3 | TRUST-LD attestation required in every build | "Progressive everywhere" degenerates into "nothing guaranteed anywhere" |
| Capabilities optional | USCP Existence — the application exists independently of any environment | UAM-4 | Capability-free path test | Capability adoption becomes a constitutional dependency |
| Canonical defaults | USCP Constraint — opinionated defaults bound the solution space | UAM-5 | Defaults registry is authoritative | Choice paralysis; fragmentation of the ecosystem |
| Tolerant methods | USCP Transformation — governed processes admit many implementations | UAM-6 | Compatibility profile check | Methods become mandates; superset-over-replacement dies |
Freeze gate: CORE-LD v0.1.0 flips Draft → Frozen upon this stress test passing (derivation chain complete: USCP → USC → UCE/UCM/UCC → URS → CORE-LD → UAM; conformance suite verified 250/250; doctrine claims all four questions answered).
End of UAM Doctrine v0.1.0 — July 31, 2026. Doctrine. Derives from USCP + CORE-LD v0.1.0.