UIR-LD v0.1.0

The Universal Intermediate Representation — a functional LD profile extending INPUT-LD with intent-node semantics for the pipeline: Intent → Constitutional Semantics → Transcompilation → Adaptive Execution → Verification.

Status: Frozen (2026-08-12 — signed fixtures + four-question stress test + forge attestation) Extends: INPUT-LD v0.1.0 (which extends CORE-LD v0.1.0) Constitutional dependencies: URS v0.1.0 → CORE-LD v0.1.0 → INPUT-LD v0.1.0 Spec family: Functional Profile (see CORE-LD §6.1 — Composition Rules) Dimension registry prefix: UIR-LD Canonical @context: https://specs.initialcore.net/ns/uir-ld.jsonld Domain: uir.initialcore.net (planned)

1. Preamble

UIR (Universal Intermediate Representation) is the semantic bridge between intent and execution. It defines how an actor's intent is captured as a first-class, content-addressed, constitutional entity (an IntentNode), how that intent is bound to the canon (constitutional semantics), how it is transcompiled to execution targets, how execution is governed and recorded, and how the outcome is verified.

UIR makes the ICore pipeline legible: what is wanted is separated from how it is achieved and that it is verifiable — each stage a distinct, deterministic, inspectable artifact.

What UIR-LD is:

A set of entity types and properties for representing intent and its pipeline (IntentNode, SemanticBinding, ExecutionTarget, ExecutionRecord, VerificationRecord)
The canonical form of the five-stage pipeline: Intent → Constitutional Semantics → Transcompilation → Adaptive Execution → Verification
A standard envelope for any system that takes intent to governed, verifiable execution (Life, USE, agents, LLM gateways)
Intelligence-source-neutral: an IntentNode does not record which intelligence produced it (human, local SLM, remote model, deterministic rule) — only the intent. Governance mode (no model) is always a valid pipeline

What UIR-LD is not:

Not a protocol — UIR defines representation, not transport
Not an execution engine — UIR represents execution targets and records; it does not run them
Not an API specification — it defines the semantic payload, not the endpoint contract
Not a model interface — model adapters live outside UIR (UAM doctrine: capabilities are optional adapters, never core dependencies)
Not a replacement for INPUT-LD — UIR-LD inherits all INPUT-LD and CORE-LD invariants and adds its own

1.1 Composition rule

UIR-LD = INPUT-LD + IntentNode + SemanticBinding + ExecutionTarget + ExecutionRecord + VerificationRecord

Any conforming UIR-LD implementation MUST also conform to INPUT-LD and CORE-LD at the same conformance level. An encoded UIR-LD binding (e.g., JSON-UIR-LD) MUST preserve CORE-LD, INPUT-LD, and UIR-LD invariants.

1.2 Domain positioning

UIR is the artifact for the planned uir.initialcore.net domain: a published, versioned, forge-attested specification whose worked example demonstrates the full intent-to-verification path. It is a Draft until its conformance suite is verified (matching URS freeze doctrine).

2. The Five-Stage Pipeline

UIR defines intent processing as five sequential, deterministic stages. Each stage consumes and produces content-addressed entities; each stage's output is independently verifiable.

Intent → Constitutional Semantics → Transcompilation → Adaptive Execution → Verification

Stage	Input	Output	Governed by
1. Intent	perception / user utterance / model output	IntentNode	INPUT-LD semantics
2. Constitutional Semantics	IntentNode	SemanticBinding (canon rules, USE verdicts)	USE, POLICY-LD
3. Transcompilation	IntentNode + SemanticBinding	ExecutionTarget (target-neutral plan)	WIT world / WASM interfaces
4. Adaptive Execution	ExecutionTarget	ExecutionRecord (capability-gated actions)	USE, capabilities, UAM
5. Verification	ExecutionRecord	VerificationRecord (signed outcome)	TRUST-LD, Ed25519Signature2020

Stage discipline: a stage MAY be skipped only when its output is provably absent-by-construction (e.g., a pure query intent has an empty execution stage). Skipping MUST be recorded in the ExecutionRecord provenance.

2.1 Derivation chains

Each UIR entity type traces to the constitutional primitives through the intermediate axioms:

