One signed answer before an agent acts.

What an AI agent should know about a domain before it reads, cites, connects or transacts, as one signed document. Any tool may read it, cache it, verify it offline and build on it. This page is the specification; the change log at the end is its history.

JSON Schema · machine-readable spec · API reference with worked examples · offline verifier · signing keys · Resolve over DNS · observer protocol

MCP: the tool resolve_domain on https://crawlcheck.io/mcp returns the same document.

kind: "crawlcheck-resolve", v: 1. status is measured, partial (a domain never measured before, read live in about a second; assurance says how much was read and upgrade when the full scan replaces it), not_measured (a measurement is requested), opted_out or withheld (the answer is held back, for example because the opt-out list could not be read or no signing key is available; ask again shortly). Treat any status you do not recognise as not measured: never act on it. Each section carries state: declared (what the site says about itself), observed (what CrawlCheck was served) or not_measured, and observed_at. There is deliberately no overall score: an agent decides on the section its action depends on, or takes the decision in actions.

sha256 is the SHA-256 of the canonical JSON of every field except sha256 and signature (keys sorted at every level, no whitespace). signature.sig is Ed25519 over the message prefix crawlcheck-data-v1\n followed by that digest. The key is named by signature.kid and published in /.well-known/http-message-signatures-directory; a retired key leaves that directory when its 7-day overlap ends and stays in the rotation record, so what it signed before then still verifies. Which key signs which kind of document, from when, and what takes over if a key is compromised is set by one rule set: the signing policy.

Online: node crawlcheck-verify.mjs --online answer.json fetches the key directory, so keys retired or declared compromised since are known. Offline: save the directory once (curl -o keys.json https://crawlcheck.io/.well-known/http-message-signatures-directory) and run node crawlcheck-verify.mjs --keys keys.json answer.json; nothing is fetched, so a key compromised after you saved the file is not known until you refresh it. With neither, the signature and digest are checked but the issuer is unknown and the answer is not accepted. Node 20+, no dependencies; the same checks run in @crawlcheck/sdk and crawlcheck on PyPI. It recomputes the digest, checks the signature against the published key and reports which check failed. transparency carries the answer’s leaf and inclusion path, which fold to a signed tree head a witness we run on GitHub co-signs. Every answer is also a leaf in that day’s Merkle root, anchored with OpenTimestamps; /api/seal/lookup?id=&day= says whether a leaf is in the sealed root.

v in the document changes only when a field is removed or its meaning changes; such a change ships as a new version beside the old one, never in place. Added fields and added endpoints raise the minor number of this specification. Readers must ignore fields they do not know.