DEV Community

euk ela
euk ela

Posted on

File provenance for the AI-agent era: evidence labels, not guesses

AI coding agents write files faster than anyone can remember where they came from. Git records versions; DVC and OpenLineage record pipelines you declared up front; nothing records the unplanned output — the CSV an agent wrote mid-task, the PNG it regenerated, the notebook that silently touched a data file.

trace-file-lineage (MIT, ~361★, v0.7.0) is a local CLI that answers "which script, notebook, data, command, or AI agent produced this file?" with five confidence labels — verified, strong-candidate, candidate, weak-signal, insufficient — and it labels guesses as guesses. I have not tested or run this tool; everything below is from reading the README and source files.

Two modes, one honest split. Retrospective: for files you already have, it reconstructs the most likely origins from code, document metadata, and Git history — "ranked guesses with the reasoning attached" (README). Prospective: lineage run --task "..." -- python sweep.py wraps a command, captures the task boundary, and files changed during the run are marked verified — "These answers are proof" (README). It never moves, renames, or deletes files; lineage layout --suggest only proposes a destination.

What verified means in source. In evidence.py, every fact carries a basis (observation / declaration / inference / confirmation), an assurance field (verified when exact, candidate otherwise), the source path and line it came from, and a deterministic id (uuid5(NAMESPACE_URL, canonical_json)), so re-scanning the same fact yields the same id. Evidence about the evidence, with location attached — that design is the part worth copying.

Trust order and privacy. The README ranks sources: your own confirmation → recorded runs → imported provenance → declarations → static code → content → names/timestamps. Extracted text lives in .file-lineage/ (SQLite-backed, git-ignored by default). Privacy claims: nothing is uploaded, no account or API key; scanning never executes your code — only lineage run runs the explicit command after --, and password-looking arguments are stripped from recorded commands.

Deliberate limits. JS/TS get "a cautious static scan, not real language understanding" (README); other languages are searched, not parsed; runtime-built paths cannot be resolved. Performance is claimed and reproducible, not something I ran: tests/benchmark.py on macOS / Python 3.14 reports 1,000 files → 0.5 s cold scan / 0.1 s warm; 10,000 files → 16.5 s / 1.1 s; individual queries in milliseconds.

Bottom line. If you run Python/notebook workflows and a pile of agent-generated files has become unanswerable trivia, this is worth evaluating — lineage enable even writes the tracing rules into CLAUDE.md and AGENTS.md (an instruction, not enforcement, per the README). If you have no agent-generated files, or cannot tolerate a git-ignored text index in your project, it is premature. A comparison with Git/DVC/OpenLineage is in docs/comparison.md.

Top comments (1)

Collapse
 
alexshev profile image
Alex Shev

Evidence labels are exactly the missing layer. Agents often treat every file as equally authoritative because the filesystem gives them paths, not confidence. A small provenance label - generated, user-authored, copied, stale, derived - can prevent a lot of bad decisions before the model even starts reasoning.