← Research archive
Technical note verified Sep 14, 2026

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.

telemetry evidence-automation nexledger provenance benchmarks
MARKDOWN

README.md

3,618 bytes SHA-256 153a342843cd7fb7…

KESPA-NOTE-011 — Automated Research Evidence Capture and NexLedger Attestation

Date: 2026-09-14 Status: Verified — operational automation completed Project: KESPA AI / NexLabs Studios

Purpose

KESPA already produced useful telemetry and benchmark artifacts, but research evidence is much less useful if it depends on somebody remembering to manually collect and preserve it after every run.

The evidence automation closes that gap.

It turns selected completed runtime/benchmark evidence into a repeatable provenance pipeline.

Operational topology

The evidence path spans KESPA's existing hosts:

  • RYANDESKTOP — live Brain/runtime machine
  • NVIDIA RTX 3070 8GB — local inference GPU
  • DESKTOP-S16TRCC — research/home server used for aggregation and background work
  • app-nexlabs — application side, including signed evidence intake and database persistence

The home server remains the research/storage/background-work machine; it is not the live Brain.

Hourly MET evidence flow

The completed automation runs hourly.

Its operational flow is:

closed RTX 3070 telemetry -> home-server aggregation -> safe MET evidence -> signed intake -> MySQL -> generic NexLedger worker

In words:

1. Read closed telemetry from RYANDESKTOP.

2. Aggregate the selected telemetry on the home/research server.

3. Construct a safe research-evidence payload classified as MET.

4. Send that payload through the signed intake.

5. Record the accepted event in MySQL.

6. Let the existing generic worker create the NexLedger attestation.

Benchmark evidence

The same automation also watches for future completed benchmark runs.

Eligible completed-run evidence is handled as BM evidence rather than requiring a one-off manual attestation process for every benchmark.

That gives KESPA a durable evidence path for both:

  • runtime/telemetry research snapshots — MET
  • completed benchmark evidence — BM

Why the pipeline is separated into stages

The system deliberately does not treat NexLedger as the application database.

The roles remain:

runtime telemetry -> evidence construction -> signed intake -> MySQL authoritative record -> NexLedger attestation

This separation allows KESPA to preserve normal application/database semantics while still creating a tamper-evident external provenance record for selected research evidence.

Ledger scope remains narrow

The automation does not expand NexLedger into a general activity log.

The ledger is not for:

  • routine Git commits or pushes;
  • source-code history;
  • ordinary deployment events;
  • private prompt/answer plaintext;
  • user profile or leaderboard statistics.

The evidence path is reserved for externally useful research/provenance material such as meaningful telemetry snapshots and completed benchmark evidence.

Research significance

This automation matters because measurement provenance is now part of the system rather than a manual afterthought.

Future research can accumulate evidence continuously while retaining a defined chain:

measurement -> aggregation -> signed submission -> authoritative DB event -> attestation

That is useful for later benchmark comparison, grant/research documentation, investor diligence, and reproducibility work.

Limitation

An attestation proves that a particular evidence record was committed through the pipeline.

It does not prove that the underlying experiment was well designed or that an interpretation is correct.

Scientific validity still depends on the experiment, measurement protocol, and analysis.

TEXT

SHA256SUMS.txt

393 bytes SHA-256 578125882485474f…
153a342843cd7fb700ee1060195810ce171303640ab6924acc15b96bd802f8d5  README.md
fa24554d02c74c87697c18bc9a32efa171b9cbda0497f39aa40144dfec47671c  note.json
74c217fd93c95f7d43d4876c828ce42880d3b6ede799f381b9b8fb388e54ac78  metrics.csv
e7d1ec0b91cad501b45662d8382e57eb9aa6a7a951ac47e062fcd7f2073fcba5  methodology.md
e19aa8ee0124fdc53a7965844975aec333e0ddf26934e72d90594bc2285e57aa  provenance.json
MARKDOWN

methodology.md

1,187 bytes SHA-256 e7d1ec0b91cad501…

Methodology

Runtime evidence source

The automation consumes closed telemetry from the live KESPA runtime on RYANDESKTOP rather than scraping an active/incomplete request.

Selected telemetry is aggregated on the research/home server.

Safe evidence construction

The automation converts the selected aggregate into a safe MET research-evidence record.

The public architecture does not require private prompt/answer plaintext or source code to be written to NexLedger.

Signed intake

Evidence crosses into the application side through a signed intake rather than an unauthenticated write path.

Accepted evidence is recorded in MySQL.

Ledger attestation

A generic worker processes eligible accepted evidence and submits the corresponding provenance attestation to NexLedger.

