What a finding says

When an investigation opens, the product posts a finding: the conclusion it reached, in its own words, with the stored signals it reached it from attached to it. A finding is not a summary of your data. It is a claim, and everything on the page is there so you can check the claim.

​

A finding cannot exist without evidence

Every finding cites at least one signal we have stored, and it is refused at the point of writing if it cites none — not by the screen, which nothing in this path passes through, but by the database itself. That is the product’s whole position, made structural: a conclusion with nothing behind it is an opinion, and this product does not ship opinions.

​

The claim, for a first appearance

There is one claim the rule can make, and it reads:

This fingerprint has never been stored for this organisation before.

Where we know which surface the error came from, one more sentence says so — It arrived on the backend, or the frontend. That is the whole claim. It carries no count and no time window, and the absence is deliberate rather than missing data. “This error has occurred 1 time in the last 24 hours” would be true, and it would be worse than saying nothing. It reads as a measurement, so it invites you to weigh a number — and the number means nothing, because a first appearance has no threshold to have crossed. What is actually true is that we have never seen this here before, so that is the sentence, and there is nothing else in it. The finding says so on the page, next to the evidence, so the absence reads as a decision rather than as data we failed to gather.

​

The release line is always there, even when we cannot name one

An error your source attributed to a build gives you:

Attributed to the release the error named.

An error that arrived without one gives you this instead, in the same place:

This finding cannot name a release. The delivery it arrived on did not carry the build string — a gap in what we were told, not a statement that no release was involved.

The line is never simply left out. Silence where a release would appear reads as no release was involved, which is a different claim and usually a false one. Whether we can attribute a finding is a property of the finding, not a condition of you getting one. Sentry’s issue delivery carries no release at all; its alert rule delivery does. If most of your findings cannot name a release, that is what it is telling you, and connecting the other delivery is the fix. The release string is your build’s own, exactly as your source sent it. It is never matched against anything of ours, and never turned into a guess about which of your deploys caused what.

​

A finding held through a source’s first fortnight

A finding raised while its source was still in its first fortnight does not reach you until that fortnight ends, and when it does it says so: when it was raised, when the error was seen at your source, when it was released, and whether the error has been seen again since. A finding raised today carries none of that, so the two never read the same.

​

The evidence, and its two clocks

Under the claim is every signal the finding cites. Each one opens, and what it opens to is the stored signal itself: Both timestamps are shown, labelled separately, always. The vendor’s is what you recognise when you go and look in Sentry. Ours is the one every window this product measures is read against, and the two are not interchangeable: they can be months apart when a team switches a webhook on over a project that already has years of history behind it. One undifferentiated time would leave you unable to use either.

​

What is on the page cannot change afterwards

Signals are append-only, and the evidence a finding cites is those signals. An attempt to edit one is refused by the database, not merely absent from the product — so a finding you read today says the same thing next year, and cites the same evidence. The one thing that removes stored signals is a deliberate deletion you ask us for in writing, which we act on within seven days. When evidence goes, the findings made from it go with it. Nothing is left behind quietly disagreeing with itself. Findings themselves are append-only for the same reason. If the product later concludes something different about the same error, that is a new finding rather than an edit to this one.