KESPA is an active NexLabs Studios research platform exploring whether smaller local models can gain practical
capability through verified knowledge, retrieval, memory, selective escalation, and adaptive research.
This archive is the public record of what we test, what worked, and what still needs proof.
3Verified research releases
11Verified claims in releases
5Evidence records in releases
37Published archive entries
Research boundary
Published KESPA results are scoped to the configuration, hardware, datasets, and policies used in each
experiment. Individual results do not establish broad superiority over frontier systems or universal cost savings.
Public research repository
Published archive
Selected experiments, benchmarks, technical notes, datasets, and project updates are versioned separately
from the private KESPA application repository and synchronized into this public archive.
Technical note
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.
Public Research Archive and Immutable Revision Sync
KESPA established a public research repository and website bridge that publishes experiments, benchmarks, technical notes, datasets, and updates through a manifest-driven archive. The sync path resolves GitHub main to an immutable commit SHA before fetching the manifest and artifacts, eliminating stale branch-CDN reads and ensuring each sync uses one consistent repository revision.
Fail-Closed Web Discovery and Evidence Qualification Pipeline
KESPA's autonomous research worker separates discovery from evidence, directly fetches candidate sources, rejects unsafe/off-topic/blocked material, requires independent organizations, and refuses high-stakes/private/volatile topics from durable autonomous learning. The validated Cuckoo-filter run accepted three independent sources while rejecting multiple unsuitable candidates and completed with four verified claims.
Signed Cross-Host Research Queue and Durable Handoff Architecture
KESPA split autonomous research across the application server and home research server using pull-based HTTPS, HMAC SHA-256 request authentication, nonce replay protection, durable filesystem queues, signed release handoff, and resumable delivery state. The design keeps the home server off the public inbound path while allowing queued research and completed releases to survive process restarts and host reboots.
Telemetry-Backed User Profiles, Community Scoring, and Privacy Controls
KESPA added complete authenticated profiles, historical usage analytics, milestones, a 182-day activity history, community leaderboards, KESPA Score v2, and opt-in public profiles using existing persisted telemetry rather than a second analytics pipeline. The design keeps prompts, answers, private memories, request diagnostics, and user/community statistics out of NexLedger.
KESPA operationalized a natural knowledge-gap research path that detects low-confidence public-knowledge gaps during normal use, queues isolated research jobs, gathers multi-source evidence, verifies claims, imports approved releases, promotes trusted knowledge, indexes it locally, and records provenance through NexLedger without modifying the legacy/manual lifecycle.
KESPA detected a live knowledge gap during normal use, researched the missing concept from multiple independent public sources, verified four claims, promoted the result to trusted knowledge, indexed it for retrieval, and recorded provenance through NexLedger.
Trusted Knowledge Indexing Boundary and Private-Data Exclusion
KESPA introduced an authenticated trusted-knowledge indexing path that allows promoted public knowledge to enter the live Chroma retrieval index while blocking internal/private plaintext indexing. MySQL trusted_knowledge remains authoritative and Chroma remains a rebuildable search index; the first promoted trusted record was confirmed live, increasing the clean production index from 423 to 424 cards.
KESPA validated a research-release path that turns audited evidence and verified claims into a gated trusted-knowledge release, imports it as a research candidate, promotes it to trusted knowledge, indexes it for live Brain retrieval, and records the result through NexLedger. A systemd release completed the full path without modifying the existing NexLedger worker.
Automated Research Evidence Capture and NexLedger Attestation
KESPA operationalized an hourly cross-host evidence pipeline that reads closed telemetry from the RTX 3070 Brain machine, aggregates it on the research/home server, submits safe MET evidence through a signed intake, records the event in MySQL, and lets the generic worker attest it to NexLedger. The same automation watches future completed benchmark runs for BM evidence.
KESPA operationalized an end-to-end trusted-knowledge lifecycle for manually trained public knowledge: synthesis, candidate creation, evidence collection, local verification, policy-gated approval, trusted-knowledge promotion, and live local indexing. Autonomous publication was separated from human approval through explicit system-policy audit metadata.
Autonomous Trust Policy v0.1 to v0.2 Backlog Reclassification
KESPA relaxed one auto-publication condition from two supporting evidence items to one while retaining verification, confidence, consensus, and zero-conflict requirements. Applying the policy change to the existing backlog made 29 previously held candidates eligible without rerunning evidence collection or local verification, raising projected backlog autonomy from 36.7% to approximately 95.9%.
KESPA replaced the legacy ~441k-card production retrieval corpus with the clean 423-claim verified baseline, preserved memory collections separately, validated known-claim retrieval at rank #1, and established trusted_knowledge as the authoritative knowledge store with Chroma as a rebuildable search index.
Public-Only External Intelligence Refinery and Budgeted Cloud Analysis
KESPA introduced an optional external-intelligence refinery that sends only explicitly classified public_external/public_benchmark tasks to Groq, retains all provider output as non-authoritative candidate analysis, enforces daily request/token budgets and rate-limit backoff, and persists queue/results/provenance locally. A desktop validation completed four Groq 120B analyses and exposed the provider's 8K TPM limit; the worker was then made rate-aware. A later Windows-service wrapper was prepared for the always-on home server but had not yet received a user-environment SCM validation at the recorded checkpoint.
KESPA V2 Research Program: Verified Intelligence and Adaptive Compute
KESPA V2 formalized the research direction emerging from the completed A/B/C benchmark: verified externalized intelligence and fast trusted retrieval as the default path, adaptive orchestration only when justified, explicit separation of evidence/knowledge/memory, continuous knowledge growth, and compute-efficiency as a first-class research objective.
Adaptive Inference D v001: Preregistered Efficiency Benchmark
KESPA D v001 tested adaptive inference on the frozen 54-case workload. It achieved a composite quality score of 55.2586 at 2.443 s mean latency and 0.153616 Wh mean energy, but failed the preregistered primary success criterion because retrieval Hit@1, gold recall, and escalation-rate thresholds were not met.
Always-On Orchestration Overhead in the Locked A/B/C Runtime Run
The locked 54-case A/B/C runtime run showed that the then-current full KESPA orchestration path was materially more expensive than both the raw local model and the verified-retrieval fast path. Arm C averaged 9.066 s and 0.5759 Wh, executed 65 LLM passes, searched RAG on all 54 cases but used it on only 28, invoked planner/reviewer selectively, and avoided inference on zero cases. This runtime profile helped motivate V2 adaptive compute rather than always-on orchestration.
Blinded Quality Judging and Offline Gold-Metadata Repair
KESPA preserved a completed 162-row A/B/C benchmark after discovering that all raw rows had empty gold_claim_ids. The evaluator repaired gold associations offline from locked reference_claim_ids without modifying raw results, verified frozen corpus/evaluation hashes, and used blinded one-answer judge inputs containing no arm labels, runtime metrics, or system identity.
Frozen Benchmark Construction and Evaluation Leakage Prevention
KESPA built a 66-question benchmark from the 423-claim verified corpus, separating 12 calibration questions from 54 locked evaluation questions. Evaluation hashes were frozen before retrieval-policy tuning, and calibration tooling verified the locked evaluation hash without parsing its contents.
Frozen Evidence Identity: Canonical URL Plus SHA-256
KESPA corrected its scale claim/evidence verifier so frozen evidence is identified by canonical URL plus SHA-256 rather than URL alone. The change addressed 17 authoritative URLs that legitimately mapped to multiple frozen excerpts, 16 of which were referenced by generated candidates, while preserving strict contamination controls.
Chroma Corpus Compatibility and Retrieval Equivalence
KESPA validated that the isolated 423-claim clean corpus could be reproduced in a Brain-compatible Chroma layout without changing IDs, documents, metadata, or observed retrieval ordering. All 423 records matched structurally, 32/32 top-1/top-10 retrieval checks matched, and only float-scale embedding round-trip differences were observed.
Compute-Aware Model Routing and Telemetry Foundation
KESPA validated its local model registry, routing infrastructure, persistent telemetry, metrics endpoint, RTX 3070 instrumentation, and Admin controls on the actual KESPA machine. A subsequent routing-policy correction separated technical-learning requests from coding requests while preserving local-first execution.
A locked 12-question calibration showed that legacy long-card retrieval filters were poorly matched to short verified atomic claims. Plain vector top-6 achieved 12/12 Hit@1 and 67/87 claim recall, while legacy minimum-length filtering produced severe retrieval loss; the final policy freeze selected plain_vector_top6.
Claim-Level Verification and Clean Corpus Consolidation
KESPA consolidated strict claim-level verifier survivors from a 100-card diagnostic subset into a clean 423-claim corpus. The experiment recorded a 48.0% strict claim survival rate and rescued 331 independently supportable claims from cards that would have been discarded under whole-card acceptance.
A/B/C Verified-Intelligence Quality and Compute Benchmark
A frozen 54-question, 162-execution benchmark compared a raw local 7B path, clean verified atomic retrieval, and the then-current KESPA orchestration. The verified-retrieval arm achieved the highest reported composite quality score (54.22), 54/54 retrieval Hit@1, 79.17% gold recall, and the lowest mean latency and GPU energy of the three arms.
KESPA executed the seeded evidence-acquisition path across 3,128 planned evidence slots representing 2,831 cards. It collected and audited 2,146 evidence excerpts; 1,555 of 2,831 cards passed the evidence gate, while 463 evidence rows required review for missing scope-term matches. The run was deliberately held before card generation.
Deterministic Evidence Acquisition Preflight and Bounded Smoke Harness
KESPA converted the validated 3,982-card knowledge blueprint into a 4,807-slot evidence-acquisition workload with explicit primary/supporting/cross-check roles, a conservative 60-family source-policy catalog, an offline evidence-quality auditor, invariant validation, and a deterministic 28-slot/24-topic smoke harness. Local preflight checks passed with zero network/provider calls; the recorded checkpoint explicitly notes that the Windows live smoke had not yet been executed.
Cross-Model Claim Verification and Human-Review Gating Pilot
Four recorded pilot verifier runs evaluated 21 candidate-card executions with a different model family from the generator. The verifier produced 19 card passes, one evidence-support failure, and one structural execution failure while rechecking frozen evidence hashes and candidate identity. Seven high-stakes/safety cards still required human review despite model-level support, demonstrating that model agreement did not bypass policy or trust gates.
Groq Evidence-Bound Generation Canary and Fail-Closed Verification
A four-blueprint cross-domain Groq canary generated four evidence-bound knowledge candidates with zero generation failures for $0.003482 in reported provider cost, while assigning no trust and making no Chroma writes. Downstream verification then demonstrated the intended fail-closed boundary: a PostgreSQL candidate passed claim support verification, a calculus candidate failed on a partially supported claim, and a diabetes candidate surfaced a structural missing-claim-number execution failure.
Clean Pilot Retrieval Gate and Contamination-Metric Correction
A 30-card clean candidate corpus achieved 93.3% exact-card retrieval at rank 1 and 100% expected-topic retrieval at rank 1. The first benchmark run incorrectly treated legitimate cross-topic top-5 retrieval as hard contamination and produced a NO-GO; benchmark v002 separated hard contamination from cross-topic retrieval, after which the recorded public checkpoint reported 0/150 hard synthetic flags and a GO scale gate.
Evidence-Bound Candidate Generation and Provider Rate-Limit Resilience
KESPA's clean pilot generator bound model output to frozen evidence, atomic claim-to-source mappings, retrieval-focused text, contamination guards, and deferred trust. Subsequent provider-pacing changes added rate-header-aware throttling, Retry-After handling, token accounting, and a regression fix for an 8,041-token estimate against an 8,000-TPM limit.
KESPA's first clean Knowledge Factory pilot defined a 15-topic, 30-card evidence-bound generation contract with authoritative-source policies, independent organization checks for high-stakes topics, evidence hashing, atomic claim-to-source mappings, contamination guards, and deferred trust assignment.
A fixed 120-card, 142-slot evidence batch was rerun after a bounded seed-precision correction. Card-level evidence-gate passage improved from 62/120 (51.7%) to 82/120 (68.3%), while hard no-scope-term-match issues fell from 24 to 1 without changing the canonical blueprint, collector architecture, or source trust registry.
Evidence Discovery: From Search Dependency to Source-First Discovery
Three bounded discovery iterations showed that general web search was not reliable enough to be a required evidence locator in the tested Windows KESPA runtime. A source-first design using catalog hints, first-party entrypoints, robots.txt, sitemaps, and same-host navigation produced candidates for 26 of 28 smoke slots without Google or DuckDuckGo.
Source-Organization Independence and High-Stakes Evidence Policy
KESPA hardened its pilot evidence policy by moving independence from hostname counting to source-organization counting, adding explicit source_organization provenance, strengthening high-stakes cross-check requirements, replacing weak/failed seeds with authoritative sources, and preserving evidence-excerpt, hashing, redirect, and SSRF safety rails. Syntax and offline cross-check policy tests passed; no LLM, Chroma, or Brain changes were involved.
KESPA recovered 729 original subject areas from the legacy synthetic corpus, resolved all 121 ambiguous taxonomy classifications, split the recovered scope into 484 TECH_REVIEW and 245 REBUILD_FROM_SOURCE topics, preserved the ~442k-card synthetic corpus as immutable archive material, and explicitly rejected those synthetic cards for clean production indexing.
These entries come directly from completed KESPA research-release manifests already received by the
production research lifecycle. They are operational research records, not automatically public repo releases.
Verified release
Key Facts About Life Purpose
What is your purpose?
1 claims2 evidence2 organizations
forge-release-bf03200aaaba424029d46688
Verified release
Key facts about cuckoo filters
What is a Cuckoo filter?
4 claims2 evidence2 organizations
forge-release-07990ffc7fc9d09f9be2dd3b
Verified release
systemd overview
What is systemd?
6 claims1 evidence1 organizations
forge-release-b668d809f8b517bb46cdb92b
Active research tracks
What KESPA is testing now
01
Adaptive knowledge acquisition
Can KESPA identify a real knowledge gap during normal use, gather evidence, verify claims, and improve future retrieval without retraining its base model?
02
Capability per unit of compute
How much practical capability can system architecture add to a constrained local model before larger inference hardware becomes necessary?
03
Retrieval and solved-work reuse
Can verified knowledge and repeated-work reuse reduce unnecessary inference while preserving or improving answer quality?
04
Trust and evidence policy
Which verification, provenance, source-independence, and release gates meaningfully reduce weak or unsupported permanent knowledge?
05
Provider and model routing
When should KESPA use local inference, stronger hosted models, external research, or no escalation at all?
06
Private memory and user context
How can persistent user context improve usefulness while remaining clearly separated from public factual knowledge?