result-provenance-review

Reviews computational result files for reproducibility, seed recording, and provenance traceability.

1|Updated Dec 13, 2025
One-click install
npx skills add https://github.com/ZK-Theory/TDL --skill result-provenance-review-zk-theory
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: result-provenance-review
Source: https://github.com/ZK-Theory/TDL/tree/main/.agents/skills/result-provenance-review
Command: npx skills add https://github.com/ZK-Theory/TDL --skill result-provenance-review-zk-theory

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? A numerically correct computational result is still unusable if it cannot be regenerated, was silently overwritten, or its parameters and seeds were never recorded. This Skill provides a structured 18-item checklist to verify that TDL result files — caches, seeds, output paths, date suffixes, and vault entries — are reproducible and correctly recorded before they are trusted as downstream inputs or paper-facing sources. ## Core Features & Use Cases - Provenance Checklist: Walks 18 checks covering date-suffixed filenames, no-overwrite behavior, two-path output rules, seed recording, cache parameter matching, and vault [RESULT] entries. - PASS/GAP Reporting: Reports PASS or GAP per item with the specific file, path, and corrective action (regenerate, re-date, record the seed, file the vault entry). - Escalation Rules: Defines stop conditions such as unrecoverable overwritten results, mismatched reused caches, or missing committed JSONs consumed downstream. - Use Case: Before citing a permutation-test p-value in a paper draft, run this review to confirm the cache was built with the current seed, B, and null model, the deliverable JSON is committed, and the vault entry is filed — catching a stale-cache mismatch like the T1.36 incident. ## Quick Start Review the result file power_analysis_2026-06-03.json against the result provenance checklist and report PASS or GAP for each item.

Frequently Asked Questions about result-provenance-review

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I verify a computational result is reproducible before citing it?

Work through the provenance checklist: confirm the date-suffixed filename, that no prior file was overwritten, that seeds are set and recorded in the vault entry, and that any reused cache matches the current seed, B, L, null model, and date. Report PASS or GAP per item with corrective actions.

How to check whether a reused cache matches current run parameters?

Compare the cache's recorded metadata against the current seed, permutation count B, landscape levels L, null model, Markov order k, and date. A cache built under different parameters is not a valid input, and reference caches should record sha256 hashes of generative inputs for cheap vintage verification.

Should CSV and PKL intermediate files be committed to git?

No. CSV and PKL files are globally gitignored due to UKDA terms and size; instead commit the producing script so they can be regenerated. Verify the intermediate exists on disk at its expected PROJ_ROOT path and record the regeneration command.

Why did a preserved cache produce invalid p-values after a formula correction?

The cache's denominator parameters no longer matched the corrected formula, so values computed from it were stale. This is the T1.36 scenario: always confirm cache provenance matches current parameters, and git rm superseded artifacts so they stop matching active validation globs.

When should a provenance review stop and escalate instead of passing?

Escalate when a results file was overwritten and the prior value cannot be recovered, when a reused cache's parameters do not match the current run, or when a committed JSON consumed downstream is missing or malformed. Surface the problem rather than fabricating a substitute.