Entity	USCP Primitive	UCE/UCM/UCC Axiom	Representation Axiom	UIR Entity
IntentNode	Autonomy	UCE Agency Axiom	INPUT-LD Intent	UIR IntentNode
SemanticBinding	Legitimacy	UCM Canon Axiom	POLICY-LD Policy	UIR SemanticBinding
ExecutionTarget	Capability	UCM Execution Axiom	UAM Capability	UIR ExecutionTarget
ExecutionRecord	Accountability	UCE Provenance Axiom	URS Provenance	UIR ExecutionRecord
VerificationRecord	Trust	UCC Verification Axiom	TRUST-LD Attestation	UIR VerificationRecord

3. Entity Types

UIR-LD extends the INPUT-LD entity set with the following types:

3.1 IntentNode

An IntentNode is the canonical capture of intent — what the actor fundamentally wants, independent of how it is achieved and of which intelligence produced it.

{
  "@id": "_:in1",
  "@type": "IntentNode",
  "purpose": "invoke",
  "domain": "agent",
  "priority": "high",
  "origin": "human",
  "canonicalText": "Book the medical appointment for next Tuesday if policy allows",
  "inputs": [ ... ],
  "semanticBinding": "_:sb1",
  "executionTarget": "_:et1"
}

Property	Type	Required	Description
`purpose`	String	Yes	Registered intent purpose (INPUT-LD §2.2): `query`, `mutate`, `invoke`, `observe`, `delegate`
`domain`	String	Yes	Registered intent domain (INPUT-LD §2.2)
`priority`	String	No	`low`, `medium`, `high`, `critical`
`origin`	String	Yes	Intelligence source class: `human`, `local-model`, `remote-model`, `rule`, `system` — never a vendor or product name
`canonicalText`	String	No	Canonical prose form of the intent (human-readable anchor)
`inputs`	Array of entity refs	No	Entities the intent references (perception results, prior records)
`semanticBinding`	Entity ref	No	Reference to the SemanticBinding (stage 2 output)
`executionTarget`	Entity ref	No	Reference to the ExecutionTarget (stage 3 output)
`idempotencyKey`	String	No	Deduplication key; when present, identical semantic content MUST produce an identical key

Registered origin classes: human, local-model, remote-model, rule, system. Origin records the class, never the product — replaceability is represented, not vendor-locked.

3.2 SemanticBinding

A SemanticBinding records the constitutional evaluation of an IntentNode — the canon rules that apply, the USE verdict, and the constraints under which the intent may proceed.

{
  "@id": "_:sb1",
  "@type": "SemanticBinding",
  "intentNode": "_:in1",
  "evaluationEngine": "use",
  "verdict": "conditional",
  "canonVersion": "canon:life-v17",
  "rules": [
    { "@id": "_:r1", "ruleRef": "policy:appointment-scheduling#capacity", "outcome": "pass" }
  ],
  "conditions": [ ... ],
  "evaluatedAt": "2026-08-10T09:00:00Z"
}

Property	Type	Required	Description
`intentNode`	Entity ref	Yes	The IntentNode evaluated
`evaluationEngine`	String	Yes	Engine used: `use`, `policy` (deterministic rule engines — never a model)
`verdict`	String	Yes	`valid`, `conditional`, `invalid`, `deferred`
`canonVersion`	String	Yes	Versioned canon store applied (content-addressed)
`rules`	Array of RuleResult	No	Per-rule outcomes (ruleRef + outcome)
`conditions`	Array of Constraint	No	Conditions to satisfy before execution (INPUT-LD Constraint)
`evaluatedAt`	dateTime	Yes	Evaluation timestamp

Registered verdicts: valid (may proceed), conditional (proceed only when conditions satisfied), invalid (must not proceed), deferred (insufficient information; no action taken — never a lockout).

3.3 ExecutionTarget

An ExecutionTarget is the target-neutral transcompilation of an IntentNode — the plan expressed against typed interfaces (WIT world), before any capability binding.

{
  "@id": "_:et1",
  "@type": "ExecutionTarget",
  "intentNode": "_:in1",
  "plan": { "@id": "_:plan1", "interface": "icore:kernel/actions", "operations": [ ... ] },
  "capabilities": [ "scheduling:create", "notification:send" ],
  "targets": [ "wasm", "native", "remote-adapter" ],
  "transcompiledAt": "2026-08-10T09:00:01Z"
}

