A diagnosis ends in a fix you can review

The sample investigation, from the product's demo workspace, ends with a confirmed cause. Tuesday's release, commit 9f3c2e1, replaced a hard-coded currency list in the stored procedure stg.usp_load_transactions with a parameter, @Currencies, defaulting to 'USD,GBP'. The nightly job calls the procedure without the parameter. Every EUR row, about 41,000 a night, has been filtered out of staging since, and the step has reported success with zero errors every time. The investigations page shows how that was established.

For the engineer who picks this up, the diagnosis is the start of the second half. The procedure has to change, and so, arguably, does the job that relies on its default. Four nights of EUR rows are sitting in the raw export, marked as loaded, and need to be loaded again without duplicating anything already in staging. The reload has to happen after the fix is deployed, not before. Someone has to confirm it worked, and someone has to tell finance which figures were wrong and when they will be right.

Each of those steps is a chance to cause a second incident. A solution from Decim does not make those decisions better than your team would. It makes sure the mechanical parts arrive written, scoped and in order, and that the decisions arrive marked as decisions.

There is a pull towards making every fix a diff, because diffs are familiar and reviewable. It produces nonsense: a pull request that claims to reload rows it cannot touch, or a change to code that was never the problem. So a solution takes one of five forms, and the form tells you who does what.

The sample incident needs both: a patch to stop EUR rows being filtered from tonight onwards, and an SQL repair to restore the four nights already lost. The rest of this page walks through each.

Data repairs go wrong in predictable ways: an UPDATE with a WHERE clause slightly wider than intended, a reload that duplicates rows already present, a fix applied before the code that caused the damage is gone. The three-part shape is there to make each of those visible before anyone runs anything.

1. A diagnostic SELECT measures the damage first. If its result does not match what the diagnosis predicts, stop: the repair is aimed at the wrong thing.
2. One bounded UPDATE makes the change. Bounded means explicit dates, an explicit scope, and an expected row count stated beside it, so an unexpected count is caught rather than committed.
3. A regression SELECT proves the repair worked, by comparing the repaired data with an independent reference.

Decim writes the repair. It never runs it: Decim does not connect to your databases. A person on your team reads it, runs it where it belongs, and decides when. For the sample incident the repair is below. Table and column names come from the sample repository.

The regression check compares staging with the export, not with itself. A check that asks "are there EUR rows in staging now" would pass after a partial reload. A check that asks "is every exported EUR row staged" cannot.

Because pipeline discovery has already linked the stg_transactions step to sql/stg/usp_load_transactions.sql and to the job spec that calls it, the patch is written against the exact lines the investigation cited. Before it is offered, Decim checks that it applies cleanly to the repository. It does not build, compile or run it: that is what your CI and your reviewers are for.

The diff is small, which is typical. Most pipeline incidents resolve to a few lines; the difficulty was never the typing. It changes two things, for different reasons. Restoring the default puts the procedure back to the behaviour it had before Tuesday. Passing the list explicitly from the job step means the next change to the default cannot silently drop a currency again, because the job no longer depends on it.

Whether to keep a default at all is a design question for your team. Removing it would make every caller state its currencies, which is safer and breaks any caller that does not. The patch takes the conservative option and leaves that decision visible in review.

From the solution, one click opens the pull request. It opens as a draft, on its own branch, in the repository the patch belongs to. Your checks run on it exactly as they would on a branch pushed by a colleague, and it waits for a person to review it, mark it ready and merge it. Nothing is merged automatically, at any confidence.

In the sample workspace the result is draft pull request #482, "Restore EUR in the ledger currency filter". Its description carries the reasoning, so a reviewer can check why the change is right without opening Decim.

Note the last section. The pull request fixes the code and says plainly what it does not do. The data repair is not hidden inside a migration that runs on deploy; it stays a separate artefact for a person to run, in the order the callout above describes.

No fix required

Some incidents need no change. An upstream file arrived late once and the next run caught up; a dashboard was read before the night's load finished; the "missing" rows were filtered on purpose by a rule nobody remembered. A solution that says no fix is required, with the reason, is a result. It stops a well-meant change to code that was working, and it records why the incident closed.

Blocked

Sometimes Decim knows the cause but cannot write a responsible fix. The code involved may be in a repository that is not connected; the deciding check may not have been run yet; the cause may be clear enough while the affected range is not. In those cases the solution is blocked, and it lists the inputs it still needs. A blocked solution that names what is missing is more useful than a confident patch built on a guess.

Every solution ends with a person. That is partly about safety and mostly about knowledge: the people who run the pipeline know things no evidence trail contains, such as a freeze before month-end, a downstream consumer that cannot take a reload mid-morning, or a finance team that needs a warning before figures change.

In the sample, the diagnosis was confirmed at 92%, corroborated by the log lines, the commit diff and a row count the team ran. That is strong evidence about what happened. It says nothing about whether the reload should run tonight or after month-end close, whether the finance dashboard for the affected days needs a correction notice, or whether the procedure should keep a default at all.

A good solution makes those questions explicit instead of answering them quietly. That is the real argument for draft-by-default. It is not that the patch might be wrong, though review catches that too. It is that a fix carries business decisions the evidence cannot settle.

An incident like the missing EUR totals does not stay with engineering. Finance wants to know which numbers were wrong and when they will be right; a manager wants to know whether it can happen again. The PDF board report answers both from the same record the engineers worked from, in this order.

The remediation section is where the solution reaches a wider audience: the kind of fix, the patch and SQL repair where there are any, and what is still waiting for a person. Because it sits after the evidence and the verification, a reader can see that the fix follows from a checked cause rather than from a guess.

An incident still in progress exports as a clearly marked interim report, so you can brief people before the investigation concludes without presenting a provisional answer as final. The same record is also available as JSON for your own tooling.

Related: investigations for how the diagnosis is reached; evidence for how log lines and commits are cited; pipeline topology for how the failing step was tied to its code; and security for what Decim can and cannot access.