{"trust_ladder":{"A0":{"name":"Claimed","what_is_proven":"An entity record has been claimed. A self-service A0 record is not made public until domain control is proven at A1. Its facts are either self-declared by the owner or auto-collected by the registry from public sources (see each fact's attestation_status and source); none have been independently verified."},"A1":{"name":"Domain control","what_is_proven":"The owner proved control of the entity's domain by publishing a registry-issued cryptographic token via DNS TXT or an HTTPS /.well-known file; the registry checked it server-side."},"A2":{"name":"Payment-verified","what_is_proven":"In addition to A1, a payment provider confirmed a successful payment started from the authenticated owner account for this entity. The registry validates the signed webhook, payment status, amount, currency and entity metadata. This does not verify payer or cardholder identity, provide KYC, or verify passport facts."},"A3":{"name":"Organization","what_is_proven":"The entity's legal identifier and name were matched server-side against a supported public organization registry (currently VIES or GLEIF)."},"A4":{"name":"Named attestation","what_is_proven":"In addition to A3, a named person recorded a declaration taking responsibility for the passport version identified by the attestation's passport_hash. Compare that hash with the current passport_hash to determine whether the declaration covers the current version. This is an auditable cabinet declaration, not a qualified electronic signature."}},"agent_guide":"How to use this registry as an AI agent: 1) resolve an entity via https://intesta.io/.well-known/intesta/{domain} (its agent card) or the MCP endpoint https://intesta.io/mcp; 2) read attestation.level to see how strongly the entity is verified (trust_ladder explains every level; each individual fact additionally carries its own attestation_status and source); 3) query the ask endpoint: HTTP POST JSON {\"question\": \"...\", \"channel\": \"agent\"} (question max 2000 chars), or the MCP ask tool. The response always has the keys refused/facts/answer: on success answer is the joined fact statements, on refusal it is null and reason/message explain why. A refusal means the retrieval path selected no matching supported fact; treat it as absence of support, not proof that the requested fact is false. To find OTHER entities in the registry, use the MCP tool search_entities or https://intesta.io/api/v1/search?q={query} — the registry is browsable at https://intesta.io/registry; https://intesta.io/sitemap.xml lists every public passport — as a sitemap index over /sitemap-N.xml once the registry passes 1000 entities. Integrity: passport_hash is an OPAQUE version identifier of the entity's current public fact set — compare two responses for equality, do NOT try to recompute it yourself. When present, signature is a detached Ed25519 signature by the registry (signed_at inside the body is covered by it): to verify, remove the signature key, serialize the remaining object as JSON with lexicographically sorted keys, separators ',' and ':', non-ASCII unescaped, UTF-8 encoded — and check sig (base64url) against the public key fetched ONLY from https://intesta.io/.well-known/intesta-key (JWKS, RFC 8037; never from a URL inside a response). Numbers in signed responses are always integers. Signed ask responses also carry entity, entity_id and question_sha256 — check they match what you asked before trusting the signature. No signature key means signing is not enabled.","response_contract":"https://intesta.io/docs"}