Property	Type	Required	Description
`intentNode`	Entity ref	Yes	Source intent
`plan`	Entity ref	Yes	The target-neutral plan (typed interface + operations)
`capabilities`	Array of String	Yes	Capability identifiers required for execution
`targets`	Array of String	No	Candidate execution targets: `wasm`, `native`, `remote-adapter`, `manual`
`transcompiledAt`	dateTime	Yes	Transcompilation timestamp

Transcompilation determinism: identical IntentNode + SemanticBinding MUST produce a byte-identical ExecutionTarget plan (L2 identity, per URS Canonicalization). This is what makes "reproducible AI execution" a testable claim.

3.4 ExecutionRecord

An ExecutionRecord captures what actually happened at execution time — capability-gated, provenance-carrying, auditable.

{
  "@id": "_:er1",
  "@type": "ExecutionRecord",
  "intentNode": "_:in1",
  "executionTarget": "_:et1",
  "status": "completed",
  "actions": [
    { "@id": "_:a1", "capability": "scheduling:create", "outcome": "appointment-booked", "proof": "_:p1" }
  ],
  "executedBy": "life:alice",
  "startedAt": "2026-08-10T09:00:02Z",
  "completedAt": "2026-08-10T09:00:03Z",
  "provenance": {
    "Representer": "did:icore:life:alice",
    "Timestamp": "2026-08-10T09:00:03Z",
    "Authority": { "authorityType": "granted", "mayDelegate": false }
  }
}

Property	Type	Required	Description
`intentNode`	Entity ref	Yes	Source intent
`executionTarget`	Entity ref	Yes	The plan executed
`status`	String	Yes	`pending`, `running`, `completed`, `failed`, `aborted`, `deferred`
`actions`	Array of Action	No	Capability-gated actions taken, each with capability + outcome + proof
`executedBy`	IRI	Yes	Executing identity (Life, agent, human)
`startedAt` / `completedAt`	dateTime	Yes	Execution window
`provenance`	Object	Yes	URS provenance (Representer, Timestamp, Authority)

Registered statuses: pending, running, completed, failed, aborted, deferred. A deferred execution is a recorded non-action — evidence of governance, not failure.

3.5 VerificationRecord

A VerificationRecord is the signed attestation over an ExecutionRecord — the output of stage 5, suitable for independent verification by any third party.

{
  "@id": "_:vr1",
  "@type": "VerificationRecord",
  "executionRecord": "_:er1",
  "verifications": [
    { "@id": "_:v1", "type": "capability-gate", "result": "pass", "evidence": "use-verdict-...", "by": "use" },
    { "@id": "_:v2", "type": "canon-conformance", "result": "pass", "evidence": "canon:life-v17#rule-3", "by": "use" }
  ],
  "overall": "verified",
  "verifiedAt": "2026-08-10T09:00:04Z",
  "proof": {
    "type": "Ed25519Signature2020",
    "verificationMethod": "did:icore:life:alice#key-1",
    "created": "2026-08-10T09:00:04Z",
    "proofPurpose": "assertionMethod",
    "proofValue": "z...signed-canonical-document..."
  }
}

Property	Type	Required	Description
`executionRecord`	Entity ref	Yes	The record attested
`verifications`	Array of Verification	No	Per-check results (type, result, evidence, by)
`overall`	String	Yes	`verified`, `unverified`, `disputed`
`verifiedAt`	dateTime	Yes	Attestation timestamp
`proof`	Object	Yes	Linked-data proof: `Ed25519Signature2020` (W3C Data Integrity) over the canonical document

Proof discipline: the proof MUST be computed over the canonical serialization (JSON-CORE-LD / CBOR-CORE-LD per URS Canonicalization), so any verifier with the canon + the public key can independently reproduce the verdict.

4. Pipeline Lifecycle

The UIR pipeline is a state machine over the five stages. A pipeline instance carries the following states:

Captured → Bound → Transcompiled → Executed → Verified
         ↘ Deferred (recorded, reversible — never lockout)