MySQL remains authoritative; NexLedger supplies the tamper-evident evidence/provenance layer.

Benchmark watch

The same automation watches for completed benchmark runs and can produce BM evidence from eligible completed-run outputs.

Cadence

The operational automation runs hourly.

This converts evidence preservation from a manual post-run task into a recurring system process.

CSV

metrics.csv

532 bytes SHA-256 74c217fd93c95f7d…
metric,value,unit_or_status
automation_cadence,hourly,schedule
live_runtime_host,RYANDESKTOP,host
live_gpu,RTX 3070 8GB,hardware
aggregation_host,DESKTOP-S16TRCC,host
runtime_evidence_class,MET,evidence_type
benchmark_evidence_class,BM,evidence_type
signed_intake,YES,control
mysql_event_record,YES,persistence
generic_nexledger_worker,YES,attestation
future_completed_benchmark_watch,YES,automation
routine_git_activity_attested,NO,scope
private_prompt_answer_plaintext_attested,NO,scope
profile_stats_routed_to_nexledger,NO,scope
JSON

note.json

2,688 bytes SHA-256 fa24554d02c74c87…
{
    "schema": "kespa.public_technical_note.v1",
    "id": "KESPA-NOTE-011",
    "title": "Automated Research Evidence Capture and NexLedger Attestation",
    "date": "2026-09-14",
    "status": "verified",
    "purpose": "Document the completed hourly automation that converts closed runtime telemetry and completed benchmark outputs into safe, durable research-evidence records with database persistence and tamper-evident NexLedger attestation.",
    "topology": {
        "live_brain_host": "RYANDESKTOP",
        "live_gpu": "NVIDIA RTX 3070 8GB",
        "research_home_server": "DESKTOP-S16TRCC",
        "web_application_host": "app-nexlabs"
    },
    "automated_flow": [
        "read closed telemetry from RYANDESKTOP / RTX 3070",
        "aggregate telemetry on the home/research server",
        "construct safe MET evidence",
        "submit MET evidence through signed intake",
        "record accepted evidence event in MySQL",
        "generic worker attests accepted evidence to NexLedger"
    ],
    "benchmark_watch": {
        "enabled": true,
        "behavior": "Automatically watches future completed benchmark runs for BM evidence.",
        "evidence_class": "BM"
    },
    "telemetry_evidence": {
        "evidence_class": "MET",
        "source": "closed KESPA runtime telemetry",
        "raw_private_payload_required_on_ledger": false
    },
    "schedule": {
        "cadence": "hourly",
        "automation_name": "FORGE Evidence Automation"
    },
    "ledger_scope": {
        "mysql_role": "authoritative application/research event record",
        "nexledger_role": "tamper-evident evidence/provenance attestation",
        "routine_git_activity_attested": false,
        "source_code_attested": false,
        "private_prompt_or_answer_plaintext_attested": false,
        "profile_or_leaderboard_statistics_routed_to_nexledger": false
    },
    "research_relevance": [
        "Turns ephemeral runtime measurements into durable research evidence without requiring manual collection after each run.",
        "Separates telemetry collection, evidence intake, authoritative database recording, and ledger attestation into distinct stages.",
        "Creates a repeatable path for future benchmark evidence so later research claims can be tied to preserved provenance."
    ],
    "limitations": [
        "The automation attests selected safe research evidence, not every telemetry field or every application event.",
        "NexLedger is not the authoritative database; MySQL remains authoritative for the application-side record.",
        "The pipeline does not make telemetry or benchmark results scientifically valid merely by attesting them; experimental design and interpretation remain separate.",
        "User profile/leaderboard statistics are intentionally outside this NexLedger evidence scope."
    ]
}
JSON

provenance.json

893 bytes SHA-256 e19aa8ee0124fdc5…
{
    "schema": "kespa.public_provenance.v1",
    "research_id": "KESPA-NOTE-011",
    "source_basis": "KESPA operational handoff record after completion of the NexLedger/evidence automation work.",
    "source_observations": [
        "The current evidence automation reads closed telemetry from RYANDESKTOP / RTX 3070.",
        "Telemetry is aggregated on the home server.",
        "Safe MET evidence is sent through a signed intake.",
        "The event is recorded in MySQL.",
        "A generic worker attests it to NexLedger.",
        "The automation watches future completed benchmark runs for BM evidence.",
        "The automation runs hourly."
    ],
    "publication_note": "This public record describes the completed evidence pipeline at the architecture level. It intentionally omits signing secrets, internal endpoints, raw private telemetry, source code, private prompts/answers, and implementation credentials."
}