CANON-GATE v0.1.0

Status: Frozen (2026-08-12 — signed fixtures + four-question stress test + forge attestation) Extends: UIR-LD v0.1.0 (which 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 → UIR-LD v0.1.0 Spec family: Functional Profile (see CORE-LD §6.1 — Composition Rules) Dimension registry prefix: CANON-GATE Canonical @context: https://specs.initialcore.net/ns/canon-gate.jsonld Domain: canon.initialcore.net (planned)

1. Preamble

Canon is the canonical/constitutional intelligence of ICore: it answers "what is valid according to the canon?" — deterministically, mechanically, and without any model in the loop. This specification defines the Canon Gate: the pure-function interface through which any intent is checked against the canon before it may proceed.

Canon is a capability inside Cardinal (universal intelligence — "what should we do, and how can we realize it?"). One intelligence, two capabilities: Cardinal proposes, Canon validates. Canon is never a separate model, service, or authority — it is a deterministic rule engine over a versioned, signed rule store. The Gate has no opinions; it only reports whether an intent conforms to the canon as amended.

What CANON-GATE is:

• A pure-function gate: `evaluate(intent, canonStore, version) → EvaluationRecord`
• The canonical form of "valid according to the canon": deterministic, replayable, model-free
• A signed, content-addressed evaluation record format (G8 attestation records)
• The first concrete rule set (v0.1) expressed in POLICY-LD/USE terms — the seed canon

What CANON-GATE is not:

• Not an intelligence — Canon does not propose, generate, or decide intent; it validates
• Not a governance body — amendment flows through the existing constitutional pipeline (spec freeze + UCF attestation), never through the Gate
• Not a model interface — no model may serve as the evaluation engine (I-CANON-2)
• Not a new rule language — rules are POLICY-LD policies, evaluated by USE (I-CANON-8)
• Not a replacement for POLICY-LD or USE — it composes them into a gate

1.1 Composition rule

CANON-GATE = POLICY-LD + USE + UIR-LD SemanticBinding + CanonStore + CanonVersion + Rule + EvaluationRecord

A conforming Canon Gate implementation MUST also conform to POLICY-LD, UIR-LD, INPUT-LD, and CORE-LD at the same conformance level. The Gate is the executable face of the canon; the canon is data, never code.

1.2 Domain positioning

The Canon Gate is the artifact for G8 (attestation/provenance deepening): every evaluation is a signed, replayable record that an independent verifier can re-run to reproduce the verdict (I-CANON-1). It is a Draft until its conformance suite (canon_gate_conformance.py) is verified and green — matching URS freeze doctrine.

2. Scope and Derivation Chains

2.1 Scope

2.2 Derivation chains

Each CANON-GATE entity traces to the constitutional primitives through the intermediate axioms:

2.3 Four-question constitutional semantics

The Gate answers, for every evaluation: Why is it constitutional? (accountability — every decision traceable to canon); What invariant requires it? (I-CANON-1..15); How is it verified? (replayable evaluation, signed record, hash-checked canon); What happens if absent? (an unsigned or unreplayable evaluation is structurally non-constitutional — it cannot be attested).

3. Entity Types

CANON-GATE extends the POLICY-LD / UIR-LD entity sets with four types:

3.1 CanonStore

A CanonStore is the versioned, signed rule store the Gate evaluates against. It is a CORE-LD Group whose members are CanonVersions.

{
  "@id": "did:icore:canon",
  "@type": "CanonStore",
  "name": "ICore Canon",
  "currentVersion": "canon:life-v17",
  "versions": ["canon:life-v1", "canon:life-v2", "...", "canon:life-v17"]
}

3.2 CanonVersion

A CanonVersion is a frozen, signed snapshot of the rule set. Versions form a linear chain (each derives from exactly one prior version, except v1).

{
  "@id": "canon:life-v17",
  "@type": "CanonVersion",
  "version": "17",
  "derivesFrom": "canon:life-v16",
  "ruleSet": ["canon:rule-101", "canon:rule-102", "canon:rule-103"],
  "canonicalHash": "zQmExampleCanonicalHash...",
  "signedBy": "did:icore:canon-governance#key1",
  "attestedAt": "2026-08-01T00:00:00Z"
}

3.3 Rule

A Rule is a deterministic condition — a POLICY-LD rule restricted to mechanically evaluable form: field, operator, value. No free text, no model calls (I-CANON-10, I-CANON-11).

{
  "@id": "canon:rule-101",
  "@type": "Rule",
  "appliesTo": ["domain:agent", "purpose:invoke"],
  "condition": {"field": "capacity.remaining", "operator": "gt", "value": 0},
  "effect": "permit",
  "severity": "required"
}

Registered operators: eq, neq, gt, gte, lt, lte, in, not-in, contains, exists, not-exists. Operators are fixed — the Gate rejects any unregistered operator.

3.4 EvaluationRecord

An EvaluationRecord is the signed output of the Gate — the G8 attestation record. It captures intent, canon version, verdict, applied rules, and proof, such that an independent verifier can replay the evaluation.

{
  "@id": "_:eval1",
  "@type": "EvaluationRecord",
  "intentNode": "_:in1",
  "canonVersion": "canon:life-v17",
  "evaluationEngine": "use",
  "verdict": "conditional",
  "conditions": [{"rule": "canon:rule-102", "required": true}],
  "appliedRules": ["canon:rule-101", "canon:rule-102"],
  "evaluatedAt": "2026-08-11T10:00:00Z",
  "provenance": {"Representer": "did:icore:canon-gate", "Timestamp": "2026-08-11T10:00:00Z",
                 "Authority": {"authorityType": "granted", "mayDelegate": false}},
  "proof": {"type": "Ed25519Signature2020", "proofValue": "z...", "verificationMethod": "did:icore:canon-gate#key1"}
}

Registered verdicts: valid, conditional, invalid, deferred. A verdict other than valid MUST carry conditions or a re-evaluation path — no lockout (I-CANON-3, mirroring UIR-LD I-UIR-15).

4. The Gate: a Pure Function

The Gate is defined as a pure function — no side effects, no state, no model:

evaluate(intent: IntentNode, canon: CanonStore, version: VersionLabel) → EvaluationRecord

Determinism (I-CANON-1): identical (intent, canon, version) MUST produce an identical EvaluationRecord — same verdict, same applied rules, same canonical serialization hash. The Gate MAY be memoized or replayed; every evaluation is reproducible by an independent verifier.

Purity (I-CANON-4): the Gate performs no I/O, writes no state, and consults nothing outside (intent, canon, version). All state is passed in; all output is the record. This is what makes G8 replay possible.

Evaluation procedure (deterministic):

1. Load — resolve the CanonVersion named by version from the CanonStore (hash-checked, I-CANON-5) 2. Select — filter ruleSet by the intent's purpose/domain (appliesTo match, I-CANON-8) 3. Evaluate — apply each matching Rule's deterministic condition against the intent's evaluated fields (operators per §3.3 registry, I-CANON-10) 4. Combine — resolve conflicts with USE's combining strategy (first-applicable, declared per PolicySet; I-CANON-9 delegates to USE semantics) 5. Verdict — valid (all required rules permit), conditional (require-consent / require-delegation / defer effects present), invalid (any deny), deferred (conditions unmet but re-evaluation path exists) 6. Record — emit the EvaluationRecord: intent ref, canon version, engine use, verdict, conditions (when ≠ valid), applied rules in deterministic order, provenance, and Ed25519Signature2020 proof over the canonical serialization

Governance mode (I-CANON-15): when the intent's origin is human or rule, the Gate runs the same procedure with the same canon — no model is ever required to obtain a verdict. The Gate's engine is always use or policy.

5. Canon Store and Amendment

5.1 Version chain

CanonVersions form a linear chain: every version (except v1) has exactly one derivesFrom; no forks, no merges (I-CANON-7). The chain is content-addressed: each version's canonicalHash covers its canonical serialization, and derivesFrom references the prior version's identity.

5.2 Amendment = the constitutional pipeline

Amending the canon is not a Gate operation. An amendment:

1. Is authored as a POLICY-LD policy change (draft) 2. Passes the constitutional pipeline: review → spec freeze → UCF forge attestation (constitutional-artifact, signed by canon governance key) 3. Becomes a new CanonVersion: derivesFrom the prior version, carries its own canonicalHash and signedBy 4. Is published; the CanonStore's currentVersion pointer moves only after attestation

This mirrors spec freeze doctrine exactly — the canon cannot be amended by the Gate, by a model, or by a single actor. Authority bounds follow DAG-Constitution-LD C1–C5 (delegation depth, mayDelegate) and are carried in the CanonVersion's provenance authority record.

5.3 Signed store

Every CanonVersion is signed (Ed25519Signature2020, I-CANON-6). The Gate verifies the version signature against the canon governance key before evaluating — an unsigned or mismatched version MUST NOT be used.

6. First Rule Set (Canon v0.1)

The seed canon — the minimal rule set every ICore agent inherits. Rules are expressed in §3.3 form (deterministic conditions only).

Conflict resolution: deny and require-* dominate permit (USE first-applicable, declared combining strategy). Advisory rules (severity: advisory) record a note but never change the verdict.

7. Invariants (I-CANON-1..15)

Every invariant is mechanically verifiable — the conformance suite (canon_gate_conformance.py) implements each check exactly as specified.

Invariant groups: I-CANON-1..4 (gate), I-CANON-5..9 (canon store), I-CANON-10..11 (rule set), I-CANON-12..14 (evaluation record / G8), I-CANON-15 (governance mode).

8. @context Extension

CANON-GATE extends the UIR-LD / POLICY-LD contexts with a small term set under the canon# namespace:

{
  "@context": {
    "canon": "https://specs.initialcore.net/ns/canon-gate.jsonld#",
    "CanonStore": "canon:CanonStore",
    "CanonVersion": "canon:CanonVersion",
    "Rule": "canon:Rule",
    "EvaluationRecord": "canon:EvaluationRecord",
    "derivesFrom": "canon:derivesFrom",
    "canonicalHash": "canon:canonicalHash",
    "signedBy": "canon:signedBy",
    "attestedAt": "canon:attestedAt",
    "ruleSet": "canon:ruleSet",
    "appliesTo": "canon:appliesTo",
    "condition": "canon:condition",
    "effect": "canon:effect",
    "severity": "canon:severity",
    "evaluationEngine": "canon:evaluationEngine",
    "verdict": "canon:verdict",
    "conditions": "canon:conditions",
    "appliedRules": "canon:appliedRules",
    "evaluatedAt": "canon:evaluatedAt"
  }
}

Terms shared with UIR-LD (intentNode, provenance, proof, canonVersion) reuse the UIR-LD / CORE-LD definitions — no redefinition.

9. Composition Examples

9.1 Gate inside Cardinal (one intelligence, two capabilities)

Cardinal (universal intelligence)
 ├─ Proposes:  intent candidates (UIR-LD IntentNode)
 └─ Validates: Canon Gate — evaluate(intent, canon, version) → EvaluationRecord
                (deterministic, model-free, signed)

Cardinal may be any replaceable intelligence (human, local SLM, remote open-weights model, rule). The Gate is identical for all — the canon does not depend on which intelligence proposes.

9.2 LifePioneer booking (UIR-LD + CANON-GATE)

An appointment-booking intent flows: IntentNode → Canon Gate (canon:life-v17) → ExecutionTarget → ExecutionRecord. The Gate's conditional verdict (consent required) becomes a condition in the SemanticBinding, which the execution stage MUST honor (UIR-LD I-UIR-10 capability gating).

9.3 Governance without model

An origin-human intent (e.g., "show my recovery phrases") passes the Gate with engine use and verdict valid — no model in the path (I-CANON-15). This is the Life no-lockout guarantee at the gate layer.

10. Conformance

Three conformance levels, matching the family:

• L1 Structural — entity shapes valid, required fields present
• L2 Identity — refs resolve, version chain linear, canonical hashes consistent
• L3 Constitutional — signed records, replayable evaluations, governance-mode replay

Conformance suite: canon_gate_conformance.py implements I-CANON-1..15 (list/test/verify CLI, family check_iN pattern). The suite must pass before CANON-GATE may move Draft → Frozen, per URS freeze doctrine. At freeze (2026-08-12) the crypto structural invariants (I-CANON-14 signature, plus I-CANON-6 canon-store signature) verify against signed fixtures (freeze_fixtures.py — deterministic Ed25519 test keys, multibase proofValues, tampered-record rejection). The base-document EvaluationRecord carries a real, verifying signature; determinism-class checks are proven by the permutation property over the same fixtures. Suite: 31/31 checks green, pytest 33/33 across the family.

11. Worked Example — LifePioneer Booking through the Gate

Intent: "Book the medical appointment for next Tuesday if policy allows" (origin human, purpose invoke, domain agent).

Canon: canon:life-v17 — rules 101 (capacity), 102 (consent), 104 (recovery viewable), 105 (human origin).

Evaluation (deterministic procedure, engine use):

EvaluationRecord (signed): verdict conditional, conditions: [{rule: canon:rule-102, required: true}], appliedRules: [101, 102, 104, 105] (deterministic order), engine use, provenance + Ed25519Signature2020 proof. An independent verifier replays the same procedure and reproduces the record hash — G8 replay.

Re-evaluation path (no lockout): the user grants consent → the intent re-enters the Gate with consent.required = false → verdict valid → execution proceeds. The original conditional record is retained as an attestation of the first pass.

12. Relationship to Other Specifications

13. Reference List

• URS v0.1.0 — Universal Representation System (frozen, specs.initialcore.net/urs)
• CORE-LD v0.1.0 — foundational LD profile (frozen, 23 invariants)
• INPUT-LD v0.1.0 — intent/request profile (12 invariants)
• POLICY-LD v0.1.0 — policy/rule profile (19 invariants)
• UIR-LD v0.1.0 — intent pipeline profile (17 invariants, Draft)
• TRUST-LD v0.1.0 — attestation profile (20 invariants)
• DAG-Constitution-LD v0.1.0 — governance codec (C1–C5 authority invariants)
• W3C Data Integrity 1.0 + Ed25519Signature2020 (Recommendation, 2025-05-15)
• W3C DID Core 1.0 (2022-07-19); VC Data Model 2.0 (2025-05-15)

14. Status and Freeze Path

Draft — this specification becomes Frozen when: (1) canon_gate_conformance.py passes 15/15 invariants on the base document with negative cases green; (2) the spec passes its four-question stress test; (3) the artifact is published and UCF-attested (constitutional-artifact, canon governance key). Amendment thereafter follows §5.2 — the constitutional pipeline, never the Gate.