P171 — AIEP — Evidence Audit Log and Compliance Reporting Protocol
Publication Date: 2026-03-27 Status: Open Source Prior Art Disclosure Licence: Apache License 2.0 Author/Organisation: Phatfella Ltd Schema: AIEP_OS_SPEC_TEMPLATE v1.0.1 — https://aiep.dev/schemas/aiep-os-spec-template/v1.0.1
Framework Context
[0001] This disclosure operates within an Architected Instruction and Evidence Protocol (AIEP) environment as defined in United Kingdom patent application number GB2519711.2, filed 20 November 2025, the entire contents of which are incorporated herein by reference.
[0002] The present disclosure defines a protocol for generating structured compliance reports from the AIEP evidence audit trail, consolidating records from the Deterministic Dual-Ledger Memory Substrate (P80) across evidence lifecycle events (access, ingestion, modification, archival, disposal, conflict) into a ComplianceReport schema suitable for submission to regulatory authorities, internal governance reviews, and third-party auditors.
Field of the Disclosure
[0003] This disclosure relates to evidence audit log consolidation and compliance reporting protocols for governed artificial intelligence reasoning systems in regulated environments.
[0004] More particularly, the disclosure concerns a ComplianceReport schema, a ReportGenerator component assembling reports from multiple ledger partitions, a set of standard report types covering common regulatory reporting scenarios, a signing procedure for report integrity, and a report submission interface compatible with standard regulatory reporting frameworks.
Background
[0005] AIEP-governed evidence infrastructure produces a rich audit trail across multiple ledger partitions: access events (P166), provenance chains (P150), conflict records (P161), disposition events (P167), and query logs (P168). Regulatory frameworks increasingly require that AI systems operating in regulated domains (healthcare, finance, law, public administration) produce evidence that their reasoning is based on appropriately governed, auditable evidence — and that access to evidence was controlled, documented, and reportable on demand.
[0006] Individual ledger partitions contain the raw data for compliance, but regulators and auditors require consolidated, structured reports — for example, a report of all evidence accessed during a given audit period, or a report demonstrating that all evidence used in a regulated decision met the minimum quality tier requirement. Assembling these reports by manually querying the ledger is error-prone and not scalable.
[0007] A standardised ComplianceReport schema with a governed generation process ensures that reports are consistent, reproducible, signed by the node producing them, and cross-referenced to the underlying ledger entries so that any report claim can be verified by an auditor with ledger access.
Summary of the Disclosure
[0008] ComplianceReport Schema:
report_id— SHA-256 of canonical serialisation of all other fieldsreport_type— from the ReportType enumeration (see [0009])reporting_node_id— P46 fingerprint of the node generating the reportreporting_period—{start: ISO8601, end: ISO8601}generated_at— ISO 8601 timestampreport_parameters— type-specific parameters used to generate the reportsummary_statistics— key counts (e.g. total events, artefacts in scope, violations found)report_sections— ordered list of ReportSection objects (type-specific)ledger_references— list of ledger entry identifiers supporting all report claimsreport_signature— cryptographic signature by the reporting node
[0009] ReportType Enumeration:
EVIDENCE_ACCESS_LOG— all evidence access events (granted and denied) in the reporting period, grouped by requestorEVIDENCE_FRESHNESS_AUDIT— all Active tier artefacts with freshness scores (P147) below a configurable threshold, with overdue re-fetch countsQUALITY_TIER_COMPLIANCE— distribution of Evidence Quality Tiers (P160) across artefacts used in reasoning outputs in the reporting period; identifies reasoning outputs that relied on artefacts below a minimum quality tierCONFLICT_RESOLUTION_AUDIT— all ConflictRecords (P161) in the reporting period, including resolution outcomes and time-to-resolution statisticsRETENTION_COMPLIANCE_AUDIT— all DispositionEvents (P167) in the reporting period, with confirmation that all dispositions were made per applicable RetentionPoliciesPROVENANCE_INTEGRITY_AUDIT— sample of ProvenanceChains (P150) verified during the reporting period (via P175 hash integrity verification), with pass/fail countsDATA_SUBJECT_ACCESS_REPORT— all evidence artefacts containing personal data about a specified data subject that were accessed or processed in the reporting period (supports data subject access requests under data protection law)
[0010] ReportGenerator: The ReportGenerator accepts a ReportRequest specifying the report_type, reporting_period, and any type-specific parameters, and assembles the ComplianceReport by: (a) querying the relevant ledger partitions for events in the reporting period; (b) computing summary statistics; (c) assembling ReportSection objects containing the event details; (d) recording all ledger entry identifiers referenced; and (e) computing and signing the report.
[0011] Report Integrity: A ComplianceReport is signed by the reporting node using its P46 private key. The signature covers all fields in the report including ledger_references. Any modification to the report after signing is detectable. An auditor with the reporting node’s public key can verify the report’s integrity and confirm that each ledger_reference corresponds to an actual ledger entry.
[0012] Scheduled Reports: Nodes may configure a ReportSchedule specifying a report_type, report_period_length (daily, weekly, monthly, quarterly), delivery_endpoint (URL or AIEP channel identifier), and recipient_public_key (for encrypted delivery). Scheduled reports are generated automatically at the end of each period and signed before delivery.
[0013] Report Retention: Generated ComplianceReports are themselves logged in the COMPLIANCE_REPORTS partition of the dual ledger (P80), identified by report_id. This ensures that the history of what was reported to whom and when is itself part of the tamper-evident audit trail.
ASCII Architecture
Ledger Partitions (P80):
ACCESS_AUDIT │
CONFLICT_LOG │
DISPOSITION │ ──▶ ┌──────────────────────┐
PROVENANCE │ │ ReportGenerator │
QUERY_AUDIT │ │ (type-specific │
... │ │ assembly logic) │
└──────────┬───────────┘
│ ComplianceReport
▼
┌──────────────────────┐
│ Sign (P46 key) │
│ Store in COMPLIANCE │
│ REPORTS partition │
└──────────┬───────────┘
│
┌─────────────┴──────────────┐
│ │
▼ ▼
Regulatory Portal Internal Governance
(signed report) (via delivery endpoint)
Operational Detail
[0014] Custom Report Types: Operators may define custom ReportTypes by specifying a ledger query template and a report section assembler. Custom types must be registered in the node’s report type registry and cannot be named with reserved prefixes from the standard ReportType enumeration.
[0015] Redaction for Third-Party Reports: Where a ComplianceReport is destined for a third-party recipient who should not see internal node identifiers or operator names, the ReportGenerator supports a redact_internal_ids parameter. This replaces internal identifiers with opaque references while preserving the statistical and structural content of the report.
[0016] Cross-Node Reports: For organisations operating multiple AIEP nodes, a federated ComplianceReport can be assembled by a designated umbrella node that queries each subordinate node’s report data and consolidates it into a single report covering the full organisation. Subordinate node data is authenticated with each node’s signature before consolidation.
Claims-Exclusion Notice
This specification is published as open-source prior art. No patent claims are asserted by the author in respect of the mechanisms described. Any third party seeking to patent mechanisms substantially equivalent to those described herein is placed on notice of this prior art disclosure.