Universal Application Model — UAM v0.2.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) · USE — Universal Selection Engine (this doctrine) 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 |
| Selection (USE) | The constitutional act of choosing among verified compatible options | Universal Selection Engine — the runtime decision point: *given verified constraints, capabilities, policies, and objectives, select the best compatible option while preserving constitutional outcomes* |
| 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 |
Selection (USE). The Universal Selection Engine is the constitutional boundary between certainty and adaptability. Everything above the Selection rung is intended to be stable — Truth, Principles, Constitution, Architecture, Verification. Everything below is intended to be replaceable — transports, storage engines, runtimes, AI models, protocols, platforms, interfaces. USE is the decision point: given verified constraints, capabilities, policies, and objectives, select the best compatible option while preserving constitutional outcomes.
Selection is the constitutional act; switching is a consequence. A switch changes from one option to another; a decision chooses a course of action; a selection identifies the best compatible option according to constitutional rules. Once selected, the system may switch, route, execute, negotiate, schedule, adapt — or do nothing. Selection precedes every adaptive behavior, which is why it is the constitutional primitive and the rest are implementations.
Selection is universal, not merely software. Evolution selects; physics selects stable states; mathematics selects valid solutions; logic selects valid inferences; networks select routes; compilers select optimizations; AI selects models and actions. Selection is the universal bridge between possibility and actuality. Operationally: Verify — what is valid? Select — what is best? Execute — what is done?
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 |
| UAM-8 | **Constitutional selection.** Every selection is made from verified options and preserves every invariant the application touches. | Selection record: each selected option's verification result and invariant-preservation check precede selection (USE log) |
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 |
| Constitutional selection | USCP Transformation — selection is the governed act of choosing among verified transformations | UAM-8 | USE log: verified options, selection rationale, invariant check before execution | Adaptation becomes arbitrary; capability drift erodes constitutional outcomes |
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 → USE; conformance suite verified 250/250; doctrine claims all four questions answered).
End of UAM Doctrine v0.2.0 — August 1, 2026. Doctrine. Derives from USCP + CORE-LD v0.1.0 + USE.