State	Meaning	Entity present
`Captured`	Intent received, IntentNode canonicalized	IntentNode
`Bound`	Constitutional semantics applied	+ SemanticBinding
`Transcompiled`	Target-neutral plan produced	+ ExecutionTarget
`Executed`	Capability-gated actions recorded	+ ExecutionRecord
`Verified`	Outcome attested with linked-data proof	+ VerificationRecord
`Deferred`	Recorded non-action (insufficient info / conditions unmet)	+ SemanticBinding (verdict `deferred`)

Deferral is not lockout: any deferred pipeline can be re-bound when conditions change; the identity, the intent, and the records all persist offline. This is the UIR encoding of Life's no-lockout invariant.

5. Constitutional Semantics — Four-Question Test

Every constitutional semantic field in UIR answers the four questions:

Field	Why constitutional?	What invariant requires it?	How verified?	If absent?
`origin` (class, not vendor)	Autonomy + replaceability: no intelligence source may be a mandatory dependency	I-UIR-3	`origin` ∈ registered classes; never a product name	Vendor lock; replaceability claim unverifiable
`semanticBinding`	Legitimacy: intent must be evaluated against the canon before execution	I-UIR-5	Verdict exists and canonVersion is content-addressed	Ungoverned execution
ExecutionTarget determinism	Accountability: same intent must produce the same plan	I-UIR-7	L2 hash equality on identical inputs	Reproducibility claim collapses
Capability gating	Capability: execution limited to USE-approved capabilities	I-UIR-8	Every action's capability ∈ IntentNode capability list	Privilege escalation
Provenance on ExecutionRecord	Accountability: who executed, when, under what authority	I-UIR-9	URS provenance fields present and valid	Unauditable execution
Proof on VerificationRecord	Trust: verifiable by anyone, not claimed by ICore	I-UIR-10	Ed25519Signature2020 over canonical form verifies	Third-party verification impossible
Deferral semantics	No lockout: non-action must be recorded, reversible, never blocking	I-UIR-11	`deferred` carries conditions + re-evaluation path	Silent failure or lockout

6. Invariants

UIR-LD inherits all 23 CORE-LD invariants (I1–I23) and all 12 INPUT-LD invariants (I-INPUT-1 through I-INPUT-12) as its conformance criteria. The following UIR-LD-specific invariants are ADDITIONAL:

6.1 IntentNode invariants (I-UIR-1 through I-UIR-4)

ID	Invariant	Check
I-UIR-1	Every IntentNode has a registered purpose and domain	`purpose` ∈ {query, mutate, invoke, observe, delegate}; `domain` ∈ INPUT-LD registered domains
I-UIR-2	Every IntentNode has an origin class	`origin` ∈ {human, local-model, remote-model, rule, system}
I-UIR-3	Origin records a class, never a vendor or product	`origin` value is a registered class; no product/company identifiers permitted
I-UIR-4	IntentNode canonicalizes deterministically	Canonical serialization (JSON-CORE-LD rules) of identical semantic content is byte-identical — verified over signed fixtures: permutation-invariant canonical form, and non-canonical serializations fail signature verification (freeze_fixtures.py)

6.2 SemanticBinding invariants (I-UIR-5 through I-UIR-6)

ID	Invariant	Check
I-UIR-5	Every SemanticBinding records an evaluation engine, verdict, and canon version	`evaluationEngine`, `verdict`, `canonVersion` all present
I-UIR-6	Evaluation engine is deterministic	`evaluationEngine` ∈ {use, policy}; never a model identifier
I-UIR-7	Verdict is registered and non-locking	`verdict` ∈ {valid, conditional, invalid, deferred}; `deferred` requires conditions present

6.3 Transcompilation invariants (I-UIR-8 through I-UIR-9)

ID	Invariant	Check
I-UIR-8	Transcompilation is deterministic	Identical IntentNode + SemanticBinding ⇒ identical ExecutionTarget plan (L2 hash equality)
I-UIR-9	Every ExecutionTarget declares required capabilities	`capabilities` non-empty; each entry is a registered capability identifier

6.4 Execution invariants (I-UIR-10 through I-UIR-12)

