Regulatory governance
Regulatory governance is one of the most significant practical outputs of the AIEP stack. An AI system built on AIEP does not just produce outputs — it produces outputs that come with automatically generated, cryptographically bound compliance certificates that a regulator, auditor, or counterparty can independently verify without access to the underlying system.
This is not a reporting feature. It is an architectural property. The compliance certificate is generated at the moment of output production, bound to the specific output hash, reasoning chain hash, and evidence substrate hash. It cannot be produced retroactively for an output that was generated outside the substrate.
The regulatory problem AIEP solves
Current AI systems face a structural compliance problem:
| Problem | What happens |
|---|---|
| Manual audit dependency | Compliance is demonstrated through post-hoc log review by human auditors — slow, expensive, and disconnected from the output itself |
| No cryptographic binding | A compliance report is a separate document. There is no proof it describes the specific output being regulated |
| Non-reproducibility | A regulator cannot independently verify the report without full access to the system |
| Framework mismatch | Different jurisdictions require evidence in different formats — the same system must produce multiple compliance reports manually |
| Fail-open behaviour | A system that cannot satisfy a compliance requirement often proceeds anyway — the compliance check is advisory, not enforced |
AIEP’s automated regulatory compliance certification (P92) addresses all five.
Automated compliance certification (P92)
At the moment any reasoning output is produced within a GENOME-compliant AIEP substrate, the compliance certification engine automatically evaluates the substrate state and generates a ComplianceCertificate.
What the ComplianceCertificate contains
| Field | Contents |
|---|---|
outputHash | SHA-256 of the specific output being certified |
reasoningChainHash | Hash of the complete reasoning chain that produced the output |
evidenceSubstrateHash | Hash of the Evidence Ledger state at time of output production |
regulatoryFrameworkId | The named regulatory framework being certified against |
frameworkVersion | The specific version of that framework |
clauseSatisfactionRecord | Enumeration of every clause assessed: clause ID, status (SATISFIED / NOT_SATISFIED / NOT_APPLICABLE), and the specific AIEP property that satisfies it |
certificateHash | SHA-256 over all preceding deterministic fields |
generationTimestamp | Recorded as data — not system-time dependent |
The certificateHash is the key verification mechanism. Any party with access to the substrate can recompute it from the stored ledger entries and confirm it matches the certificate presented. No access to the reasoning internals is required — only the hash-verifiable ledger state.
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. The system does not produce a non-compliant output and attach a failed certificate. It does not produce an output at all.
A ComplianceFailureRecord is appended to the Reasoning Ledger identifying:
- Which substrate property was not satisfied
- Which regulatory clause that property maps to
- The framework version in force at the time
This record is itself hash-bound and auditable. You can see not only what was certified but what was refused and why.
Named regulatory framework mappings
The RegulatoryFrameworkRegistry maintains versioned mappings from named regulatory frameworks to specific AIEP substrate properties. Current mappings include:
AI Act (Article 12 — Logging and traceability)
| Clause | AIEP property that satisfies it |
|---|---|
| Art.12 — Logging | evidence_ledger_append_only_integrity — append-only ledger with hash-chained entries |
| Art.12 — Traceability | evidence_hash_chain_completeness — unbroken hash chain from output to source artefacts |
| Art.12 — Auditability | deterministic_replay_path_available — any output can be reproduced from stored ledger entries |
| Art.12 — Reproducibility | schema_version_bound_execution — all operations bound to declared schema versions |
FCA — Algorithmic accountability
| Clause | AIEP property that satisfies it |
|---|---|
| Decision traceability | reasoning_ledger_evidence_references — every decision references the evidence artefacts that justified it |
| Audit trail completeness | evidence_ledger_append_only_integrity |
| Model governance | goalvector_commitment_record — every goal state is a signed, timestamped commitment |
FDA — AI-enabled medical devices (guidance)
| Clause | AIEP property that satisfies it |
|---|---|
| Pre-determined change control | schema_version_bound_execution + genome_lockfile_hash |
| Algorithm transparency | divergence_graph_available — all alternative interpretations recorded and retrievable |
| Real-world performance monitoring | evidence_hash_chain_completeness + temporal_gap_detection_active |
The RegulatoryFrameworkRegistry is itself versioned and append-only. New frameworks can be added. Existing framework mappings can be versioned but not retroactively altered — the version in force at the time of certification is permanently recorded in the certificate.
Jurisdiction-specific compliance packaging (P93)
Different regulators require evidence in different formats. The AI Act submission format is not the same as an FCA algorithmic accountability report. P93 introduces jurisdiction-specific compliance package generation — deterministic extraction and formatting of evidence from the AIEP substrate into the exact format required by the named regulatory authority.
How it works
- A compliance package generation request names the target jurisdiction
- The system retrieves the active JurisdictionComplianceSchema for that jurisdiction from the registry
- The schema defines: required evidence fields, selection criteria, presentation structure, retention period requirements, and output format
- The system evaluates the substrate audit trail against the schema requirements
- If any required evidence field is absent, generation fails closed — a RequiredEvidenceAbsenceRecord is appended to the audit trail
- The JurisdictionCompliancePackage is generated, containing all required evidence fields plus a PackageIntegrityHash
The PackageIntegrityHash
$$\text{PackageIntegrityHash} = H(\text{ExtractedEvidenceFields} | \text{SubstrateStateHash} | \text{SchemaVersionId})$$
A regulator receiving the package can recompute this hash from the substrate state and verify that the package accurately represents the underlying substrate. The package cannot be modified after generation without producing a different hash.
Multi-jurisdiction deployment
An AIEP substrate deployed across multiple jurisdictions simultaneously can generate compliance packages for each jurisdiction independently from the same underlying audit trail — without requiring separate logging or manual extraction for each jurisdiction. The evidence is in the ledger. The jurisdiction-specific schema governs how it is selected and presented.
Audit artefacts without enforcement (P28)
A regulator or independent auditor may need to verify AIEP substrate behaviour without taking on enforcement responsibility. The deterministic audit support mechanism (P28) generates structured audit artefacts as a passive by-product of the admissibility determination process — without asserting enforcement authority, modifying execution state, or producing evaluative output.
What an audit artefact contains:
- Canonical evidence references
- Registry version identifiers in force during determination
- Deterministic admissibility outcome records
- Processing trace commitments
What an audit artefact explicitly excludes:
- Evaluative or advisory commentary
- Enforcement triggers
- Discretionary interpretation
- Recommendations
This separation matters for independent verification contexts — a regulator can receive and verify audit artefacts without inheriting any enforcement dependency on the system that produced them.
Evidence presentation without judgement (P29)
Related to audit support, the evidence presentation mechanism (P29) provides structured factual records suitable for submission to legal, regulatory, or arbitration proceedings — without asserting a conclusion.
The principle: AIEP presents evidence. It does not judge. A system that presents evidence and asserts its own conclusion about that evidence creates a different legal artefact than one that presents evidence and leaves judgement to the receiving party.
For legal and regulatory submissions, this distinction matters significantly. AIEP-structured evidence records are presentable to a court or tribunal as structured factual records with cryptographic provenance — not as the conclusion of the system that produced them.
The regulatory governance stack in practice
For a regulated AI deployment, the full stack produces:
| Output | Mechanism | Who can verify it |
|---|---|---|
| Output itself | GENOME-compliant execution | Any party with the output hash |
| Compliance certificate | P92 — automatic at output production | Any party with ledger access |
| Jurisdiction package | P93 — on-demand per jurisdiction | Named regulatory authority |
| Audit artefacts | P28 — passive by-product | Independent auditor |
| Evidence records | P29 — structured factual records | Court, tribunal, arbitrator |
| Gap detection | P16 — temporal completeness | Any party querying the ledger |
None of these require human review at production time. All are cryptographically bound to the specific output that triggered them. All can be independently verified against the stored ledger state.
What this means for compliance teams
An organisation deploying AIEP for a high-risk AI application does not produce compliance evidence by writing reports after the fact. The compliance evidence is produced automatically, at the moment of execution, by the substrate itself.
When a regulator asks “can you show me the compliance evidence for output X from 14 January 2026?” — the answer is not a manual extraction exercise. It is a ledger query that returns the ComplianceCertificate, the ClauseSatisfactionRecord, the reasoning chain hash, and the evidence substrate hash, all bound together and independently verifiable.
This is the difference between compliance as assertion and compliance as proof.
Use cases · Audit · GENOME SDK · Constitutional substrate · Patents — P28, P29, P92, P93