Source-linked AI summary
Computer Science Conferences Should Require Nonrepudiable Experimental Results
Mamadou K. Keita, Christopher Homan
TL;DR
The paper addresses the inability of current conference practices to verify whether reported numbers came from the described computations. It defines experiment nonrepudiation, proposes independent tamper-evident attestations, and presents K-Veritas as a testbed while acknowledging governance and adoption boundaries.
Problem
Current conference practices cannot independently verify that reported results came from actual executions, leaving plausible fabricated tables indistinguishable from real ones by inspection.
Method
The paper defines experiment nonrepudiation, specifies security properties and threats, and presents K-Veritas as a Go testbed producing signed reports without accessing training data.
Results
The paper concludes that reported results alone cannot be trusted and that K-Veritas demonstrates the problem is tractable without being a finished solution.
Takeaways & Limitations
Computer-science conferences should require nonrepudiable experimental results and help develop an open, independent standard.
Takeaways & Limitations
The proposed end state requires mature protocols, broad tool support, federation, and community consensus, estimated to take 3–8 years from initial adoption.
Abstract
from arXiv · showhide
This position paper argues that computer science conferences should require tamper-evident, nonrepudiable attestations of experimental results. We name the underlying problem experiment nonrepudiation: a compliant protocol must bind the numbers in a paper to an actual executed computation in a way the author cannot later alter or deny. The current system relies on self-reported checklists, optional code sharing, and author-controlled logging. None of these mechanisms answer the question a reviewer cannot check: did the code the paper describes produce the numbers the paper reports? We define the problem formally, state the security properties any compliant protocol must satisfy, and describe a threat model that includes attacks current approaches do not prevent. To show that the problem is solvable, we built K-Veritas, a reference implementation in Go that produces signed reports without accessing training data. K-Veritas is a testbed, not a finished answer. We call on conferences and the community to treat nonrepudiation as a first-class requirement and to help build an open, independent standard for it.
1 Introduction
Machine-learning reproducibility remains structurally weak because reviewers generally take reported numbers on faith. The paper names this gap experiment nonrepudiation and proposes independent attestations binding reported numbers to executed computations.
- Reproducibility problems in machine learning persist despite more than a decade of concern.
- Published studies report widespread barriers including missing code, undocumented training conditions, initialization sensitivity, and data leakage.
- Reviewers lack the time and resources to rerun experiments, so reported numbers are generally accepted on faith.
- Checklists, artifact evaluation, logging, and preregistration are voluntary, self-reported, author-controlled, or post-hoc rather than independent verification.
- The paper defines experiment nonrepudiation as independently verifiable evidence that an author cannot alter, deny, or misrepresent what a computation produced.
- The authors propose requiring tamper-evident attestations generated by an independent, author-inaccessible protocol that binds reported numbers to executed computations.
2 The Verification Gap
Existing conference mechanisms improve documentation, code availability, or planning, but none independently and tamper-evidently bind reported numbers to actual runs. The paper therefore identifies a verification gap between what conferences request and what they verify.
- The verification gap is structural: conferences ask for reproducibility information but do not directly verify execution.
- Self-Reported Checklists: NeurIPS checklists verify authors’ disclosure claims rather than whether experiments were actually executed.
- Self-Reported Checklists: None of 400 surveyed AAAI and IJCAI papers documented all variables required for reproducibility, with only 20–30% documented per paper.
- Artifact Evaluation: Artifact evaluation checks whether code runs, not whether it produced the paper’s specific numbers, and it is typically optional and post-acceptance.
- Artifact Evaluation: Only 40% of nearly 750 surveyed papers included artifacts, 44% of those artifacts ran successfully, and artifact committees produced no statistically significant improvement.
- Author-controlled logging, preregistration, dataset documentation, and software signing address related concerns but do not bind reported results to actual computations.
- The AI Review Problem: A plausible result table cannot be distinguished as real or fabricated by inspection alone.
- No existing major computer-science conference mechanism provides a tamper-evident, independently verifiable binding between paper numbers and executed computations.
3 Why Reported Results Alone Cannot Be Trusted
Two indistinguishable result tables show that plausible numbers cannot establish whether an experiment was actually run. Because reviewers lack time to rerun configurations, verification must bind reported numbers to computations during execution.
- Two tables report sentiment-classification fine-tuning results, but only one comes from a real training run.The other was generated by a language model asked to produce plausible results for the same setup.
- Both tables were generated to show that reviewers cannot distinguish real results from fabricated ones by inspecting a result table.The numbers are plausible and the baselines are broadly consistent with published benchmarks.
- Plausible optimizer, schedule, batch-size, and hardware descriptions can also be fabricated without running a single batch.A reviewer could rerun the configuration, but standard review provides neither the time nor the obligation to do so.
- The review process evaluates plausibility rather than authenticity, motivating source-level verification that binds reported numbers to actual computations during execution.The proposed record must be tamper-evident and produced by a process the author does not control.
4 Experiment Nonrepudiation
Experiment nonrepudiation binds reported empirical numbers to a specific executed computation in a tamper-evident record the author cannot alter or deny. The proposed protocol combines independent signing and verification with execution-linked evidence while preserving dataset confidentiality.
- Experiment nonrepudiation means a tamper-evident record binds reported numbers to a specific executed computation that the author cannot alter or deny.
- Unlike reproducibility, replicability, and provenance, nonrepudiation asks whether reported results are bound to what the author’s computation actually produced.
- The computation includes code, dependencies, configuration, hardware, and dataset inputs, while the attestation records digests, metrics, telemetry, and observed output.The dataset itself is never exposed outside the author’s machine.
- A compliant protocol requires passivity, data blindness, execution-binding, tamper-evidence, author-key separation, and independent verifiability.These requirements ensure the observer does not modify the run, access the dataset, or rely on author-controlled signing and verification.
- The property applies beyond ML to empirical computational claims including systems benchmarks, optimization, simulations, and agent evaluations.
5 Threat Models
The threat model covers ordinary fabrication and selective reporting but is explicit that software-only observation cannot defeat privileged kernel, hardware, or signing-service adversaries. This defines both the protocol’s practical value and its security boundary.
- Text-level fabrication is detected by comparing paper claims with the signed record, while signed stdout digests prevent later log edits.
- Selective reporting remains possible because an author can submit an attestation for a favorable run and hide other runs.Pre-registration and recording the run count reduce this risk, but nonrepudiation alone does not eliminate it.
- Hardware-accountability checks can flag superficial fake training by comparing claimed workloads with GPU activity and memory usage.A compute-heavy script producing chosen numbers would nevertheless perform most of the work of real research.
- A compromised operating system can forge telemetry or interpose library calls, so a user-space observer cannot prevent kernel-level tampering.
- Malicious firmware or virtualized hardware can misreport counters, and a user-space observer cannot prevent this stronger attack.
- If the attestation signing key is stolen, attackers can create valid attestations for anything; federation, key rotation, and auditing address this governance problem.
- Software-only protocols handle ordinary fabrication, log edits, naive selective reporting, and superficial fake training, but not privileged kernel or hardware adversaries.
6 K-Veritas: A Testbed
K-Veritas demonstrates a practical testbed for producing signed experimental reports without author code modification or dataset access. It captures execution evidence and provides a consistency heuristic, while remaining vulnerable to OS- and hardware-level attacks.
- K-Veritas is a Go reference implementation intended to show that the required nonrepudiation properties are achievable, not to serve as the final solution.Other implementations satisfying the requirements would be equally valid.
- Authors run existing commands through a standalone compiled binary and seal the resulting session into a report.The workflow uses kveritas run and kveritas seal without requiring authors to modify their code.
- The observer captures outputs, hashes source files, samples resource usage, and sends a canonical SHA-256 session digest to a remote attestation service.Captured telemetry includes CPU time, memory, GPU utilization, GPU memory, and disk I/O.
- Signed stdout and source-code hashes connect printed metrics and executed code to the attested session, while HMC checks consistency between metrics and hardware activity.HMC is presented as a heuristic that future implementations may refine.
- K-Veritas stops casual and moderate fabrication and provides a concrete artifact for testing the definition, but it does not prevent OS-level or hardware-level attacks.
7 Path to Adoption
The paper proposes independent governance and a phased adoption path for nonrepudiable attestations, progressing from voluntary badges to requirements for all empirical papers. Reaching the required phase depends on protocol maturity, broad tooling, federation, and community consensus.
- Governance: Nonrepudiation should be maintained as an open standard by an independent nonprofit organization without restrictive financial ties.The proposed governance model is intended to prevent any single institution from controlling the verification standard.
- Phase 1: Voluntary: Adoption begins with optional attestations, visible badges, and web-based verification that requires no software installation for reviewers.
- Phase 2: Expected: Attestations then become expected, with absence recorded in review forms and verification integrated into submission portals.
- Phase 3: Required: The end goal requires attestations for all empirical papers, with unattested papers desk-rejected or flagged for additional scrutiny.
- Requirements for adoption: Reaching the required phase requires mature protocols, broad tool support, provider federation, and community consensus, estimated to take 3–8 years.
8 Alternative Views
The paper acknowledges practical and adversarial objections while arguing that nonrepudiation can complement existing practices and improve the evidentiary status of honest results. It also recognizes that centralized control and software-only verification remain important concerns.
- Adversarial workarounds: Nonrepudiation does not eliminate workarounds by motivated cheaters, but it raises fabrication from editing text to running computation or compromising a kernel.
- Pre-registration: Pre-registration and nonrepudiation are complementary: the former commits the experimental plan, while the latter links reported numbers to an actual run.
- Industry concerns: A tiered metadata schema allows minimal compliance using final metrics, timestamps, framework versions, and random seeds without requiring proprietary hardware details.
- Effect on honest researchers: Verified results can improve the credibility of honest researchers by giving them stronger evidentiary status than unverified results.
- Centralization: Centralized attestation risks concentrated control, so the paper proposes independent governance, public specifications, multiple implementations, advisory status, and eventual federation.
9 Conclusion
The conclusion presents experiment nonrepudiation as a defined security problem with a proposed software testbed, while acknowledging that software-only schemes have limits. It extends the argument beyond machine learning and calls for community participation.
- The paper defines experiment nonrepudiation through security properties and a threat model that distinguishes defeated attacks from attacks software-only schemes do not defeat.
- K-Veritas is presented as a tractability testbed rather than a finished solution, with hardware-backed attestation identified as a next step.
- The paper argues that nonrepudiation should apply universally because verification does not depend on a researcher’s identity, workplace, or lab reputation.
- Tamper-evident, independently verifiable attestations are characterized as stronger evidence than paper tables for computational empirical results across fields.
- The paper invites the community, organizations, and conferences to help build the proposed framework.
A Comparison with Existing Approaches
The section introduces a comparison of nonrepudiation with existing reproducibility mechanisms and identifies K-Veritas as one possible compliant implementation. The supplied passages also note that required adoption is only a future phase.
- Table 4 compares nonrepudiation with existing reproducibility mechanisms and presents K-Veritas as one possible instantiation of a compliant protocol.
- Required adoption is described as a future phase, with voluntary adoption proposed first.
B Limitations
The paper identifies five limitations: nonrepudiation verifies execution authenticity but not experimental quality, depends on secure attestation infrastructure, requires author compliance, cannot defeat OS- or hardware-level adversaries, and needs institutional deployment infrastructure.
- Nonrepudiation binds reported numbers to an actual execution but does not verify whether the experiment was well-designed.A poorly controlled experiment can still produce real, verified numbers.
- Tamper-evidence depends on the attestation service and signing key remaining secure.Compromise could allow fabricated attestations, requiring infrastructure management, federated attesters, and regular key rotation.
- The protocol requires authors to use a compliant implementation, so conferences must make compliance mandatory or strongly encouraged.If an author refuses compliance, no attestation is generated.
- A software-only observer cannot defeat OS-level or hardware-level adversaries.The paper identifies hardware-backed attestation as a possible path for high-assurance submissions.
- Conference-scale deployment requires persistent session storage, rate limiting, key rotation, and auditing.The paper classifies these as operational requirements rather than protocol limitations.