Compliance
Compliance in AIEP operates at two distinct levels. The first is the open protocol’s own governance stance — narrow, trust-preserving, not an adoption gate. The second is the substrate’s automated regulatory compliance output — a significant part of the invention, where the AIEP stack automatically generates cryptographically bound compliance certificates for named regulatory frameworks at the moment of output production.
Protocol compliance stance
AIEP is open. Open use is always permitted. The compliance stance for the open protocol is intentionally narrow and focuses only on three things:
| Scope | What it covers |
|---|---|
| False certification claims | Claiming “AIEP Certified” without publishing verifiable certificate fields |
| Misuse of certification marks | Using AIEP certification phrases in ways that mislead users or regulators |
| NDA-restricted redistribution | Redistributing development packs that were shared under a signed NDA |
Compliance does not police open adoption. If you publish Mirror endpoints, build validators, implement schemas, or deploy the protocol in any way — that is encouraged. Open use is always permitted.
The compliance surface exists to preserve the meaning of a specific claim: “AIEP Certified.” If that phrase is used without verifiable proof, it becomes worthless to the users, organisations, and regulators who may rely on it.
Machine-readable compliance signals
/.well-known/aiep/compliance/policy.json
/.well-known/aiep/compliance/signals.json
Compliance policy and signals are exposed as machine-readable files. Validators and automated checks can query these endpoints and behave consistently without human review.
Automated regulatory compliance certification (P92)
This is the deeper compliance story — and the one most relevant to enterprise, regulated, and high-stakes AI deployments.
An AI system built on the AIEP constitutional stack does not produce compliance evidence through manual audit. It produces a ComplianceCertificate automatically at the moment of every reasoning output — bound by cryptographic hash to that specific output, the reasoning chain that produced it, and the evidence substrate state it drew on.
What the certificate is not
- Not a report written by a human auditor after the fact
- Not a separate document attached to the output
- Not based on log review
- Not producible for an output that was generated outside the AIEP substrate
What the certificate is
A structured record generated by the substrate at output production time, containing:
| Field | Contents |
|---|---|
outputHash | SHA-256 of the specific output |
reasoningChainHash | Hash of the complete reasoning chain |
evidenceSubstrateHash | Hash of the Evidence Ledger state at time of output |
regulatoryFrameworkId | The named framework being certified against |
clauseSatisfactionRecord | Every regulatory clause assessed, with SATISFIED / NOT_SATISFIED / NOT_APPLICABLE status |
certificateHash | SHA-256 over all preceding fields — independently recomputable |
Any party with access to the substrate can recompute the certificateHash from the stored ledger entries and verify it matches the certificate presented. No access to the executing system is required.
Fail-closed output suppression
If the substrate state does not satisfy the minimum compliance properties required by the named regulatory framework, output production is suppressed. A ComplianceFailureRecord is appended to the Reasoning Ledger. The system does not produce a non-compliant output.
Named regulatory frameworks
The RegulatoryFrameworkRegistry maps named regulatory frameworks to specific AIEP substrate properties. Current mappings include:
| Framework | AIEP properties that satisfy it |
|---|---|
| EU AI Act Art.12 — Logging, traceability, auditability, reproducibility | Append-only Evidence Ledger + hash chain completeness + deterministic replay path + schema-version-bound execution |
| FCA — Algorithmic accountability | Reasoning Ledger evidence references + GoalVector commitment records |
| FDA — AI-enabled medical device guidance | Schema-version-bound execution + GENOME_LOCKFILE hash + DivergenceGraph availability |
See /regulatory-governance for the full clause-by-clause mapping and the jurisdiction-specific package generation mechanism (P93).
What to do if a concern is raised
For open protocol compliance concerns (mark misuse, false certification claims): a notice should include timestamps, retrieved URLs, and hashes of the relevant artefacts so the observation can be reproduced. The remediation path is simple — either remove the false claim or publish the proof required to support it.
For substrate compliance questions from regulators or auditors: the correct starting point is a ledger query. The ComplianceCertificate, ClauseSatisfactionRecord, and JurisdictionCompliancePackage for any specific output can be retrieved and independently verified.
Regulatory governance · Audit · Certification · Trust · Patents — P92, P93
Compliance in detail
Regulatory Governance
Full clause-by-clause framework mapping — AIEP substrate properties to specific EU AI Act, FCA, FDA, and comparable jurisdictional requirements. Jurisdiction-specific package generation (P93).
Audit
The AIEP audit export surface: AiepAuditRecord schema, session-scoped export, ledger query endpoints, and how a regulator retrieves and independently verifies a complete compliance record.