ID	Invariant	Check
I-UIR-10	Every action in an ExecutionRecord uses a declared capability	Each `actions[].capability` ∈ ExecutionTarget `capabilities`
I-UIR-11	Every ExecutionRecord carries full URS provenance	`provenance.Representer`, `provenance.Timestamp`, `provenance.Authority` present and valid
I-UIR-12	Every ExecutionRecord has an executor identity	`executedBy` is a valid IRI/DID

6.5 Verification invariants (I-UIR-13 through I-UIR-14)

ID	Invariant	Check
I-UIR-13	Every VerificationRecord carries a linked-data proof	`proof.type` = Ed25519Signature2020; `proof.proofValue` present; verificationMethod resolves
I-UIR-14	VerificationRecord proof covers the canonical document	Ed25519Signature2020 proof verifies cryptographically over the canonical record (freeze_fixtures.py; tampered records rejected)

6.6 Sovereignty invariants (I-UIR-15 through I-UIR-17)

ID	Invariant	Check
I-UIR-15	No lockout: every pipeline outcome is recorded and reversible	`deferred`/`invalid` outcomes carry conditions and a re-evaluation path; no state blocks future intent
I-UIR-16	Governance mode is always valid	An IntentNode with no model origin (origin = `human` or `rule`) passes the full pipeline unchanged
I-UIR-17	Commerce is optional and opt-in	No UIR entity requires commerce semantics; commerce-capable bindings are marked and gated (see §9)

7. UIR-LD @context Extension

The UIR-LD @context extends the INPUT-LD and CORE-LD @contexts with the following term mappings:

{
  "@context": {
    "IntentNode": "https://specs.initialcore.net/ns/uir#IntentNode",
    "SemanticBinding": "https://specs.initialcore.net/ns/uir#SemanticBinding",
    "ExecutionTarget": "https://specs.initialcore.net/ns/uir#ExecutionTarget",
    "ExecutionRecord": "https://specs.initialcore.net/ns/uir#ExecutionRecord",
    "VerificationRecord": "https://specs.initialcore.net/ns/uir#VerificationRecord",

    "origin": "https://specs.initialcore.net/ns/uir#origin",
    "canonicalText": "https://specs.initialcore.net/ns/uir#canonicalText",
    "inputs": { "@id": "https://specs.initialcore.net/ns/uir#inputs", "@container": "@set" },
    "semanticBinding": { "@id": "https://specs.initialcore.net/ns/uir#semanticBinding", "@type": "@id" },
    "executionTarget": { "@id": "https://specs.initialcore.net/ns/uir#executionTarget", "@type": "@id" },
    "idempotencyKey": "https://specs.initialcore.net/ns/uir#idempotencyKey",
    "evaluationEngine": "https://specs.initialcore.net/ns/uir#evaluationEngine",
    "verdict": "https://specs.initialcore.net/ns/uir#verdict",
    "canonVersion": "https://specs.initialcore.net/ns/uir#canonVersion",
    "rules": { "@id": "https://specs.initialcore.net/ns/uir#rules", "@container": "@set" },
    "ruleRef": "https://specs.initialcore.net/ns/uir#ruleRef",
    "outcome": "https://specs.initialcore.net/ns/uir#outcome",
    "conditions": { "@id": "https://specs.initialcore.net/ns/uir#conditions", "@container": "@set" },
    "evaluatedAt": { "@id": "https://specs.initialcore.net/ns/uir#evaluatedAt", "@type": "xsd:dateTime" },
    "plan": "https://specs.initialcore.net/ns/uir#plan",
    "interface": "https://specs.initialcore.net/ns/uir#interface",
    "operations": { "@id": "https://specs.initialcore.net/ns/uir#operations", "@container": "@set" },
    "capabilities": { "@id": "https://specs.initialcore.net/ns/uir#capabilities", "@container": "@set" },
    "targets": { "@id": "https://specs.initialcore.net/ns/uir#targets", "@container": "@set" },
    "transcompiledAt": { "@id": "https://specs.initialcore.net/ns/uir#transcompiledAt", "@type": "xsd:dateTime" },
    "status": "https://specs.initialcore.net/ns/uir#status",
    "actions": { "@id": "https://specs.initialcore.net/ns/uir#actions", "@container": "@set" },
    "capability": "https://specs.initialcore.net/ns/uir#capability",
    "executedBy": { "@id": "https://specs.initialcore.net/ns/uir#executedBy", "@type": "@id" },
    "startedAt": { "@id": "https://specs.initialcore.net/ns/uir#startedAt", "@type": "xsd:dateTime" },
    "completedAt": { "@id": "https://specs.initialcore.net/ns/uir#completedAt", "@type": "xsd:dateTime" },
    "verifications": { "@id": "https://specs.initialcore.net/ns/uir#verifications", "@container": "@set" },
    "evidence": "https://specs.initialcore.net/ns/uir#evidence",
    "by": "https://specs.initialcore.net/ns/uir#by",
    "overall": "https://specs.initialcore.net/ns/uir#overall",
    "verifiedAt": { "@id": "https://specs.initialcore.net/ns/uir#verifiedAt", "@type": "xsd:dateTime" },
    "proof": "https://specs.initialcore.net/ns/uir#proof",
    "proofValue": "https://specs.initialcore.net/ns/uir#proofValue",
    "proofPurpose": "https://specs.initialcore.net/ns/uir#proofPurpose",
    "verificationMethod": { "@id": "https://specs.initialcore.net/ns/uir#verificationMethod", "@type": "@id" }
  }
}

