> ## Documentation Index > Fetch the complete documentation index at: https://docs.scaling.cloud/llms.txt > Use this file to discover all available pages before exploring further. # What a finding says > A finding is a conclusion with the evidence attached. This is every sentence it can say, why a first appearance carries no numbers, and what you see when you open the evidence. When [an investigation opens](/guides/how-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. A rate claim — the same error suddenly firing far more often — was once the other half of this rule. It was [decided against rather than postponed](/guides/how-an-investigation-opens#what-it-does-not-do): no finding cites a rate, on any source, and there is nothing you could configure at your end to switch it on. ## 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](/guides/connect-a-source) 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](/guides/your-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: | Field | What it is | | -------------------------- | ------------------------------------------------------------------------------------------------------------- | | **At the source** *(name)* | The vendor's own timestamp — when it happened — labelled with which connected source sent it | | **Stored by us** | When the signal reached us and was written down | | The source's own id | What you search for in Sentry to find the same thing | | Surface | Where it happened, backend or frontend, when the delivery said so | | Why it is cited | Why this signal counts as evidence — today, always because its arrival is the appearance the finding is about | **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.