P182 — AIEP — Evidence Mirror Health and Availability 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 continuously monitoring the health, replication lag, content integrity, and service availability of mirror nodes (P60–P63) holding copies of the AIEP evidence corpus — producing MirrorHealthReports that enable evidence routing logic to select healthy mirrors and detect degraded or diverged mirrors before they serve stale or corrupted evidence to reasoning chains.

Field of the Disclosure

[0003] This disclosure relates to distributed health monitoring and availability management protocols for evidence corpus mirror networks in governed artificial intelligence systems.

[0004] More particularly, the disclosure concerns: a MirrorHealthRecord schema; health probe mechanisms; replication lag measurement; corpus integrity comparison using HashChainCertificates (P175); availability classification; mirror routing guidance; alert generation on health degradation; and the relationship of this Protocol to the federated evidence network standard (P156) and the cross-node replication protocol (P169).

Background

[0005] Mirror nodes (P60–P63) provide geographic distribution, resilience, and load balancing for evidence retrieval. A reasoning chain that routes queries to degraded mirrors risks receiving stale evidence (high replication lag), corrupt evidence (corpus integrity deviation), or no evidence (availability failure). Without a governed health monitoring mechanism, the mirror network degrades silently and evidence retrieval quality deteriorates without visible signal.

[0006] Health monitoring must be lightweight (not materially impacting mirror throughput), continuous (detecting outages quickly rather than on next query), and cryptographically grounded (using HashChainCertificates rather than sample-based integrity probes that could miss targeted corruptions).

Summary of the Disclosure

[0007] MirrorHealthRecord Schema: A health snapshot for a single mirror node, produced by the health monitoring process:

• health_record_id — SHA-256 of canonical serialisation
• mirror_node_id — the node fingerprint (P46) of the mirror being assessed
• assessed_at — ISO 8601 timestamp
• availability_status — AVAILABLE, DEGRADED, UNAVAILABLE
• replication_lag_seconds — the measured lag in seconds between the primary corpus ChainHead (P175) entry index and the mirror’s ChainHead entry index; zero indicates the mirror is fully synchronised
• corpus_integrity_status — VERIFIED (HashChainCertificate (P175) from mirror matches primary), DEVIATED (certificate mismatch), UNVERIFIED (certificate not yet received in this assessment cycle)
• last_certificate_received_at — timestamp of last received HashChainCertificate from this mirror
• availability_probe_latency_ms — round-trip time in milliseconds of the most recent availability probe
• error_rate_last_hour — fraction of evidence queries to this mirror that returned errors in the last hour
• health_score — computed composite score in [0.0, 1.0] (see [0008])
• health_classification — HEALTHY (score ≥ 0.8), DEGRADED (0.5–0.79), CRITICAL (< 0.5)

[0008] Health Score Computation: The composite health_score is computed as:

• availability_component = 1.0 if availability_status: AVAILABLE; 0.5 if DEGRADED; 0.0 if UNAVAILABLE — weight: 0.4
• lag_component = max(0.0, 1.0 - (replication_lag_seconds / max_acceptable_lag)) where max_acceptable_lag is configurable (default: 300 seconds) — weight: 0.3
• integrity_component = 1.0 if corpus_integrity_status: VERIFIED; 0.5 if UNVERIFIED; 0.0 if DEVIATED — weight: 0.3
• health_score = (0.4 × availability_component) + (0.3 × lag_component) + (0.3 × integrity_component)

[0009] Health Probe Mechanisms: The health monitoring process executes three probe types on each assessment cycle:

• Availability Probe — a minimal HTTP HEAD request to the mirror’s evidence API health endpoint; response within configured timeout (default: 5 seconds) = AVAILABLE; timeout = UNAVAILABLE; 5xx response = DEGRADED
• Replication Lag Probe — a query to the mirror for its current HashChain ChainHead entry index; compared against the primary’s current ChainHead; difference = replication lag in entries (converted to seconds based on admission rate)
• Integrity Probe — request the mirror’s most recent HashChainCertificate (P175); verify its chain_head_digest against the primary’s stored certificate for the same chain_head_index

[0010] Assessment Schedule: By default, health probes are executed every 60 seconds per mirror. The MirrorHealthMonitor maintains a health history for each mirror, retaining the last 24 hours of MirrorHealthRecords (retaining one record per completed assessment cycle).

[0011] Mirror Routing Guidance: The MirrorHealthMonitor publishes a MirrorRoutingTable to the evidence routing layer — a ranked list of mirrors sorted by health_score (descending). The routing layer uses this table to direct evidence queries preferentially to the healthiest mirrors. Mirrors with health_classification: CRITICAL are excluded from the routing table until they recover to DEGRADED or better.

[0012] MirrorHealthAlert: When a mirror’s health_classification transitions from HEALTHY to DEGRADED or from DEGRADED to CRITICAL, a MirrorHealthAlert is generated and published to: the corpus operator dashboard; the governance node (P89); and the Watch Protocol (P180) for any subscribers watching mirror health events. The alert includes the mirror node ID, the previous and new health classifications, and the contributing factor (availability, lag, or integrity).

ASCII Architecture

MirrorHealthMonitor (every 60s per mirror)
        │
        ├── Availability Probe (HTTP HEAD)
        ├── Replication Lag Probe (ChainHead index query)
        └── Integrity Probe (HashChainCertificate verify, P175)
        │
        ▼
MirrorHealthRecord
(availability, lag_seconds, integrity_status, health_score)
        │
        ├──▶ MirrorRoutingTable (ranked by health_score)
        │    └── Routing Layer: prefer HEALTHY mirrors
        │        exclude CRITICAL mirrors
        │
        ├──▶ MirrorHealthAlert (on classification transition)
        │    └── Operator Dashboard / Governance Node (P89)
        │        Watch Protocol (P180) subscribers
        │
        └──▶ Corpus health report (P172)

Operational Detail

[0013] Cascade Failure Detection: If multiple mirrors simultaneously degrade to UNAVAILABLE, the MirrorHealthMonitor raises a CascadeFailureAlert — indicating a systemic event (e.g. network partition, coordinated failure) rather than individual mirror failures. The governance node (P89) is notified immediately. The primary corpus node increases its own availability probe frequency to detect its own status.

[0014] Mirror Recovery Cycle: When a mirror that was CRITICAL or UNAVAILABLE becomes available again, the replication protocol (P169) executes a catch-up sync to close the replication lag. The mirror is not restored to the MirrorRoutingTable until its health_score ≥ 0.8 and the corpus_integrity_status: VERIFIED for at least two consecutive assessment cycles.

[0015] Integrity Deviation Response: If a mirror’s corpus_integrity_status is DEVIATED, the HashChain binary search protocol (P175 [0017]) is executed to identify the first divergence point. The mirror is removed from the MirrorRoutingTable and a full replication resync is triggered. If the divergence cannot be explained by replication lag, a HashChainDeviationRecord (P175) is filed and the mirror is held out of service until the deviation is resolved.

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.