Every finding, one click from its proof

Academic work carries citations; incident reports usually do not. In a paper, an uncited claim is a defect anyone can point at. In an incident report, "we think the currency filter changed" sits comfortably next to "the currency filter changed", and a reader six weeks later cannot tell which was established and which was inferred at two in the morning.

That ambiguity costs twice. During the incident, a plausible claim gets acted on before anyone checks it. Afterwards, the report becomes the record of what happened, and nobody can work out which parts were solid.

So a Decim finding is not written first and supported later. Each observation is saved with the evidence it cites, each hypothesis lists the evidence for and against it by reference, and the diagnosis rests on those. Here is how an observation from the worked investigation renders, using sample data from the demo workspace:

Every line under the observation is a citation, not a quotation someone typed. The claim ("EUR rows stop arriving in staging") is above; the evidence is below; and the baseline from the night before shows what the step normally logs. The finding is the difference between the two.

Different questions need different evidence, and each kind is cited in the way that makes it checkable. A log entry is identified by where it sits in what was collected. Code is identified by a file, a line range and a commit. An attachment is identified by its content hash. A check result is identified by the check that asked for it.

During an investigation Decim reads logs step by step: from Google Cloud Logging through the named log sources you defined, through the optional Windows agent for files and Windows Event Logs, and from log files attached to the incident. Each read is a collection task, and its result is stored with a SHA-256 hash.

When an observation cites a line, it records the task, the position of the excerpt, the excerpt itself, and the hash. For record-based sources — Cloud Logging entries, Event Log records — the position is the record, plus a byte range within its message. For files, it is a byte offset and length in the file. The simplified record below is the first cited line in the example above:

The same line read from a log file through the agent is cited by byte offset instead:

A failing run read on its own invites over-interpretation. A warning that appears every night, a slow step that is always slow, a retry that always succeeds: each looks suspicious in isolation and means nothing. So for each step Decim also reads successful runs, up to 30 days back, and cites them as a baseline next to the finding.

In the example, the baseline is one line from the previous night: Loaded 40903 rows for EUR. It turns "the log has USD and GBP lines" — which is unremarkable — into "the log has USD and GBP lines and is missing the EUR line it has had on every previous run", which is the finding. Baseline citations carry the same location, excerpt and hash as any other citation, and the PDF report prints them under the heading "what normal looks like".

"There was no EUR line on Tuesday" is a finding, and it is the finding the example turns on. But a negative is weaker than a positive: it depends on having read the right source over the right window. A missing line in a log that was only partly read means nothing.

So Decim records what it could not read as explicitly as what it found. A step whose source returned nothing ends as "no logs"; a step with too little to judge ends as "not enough logs"; a source that could not be reached ends as "collection unavailable". When a Cloud Logging read hits its entry or size limit, the gap says so and asks for a narrower window or filter. When a large file is sampled rather than read in full, a citation that falls between the samples is refused. That is why the example's absence carries weight: the run was read continuously, and the baseline shows the EUR line on the night before.

Decim reads code, commits and pull requests from the GitHub repositories you selected. When a hypothesis or a pipeline match cites code, it cites a file and a line range from a snapshot of the repository frozen at a specific commit, together with the excerpt. Later commits do not move the citation: sql/stg/usp_load_transactions.sql, lines 4–9, means those lines at that commit, not whatever is there today.

Commits are evidence in their own right. In the example, the diff of 9f3c2e1 is what shows the hard-coded ('USD','GBP','EUR') list becoming a parameter @Currencies with a default of 'USD,GBP'. The hypothesis cites the changed lines, and the report labels the excerpt with the commit it was read at.

If a hypothesis was formed against a different revision of the code from the one the pipeline was matched on — the repository moved during the investigation, say — the hypothesis carries a visible note saying so, so you know the two pieces of reasoning looked at different code.

Jira ticket snapshot

When you link a Jira Cloud issue to an incident, Decim imports its description, comments and attachments once, as an immutable snapshot, over a read-only connection. The investigation reads that snapshot. If someone edits the ticket, adds a comment or deletes an attachment afterwards, the evidence the investigation used is unchanged, and the snapshot is reproduced in the report's appendix as the source ticket. In the example, FIN-2291 ("EUR totals missing from the daily finance dashboard since Tuesday") is what pointed Locate at the finance dashboard and, through it, at fact_transactions.

Attachments

You can attach files to an incident at any time, up to 500 MB each: log exports from systems Decim cannot reach, data extracts, configuration files, screenshots. Text files are cited the way code is, by file name and line range with the excerpt, plus the file's SHA-256 and the version of the upload, so a citation always points at the exact file content that was read. A log export attached to the incident can serve as a baseline as well as a finding.

Some questions can only be answered where Decim has no access, most often a database. For those, Decim writes a check: a read-only SQL query validated against a read-only allowlist, a file to fetch, or guided steps. Each check states which hypotheses it tests and, before anyone runs it, what result would support them, refute them, or leave the question open. Decim never runs the query; your team does, with their own access.

The submitted result — pasted output, an uploaded file, an explanation — is stored against the check with the time it was submitted, the submission appears in the workspace audit log, and it starts a new revision of the hypotheses. In the example, the team's result showed EUR row counts in staging falling to zero on 13 October while USD and GBP held steady. That result, the cited log lines and the commit diff are the three independent pieces of evidence the diagnosis rests on. Because the check wrote down its criteria in advance, you can see that the result was read against a standard set before it came in, not one chosen after.

In the incident view, each observation from the log sweep expands to its cited lines and its baseline. Each hypothesis lists the evidence that supports it and the evidence that contradicts it, by reference, along with the code it cites and the tests that would settle it. A diagnosis points at the hypothesis it confirms, and that hypothesis points at its evidence. You can walk from the headline down to a single log line without leaving the incident.

The one-click PDF report keeps the same links on paper, so someone who never opens Decim can still check the reasoning. An incident that is still in progress exports as a clearly marked interim report, and the same record is available as JSON.

Evidence is gathered for one incident, around one pipeline and one time window. There is no continuous log collection from your systems; Decim reads what the investigation needs, within the request, byte and model-call limits each investigation has.

Once an incident closes, the raw material is purged on a short schedule. What remains is the record: the excerpts that were cited, with their location and hash, alongside the reasoning built on them. That is enough to show what the conclusion rests on without keeping whole log files indefinitely.

Related: investigations for how evidence settles hypotheses; the agent for how files and Windows Event Logs are collected on your own servers; security for retention, access and processing.