Technical note published Sep 15, 2026

Trusted Knowledge Freshness and Continuous Reverification Foundation

KESPA established the database foundation for freshness-aware Trusted Knowledge and documented a configurable continuous-reverification lifecycle. Freshness state now exists on trusted knowledge, a knowledge_refresh_jobs queue exists, and the existing supersession/versioning path can be reused; policy configuration, scheduling, evidence reacquisition, change detection, stale-on-retrieval behavior, Admin controls, and refresh telemetry remain planned at this checkpoint.

trusted-knowledge freshness reverification supersession knowledge-lifecycle rag

MARKDOWN

README.md

6,241 bytes SHA-256 3f52597deebd048b…

KESPA-NOTE-024 — Trusted Knowledge Freshness and Continuous Reverification Foundation

Type: Technical Note Date: 2026-09-15 Status: published

Summary

KESPA has begun extending Trusted Knowledge from a promotion-only lifecycle into a freshness-aware lifecycle that can distinguish durable knowledge from time-sensitive knowledge and eventually reverify it without repeatedly researching every known fact.

At this checkpoint, the database foundation is complete: trusted_knowledge has freshness-related state, knowledge_refresh_jobs exists, and KESPA's existing supersession/versioning mechanism can be reused when a trusted claim materially changes. The policy layer, scheduler/queueing worker, evidence reacquisition, comparison logic, stale-on-retrieval behavior, Admin controls, and refresh telemetry remain planned next-stage work.

This note intentionally documents the boundary between what is complete and what is still design/implementation work. It does not claim that continuous reverification is operational yet.

Research / Technical Motivation

A verified knowledge system has two competing goals:

1. Reuse previously verified knowledge quickly rather than researching the same fact on every request.

2. Avoid treating time-sensitive knowledge as permanently true after its original verification.

The proposed lifecycle is:

``text Don't know → acquire evidence → verify → Trusted Knowledge → RAG reuse → scheduled freshness checks → refresh / supersede / hold → continue serving current verified knowledge ``

The design therefore separates knowledge reuse from knowledge freshness. RAG can remain the fast path for known claims, while freshness policy determines when a claim must be checked again.

Freshness Classes

The supplied design defines six freshness classes:

| Class | Intended role | |---|---| | static | Knowledge expected to change rarely or effectively never under normal operation. | | slow | Knowledge that may change, but normally on long timescales. | | volatile | Knowledge expected to require recurring reverification. | | highly_volatile | Knowledge where short freshness windows may be appropriate. | | event_driven | Knowledge refreshed in response to a relevant event rather than only a fixed interval. | | manual | Knowledge refreshed only through an explicit human/system action. |

The exact refresh intervals are intentionally not hard-coded in this note. The plan is for them to live in brain_config / Admin so policy can be tuned without altering core runtime mechanics.

Completed Foundation at This Checkpoint

Directly recorded as complete in the supplied project update:

Freshness-related state has been added to trusted_knowledge.
A knowledge_refresh_jobs queue table exists.
Existing trusted-knowledge supersession/versioning can be reused for refreshed claims.

These changes establish the persistence layer needed for later scheduling and reverification.

Planned Refresh Lifecycle

The remaining planned lifecycle is:

1. Freshness policy

Define class-specific policy in brain_config / Admin.
Track verification time, next refresh time, interval/state, attempts, and failures.

2. Scheduler / queueing

Find trusted rows that are due under current policy.
Queue bounded refresh jobs in knowledge_refresh_jobs.

3. Evidence reacquisition

Prefer authoritative sources and APIs where appropriate.
Allow web discovery and external/Groq assistance when appropriate to the existing evidence policy.

4. Claim comparison

Compare newly verified evidence with the currently trusted claim.

5. Outcome handling

Unchanged: refresh verification/freshness timestamps without creating unnecessary new knowledge.
Changed: create a newly verified claim and connect history through the existing supersession mechanism.
Conflict / insufficient evidence: hold for review instead of silently replacing trusted knowledge.

6. Indexing behavior

Re-index Chroma only when the trusted knowledge materially changes.
Avoid churn when reverification confirms the existing claim.

7. Stale-on-retrieval behavior

Requests containing freshness-sensitive intent such as “latest” or “current” may trigger revalidation when the trusted claim is stale or otherwise due.

8. Operational visibility

Admin views for freshness state, overdue knowledge, queued refreshes, failures, conflicts, and manual reverification.
Telemetry for refresh frequency, latency, provider usage, cost, unchanged-vs-changed outcomes, and knowledge reuse.

Supersession Model

A material change should not overwrite history in place. The design reuses the existing trusted-knowledge versioning boundary:

