Record found and verified

What this proves, and what it does not

It proves the check outcomes are as they were written. A record cannot move to another host, rubric version, or scope and still match its fingerprint. Neither can a check's status, points, counted flag, or exclusion change. Neither can an unscored check's state. The score and level follow from them under the scope the record names.

Not everything is bound. An edit to any of these is not caught:

• the measured origin
• the redirect
• the defect flag
• every detail, evidence and fix text

It binds the scope. The site profile, the commerce module, and the agent signal kinds are part of the fingerprint. They decide the dimension factors, the checks each level requires, which checks are out of scope, and the highest level the site can reach. When no check was scored, whether the scan was refused is read from the record.

It does not prove the measurement is correct. It proves only that these check outcomes are the ones that were published. For correctness, re-run the scan.

Of the 60 checks, 3 are evaluated against a clock, so they can change with no change to the site:

• security-txt reads as present only while its Expires field is in the future.
• status-page reports a partial pass once the newest entry in a linked feed is more than 180 days old.
• inventory-freshness reports a partial pass once an Offer’s priceValidUntil is before the scan date.

When one changes, the fingerprint changes with it. A difference there is not a finding.

Other things change a result with no change to the site. A request with no response within 12 s counts as no response, so the same bytes served slowly can change a check. A scan that reaches its 60 s deadline is not measured at all. dns-aid reads DNS. When the DNS-over-HTTPS resolver answers no question, it is not measured. A question that fails while others answer reads as no records. A difference that comes from one of these is not a finding either. A difference in any other check is a difference in what the site returned.

It is not a directory listing. Being listed is a separate claim that only exists while the site itself carries the verification token we issued. A fingerprint matches a record we hold; it does not mean the host endorses it, or that it is in the directory.

fingerprint = SHA-256( JSON( { v: 3, host, rubric, scope, checks: [ [check_id, status, round(points, 3), counted ? 1 : 0, exclusion, discoveredBy if any], … ], unscored: [ [check_id, state], … ] } ) ), rows sorted by check id in code-point order

The mcp-server row has a sixth element, discoveredBy, when the scan found an MCP endpoint. No other row has one.

The bytes hashed for an example record with 4 scored checks and 2 unscored checks: {"v":3,"host":"example.com","rubric":"0.9","scope":{"profile":null,"commerce":false,"agent":[]},"checks":[["llms-txt","fail",0,1,""],["meta","warn",0.667,1,""],["product-schema","na",0,0,"out-of-scope"],["reachable","pass",1,1,""]],"unscored":[["faq-schema","present"],["security-txt","absent"]]}

Its fingerprint: a7cf0c2b058c35a97d2acde9f195486e4f9e2e110dfdb2715a097f4c982a3cce

serialisation v3 · a record measured under an earlier rubric is not shown · rubric v0.9 in force today