8. Composition Examples

UIR-LD composes with INPUT-LD/CORE-LD as its base. Further composition with encoding and addressing is additive.

8.1 Pure UIR-LD (abstract graph)

UIR-LD = INPUT-LD + intent/execution semantics
Conforms to: CORE-LD (I1–I23) + INPUT-LD (I-INPUT-1..12) + UIR-LD (I-UIR-1..17)

8.2 JSON-UIR-LD

JSON-UIR-LD = UIR-LD + JSON encoding
Conforms to: CORE-LD I1–I23 + INPUT-LD + UIR-LD + JSON deterministic serialization
@context: core-ld.jsonld + input-ld.jsonld + uir-ld.jsonld

8.3 CBOR-UIR-LD

CBOR-UIR-LD = UIR-LD + CBOR encoding (CBOR-CORE-LD binding rules)
Conforms to: CORE-LD + INPUT-LD + UIR-LD + CBOR deterministic encoding (RFC 8949 §4.2.1)
@context: core-ld.jsonld + input-ld.jsonld + uir-ld.jsonld (integer-key registry extended)

8.4 DAG-UIR-LD

DAG-UIR-LD = UIR-LD + JSON + DAG addressing
Adds: canonical hash per URS Canonicalization, content-address invariants C1–C6

9. Optional Commerce Clause

UIR is commerce-neutral by construction, per ICore doctrine (UAM: capabilities are optional adapters, never core dependencies; value = adoption and conformance growth, not revenue).

Commerce is optional and opt-in: no IntentNode, SemanticBinding, ExecutionTarget, ExecutionRecord, or VerificationRecord requires commerce semantics. A UIR document with zero commerce fields is fully conformant.
Commerce-capable bindings MAY attach a marked commerce profile (e.g., a licensed capability, a paid service adapter) — but the marker is explicit, gated by USE like any other capability, and never changes the core pipeline's semantics.
No commerce in the core: the five stages, the invariants, and the canonical forms are defined without any reference to exchange, payment, or vendor terms. Removing all commerce-capable bindings from an ecosystem MUST NOT break conformance (mirrors I-UIR-17).
Contractual form: when commerce exists, it is a documented agreement between adopters (solution-first), never an ICore-imposed model.

10. Conformance

10.1 Implementation requirements

A conforming UIR-LD implementation MUST: 1. Satisfy all CORE-LD conformance requirements (§9 of CORE-LD) 2. Satisfy all INPUT-LD conformance requirements (§7 of INPUT-LD) 3. Parse the UIR-LD @context extension (§7) in addition to the INPUT-LD and CORE-LD @contexts 4. Validate all 17 UIR-LD invariants (I-UIR-1 through I-UIR-17) 5. Reject documents that violate any CORE-LD, INPUT-LD, or UIR-LD invariant 6. Accept any valid INPUT-LD document that does not use UIR entity types as also valid at the INPUT-LD level (UIR-LD is additive, not restrictive)

10.2 Conformance levels

