Product
Monitoring tells you it broke. Decim finds out why.
Something already told you a pipeline is wrong: an alert, a ticket, a finance team asking where the EUR totals went. Decim starts there and works until it can show you the cause, with evidence you can check line by line.
One incident, five parts
Decim is not one model answering a question. It is a sequence of parts, each producing something you can inspect before the next one uses it.
1. Connect what you have
An incident starts as a plain-language description. You can add the affected period, a scope (a repository, a pipeline or a step), a linked Jira ticket, and attachments up to 500 MB each. Behind that sit the integrations: the GitHub App for code, commits and pull requests; Google Cloud Logging for named log sources such as "Ledger load jobs"; Jira Cloud, read-only, for tickets; and, where logs live on Windows machines inside your network, the optional Windows agent. The full list, with what is planned, is on integrations.
2. Discover the pipelines in your code
Decim reads a selected GitHub repository and finds the pipelines in it, each defined by what starts it: a schedule, a queue consumer, a file arrival, a CDC feed, a batch command. For each one it builds a step graph with the code lines behind every step, including stored procedures kept in the repository. It reads code in any language. It only knows what the repository contains, and pipeline topology is explicit about what that leaves out.
3. Investigate
The investigation runs in phases you can follow on a timeline. It locates the pipeline and step your description points at, citing the code that made the match. It reads each step's logs, most suspicious first, against successful runs up to 30 days back. It weighs up to five competing explanations, with an independent critique pass. Where the deciding evidence sits somewhere Decim cannot read, such as a database, it writes a read-only check for a person to run. It confirms a cause only when evidence corroborates it.
4. Check every claim
Each finding cites its source: a file and line range, a commit, the exact log lines with their offsets and a hash, a ticket comment. The evidence page covers what is collected, how long it is kept, and how it is processed.
5. Fix and report
A diagnosis ends in a solution: an SQL repair Decim never runs, a repository patch checked to apply cleanly, both, or a plain statement that no fix is needed. One click opens a draft pull request on GitHub, and nothing is merged automatically. The whole incident exports as a PDF board report. Remediations walks through both.
Read each part in depth
Where a page needs a worked example it uses the same sample incident: the Nightly ledger load that stopped loading EUR rows on a Tuesday. You can follow one problem from report to pull request.
01
Pipeline topology
Pipelines discovered from a GitHub repository: each trigger, each step, and the code lines behind every step.
Read02
Investigations
Locate, read the logs step by step, weigh competing explanations, settle them, conclude. Shown as a timeline.
Read03
Evidence
Code, commits, log lines, tickets and attachments, each cited precisely enough to check by hand.
Read04
Remediations
An SQL repair, a repository patch, or both, delivered as a draft pull request. Nothing merged automatically.
Read05
The Windows agent
Optional. Reads on-prem directories, files and Windows Event Logs over outbound polling. No SQL.
ReadWhat Decim does not do
It does not detect problems: keep the monitoring you have. It does not connect to your databases or run SQL; when a query would settle a question, a person runs it and returns the result. It does not merge, deploy or restart anything. Database, scheduler and orchestrator connectors are planned, and the security page states plainly what is and is not in place today.
Get started
Bring us a pipeline that broke last week
The fastest way to evaluate this is a real incident you already know the answer to. If Decim gets it wrong, that is a far more useful demo than one where it doesn't.