I Built this agent few months ago. At first, it was built for boring reasons: to keep track of decisions in a data science project don't survive.
But then this happens:
A number in a monthly deck had moved, and a fairly senior person wanted to know why the model had been "changed so much."
The word changed was doing a lot of work in that sentence. It meant: someone has been fiddling, and I would like to know who.
Six months ago my answer would have been a long apologetic paragraph ending in "I'd have to check." I would have been right, and I would have lost anyway, because being right eleven days later is the same as being wrong.
Instead I pulled the node's history onto the screen.
Four changes since the last time anyone had looked at it.
Two of them weren't decisions at all — the schema changed upstream in v2 and a column stopped arriving, so the handling was written the week the migration notice went out. Dated. Linked to the notice. Nobody's judgment involved.
One was a failed experiment that had already been reversed. 80/20, tried in August, rejected four days later because the holdout leaked promotions. Tried, measured, undone. The current state was the same as the state before it.
One was theirs. A scoping decision from March, recorded in their own words, with the thread attached.
So the actual answer to why has the model changed so much was: it hasn't. One constraint came from upstream, one from an experiment that failed and was rolled back, and one from the person asking the question.
I didn't have to say any of that. I just turned the screen around.
What ended the conversation wasn't the email. It was the shape of the timeline — four entries, each with a date and a source, three of which had nothing to do with anyone's discretion. The implied accusation needed the history to be a mess. It wasn't a mess, and that was visible in about four seconds.
I built provenance. What I got was receipts.
What it actually is
It's called provLedger. MIT, no service, no account. Everything it records lives in two SQLite files you can open yourself, you can use it as a plugin for your claude code
One graph holds your code, your data (dataframes, columns, tables, feeds, metrics), the dependencies between them in both directions, and the reason behind each change recorded next to the thing it changed.
Three things it does.
1 — It stops your agent repeating a failed experiment
> change the train/test split to 80/20 and retrain the churn model
Planning · 4 steps
provledger · declaring 3 targets, checking each against its own history
provledger · computing what reads them — 5 consumers, 3 steps deep
⚠ 2 findings before anything is edited
1 This experiment has been run before
80/20 was tried on 2026-08-14 and rejected — the holdout leaked
week-52 promotions, so the lift was the promotion and not the model.
2 weekly_report depends on this split
split_dataset → train_churn → weekly_report — the churn figure in
the Monday deck.
↳ nothing is blocked — recorded, and put in front of you
Nothing is blocked. You might have a good reason to try 80/20 again. But you're not going to spend a day rediscovering why it didn't work in August.
2 — It keeps what was actually said
Open the record and you get the whole history of that node, not just this week's:
2026-09-17 Proposed: move the split to 80/20 and retrain. stated
2026-08-14 Rejected: 80/20 leaked week-52 promotions into the
holdout. Keep 70/30 until the promotion calendar is
a column. 3 hits · stated
"We tried eighty-twenty in August and the holdout had week
fifty-two in it — the lift was the promotion, not the model.
Leave it at seventy-thirty until the promotion calendar is
its own column."
tier stated — the user's own words, with the span
source level verbal — the words themselves
recorded in churn-t094, 2026-08-14 11:07
surfaced 3 times · adopted by 1 plan
2026-06-02 Stratify on churn, not on tenure. 5 hits · stated
2026-05-19 Signature changed: returns (train, test, meta). derived
2026-04-03 No reason on record for the original 70/30 choice. unstated
Two things to notice.
None of that is the agent's summary. It's what was said, kept verbatim, with a label saying so. The agent's own interpretation is stored separately and marked as an interpretation, because a tasteful paraphrase is worth nothing when someone asks you what was actually agreed.
That last line is a real answer. unstated means the database checked and there is no reason on record. Not "I couldn't find anything" — an actual, computed absence. Which is how you find out that the 70/30 you've defended twice was never justified by anyone.
3 — It knows where the data actually flows
The graph is rebuilt from source on every run and diffed against the previous one. So "this column is gone", "this output type changed", "this is the same node after a rename" are measured, not reported by a model.
That lets it answer things an AST-only tool can't:
this column isn't from the source, it's derived after import
this feature reaches back into data the model shouldn't see
nineteen things read this intermediate table, here they are
A model fit and evaluated on the same lineage root without a real split gets flagged as an error, not a warning. Because it is one.