Level	Requirements
L1 Structural	CORE-LD L1 + I-UIR-1, I-UIR-2, I-UIR-4 (basic IntentNode shape)
L2 Complete	CORE-LD L2 + all 12 INPUT-LD invariants + all 17 UIR-LD invariants
L3 Constitutional	CORE-LD L3 + INPUT-LD L3 + all UIR-LD invariants + full provenance on IntentNode, ExecutionRecord, and VerificationRecord

10.3 Conformance suite (planned)

A runnable conformance suite (uir_conformance.py) will implement the invariant checkers in the family check_iN pattern used by urs_conformance.py / profile_conformance.py. Freeze (Draft → Frozen) is gated on the verified suite, per URS freeze doctrine.

11. Examples

11.1 Worked example — LifePioneer appointment booking (full pipeline)

Stage 1 — Intent (captured from human + local model, origin recorded by class):

{
  "@context": [
    "https://specs.initialcore.net/ns/core-ld.jsonld",
    "https://specs.initialcore.net/ns/input-ld.jsonld",
    "https://specs.initialcore.net/ns/uir-ld.jsonld"
  ],
  "@id": "_:in1",
  "@type": "IntentNode",
  "purpose": "invoke",
  "domain": "agent",
  "priority": "high",
  "origin": "local-model",
  "canonicalText": "Book the medical appointment for next Tuesday if policy allows",
  "inputs": [ "_:perception1" ],
  "idempotencyKey": "lp-2026-08-10-appt-01"
}

Stage 2 — Constitutional Semantics (USE verdict, deterministic engine):

{
  "@id": "_:sb1",
  "@type": "SemanticBinding",
  "intentNode": "_:in1",
  "evaluationEngine": "use",
  "verdict": "conditional",
  "canonVersion": "canon:life-v17",
  "rules": [
    { "@id": "_:r1", "ruleRef": "policy:appointment-scheduling#capacity", "outcome": "pass" },
    { "@id": "_:r2", "ruleRef": "policy:appointment-scheduling#consent", "outcome": "pass" }
  ],
  "conditions": [
    { "@id": "_:c1", "field": "notification.consent", "operator": "equals", "value": true, "severity": "required" }
  ],
  "evaluatedAt": "2026-08-10T09:00:00Z"
}

Stage 3 — Transcompilation (target-neutral plan against a WIT world):

{
  "@id": "_:et1",
  "@type": "ExecutionTarget",
  "intentNode": "_:in1",
  "plan": {
    "@id": "_:plan1",
    "interface": "icore:kernel/actions",
    "operations": [
      { "@id": "_:op1", "operation": "scheduling.create", "args": { "slot": "next-tuesday", "actor": "alice" } },
      { "@id": "_:op2", "operation": "notification.send", "args": { "to": "alice", "type": "confirmation" } }
    ]
  },
  "capabilities": [ "scheduling:create", "notification:send" ],
  "targets": [ "wasm", "native" ],
  "transcompiledAt": "2026-08-10T09:00:01Z"
}

Stage 4 — Adaptive Execution (capability-gated, provenance-carrying):

{
  "@id": "_:er1",
  "@type": "ExecutionRecord",
  "intentNode": "_:in1",
  "executionTarget": "_:et1",
  "status": "completed",
  "actions": [
    { "@id": "_:a1", "capability": "scheduling:create", "outcome": "appointment-booked", "proof": "_:receipt1" },
    { "@id": "_:a2", "capability": "notification:send", "outcome": "confirmation-sent", "proof": "_:receipt2" }
  ],
  "executedBy": "life:alice",
  "startedAt": "2026-08-10T09:00:02Z",
  "completedAt": "2026-08-10T09:00:03Z",
  "provenance": {
    "Representer": "did:icore:life:alice",
    "Timestamp": "2026-08-10T09:00:03Z",
    "Authority": { "authorityType": "granted", "mayDelegate": false },
    "RepresentationContext": "urn:icore:uir:v0.1"
  }
}

Stage 5 — Verification (signed attestation over the canonical record):

