P199 — AIEP — Evidence Stack Completeness Certification 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

Framework Context

[0001] This specification is published as open-source prior art under the AIEP publication programme. It relates to the Architected Instruction and Evidence Protocol (AIEP) defined in United Kingdom patent application GB2519711.2 (filed 20 November 2025). All protocol mechanisms described herein are publicly disclosed as of the publication date above.

[0002] P199 defines the Evidence Stack Completeness Certification Protocol — the capstone of the AIEP Core Evidence Stack. P199 establishes a formal certification process by which an AIEP evidence deployment is assessed against the full mandatory protocol surface of the Evidence Stack (P10–P198) and issued an EvidenceStackCertificate attesting to which protocol layers are implemented, which are absent, and whether the deployment meets the minimum mandatory requirements for operational AIEP compliance.

[0003] P199 sits at the top of the AIEP Evidence Stack. All specifications from P10 through P198 define the protocol mechanisms that constitute the Evidence Stack. P199 occupies the certification and governance layer above those mechanisms, establishing the terms on which a deployment can be declared complete.

Field

[0004] This specification relates to completeness certification protocols for evidence infrastructure in deterministic artificial intelligence reasoning systems.

[0005] More particularly, P199 concerns: the EvidenceStackCertificate schema; the mandatory and optional protocol requirement taxonomy; the certification assessment methodology; certificate issuance, renewal, and revocation lifecycles; integration with governance (P89); integration with compliance reporting (P171); and the public EvidenceStack compliance registry.

Background

[0006] The AIEP Evidence Stack is a layered architecture of 189 protocol specifications spanning P10 through P198. These specifications define mechanisms for evidence normalisation, provenance, trust scoring, freshness, conflict resolution, semantic querying, structured search, snapshotting, synthesis, corroboration, and dozens of specialised evidence governance functions.

[0007] A deployment that implements only a subset of these protocols — omitting, for example, the dual-ledger memory substrate (P80) or the conflict record protocol (P161) — cannot be considered a compliant AIEP node. Operators and integrators require a formal mechanism for asserting and verifying that a given deployment has implemented the full required protocol surface, and for tracking which optional extensions have been added.

[0008] Without a certification protocol, there is no canonical mechanism for an operator to assert compliance, for a dependent system to verify compliance before connecting, or for a regulator to audit which protocol layers are present in a given deployment.

Summary

[0009] Evidence Stack Tier Classification: The Evidence Stack is partitioned into four compliance tiers:

• TIER-1 (Mandatory Core): Protocols without which no AIEP evidence operation is possible. A deployment lacking any TIER-1 protocol is non-compliant and may not be issued an EvidenceStackCertificate. TIER-1 protocols: P10, P17, P22, P38, P41, P46, P60 (one mirror minimum), P80, P89, P124, P133, P147, P150, P160, P161, P162.

• TIER-2 (Mandatory Extension): Protocols required for full evidence corpus governance but not for minimal operation. A deployment must implement all TIER-2 protocols to receive a FULL compliance certificate; absence of any TIER-2 protocol yields a PARTIAL certificate. TIER-2 protocols: P37, P42, P50, P83, P146, P148, P149, P151, P152, P153, P154, P156, P157, P158, P163, P164, P165, P166, P167, P168, P169, P170, P171, P172, P173, P174, P175, P176, P177, P179, P180, P182, P183, P184, P185, P186, P187, P189, P190, P191, P192, P193, P194, P195, P197, P198.

• TIER-3 (Governed Extension): Protocols that extend the stack with jurisdiction-specific or deployment-specific governance mechanisms. These are optional but must be implemented correctly if deployed. TIER-3 protocols: P155, P166, P173, P178, P181, P188, P193, P196.

• TIER-4 (Declared Optional): Advanced protocols implementations may deploy at their discretion. Presence is noted in the certificate but absence does not affect the compliance grade.

[0010] EvidenceStackCertificate Schema:

• certificate_id — SHA-256 of the canonical certificate payload
• node_fingerprint — fingerprint of the assessed AIEP node (P46)
• assessment_timestamp — ISO 8601 timestamp of the assessment
• compliance_grade — FULL | PARTIAL | NON_COMPLIANT (see [0011])
• tier1_status — COMPLETE | INCOMPLETE with list of missing TIER-1 protocols
• tier2_status — COMPLETE | INCOMPLETE with list of missing TIER-2 protocols
• tier3_deployed — list of TIER-3 protocols deployed (and their implementation versions)
• tier4_deployed — list of TIER-4 protocols deployed
• total_stack_coverage_pct — (implemented protocols / total stack) × 100
• certificate_valid_until — expiry date (default: 12 months from assessment)
• issued_by — identifying information for the issuing assessment agent
• certificate_signature — digital signature over the canonical certificate payload

[0011] Compliance Grade Assignment:

• FULL — All TIER-1 and TIER-2 protocols implemented and passing assessment checks
• PARTIAL — All TIER-1 protocols implemented; one or more TIER-2 protocols absent or failing
• NON_COMPLIANT — One or more TIER-1 protocols absent or failing

[0012] Assessment Methodology: The certification assessment is performed by submitting POST /evidence/certify to the target node. The assessment agent (which may be the node itself performing self-assessment, or an external AIEP certification authority) executes the following for each assessed protocol:

