Every finding carries two receipts

A finding carries the bytes in your repository that prove it and the exact sentence in your published document those bytes contradict. Neither is optional. The code that builds a finding returns an error when either is missing, so a finding without both cannot be constructed, stored or shown. If we cannot show you why, we do not tell you.

Why is this a rule rather than a habit?

Because the alternative is a product that generates plausible sentences about your compliance, and there are already several of those.

The moment a tool can say "you may have an undisclosed processor" without pointing at anything, it is guessing, and you have no way to tell a real finding from a confident one. The two receipts are what make the claim checkable in about ten seconds:

  FINDING
    |
    +-- content hash   the exact bytes we read, addressable and unchanging
    +-- verbatim quote the sentence from your live document, copied not summarised

Open the file at that hash. Read the sentence on your own website. Decide for yourself.

What does a finding look like?

Each one names the gap, the vendor, the file, and the sentence:

That last field is the load-bearing one. It is not a paraphrase of your policy and not a section reference. It is the sentence, so you can search your own document for it.

What stops it inventing a finding?

Three things, in order of how much they matter.

The document is read, not assumed. The scan fetches your published document from its public address, which is the same bytes a visitor to your site receives. There is no cached copy of what we think you published.

A vendor named anywhere in the document is never a finding. Including inside a denial. "We do not share your data with Stripe" contains Stripe, and a substring search would flag it. That sentence was written by a human on purpose and it discloses the relationship, so it is not a gap.

When it is unsure it produces nothing. This is a deliberate asymmetry. A missed finding costs you a stale sentence until the next push. A false finding tells you your lawyer-reviewed document is wrong when it is not, and the second one is how a tool stops being read.

Does a paid finding work differently?

The receipts are the same, and the rule is enforced in the same place. What changes is what can be found.

The deterministic scan sees what your code imports. The agent reads what your code does: where personal data flows server-side, what is retained and for how long, which region it lands in, what gets logged. That half is invisible to any scanner, and it is the half every questionnaire asks you about and believes your answer.

The agent's tools are read-only and resolve every path through a single snapshot manifest, so it cannot cite bytes it did not read, and the tool that records a finding refuses one that is missing either receipt. The rule does not relax because a model is involved. It gets stricter.

Frequently asked

Can I dismiss a finding I disagree with?
Yes, and it stays dismissed. You have context about your own system that a manifest does not carry, and a tool that re-raises something you have already judged is a tool you stop reading.

Why a content hash rather than a line number?
A line number describes a file at a moment. A hash describes the bytes. If the finding is still open in three weeks, the hash still resolves to what we actually read, and a line number would be pointing at whatever moved into its place.