K-Veritas signs computational results to their code and hardware in a verifiable PDF

What K-Veritas does

A project called K-Veritas, presented in a Show HN post on Hacker News, is a command-line tool for tamper-evident verification of computational experiments. According to its GitHub repository, it binds a published result to the exact code, hardware and time that produced it, and packages the evidence into a cryptographically signed PDF that anyone can verify without rerunning the experiment. The tool is written in Go 1.22, ships as a single static binary with zero runtime dependencies, and works with programs written in any language.

How a session works

The core workflow is four commands. kveritas init starts a session, redacted by default. kveritas run -- executes any command underneath the tool while it captures telemetry. kveritas seal signs the session into a report PDF, and kveritas verify checks it, with an --offline flag that skips the attestation server.

Programs report results by printing simple protocol lines to stdout — KVERITAS_METRIC, KVERITAS_CLAIM, seed commitments via KVERITAS_INPUT, and model and workload cards that feed the compute-cost checks. Metrics from Keras training histories, scikit-learn cross-validation and metric-like local variables are auto-detected, so simple runs need no instrumentation at all.

One platform caveat: sealing, verification, proofs, checkout, benchmark artifacts, provenance and disclosure levels work across Linux, macOS and Windows, but the per-process hardware attribution and the file/subprocess activity map are Linux-only; elsewhere the tool falls back to system-wide readings.

Coherence and plausibility checks

Two mechanisms do most of the anti-fabrication work.

The first, called HMCA or execution coherence, is deliberately metric-blind — it never looks at the reported result. During a run, a background sampler records per-process telemetry at about 10 Hz: CPU, memory, context switches, page faults, CPU frequency and I/O, plus GPU utilization, memory, power and temperature where a GPU is used. At seal time HMCA scores whether those channels co-fluctuate as shadows of a single process. A genuine run drives every channel from one activity stream; a fabricated or replayed trace does not. Verdicts are PASS, WARN, FAIL or N/A, and light runs are judged only on the activity they actually have.

The second is compute-cost attestation. When a run declares a model card, the seal step checks the declared FLOP count against what the hardware could physically deliver, using time, energy and memory bounds. The time bound sums every device, and the repository notes that a 175-billion-parameter model declared on an idle CPU gets caught this way. A hard violation is labeled FABRICATION-IMPOSSIBLE and bound into the signature; honest runs pass because the bounds are generous.

Disclosure, provenance and proofs

Each run is recorded as a signed timeline of content-addressed source snapshots — at run start, at each marked phase and at run end — Merkle-linked into the signature. Disclosure is a per-session choice: redacted by default, real file names with a flag, or fully open, which also writes a checkout bundle of the source code. Datasets and weights are never included, and files excluded via .kveritasignore still appear as hash-only leaves so they cannot be silently dropped.

Selective-disclosure proofs go further: an author can show that one file was part of a signed snapshot without exposing any other. There is also an agent mode, kveritas init --harness, which records a hash-chained log of designated agent actions — including hooks for Claude Code — and verification can localize tampering to the exact entry, with per-agent attribution.

Cryptographically, canonical JSON is hashed with SHA-256 and signed with RSA-PSS using a 4096-bit key, with the seal embedded in the PDF after %%EOF. Reports can also be uploaded to kveritas.org/verify for a server-side audit, with no account required.

Why it matters

Reproducibility is a chronic weakness in computational science and machine learning: reviewers almost never rerun experiments, so published numbers rest largely on trust. K-Veritas does not prove a result is correct, but it changes the economics of faking one — a fabricated claim would need to also fake coherent low-level telemetry and a plausible energy and time budget on the declared hardware. For benchmark submissions, AI-agent transcripts and papers that are impractical to rerun, that binding between claim, code and machine adds a real layer of accountability. The Linux-only telemetry limits and the fact that the sampler runs client-side are the obvious caveats to weigh.