The AIEP Canon
The Canon is the frozen kernel of AIEP. It defines eight canonical primitives — R1 through R8 — that every AIEP artefact, every GENOME-compliant agent, and every certified issuer commits to at build time.
The Canon does not change. New capabilities are built on top of it. New patents extend it. But the kernel itself is immutable. This is what makes cross-organisation, cross-jurisdiction, cross-time verification possible: if two systems both commit to the same Canon version, any artefact produced by one is verifiable by the other.
The Canon is defined in GB2519711.2 and is the foundation patent of the entire AIEP portfolio.
The eight canonical primitives
| Primitive | Name | What it defines |
|---|---|---|
| R1 | Identity | How an issuer is identified — the canonical issuer identifier format, the registry link, and the resolution protocol |
| R2 | Content | How artefact content is represented — encoding, normalisation, canonical form before hashing |
| R3 | Hash | How content integrity is verified — algorithm (SHA-256), input (canonical form of R2), output format (sha256:<hex>) |
| R4 | Time | How timestamps are represented — ISO 8601 UTC, precision requirements, validity window fields |
| R5 | Schema | How artefact structure is declared — schema URI, version, validation protocol |
| R6 | Evidence | How evidence is referenced — binding format, evidence hash, relationship type |
| R7 | Provenance | How artefact history is recorded — provenance chain format, step record structure, chain signature |
| R8 | State | How artefact lifecycle state is represented — knowledge state taxonomy, state transition rules, reclassification protocol |
Every AIEP artefact must implement all eight primitives. An artefact that omits any one of them is not a valid AIEP artefact — it may be a useful document, but it carries none of the protocol’s verifiability guarantees.
Why the Canon must be frozen
Consider what happens if R3 (Hash) is not frozen:
- Publisher A produces artefact X using SHA-256
- The protocol updates the hash algorithm to SHA-3
- Any retriever using the new algorithm cannot verify artefact X
- All historical artefacts become unverifiable without knowing which algorithm to apply
This is not theoretical. It is what happens to every system that allows its core primitives to drift over time. PKI hierarchies, certificate formats, and schema registries all face this problem when their core specifications change without a versioned commitment mechanism.
The Canon solves it by freezing R1–R8 permanently per version. The GENOME_LOCKFILE.json records which Canon version a system committed to at build time. Any artefact produced against Canon v1.0 can be verified against Canon v1.0 indefinitely — regardless of what later versions introduce.
GENOME_LOCKFILE.json
Every GENOME-compliant system produces a GENOME_LOCKFILE.json at build time:
| Field | Purpose |
|---|---|
canon_version | The Canon version committed to (e.g. "1.0.0") |
canon_hash | SHA-256 of the canonical Canon specification document |
primitives | Array of R1–R8 entries with their version hashes |
locked_at | ISO 8601 timestamp of build |
system_id | Identifier of the system that produced this lockfile |
lockfile_signature | Cryptographic signature over the above fields |
Every artefact produced by that system carries a reference to its GENOME_LOCKFILE.json. A verifier retrieves the lockfile, confirms the Canon version, and verifies the artefact against the primitives that were in force when it was produced.
How the Canon is extended
The Canon is extended through the Layer 2–5 patent portfolio. Each extension must:
- Not alter R1–R8 in the committed Canon version
- Declare which Canon version it extends
- Be backward-compatible — artefacts produced before the extension must remain verifiable
| Extension layer | What it adds | Key patents |
|---|---|---|
| Layer 1 | Canon kernel — R1–R8 primitives, GENOME_LOCKFILE, immutability guarantee | GB2519711.2 |
| Layer 2 | Web surface — Mirror endpoints, well-known paths, machine discovery | P60–P70 |
| Layer 3 | Evidence ecosystem — normalisation, stitching, weight, audit | P10–P30 |
| Layer 4 | Constitutional stack — GoalVector, compliance, chip governance | P37–P94 |
| Layer 5 | Cognitive continuity — swarm, cross-session, moral substrate | P95–P103 |
The Canon versus other protocols
The Canon addresses what schema.org, JSON-LD, and ActivityPub intentionally leave open:
| Protocol | Standardises | Does not standardise |
|---|---|---|
| schema.org | Vocabulary — what fields exist and what they mean | Hash integrity, issuer identity, evidence binding, lifecycle state |
| JSON-LD | Serialisation and linked data format | Content integrity, provenance chain, knowledge state |
| ActivityPub | Message passing and social graph | Evidence binding, temporal validity, fail-closed execution |
| AIEP Canon | Identity, content, hash, time, schema, evidence, provenance, state | Vocabulary — domain-specific schemas extend freely on top |
AIEP does not replace these protocols. It provides the eight primitives that none of them define, making it complementary rather than competitive with existing web standards.
Patent
GB2519711.2 — filed November 2025, UK Intellectual Property Office. The eight primitives, the GENOME_LOCKFILE mechanism, the Canon versioning protocol, and the immutability guarantee are the subject of this application.
Related
- Architecture — how the Canon underpins all five layers
- Constitutional Substrate — what the kernel enforces at runtime
- GENOME SDK — building Canon-compliant systems
- Specification — full canonical primitive field definitions
- Patents — GB2519711.2