• Presence check: Queries GET /evidence/capabilities to confirm the protocol is declared implemented (see [0013])
• Functional check: Executes a standardised probe operation defined per protocol (e.g. for P161: submits a synthetic ConflictRecord and verifies it is correctly stored and retrievable; for P175: requests a hash integrity verification and confirms the response schema is correct)
• Schema conformance check: Validates that response payloads for each protocol conform to the published AIEP schema for that protocol Checks that fail are recorded in the failed_checks list of the ProtocolAssessmentResult for that protocol.

[0013] Capabilities Declaration: Every AIEP evidence node must expose GET /evidence/capabilities returning a CapabilitiesManifest:

• node_fingerprint — P46 fingerprint
• stack_version — the AIEP release version this deployment targets
• implemented_protocols — array of protocol numbers (e.g. [10, 17, 22, 38, ...]) declared implemented
• implementation_versions — map of protocol number to implementation version string
• partial_implementations — protocols implemented partially (e.g. core schema only, no full functional implementation), with explanation
• planned_implementations — protocols planned but not yet implemented, with target dates

[0014] Certificate Lifecycle: Certificates are valid for 12 months by default. Certificates are automatically revoked if:

• A subsequent assessment reveals a TIER-1 protocol has ceased functioning
• The node’s P46 fingerprint changes without a documented node migration (per P99 hardware migration)
• The node operator requests revocation
• A security vulnerability is discovered that compromises a TIER-1 protocol implementation

[0015] Public Compliance Registry: AIEP deployments may opt to register their EvidenceStackCertificate with a public AIEP Compliance Registry (a distributed ledger per P80 dual-ledger architecture). The registry enables third parties — integrators, regulators, dependent reasoning chains — to verify the compliance status of a node before connecting or accepting evidence from it. Registration is voluntary but recommended for production deployments.

[0016] Integration with Audit Reporting: The compliance certificate is referenced in Evidence Audit Reports (P171) generated by a node. An audit report produced by a node with a current FULL compliance certificate carries a higher assurance rating than one produced by a PARTIAL or uncertified node.

[0017] Stack Completeness Summary: Table of the full Evidence Stack covered by P199 certification:

ASCII Architecture

Target AIEP Evidence Node
        │
        ▼
GET /evidence/capabilities
  CapabilitiesManifest:
    implemented_protocols[]
    implementation_versions{}
    partial_implementations[]
        │
        ▼
Assessment Probes (per protocol)
  Presence check → capability declared?
  Functional check → probe operation succeeds?
  Schema check → response conforms to spec?
        │
        ▼
ProtocolAssessmentResult[] (one per protocol)
  protocol_id
  tier
  status: PASS | FAIL | ABSENT | PARTIAL
  failed_checks[]
        │
        ▼
EvidenceStackCertificate
  compliance_grade: FULL | PARTIAL | NON_COMPLIANT
  ┌─────────────────────────────────────────────┐
  │ FULL: all T1 + T2 pass                      │
  │ PARTIAL: all T1 pass, ≥1 T2 absent/fail     │
  │ NON_COMPLIANT: ≥1 T1 absent/fail            │
  └─────────────────────────────────────────────┘
  total_stack_coverage_pct
  certificate_valid_until (+12 months)
  certificate_signature
        │
  ┌─────┼──────────────────────────────┐
  │     │                              │
  ▼     ▼                              ▼
Audit Reports   Public Compliance   Dependent
(P171)          Registry (P80)      Systems
assurance       voluntary           verify before
rating          registration        connecting

Operational Detail

[0018] Incremental Certification: Operators may request a targeted incremental assessment for a specific tier only (e.g. POST /evidence/certify?tier=TIER2) after adding new protocol implementations, rather than running the full assessment. The incremental result is merged with the existing certificate, extending validity for updated tiers while preserving existing tier assessments.

[0019] Self-Certification vs. Third-Party Certification: In development and test deployments, nodes may perform self-certification (the node itself executes the assessment probes against its own endpoints). In production deployments connecting to critical reasoning chains, third-party certification by a designated AIEP Certification Authority is recommended. The issued_by field of the certificate distinguishes self-certified from third-party-certified certificates.

[0020] Minimum Viable AIEP Evidence Node: An AIEP evidence node implementing all TIER-1 protocols and a minimum subset of TIER-2 protocols (specifically: P37, P42, P50, P83, P146, P147, P148, P150, P151, P163, P165, P185) receives the designation AIEP-MVN (Minimum Viable Node) — a sub-grade of PARTIAL compliance intended for constrained-resource deployments (e.g. edge nodes). The AIEP-MVN designation is recorded in the compliance_grade_detail field of the certificate.

[0021] Stack Evolution: As the AIEP Evidence Stack evolves beyond P199, new protocols added to the stack are assigned a tier classification and incorporated into the certification assessment in future releases of this protocol. The stack_version field of the CapabilitiesManifest and the EvidenceStackCertificate enables assessors to apply the correct tier taxonomy for the protocol version a node targets.

Claims-Exclusion Notice

This specification is published as open-source prior art. No patent protection is sought for the mechanisms described herein. Publication is intended to establish priority date for prior art and to prevent third parties from obtaining patent protection over these mechanisms. The specification is released under the Apache License 2.0.