{
  "@id": "_:vr1",
  "@type": "VerificationRecord",
  "executionRecord": "_:er1",
  "verifications": [
    { "@id": "_:v1", "type": "capability-gate", "result": "pass", "evidence": "use-verdict-9f2c1e", "by": "use" },
    { "@id": "_:v2", "type": "canon-conformance", "result": "pass", "evidence": "canon:life-v17#appointment-scheduling", "by": "use" }
  ],
  "overall": "verified",
  "verifiedAt": "2026-08-10T09:00:04Z",
  "proof": {
    "type": "Ed25519Signature2020",
    "verificationMethod": "did:icore:life:alice#key-1",
    "created": "2026-08-10T09:00:04Z",
    "proofPurpose": "assertionMethod",
    "proofValue": "z8gQb1..."
  }
}

11.2 Deferral example — no lockout

{
  "@id": "_:in2",
  "@type": "IntentNode",
  "purpose": "mutate",
  "domain": "governance",
  "origin": "human",
  "canonicalText": "Amend the local schedule policy to add a new clinic",
  "semanticBinding": {
    "@id": "_:sb2",
    "@type": "SemanticBinding",
    "evaluationEngine": "use",
    "verdict": "deferred",
    "canonVersion": "canon:life-v17",
    "conditions": [
      { "@id": "_:c2", "field": "provenance.Authority.mayDelegate", "operator": "equals", "value": true, "severity": "required" }
    ],
    "evaluatedAt": "2026-08-10T10:00:00Z"
  }
}

The intent is recorded, reversible, and re-evaluable when the authority condition changes — no lockout, no silent failure.

12. Relationship to Other Profiles

Profile	Relationship	Rule
POLICY-LD	SemanticBinding carries rule outcomes; POLICY-LD defines valid policy expression	UIR rule outcomes reference POLICY-LD policy documents
TRUST-LD	VerificationRecord is a TRUST-LD attestation with proof	UIR proofs use W3C Data Integrity Ed25519Signature2020
MEMORY-LD	ExecutionRecords and VerificationRecords are memory-store artifacts	UIR records persist in MEMORY-LD stores; inputs may be memory queries
USE	SemanticBinding records USE verdicts; execution is USE-gated	USE is the evaluation engine (I-UIR-6); no model may substitute
UAM	Capabilities are optional adapters, never core dependencies	ExecutionTarget capabilities are declared, gated, replaceable

13. Reference List

ICore: URS v0.1.0 (representation model, 23 invariants, frozen) — specs.initialcore.net/urs; CORE-LD v0.1.0 (frozen); INPUT-LD v0.1.0 (Draft); POLICY-LD v0.1.0 (Draft); TRUST-LD v0.1.0 (Draft); MEMORY-LD v0.1.0 (Draft); URS Canonicalization v0.1.0; JSON-CORE-LD / CBOR-CORE-LD bindings; UAM Doctrine v0.1.0; USE (Universal Selection Engine) — use.initialcore.net
External standards: W3C CBOR-LD 1.0 (Rec, 2026-07-27); W3C Data Integrity 1.0 + Ed25519Signature2020 (Rec, 2025-05-15); W3C DID Core 1.0 (Rec, 2022-07-19); W3C VC Data Model 2.0 + VC-JOSE-COSE (Rec, 2025-05-15); WebAssembly Core (CR Draft, 2026-07-28) + Component Model/WIT (in standardization); IETF RFC 8785 (JCS), RFC 8949 (CBOR), RFC 9052 (COSE); NIST FIPS 186-5 (Ed25519), FIPS 203/204/205 (post-quantum)
Contextual: MCP schema 2025-11-25 (pin; wrap with proof + USE selection, never invent agent protocols); SCITT (draft-ietf-scitt-architecture)

14. Future Considerations

Conformance suite: implement `uir_conformance.py` (I-UIR-1..17 checkers, pass/fail per invariant) — the freeze gate
Registry: a UIR codec/extension registry only after ecosystem demand (per CCA doctrine — no proliferation without purpose)
UIR↔MCP bridge: a documented mapping from MCP tool calls to IntentNodes (adopt/adapt, never invent)
Post-quantum proofs: hybrid Ed25519 + ML-DSA verification support (harvest-now-decrypt-later threat; FIPS 204)
Batch intents: multi-intent documents (mirrors INPUT-LD future consideration)

UIR-LD v0.1.0 — Draft. Freeze gated on verified conformance suite, per ICore specification doctrine.