What is web provenance and why does it matter?
Knowing where a claim about a website came from — and why "measured", "derived" and "inferred" must never be presented as the same thing.
Provenance is the record of how a claim was arrived at. In web analysis it separates something directly observed in a response from something computed from an observation, from something guessed at heuristically. Presenting all three with equal confidence is how analysis tools mislead people without stating anything false.
Four ways a claim can arise
| Kind | Meaning | Can it be wrong? |
|---|---|---|
| Measured | Observed directly in a response, handshake or DNS answer | Only if the observation itself failed |
| Derived | Computed deterministically from observations | Only if the computation is wrong |
| Inferred | A heuristic. Pattern-matching, likelihood, judgement | Yes, routinely |
| External | From a third-party source | As reliable as that source, which you did not verify |
Consider three statements that a typical report renders identically:
- "No
Content-Security-Policyheader." — measured. The header was absent from the response. This is a fact. - "GPTBot is blocked from
/blog/." — derived. The robots.txt rules were read and resolved against that path. Correct if the resolution logic is correct. - "This content appears machine-generated." — inferred. A heuristic over stylistic signals. Frequently wrong in both directions.
The third is a guess and the first is an observation. Shown side by side in the same list, at the same visual weight, a reader will treat them as equally solid — and act on the guess as though it were the fact.
Why this matters more for agents than for people
A person reading "appears machine-generated" applies natural scepticism to the hedging language. A model reading a JSON field does not — it receives a finding, and findings are things that are true. Without an explicit provenance label, a heuristic becomes a fact the moment it crosses into an agent's context, and everything downstream inherits false confidence.
provenance: inferred field survives serialisation.The related question: what was not examined
Provenance answers "how do you know this?" A second field answers "what did you not look at?", and the two together are what make a report honest.
Without a coverage statement, absence is ambiguous: no security findings might mean a clean site or an unexamined one. A reader — human or model — will default to the flattering interpretation, because that is the more plausible continuation.
What good provenance looks like in practice
- The observation is returned, not just the verdict. Not "HSTS missing" but the fact that no
Strict-Transport-Securityheader was present in a response you can go and check. - Heuristics are labelled as heuristics, in a field rather than in adjectives.
- Failure to determine is distinguished from a negative result, with the reason attached.
- The ruleset version is stamped, so a claim can be tied to the rules that produced it.
The test to apply to any analysis tool
Pick one finding and ask what it would take to disprove it. A measured claim has an obvious answer — read the header yourself. A derived claim has a slightly longer one — check the rule resolution. An inferred claim often has none, and if the tool did not tell you which kind you were reading, that is the finding about the tool.
What our audit reports about this
Every item below is measured directly, not inferred. Run it against your own site and the result names the exact rule or header responsible.
- A provenance label on every check — measured, derived, inferred or external — as a field rather than as hedged wording.
- The raw observation returned alongside every verdict, so any measured claim can be independently confirmed.
- Undetermined results reported with a reason, kept separate from negative results.
- A published coverage statement naming what is never examined, so absence of a finding is unambiguous.
For agents and scripts, the same measurement is at
/api/v1/summary?url=yoursite.com —
see the API documentation.
Related questions
Why report inferred findings at all?
Because they are useful when labelled. A machine-generated-content signal is worth knowing about; it just should not be weighted like a header observation. The problem is unlabelled inference, not inference.
Is "derived" as reliable as "measured"?
Nearly, and the distinction is still worth making. Derived means a rule was applied to an observation — so it is only as correct as the rule. robots.txt precedence in particular is a place where reasonable implementations differ.
What does external provenance mean here?
A finding sourced from a third-party service rather than from direct observation. Nothing in Outrings currently uses one — the category exists so that if anything ever did, it would be labelled rather than blended in.
How does this help an AI agent?
It lets the agent weight its own statements. A finding marked inferred can be reported as a possibility; one marked measured can be reported as a fact with the evidence quoted. Without the label, both come out sounding identical.
Read next
What is evidence-based website analysis?
The difference between a tool that tells you a verdict and one that shows you what it saw — and why the second is worth insisting on.
ReadWhat should an AI agent do when it cannot determine something?
Why "not checked" and "passed" must never be the same answer, and how a well-built tool keeps them apart.
ReadWhy do LLMs hallucinate website audits?
The specific reason a model invents plausible findings about your site, and the two design choices that stop it.
ReadWhat is a deterministic website audit?
Why running the same audit twice should give the same answer, what breaks that property, and why it matters more than accuracy.
Read