evidence-convention
Skill0 starsChanged 4 months agoMITView on GitHub
Use when launching any computational campaign whose results will be kept, cited, or decided upon — sweeps, batch runs, Monte Carlo draws, precomputes — and when auditing for "dark runs" (results that exist only in caches, scratch dirs, or chat logs). Defines where evidence lands and what a run must record. Trigger phrases: "where do the results go", "record this run", "write the meta file", "dark run", "promote these results", "run report".
In this repository15 other files it gives its agents.
- templates/CLAUDE.mdCLAUDE.md
- build-logSkill
- canonical-paramsSkill
- correctness-gateSkill
- decision-logSkill
- layer-syncSkill
- phase-gateSkill
- project-layoutSkill
- run-provenanceSkill
- external-positioningSkill
- lit-anchorSkill
- negative-results-ledgerSkill
- numerical-determinismSkill
- statistical-reportingSkill
- skill-library-generatorSkill
The file
We split this skill into the rules it gives an agent
1 rule. About 0 are common, 0 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈0
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 42
If the script does not write meta.json itself, the runner writes it by hand — absence of tooling is not absence of obligation.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
evidence-convention
No dark runs. A result that exists only in a gitignored cache, a scratch directory, a
terminal scrollback, or a chat transcript is not evidence — it is a rumor with numbers. The
contract: every kept campaign lands in {{evidence_dir}}/<name>_<YYYY-MM-DD>/ with a
meta.json, and what the repo tracks is the record (meta + curated summaries), not the
bulk.
When to use
- Launching a sweep, batch run, sampling campaign, or precompute whose output will be kept.
- A decision, build-log entry, or paper claim is about to cite a run — does the run have an evidence directory?
- Auditing the project for dark runs.
- Writing the run report after a campaign finishes.
When NOT to use
- Small exploratory probes — those are notebook work (
project-layout); the convention starts when a result will outlive the session. - Pure cache regeneration with no new claim attached (caches are inputs, not evidence — but
see
run-provenancefor their keys).
The convention
- One directory per campaign:
{{evidence_dir}}/<name>_<YYYY-MM-DD>/. meta.jsonis mandatory. Minimum fields (schema:templates/results-meta.schema.json):task— what this campaign is, with a pointer to the plan item or contract it executes;git_commit+git_tree_clean_at_launch— code identity;- config hash + input-data hashes (see
run-provenance); - environment fingerprint (see
run-provenance); - parameters/grid actually run, seeds/realization list;
expectation— what was predicted before running (pre-registration; numbers fitted afterward are captions);statusand pointers to output files. If the script does not writemeta.jsonitself, the runner writes it by hand — absence of tooling is not absence of obligation.
- Bulk outputs may be gitignored; the record is tracked. Track
meta.json, a README with the key numbers, and curated summary files (explicit force-add per the project's gitignore policy). If output logs stay ignored, embed the load-bearing numbers in the tracked README — a claim must not depend on an untracked file. - Preflight before long campaigns:
{{gate_command}}green; tree clean (or the dirty state explicitly waived and blob-hashed); environment native-arch verified. A red gate aborts the launch. - Failed and degenerate cells are data. Infeasible points, timeouts, divergences, and empty windows are recorded verbatim with their counts — never re-run with a nudged grid to make them disappear, and never dropped silently. A truncated or skipped portion gets an explicit "not done / dropped" note in the run report.
- Run report at completion: command, wall time, output directory, status distribution table (per-cell outcomes and counts), anomalies, and the not-done list.
The runner role (documented pattern)
Working practice separates deciding from running: campaigns are executed by a runner
(a person, a subagent, or a script harness) under a written task contract — entry point,
grid/axes, seeds, time limits, output directory, definition of done. The runner runs and
records; it never reformulates the model, never edits source or protected defaults, never
alters the grid beyond the contract, and stops to report anomalies instead of "fixing" them.
This pack ships no writer agents — the pattern is documented here and in the pack's
examples/ directory; implement the role with whatever executes runs in your project.
Rules
- A claim without an evidence directory is treated as unverified — by
phase-gate(item stays OPEN), bydecision-log(Impact cannot cite it), and by reviewers. - Caches are not records. Scratch/cache dirs hold reproducible intermediates; evidence dirs hold what claims rest on. Promoting from cache to evidence is a deliberate act that produces a meta file.
- Name by content and date,
<name>_<YYYY-MM-DD>/— discoverable byls, sortable by time, no "final_v2_really". - The expectation field is written before launch. Post-hoc "expected" values are predictions in name only.
- Anomaly patterns are flags to report, not noise to smooth — a status-rate split across seed batches, cells far above the median cell time, cache misses forcing recomputes.
Configuration
{{evidence_dir}}— evidence root (defaultresults/).{{gate_command}}— preflight gate.
Provenance & maintenance
Generalized from a working repository's runner discipline and audit history — the convention
exists because an audit found kept results living only in gitignored caches ("dark runs"),
and the fix (evidence dirs + mandatory meta + tracked key numbers) is enforced there as an
acceptance criterion. The meta-field minimum mirrors a real campaign meta file; the
run-report shape mirrors the exemplar runner's report format. See the pack's examples/
directory for the worked exemplar mapping.
Re-verify in your project:
ls {{evidence_dir}} | grep -E '_[0-9]{4}-[0-9]{2}-[0-9]{2}$'— campaigns follow the naming convention.find {{evidence_dir}} -maxdepth 2 -name meta.json | wc -l— evidence dirs carry meta files (compare with the dir count).git ls-files {{evidence_dir}} | head— the record layer (meta/READMEs/summaries) is actually tracked, not just present on disk.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

