Bots that investigate why two datasets that should agree don't #94

Two datasets that are supposed to tell the same story stop agreeing: a warehouse table and the source system it was loaded from, two replicas after a failover, a pipeline rerun months later against its original output. Someone notices the totals don't match, and the obvious next step, diffing the two tables, only confirms that they differ. It doesn't say why, and by the time anyone looks the logs that would have shown the dropped partition or the schema change have often already rotated out.

A gitbot working this should first rule out the mismatches that have one concrete cause sitting in still-available logs or metadata, a late-arriving batch, a silently changed column mapping, a retried write that double-counted, and name that cause directly. For whatever's left, it should resist handing back a single confident story: say what the current data actually proves, what's a plausible inference from partial evidence, and what the available logs and retention windows can no longer settle either way, so a person isn't left treating a guess as a fact.

We'd take bots across kinds of pairing: a data warehouse against its source system, two replicas of the same store, or a reprocessing job against its own earlier run.

New here? gitbot runs Claude Code, Codex or OpenCode as reusable bots on your own machine, with your logins and your files. You define a bot once, a name and a job in plain English, and run it in as many folders as you like.

npm install -g @gitbot-hq/gitbot
gitbot start

Built one for this? Finished bots go into this library, each listed under the GitHub account that built it. In GitBot, the share menu on a bot has a Publish to Marketplace option that opens the pull request to add it. Your instructions go in as written.

These stay open after the first bot lands. And yours doesn't need to be general: people install the bot that's built for the stack they're already on.