P163 — AIEP — Evidence Volatility and Stability Classification 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 classifying evidence artefacts by the frequency and magnitude at which their underlying source content changes — their volatility — producing a VolatilityClass assignment that governs caching policy, refresh scheduling, reasoning validity bounds, and streaming subscription priority across AIEP-governed evidence infrastructure.

Field of the Disclosure

[0003] This disclosure relates to evidence volatility assessment and stability classification protocols for governed artificial intelligence reasoning systems.

[0004] More particularly, the disclosure concerns a VolatilityClass enumeration, a VolatilityProfiler component that determines VolatilityClass from source type signals and empirical change history, a VolatilityRecord schema, interaction with the Evidence Freshness Decay model (P147), cache policy assignment, and integration with the Real-Time Evidence Streaming Protocol (P158) for adaptive subscription priority.

Background

[0005] Not all evidence artefacts change at the same rate. A published peer-reviewed journal article is typically static after publication; it may be corrected or retracted but its content does not change day-to-day. A government statistics dataset may be updated monthly. A financial market data feed updates in milliseconds. A weather observation record updates continuously. A mathematical theorem proof is, in principle, permanently stable.

[0006] The AIEP Evidence Freshness Decay model (P147) defines how confidence in an artefact decays over time based on its age since last verification. However, freshness decay parameters must be tuned to the actual volatility of the source: a static published article should not trigger aggressive re-fetching, whereas a live data feed should always be assumed to have changed. Without a formal volatility classification, freshness decay parameters are applied uniformly, producing either wasteful re-fetching of static content or stale reasoning about live content.

[0007] Volatility classification must be both assignable at ingestion time from source type signals (for a reasonable initial estimate) and refinable empirically over time as observed change frequency data accumulates. An artefact initially classified as LOW volatility that is subsequently observed to change frequently should be reclassified upward without discarding ingestion-time metadata.

Summary of the Disclosure

[0008] VolatilityClass Enumeration: Five mutually exclusive volatility classes are defined:

• STATIC — content is permanently fixed after publication (peer-reviewed articles post-acceptance, enacted legislation, formally published standards, mathematical proofs). Re-fetch only on explicit retraction or correction signal.
• LOW — content changes infrequently, typically annually or less (annual government reports, edition-based textbooks, stable reference datasets). Re-fetch at 90-day intervals.
• MEDIUM — content changes regularly on a scheduled basis (monthly or quarterly datasets, periodically revised policy documents). Re-fetch at 14-day intervals.
• HIGH — content changes frequently or continuously (news feeds, daily government bulletins, frequently revised regulatory guidance). Re-fetch at 24-hour intervals.
• LIVE — content is a real-time or near-real-time data stream (financial data, sensor telemetry, live event feeds). Do not cache; subscribe via streaming protocol (P158) within 60-second event latency.

[0009] VolatilityRecord Schema: A VolatilityRecord is attached to each EvidenceNode:

• volatility_class — from the VolatilityClass enumeration
• volatility_source — INFERRED (from source type signals at ingestion), EMPIRICAL (from observed change history), or MANUAL (human override)
• observed_change_count — count of content changes detected across re-fetch verifications
• observation_period_days — number of days over which change observations were made
• last_observed_change — ISO 8601 timestamp of the most recently detected content change
• next_scheduled_refetch — ISO 8601 timestamp of the next scheduled verification fetch
• assigned_at — ISO 8601 timestamp of most recent classification update

[0010] VolatilityProfiler: The VolatilityProfiler assigns an initial VolatilityClass at ingestion using source type signals:

• Source URL domain patterns known to be academic journals → STATIC
• Source URL paths containing /live/, /stream/, /realtime/ → LIVE
• Evidence Taxonomy Temporal Class (P160) TC.PERM → STATIC, TC.LIVE → LIVE
• Evidence Quality Tier (P160) EQ.T1 peer-reviewed with citation.year < current year → STATIC
• citation_type = DATASET with no explicit update schedule → MEDIUM
• Web pages (citation_type = WEB_PAGE) → HIGH by default

