From an empty workspace to a diagnosis

GitHub is where Decim learns what your pipelines are, and where fixes land. Access is through the Decim GitHub App, limited to the repositories you choose.

1. In the admin, open Integrations → GitHub and choose Connect GitHub. Decim generates a short-lived installation link.
2. On GitHub, install the App on an organization or account and finish authorization.
3. Back in Decim, choose the repositories this workspace uses on the Repositories tab.

Decim reads code, commits and pull requests from those repositories. The only write it makes is opening a draft pull request, and only when a person clicks to open one. Removing the workspace's access stops further reads; data already saved is retained. GitHub is the only source-control provider today. More on what is read: GitHub integration.

Cloud Logging is where an investigation reads what a run actually did. You grant read-only access once per GCP project and decide exactly which logs are in scope.

1. Open Integrations → Google Cloud Logging and choose Connect a GCP project.
2. Choose the project and define one or more named log sources. Each is a Cloud Logging filter with a name a person recognises.
3. Sign in with a Google account that can view the project's logs and grant the read-only logging.read scope.

Investigations read only inside the filters you set, so keep them specific: one source per pipeline or job family reads faster and cites more precisely than one filter for the whole project. A step whose logs fall outside every source ends as an honest gap, not a guess. Repeat for each project.

1. Open Integrations → Jira and connect a site. You sign in with Atlassian and grant Decim read access.
2. When you open an incident, search for an issue by key, by text, or by pasting its link.

Linking an issue imports its description, comments and attachments as an immutable snapshot. The investigation uses that snapshot as evidence — the locate phase ranks pipelines against the ticket as well as your description — and the snapshot does not change if the ticket is edited later. Decim never comments on, transitions or edits an issue.

Only needed when the logs or files an investigation needs live on Windows hosts inside your network. Decim works without it.

1. Open Agents, register an agent and create its one-time key. You can scope the agent to a pipeline.
2. Install the MIT-licensed service on a Windows x64 host and give it the key. It connects outbound only and polls for work; nothing connects in.
3. Investigations send it tasks automatically. You can also create a task by hand from the agent's page.

The agent has three tasks: list a directory, read a file (by byte range) and read the Windows Event Log. It runs no SQL, connects to no database and does not redact. Raw payloads are purged three days after the incident closes; cited excerpts stay with the record. More detail on the agent page.

1. Open Pipelines and choose Add a repository from those you connected.
2. Run Discover pipelines. Decim reads the code 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.
3. Open a pipeline to see its step graph — sources, transformations (including stored procedures kept in the repository) and destinations — with the code lines behind each step and the reasoning discovery recorded.
4. Rescan after significant changes. A pipeline keeps its identity when the same trigger is found again, so incidents and history stay attached to it.

Each connection between steps is marked direct or inferred, and steps where things tend to break are flagged as points of interest. Discovery reads code in any language; there are no format-specific parsers. It knows only what is in the repository: a job defined only inside a scheduler or cloud console is not seen yet. More on pipeline topology.

1. Open Incidents and choose New incident.
2. Describe what is wrong in plain words, as you would to a colleague.
3. Optionally add the affected period; a scope (a repository, pipeline or step); a Jira ticket; and files up to 500 MB each — logs, exports, screenshots.
4. Create the incident. The investigation starts straight away.

A good description names the symptom and when it started: “Transaction volume dropped by 38% in the nightly ledger load. Finance says the EUR totals have been missing since Tuesday.” Decim does not need you to know which step failed — finding that is its first job.

The incident's timeline shows the investigation as it runs, phase by phase. Nothing is hidden in a transcript: each phase leaves records you can open.

1. Locate. Discovered pipelines and steps are ranked against your description and ticket, citing the code (file and line range) behind the match. If nothing matches well enough, Decim asks for more context.
2. Read the logs. The most suspicious steps are walked first, with logs pulled from Cloud Logging or the agent within fixed limits. Each step ends as looked fine, found something or an honest gap. The failing run is compared with successful runs up to 30 days back, and exact log lines are cited with offset or record ID, excerpt and hash.
3. Weigh explanations. Up to five competing hypotheses, each with a confidence, evidence for and against, the code involved and the tests that would settle it. An independent critique pass challenges them. Revisions are numbered; rejected hypotheses are kept with the evidence that ruled them out.
4. Settle it. Explanations are tested against everything collected. When the deciding evidence is somewhere Decim cannot read, it writes a check (below).
5. Conclude. A cause is confirmed only with corroborating evidence, never on confidence alone.

Every investigation ends in one of four outcomes: Cause found (a diagnosis), Likely cause (provisional), Cause unclear (the evidence does not settle it) or Needs log access (an instrumentation gap). At any point you can challenge a conclusion or add files, and the investigation revises. More on how investigations work.

Decim does not connect to databases. When the evidence that would settle a hypothesis lives in one, Decim writes a check for a person to run instead. A check is one of three things: a read-only SQL query, validated against a read-only allowlist and never executed by Decim; a file to fetch; or guided steps.

1. Open the incident's Checks and read why the check was written — which hypothesis it tests and what result would confirm or reject it.
2. Run the query with your own access, fetch the file, or follow the steps.
3. Paste or upload the result. It becomes evidence and triggers a new revision of the hypotheses.

Once a cause is found, the Solutions tab proposes what to do about it. A solution can be:

• an SQL repair — a diagnostic SELECT, one bounded UPDATE and a regression SELECT, for you to run; Decim never runs it;
• a repository patch — checked to apply cleanly, never built or run;
• both, or no fix required;
• or blocked, listing the inputs it still needs.

Review the patch and its reasoning, then choose Open a draft pull request and confirm. The pull request opens on GitHub as a draft, for your normal review and CI. Nothing is merged automatically. More on remediations.

From the incident, choose Export → Board report · PDF. The report contains an executive summary, the investigation timeline, the root cause with its confidence, the evidence, how it was verified, the remediation and an appendix. Exporting an incident that is still in progress produces a clearly marked interim report. JSON exports are available too.

People sign in with single sign-on — Microsoft Entra ID, Google or GitHub — or with a password, and join a workspace by invitation.

Audit logs records every user action in the workspace: the actor, the action, the target and the outcome. Filter by date (times are UTC) and export the result as CSV or JSON. Workspaces are isolated from one another, and OAuth grants are encrypted at rest. Retention and data handling are on the security page.