Registry

The Registry is the trust resolution layer of the AIEP ecosystem. It provides the canonical source for issuer identities, certificate policies, and safety-critical registry data - including the versioned plausibility scores that govern execution eligibility across all conformant deployments.

Open AIEP adoption requires no registry interaction. The Registry exists to answer one question at enterprise and regulated scale: who issued this, is it still valid, and what does current registry state say about the claim-type?

What the Registry provides

Issuer DID resolution

Every issuer registered with AIEP has a Decentralised Identifier (DID) document published at /.well-known/aiep/registry/issuers/<issuer_id>.json. The document contains:

• the issuer’s domain and public key material
• scope of certification authority (e.g. compliance certificates, plausibility declarations, protocol audits)
• effective date and optional expiry
• a canonical hash of the DID document itself

When an artefact carries an issuer_id, a conformant retriever resolves the issuer DID document and verifies that the issuer_id matches the domain and that the public key material is consistent with the signed artefact. DID document resolution is fail-closed: if the document is absent or non-resolving, the issuer identity cannot be confirmed and the conjunction trust model fails at the Identity condition.

Merkle-verified plausibility scores

The plausibility registry publishes current PlausibilityScore values for claim-types in a versioned Merkle tree. The root hash of the tree is signed by the registry authority and published at /.well-known/aiep/registry/plausibility/root.json.

To verify a plausibility score, a retriever:

1. fetches the score and its Merkle path from /.well-known/aiep/registry/plausibility/<claim_type>.json
2. recomputes the path to the root
3. compares the computed root against the signed root
4. confirms the root signature against the registry authority’s key

If any step fails: non-executable. The score cannot be used to gate execution without verified Merkle inclusion. This prevents a class of attack where a local or cached score is substituted for the current registry value.

Certificate issuance and revocation

Registered issuers publish certificates as artefacts at /.well-known/aiep/registry/certs/<cert_id>.json. The registry maintains a revocation list at /.well-known/aiep/registry/revoked.json. Before relying on any certificate for execution decisions, the certificate hash must be confirmed absent from the revocation list.

Certificate policies

Certification types are defined in policy documents at /.well-known/aiep/registry/policies/<policy_id>.json. A policy document defines: what the certification covers, the evidence requirements for issuance, the audit frequency, and the required schema version. Policies are versioned independently of the protocol specification.

Conjunction trust and the Registry

The Registry provides the verification material for two of the four conjunction trust conditions:

• Identity: DID resolution - the issuer resolves and the key material matches
• Admissibility: Merkle-verified plausibility score - the claim-type is registry-approved at or above the execution threshold

Integrity and goal commitment are independently verified by the retriever against the artefact hash and the GoalVector commitment record respectively. No registry component can override a failed integrity or goal-commitment check.

Enterprise deployment patterns

Pattern 1 - Hosted static registry (recommended for most deployments)

Publish registry content as static JSON at /.well-known/aiep/registry/. Serve via CDN with strong cache headers. The Merkle root is the only component that requires re-signing when plausibility scores are updated. All other registry artefacts are immutable once published (revocation adds to the revocation list; it does not modify an existing artefact).

Pattern 2 - Worker-served registry with audit logging

For regulated deployments requiring access audit trails on registry lookups, serve registry content via an edge Worker that logs each resolution request with requester identity, artefact reference, and resolution outcome. The Worker remains a thin proxy - no business logic, no score modification, no selective availability.

Pattern 3 - Air-gapped registry mirror

For deployments that cannot route to a public registry (classified contexts, industrial isolation), a registry mirror can be synchronised on a scheduled basis and served internally. The plausibility root signature remains authoritative; the local mirror must carry the full Merkle path for any claim-type queried at runtime.

What happens when verification fails

All registry verification failures are fail-closed:

There is no cached-value fallback for execution-critical registry lookups. A stale or unverifiable registry state is treated identically to a failed state.

See: Security · Plausibility Matrix · Protocol · Certification