``text old trusted claim → status = superseded → new verified claim → supersedes_knowledge_id = prior knowledge row ``

This preserves lineage and allows KESPA to distinguish “previously verified but no longer current” from “never trusted.”

Re-indexing Boundary

The proposed indexing rule is deliberately narrow:

```text reverification confirms same trusted claim → update freshness metadata → no material Chroma rewrite

reverification produces materially changed trusted claim → promote/supersede → re-index affected trusted knowledge ```

This keeps the rebuildable retrieval index aligned with authoritative Trusted Knowledge while avoiding unnecessary index churn.

Validation Boundary

No database dump, migration SQL, scheduler execution, refresh-job run, provider trace, changed-claim example, conflict example, or end-to-end reverification result was supplied for this artifact.

Accordingly:

The database foundation is recorded as completed project state.
The continuous reverification architecture is documented design.
The scheduler and full refresh lifecycle are not claimed operational.
Status is therefore published, not verified.

Next Recorded Implementation Step

The supplied project update identifies the next implementation step as:

``text freshness policy in brain_config / Admin + scheduler / queueing worker ``

TEXT

SHA256SUMS.txt

393 bytes SHA-256 64c0534d05adff97…

3f52597deebd048bec2c26379b0a48634d036a5ddd1037d7e086bacf5202d18c  README.md
52a657d29ae2cc7dcf985abb933ac41709a2b4cfe1825037f3490a973b5193e5  note.json
c15c0d1ff4e18bd3ab5c4985e22cb47abac89be0075c3aabc6e0377356a1843d  metrics.csv
9e76dd38d06fee41fb386351354e9b9202f48ba0fb2a2090a73812e62868e8b4  methodology.md
0f89e0d231256711089c646a1160ab38b8b9a37f76c593a428289696807531de  provenance.json

MARKDOWN

methodology.md

3,086 bytes SHA-256 9e76dd38d06fee41…

Methodology

Purpose

This artifact converts a KESPA implementation/Jira update into a public technical record while preserving the distinction between completed foundation work and future lifecycle design.

Source Handling

The supplied raw update was treated as the factual source of truth. Duplicate text in the dump was deduplicated before packaging.

The artifact was compared against the existing public manifest. The closest existing records describe:

autonomous trusted-knowledge promotion,
trusted research release promotion,
trusted-knowledge indexing and private-data exclusion,
autonomous natural research-gap acquisition,
and the public research archive.

None of those entries documents post-promotion freshness policy, scheduled reverification, change detection, or supersession-on-refresh as its primary technical purpose. This lifecycle was therefore treated as a materially distinct technical note rather than an update to an existing package.

Classification

The package is classified as technical_note because the supplied material primarily documents architecture, persistence foundations, policy boundaries, and an implementation plan rather than a completed controlled experiment or benchmark.

The status is published, not verified, because the source states that the database foundation is complete but does not include live schema output, scheduler execution, queued job output, refresh-worker traces, or end-to-end reverification results.

Recorded vs Derived Content

Directly recorded

Trusted Knowledge freshness lifecycle is the module goal.
Six named freshness classes are planned.
Database foundation is complete.
trusted_knowledge has freshness-related state.
knowledge_refresh_jobs exists.
Existing supersession/versioning can be reused.
Freshness policy belongs in brain_config / Admin rather than hard-coded runtime intervals.
The next implementation step is policy configuration plus scheduler/queueing.
Planned outcomes include unchanged refresh, changed-claim supersession, review holds, material-change re-indexing, stale-on-retrieval checks, Admin visibility, and telemetry.

Derived

freshness_classes_defined = 6, obtained by counting the six explicitly named classes.

No other numerical performance, cost, latency, provider, or refresh metrics were derived because the source did not provide execution data.

Publication Safety

No credentials, prompts, user data, raw telemetry, private source code, API secrets, IP addresses, or private evidence bodies were included.

Validation Limitations

This artifact does not establish that:

any refresh interval has been configured,
any scheduler has run,
any refresh job has been queued or processed,
any evidence has been reacquired,
any trusted claim has been refreshed or superseded through this module,
any conflict has been held for review,
or any Chroma record has been re-indexed through a freshness event.

Those results should become future artifacts only after concrete execution evidence exists.

CSV

metrics.csv

846 bytes SHA-256 c15c0d1ff4e18bd3…

metric,value,unit,status,notes
freshness_classes_defined,6,classes,derived,"Counted from the six explicitly listed policy classes: static, slow, volatile, highly_volatile, event_driven, manual."
database_foundation_complete,1,boolean,recorded,"Project update states the DB foundation is complete."
trusted_knowledge_freshness_state_present,1,boolean,recorded,"Project update states trusted_knowledge now has freshness fields; exact live schema was not supplied."
knowledge_refresh_jobs_table_present,1,boolean,recorded,"Project update states knowledge_refresh_jobs exists."
existing_supersession_system_reusable,1,boolean,recorded,"Project update states existing supersession/versioning can be reused."
continuous_reverification_end_to_end_verified,0,boolean,boundary,"No end-to-end reverification execution evidence was supplied in this batch."

