Protocol
What the protocol defines
AIEP defines a standard for publishing, retrieving, and verifying structured artefacts. It specifies:
- Where artefacts are published (the Mirror path convention)
- What structure they must conform to (canonical schemas)
- How integrity is confirmed (hashing)
- Who issued them (registry-linked publisher identity)
The retrieval and execution flow
Here is what happens when an AI agent retrieves and acts on an AIEP artefact:
| Step | Action | Detail |
|---|---|---|
| 1 | Agent queries | GET /.well-known/aiep/index.json |
| 2 | Index returns | list of artefact paths + types + hashes |
| 3 | Agent retrieves | GET /.well-known/aiep/<artefact>.json |
| 4 | Agent validates | artefact structure against canonical schema |
| 5 | Agent checks | SHA-256 hash matches index entry |
| 6 | Agent resolves | issuer_id against AIEP registry |
| 7 | Agent confirms | certificate chain if artefact is certified |
| 8 | Plausibility gate | PlausibilityScore for the claim_type retrieved, Merkle proof verified — fail-closed if missing or below threshold |
| 9 | Probability gate | Certified tail-risk bound verified against threshold, cryptographic commitment checked — fail-closed if absent or mismatched |
| 10 | GoalVector check | Artefact’s goalVectorRef resolves to a committed, non-drifted GoalVector |
| 11 | Agent acts | On a fully verified, execution-admitted artefact: known origin, unaltered content, schema-conformant, plausibility-cleared, probability-certified, goal-committed |
Steps 1–7 establish what the artefact is. Steps 8–10 establish whether it is admitted for execution. This distinction is central to AIEP: existence and verifiability are not the same as execution eligibility.
Core artefact types
| Type | Description |
|---|---|
AIEP_METADATA | Publisher identity and protocol version declaration |
AIEP_CERTIFICATE | Issued certificate linking a publisher to a certified claim |
AIEP_AUDIT_EVENT | Immutable record of an action or compliance event |
AIEP_INNOVATION_LEDGER_ENTRY | Timestamped innovation record for IP provenance |
AIEP_WELL_KNOWN_INDEX | The root index listing all published artefacts |
AIEP_DIVERGENCE_RECORD | Typed record of a detected evidential, temporal, interpretive, or branch divergence |
AIEP_GOAL_VECTOR | Committed, hash-bound AI goal state at a specific point in time |
AIEP_COMPLIANCE_CERTIFICATE | Automated regulatory compliance certification bound to a specific output and evidence chain |
AIEP_NORMALISATION_MANIFEST | Record of normalisation transformations applied to an evidence artefact |
AIEP_BLOCKCHAIN_ANCHOR | External timestamp anchoring an artefact hash to a specific block height and transaction |
Required fields (all artefacts)
| Field | Type | Description |
|---|---|---|
aiep_protocol | string | Always "AIEP" |
record_type | string | One of the core types above |
aiep_spec_version | string | Protocol version (e.g. "1.0") |
publisher | object | Publisher name, domain, contact |
Protocol versioning
The protocol uses semantic versioning. Breaking changes increment the major version. The current stable version is 1.0.
Artefacts must declare the protocol version they conform to. Retrievers that do not support a declared version must treat the artefact as unverifiable, not as invalid.
See: Glossary · Versioning & Changelog · Schema Catalogue · Quickstart
AIEP — the Architected Instruction & Evidence Protocol — is a simple idea made operational.
It exists because instructions and claims shape the real world, but the evidence that should support them is often scattered, unverifiable, or lost. The web made publishing easy. AIEP makes publishing knowledge easier by linking what is said to what supports it.
AIEP does not require a new internet. It uses the one we already have.
The core rule
An instruction should be linked to evidence.
In AIEP, an instruction is any statement that people or machines may rely on: a decision, a directive, a conclusion, a requirement, a certification claim, a compliance statement, or an operational event.
Evidence is the artefact or set of artefacts that justify the instruction. Evidence can be a document, dataset, log, certificate, image, measurement, or any object that can be referenced and validated.
AIEP turns this into publishable infrastructure by making three things normal:
- Publish machine-readable surfaces so AI can discover what is available.
- Publish artefacts with provenance and hashes so integrity can be checked.
- Preserve dissent and outliers so discovery stays alive and recall is possible when new evidence appears.
Mirror: how AIEP is published on the web
AIEP Mirror is the publishing pattern that makes AIEP usable at scale.
A Mirror-compatible site publishes machine endpoints under:
/.well-known/aiep/
Those endpoints allow automated systems to discover the publisher’s artefacts, schemas, and policies. This Hub is itself an exemplar Mirror node.
Knowledge states: consensus, outliers, and recall
AIEP reflects how knowledge actually evolves.
Consensus is what the evidence most strongly supports today. Outliers are ideas that do not currently fit, but may fit later. Radical outliers are archived ideas held at low confidence until evidence arrives.
AIEP treats dissent as a feature: it preserves competing views while requiring that claims be linked to supporting artefacts. This allows “dead theories” to be recalled when new evidence makes them relevant again.
Why this matters for AI
More people are using AI as a replacement for search. But models cannot safely rely on unstructured, unverifiable web content.
AIEP enables evidence-backed knowledge retrieval: machines can retrieve artefacts from sources that publish them, validate structure with schemas, and check integrity using hashes.
The future of information retrieval is not search — it is evidence-backed knowledge retrieval.