Four sources today, the rest planned

A connector in most products is a pipe: it extracts data and loads it somewhere else. Nothing on this page works that way. Each source is read during an investigation, inside limits you set — the repositories you chose, the log filters you defined, the ticket you linked, the directory a task names — and what an investigation reads is cited back to you with a pointer precise enough to check: a file and line range, a log record ID, a byte offset.

The sources do different jobs. GitHub is how Decim learns what your pipelines are, and where most fixes land. Logs — from Cloud Logging, or from a Windows host through the agent — are how it learns what a run actually did. Jira carries the symptom in the words of the person who saw it. What none of them reach, typically a database, Decim asks for: it writes a read-only check for someone on your team to run, and the result goes back into the investigation.

Evidence is processed by a third-party language-model provider, and there is no redaction today. The full posture — retention, encryption of OAuth grants, tenant isolation — is on the security page.

How it connects

Install the Decim GitHub App on an organization or account, then choose which repositories this workspace uses. Decim reads only those repositories. The one write it can make is opening a draft pull request, and only when a person clicks to open one. GitHub is the only source-control provider today; GitLab, Azure Repos and Bitbucket are planned.

How an investigation uses it

GitHub is where Decim learns what your pipelines are. Discovery reads a selected repository and finds each pipeline by its trigger — a schedule, cron expression or Hangfire job, a queue consumer, a file arrival, CDC, or a batch command — then builds a step graph of sources, transformations and destinations with the code lines behind every step. Each connection is marked direct or inferred, and the places where things tend to break are flagged as points of interest. It reads code in any language; there are no format-specific parsers.

During an investigation the same repository is evidence. The locate phase cites the file and line range that matched the incident to a pipeline. Hypotheses cite the code involved. A commit that changed a filter on the day the symptom started is cited by hash, with its diff. When a solution includes a repository patch, Decim checks that it applies cleanly and, when you ask, opens it as a draft pull request for your normal review.

Limits

• Discovery knows only what is in the repository. A job defined only inside a scheduler or a cloud console is not seen yet.
• Patches are checked to apply cleanly. Decim never builds, runs or merges them.
• GitHub only. Other source-control hosts are planned.

Connecting GitHub

How it connects

Sign in with Google once per GCP project and grant the read-only logging.read scope. Then define named log sources: each one is a Cloud Logging filter with a name a person recognises, such as “Ledger load jobs”. Investigations read only inside those filters. Decim cannot write logs, delete them or change log routing.

How an investigation uses it

In the read-the-logs phase, Decim walks the suspected steps most-suspicious first and pulls each step's entries from the log sources that cover it. Collection is bounded — a limited number of requests, bytes and model calls — so a broad filter cannot turn into an open-ended crawl.

Each step ends in one of three ways: looked fine, found something, or an honest gap such as no logs or not enough logs. A finding cites the exact entries and compares them with the same step on successful runs. In the sample incident the failing night logs rows loaded for USD and GBP and no EUR line at all, where the night before logged Loaded 40903 rows for EUR.

Limits

• Reads only inside the filters you define. A step whose logs fall outside every named source ends as a gap, not a guess.
• Google Cloud only today. AWS CloudWatch Logs and Azure Monitor log reading are planned.
• Only what was logged can be cited. A step that logs nothing about row counts cannot be reconciled from its logs.

Connecting Cloud Logging

How it connects

Connect a Jira Cloud site with Atlassian sign-in and grant read-only OAuth access. Decim searches issues so you can link one to an incident; it never comments on, transitions or edits an issue.

How an investigation uses it

A ticket often holds the clearest description of the symptom, written by the person who saw it: “EUR totals missing from the daily finance dashboard since Tuesday.” Linking it imports the description, comments and attachments as a snapshot that does not change if the ticket is edited later, so the record cites exactly what the investigation read.

The locate phase ranks discovered pipelines against both the incident description and the ticket. Screenshots and exports attached to the ticket sit beside the logs and code as evidence.

Limits

• Jira Cloud only today. ServiceNow and Azure Boards are planned.
• The snapshot is taken when the issue is linked; it is a record of that moment, not a live mirror.
• Read-only. Decim does not post the diagnosis back to the ticket.

Connecting Jira

How it connects

An MIT-licensed service for Windows x64 that you install on a host inside your network and register with a one-time key. It connects outbound only and polls for work; nothing connects in to it. It is one optional collection path, for logs and files that live on on-prem hosts — Decim works without it.

How an investigation uses it

When a step's logs live on a Windows host rather than in Cloud Logging, the investigation sends the agent a task — list this directory, read these bytes of this file, read this Event Log for this window — and the result comes back as evidence. Cited lines carry the byte offsets they were read from, the excerpt and a hash, so anyone can open the same file and check them.

Those three tasks are the whole surface. The agent does not run SQL, does not connect to databases and does not redact. Raw payloads it returns are purged three days after the incident closes; the excerpts an investigation cites are kept with the record.

Limits

• Windows x64 only. A Linux agent is planned.
• No SQL and no database connections. Database evidence comes from checks your team runs.
• No redaction today. What the agent returns is processed like any other evidence.

The agent in detail

Today an incident starts from a plain-language description, optionally with an affected period, a scope (repository, pipeline or step), a linked Jira ticket and attached files. Opening incidents directly from an alert — Datadog, PagerDuty, Amazon CloudWatch or a custom webhook — is in preview, shown in the admin with sample data and clearly labelled as such. It is not generally available, and none of these tools is read as an evidence source.

The intent is the same division of labour as today, with less copying: your monitoring decides that something is wrong, and Decim starts from that alert to find out why.

Pipeline definitions live in different places on different platforms, which is why one integration per platform is needed and why a repository alone is not always enough. The pages are worth reading before an incident either way: the views, columns and retention limits they name are the ones to know when you are investigating by hand.

• Read-only. The one write anywhere is opening a draft pull request on GitHub, when a person asks for one. Nothing is merged automatically.
• Scoped and bounded. Investigations read inside the repositories, log sources and tasks you defined, with limits on requests, bytes and model calls.
• Cited. Every finding points at the evidence behind it: a file and line range, a commit, a log record ID or byte offset, an excerpt and a hash.
• Retained briefly. OAuth grants are encrypted at rest. Raw agent payloads are purged three days after an incident closes and attachments after seven; cited excerpts stay with the record.
• A stated limit. Every source above, and every planned page, says what it cannot tell you.

Step-by-step setup for each source is in the documentation.