Where no specific signal matches, the default initial classification is MEDIUM.

[0011] Empirical Reclassification: Each time a scheduled re-fetch returns an updated content_hash_raw for an artefact, the observed_change_count is incremented. After a minimum of 30 days of observation, the VolatilityProfiler computes empirical_change_rate = observed_change_count / observation_period_days and reassigns VolatilityClass according to the following thresholds:

• < 0.01 changes/day → STATIC
• 0.01 – 0.07 changes/day → LOW
• 0.07 – 0.30 changes/day → MEDIUM
• 0.30 – 1.0 changes/day → HIGH
• > 1.0 changes/day → LIVE

Reclassification updates the VolatilityRecord with volatility_source = EMPIRICAL and adjusts the next_scheduled_refetch according to the new class’s re-fetch interval.

[0012] Freshness Decay Integration: The Evidence Freshness Decay model (P147) uses the VolatilityClass to set the half-life parameter of the confidence decay function:

• STATIC → half-life = 3,650 days (10 years)
• LOW → half-life = 365 days (1 year)
• MEDIUM → half-life = 90 days
• HIGH → half-life = 14 days
• LIVE → half-life = 0.1 days (2.4 hours; streaming subscriptions reset the clock on each event)

[0013] Streaming Priority Integration: The StreamBroker (P158) uses VolatilityClass as an input to subscription priority assignment: LIVE and HIGH artefacts receive highest streaming priority; STATIC artefacts are excluded from streaming subscriptions entirely (change notifications for STATIC artefacts are delivered via retraction or correction signals rather than continuous streaming).

ASCII Architecture

EvidenceNode (ingested)
        │
        ▼
┌───────────────────────┐
│  VolatilityProfiler   │◀── Source type signals
│  (initial INFERRED    │    URL patterns, TC code,
│   classification)     │    EQ tier, citation_type
└──────────┬────────────┘
           │ VolatilityClass (initial)
           ▼
┌───────────────────────┐
│  VolatilityRecord     │──▶ EvidenceNode.volatility
│  attached to Node     │
└──────────┬────────────┘
           │ (over time)
           ▼
┌───────────────────────┐
│  Empirical Refetch    │    content_hash changed?
│  Scheduler            │──▶ increment change_count
│  (class intervals)    │    reclassify after 30 days
└──────────┬────────────┘
           │ VolatilityClass (EMPIRICAL)
           ▼
┌───────────────┐    ┌─────────────────┐    ┌──────────────────┐
│ Freshness     │    │  Cache Policy   │    │  Stream          │
│ Decay (P147)  │    │  Assignment     │    │  Priority (P158) │
│ half-life adj │    │  (refetch sched)│    │  LIVE/HIGH first │
└───────────────┘    └─────────────────┘    └──────────────────┘

Operational Detail

[0014] STATIC Verification Trigger: Although STATIC artefacts are not scheduled for periodic re-fetch, they are verified when: (a) a DEIDInvalidationNotice (P162) is received for the artefact’s DEID; (b) a retraction or conflict signal (P161) references the artefact; or (c) more than 3,650 days have elapsed since last verification. This ensures even STATIC artefacts are eventually re-verified.

[0015] Governance Override: System operators may manually set a VolatilityClass override with volatility_source = MANUAL, which takes precedence over both INFERRED and EMPIRICAL assignments and suppresses automatic reclassification. Manual overrides are recorded in the ledger (P80) with the operator identity and justification.

[0016] Downward Reclassification: Empirical reclassification may reduce as well as increase VolatilityClass. An artefact initially classified as HIGH that is observed to have changed fewer than 0.07 times per day over a 90-day window is reclassified to MEDIUM, reducing unnecessary re-fetch overhead.

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.