JSON

note.json

1,692 bytes SHA-256 52a657d29ae2cc7d…

{
    "id": "KESPA-NOTE-024",
    "type": "technical_note",
    "title": "Trusted Knowledge Freshness and Continuous Reverification Foundation",
    "date": "2026-09-15",
    "status": "published",
    "summary": "KESPA established the database foundation for freshness-aware Trusted Knowledge and documented a configurable continuous-reverification lifecycle. Freshness state now exists on trusted knowledge, a knowledge_refresh_jobs queue exists, and the existing supersession/versioning path can be reused; policy configuration, scheduling, evidence reacquisition, change detection, stale-on-retrieval behavior, Admin controls, and refresh telemetry remain planned at this checkpoint.",
    "freshness_classes": [
        "static",
        "slow",
        "volatile",
        "highly_volatile",
        "event_driven",
        "manual"
    ],
    "completed_at_checkpoint": {
        "trusted_knowledge_freshness_foundation": true,
        "knowledge_refresh_jobs_table": true,
        "existing_supersession_versioning_reusable": true
    },
    "not_yet_claimed_operational": [
        "brain_config_admin_freshness_policy",
        "scheduler_queueing_worker",
        "evidence_reacquisition_worker",
        "claim_change_comparison",
        "automatic_unchanged_refresh",
        "automatic_changed_claim_supersession",
        "conflict_or_insufficient_evidence_hold_flow",
        "material_change_chroma_reindex",
        "stale_on_retrieval_revalidation",
        "freshness_admin_views_and_manual_reverify",
        "refresh_telemetry"
    ],
    "next_recorded_step": "freshness policy in brain_config / Admin plus scheduler/queueing worker",
    "tags": [
        "trusted-knowledge",
        "freshness",
        "reverification",
        "supersession",
        "knowledge-lifecycle",
        "rag"
    ]
}

JSON

provenance.json

2,644 bytes SHA-256 0f89e0d231256711…

{
    "artifact_id": "KESPA-NOTE-024",
    "source_material": [
        {
            "type": "user_provided_project_update",
            "description": "Raw KESPA Trusted Knowledge Freshness & Continuous Reverification overview, scope/plan, primary goal, and current-status checkpoint supplied for public artifact packaging on 2026-09-15."
        },
        {
            "type": "existing_public_manifest",
            "description": "Authoritative KESPA public manifest supplied in the same packaging session and used for ID allocation and deduplication."
        }
    ],
    "directly_recorded_facts": [
        "The DB foundation is complete.",
        "trusted_knowledge now has freshness-related fields/state.",
        "knowledge_refresh_jobs exists.",
        "The existing supersession/versioning system can be reused.",
        "The design names six freshness classes: static, slow, volatile, highly_volatile, event_driven, and manual.",
        "Freshness policy is intended to live in brain_config / Admin rather than hard-coded intervals.",
        "The next implementation step is freshness policy plus scheduler/queueing worker."
    ],
    "derived_values": [
        {
            "name": "freshness_classes_defined",
            "value": 6,
            "formula": "count(static, slow, volatile, highly_volatile, event_driven, manual)"
        }
    ],
    "interpretations": [
        "The freshness lifecycle is materially distinct from existing public artifacts focused on initial acquisition, promotion, release, indexing, and retrieval because its primary concern is post-promotion validity over time.",
        "The current source supports publication of the architecture/foundation but not a verified claim that continuous reverification is operational end to end."
    ],
    "validation_boundary": {
        "recorded_complete": [
            "database foundation",
            "freshness-related trusted_knowledge state",
            "knowledge_refresh_jobs table",
            "reuse of existing supersession/versioning mechanism"
        ],
        "not_independently_demonstrated_in_source": [
            "exact live database schema",
            "configured refresh intervals",
            "scheduler execution",
            "queued refresh job execution",
            "evidence reacquisition",
            "unchanged-claim refresh",
            "changed-claim supersession",
            "conflict hold behavior",
            "freshness-driven Chroma reindex",
            "stale-on-retrieval revalidation",
            "Admin freshness controls",
            "refresh telemetry"
        ]
    },
    "publication_exclusions": [
        "credentials and secrets",
        "private user information",
        "raw telemetry",
        "prompts and conversation contents",
        "private application source code",
        "security-sensitive implementation details"
    ]
}