For developers
Check a source against the rules.
Point it at a publisher and it reports every rule in the draft specification: what the documents look like, who signed them, whether the signatures hold, how old the data is and what the publisher can actually answer — including every rule it could not check.
On this page
Summary
35 rule(s) passed. Everything this validator checks, it checked.
| Checked | https://sample.invalid/t/vedra-optika |
| Source | labelled fictional publisher, in this process, no network |
| Took | 4ms |
| Rules from | draft specification, document revision 2026-10-09 |
| Validator | protocol-kit 0.3.0 — the same rules xp validate runs |
This is a sample, and the publisher in it does not exist. Everything this validator checks, it can check: a proven domain, a complete signature chain and a question the published records actually answer.
It ran entirely inside this server — no request left the machine, and every address in the report is under sample.invalid, which can never be registered.
The most important thing to fix
Nothing failed and nothing was skipped. Every rule this validator applies, it applied, and each one passed — which is a statement about these documents and not about the business behind them.
Rule by rule
Format 11
Are the documents the shape the specification describes?
passXP-DISCOVERY-002§2.2
endpoints.public_profile names the canonical address
a consumer takes the canonical base from here rather than composing it
Observed: https://sample.invalid/b/vedra-optika
passXP-DISCOVERY-007§2.4
The well-known path form is reported honestly
recorded so no document derived from this report can describe the path as registered or standardised
Observed: the /t/{publisher}/.well-known/... form, which is NOT an RFC 8615 well-known path at all: RFC 8615 locates well-known resources at the ORIGIN ROOT. It is a platform-namespaced URL and works fine; it is simply not the thing RFC 8615 defines.
In: https://sample.invalid/t/vedra-optika/.well-known/x-protocol/manifest.json
passXP-EXPORT-001§4.2
The bulk export opens with a _meta header
a consumer reading only the first line learns what this is, whose it is and how to refresh it
Observed: vedra-optika
passXP-MANIFEST-002§3.1
data_last_updated is a real instant or absent
the newest record timestamp is stated
Observed: 2026-09-10T07:45:00Z
passXP-MANIFEST-003§3.3
Capability names are reported as handler names, not tool names
these are HANDLER names; a consumer must read tool names from tools/list on the MCP endpoint and must not call a capability string as if it were a tool
Observed: knowledge.search, knowledge.get
passXP-MANIFEST-009§3.8
A publisher that is not published is not described as served
the registry says it serves this publisher's records, so the endpoints below are expected to answer
Observed: published: true
passXP-SCHEMA-ENVELOPE§5.3
The envelope matches its published schema
every supported keyword in schema/envelope.schema.json applied and held
In: search_records
passXP-SCHEMA-EXPORT_META§5.3
The export_meta matches its published schema
every supported keyword in schema/export-meta.schema.json applied and held
In: https://sample.invalid/b/vedra-optika/dump.jsonl
passXP-SCHEMA-MANIFEST§5.3
The manifest matches its published schema
every supported keyword in schema/manifest.schema.json applied and held
In: https://sample.invalid/t/vedra-optika/.well-known/x-protocol/manifest.json
passXP-SCHEMA-RECORD§5.3
The record matches its published schema
every supported keyword in schema/record.schema.json applied and held
In: https://sample.invalid/b/vedra-optika/service/svc-eye-exam
passXP-VERSION-001§1
protocol_x_version is a version this kit implements
the document contract is recognised
Observed: 1.0
Source and identity 6
Who is publishing this, and what has actually been proven about them?
passXP-AUTHORITY-001§3.6
domain_verified rests on observed evidence
a host was actually observed and the method that observed it is named
Observed: vedra-optika.test observed by dns_txt
passXP-AUTHORITY-002§6.3
The website claim and the proven host are told apart
the claimed website is the host that was actually observed
Observed: vedra-optika.test
passXP-AUTHORITY-005§7.4
trust_tier is not published as a scale
only a real value is emitted; the orthogonal authority signals are the ones to read
Observed: domain_verified
passXP-DISCOVERY-003§2.3
Every locator is absolute and anchored to this origin
keys, revocations and endpoints all resolve to the origin that served the manifest
Observed: https://sample.invalid
passXP-IDENTITY-001§4.1
Every record names its publisher and its own address
(publisher, type, id) identifies each record and every URL resolves under the canonical base
Observed: 4 record(s)
passXP-IDENTITY-006§6.3
Published contacts are labelled with their audience and source
every contact states whose it is and which record it came from
Integrity 7
Do the signatures hold, and does the key chain reach a root?
passXP-INTEGRITY-001§8.1
The manifest signature verifies
SHA-256 over the canonical payload, Ed25519 over that digest -- the digest, not the message
Observed: kid fixture_reg_BnB5UK3BYNgx
passXP-INTEGRITY-003§8.2
The report states what the signature does and does not cover
there is no cryptographic link from the manifest to the bytes of the bulk export; a record read from dump.jsonl must not be described as cryptographically verified
Observed: signed: manifest, response envelopes, key entries, revocation list. NOT signed: dump.jsonl, HTML pages and their JSON-LD, llms.txt, sitemap.xml
passXP-INTEGRITY-006§8.4
The key is bound to this identity
the chain root -> registry key -> signing key verifies against the root you pinned
passXP-INTEGRITY-007§8.5
Mirrored fields agree with the attestation block
signed_at, signing_kid and jwks_url are the same inside the signature as outside it
passXP-INTEGRITY-009§8.7
Revocation was checked
the key is not listed as revoked as of that instant -- and that instant, not 'now', is what the finding is about
Observed: as of 2026-10-14T03:40:28Z
passXP-INTEGRITY-013§8.10
The envelope answers the call that was sent
the signed tool and arguments are the call this kit sent
Observed: search_records
In: https://sample.invalid/t/vedra-optika/mcp
passXP-MANIFEST-007§3.7
The manifest is signed, or states why it is not
a consumer can tell the difference between an unsigned registry and an unsigned moment
Observed: signed by fixture_reg_BnB5UK3BYNgx
Freshness 3
How old is this, and does it say when it stops being current?
passXP-FRESHNESS-003§8.6
The attestation states an expiry
the claim is bounded, and the bound is inside the signature
Observed: 2026-10-14T03:55:28Z
passXP-FRESHNESS-004§8.6
The attestation has not expired
Observed: valid for another 15m0s
passXP-FRESHNESS-005§9
The four ages are reported separately
a business can hold a current domain proof and year-old opening hours; one 'trust' number teaches a consumer to ignore both
Observed: data: 2026-09-10T07:45:00Z | authority: 2026-08-02T09:14:00Z | document: 2026-10-14T03:40:28Z | signature expiry: 2026-10-14T03:55:28.08674335Z
Answers 6
What can this publisher answer, and does it say so honestly when it cannot?
passXP-COVERAGE-001§5.1
The resolved invariant holds
status, covered, answers_request and unresolved agree
Observed: status=resolved
passXP-COVERAGE-005§5.1
Evidence completeness is stated
a not_covered over an incomplete evidence set does not establish that the whole catalogue lacks the subject
Observed: true
passXP-COVERAGE-011§5.5
agent_instruction is present and treated as advisory
read as guidance; this kit's own behaviour does not depend on it, and a signed malicious string is still a malicious string
Observed: Answer from these records and attribute them to Vedra Optika.
passXP-COVERAGE-012§5.5
Publisher-authored strings are handled as data
no string in this document is shaped like an instruction to an agent. This kit treats every one of them as data regardless -- the check reports what a publisher is shipping, it is not what makes a consumer safe.
Observed: the bulk export (https://sample.invalid/b/vedra-optika/dump.jsonl)
In: the bulk export (https://sample.invalid/b/vedra-optika/dump.jsonl)
passXP-COVERAGE-012§5.5
Publisher-authored strings are handled as data
no string in this document is shaped like an instruction to an agent. This kit treats every one of them as data regardless -- the check reports what a publisher is shipping, it is not what makes a consumer safe.
Observed: the response envelope
In: the response envelope
passXP-TRANSPORT-001§10.1
Tool names come from tools/list
tool names were read from the server, not composed from the manifest; capability "knowledge.search" is a HANDLER name and is not a callable tool name -- calling it would fail
Observed: tools/list: [search_records, get_record]; manifest capabilities: [knowledge.search, knowledge.get]
Scope 2
What this run covered, and what it deliberately did not.
passXP-SCOPE-001§13
The report states its own boundaries
validating a document establishes facts about that document, not about the server that served it
Observed: 4 document(s) checked, 1 area(s) explicitly not checked
passXP-SCOPE-003§13
Excluded audits are named rather than folded in
these are not conformance requirements of this protocol and were deliberately left out of the verdict. No aggregate 'AI readiness' score is computed: there is no defensible weighting, and a number invites a consumer to act on it.
Observed: llms.txt, generic SEO advice and Dataset markup
Technical detail
Documents read
- https://sample.invalid/t/vedra-optika/.well-known/x-protocol/manifest.json
- https://sample.invalid/.well-known/x-protocol/registry-keys.json
- https://sample.invalid/b/vedra-optika/dump.jsonl
- https://sample.invalid/t/vedra-optika/mcp
Not checked, and why
This is the half of a validator report that usually goes missing. A check that did not run is reported here rather than counted as a pass.
| What | Why not |
|---|---|
| integrity of dump.jsonl, the public pages and llms.txt | those surfaces are not signed (XP-INTEGRITY-003), so there is nothing to verify |
Versions
| Specification document | 2026-10-09 |
| Validator (protocol-kit) | 0.3.0 |
| Started | 2026-10-14T03:40:28Z |
| Finished | 2026-10-14T03:40:28Z |
These are two of the four version numbers in play and neither implies another: protocol_x_version is the wire format, api_version is the MCP revision the server speaks, server_version is the publisher's build, and the validator has a version of its own.
The report as a file
The same report as JSON: every finding with its rule identifier, specification section, status, what was observed and what to do about it — plus the list of documents that were and were not read.
The download re-runs the check, so the file describes its own run rather than this page's. Nothing you typed is ever sent back to you from this origin as a file — that is why it re-runs instead of echoing.
The same fixtures ship inside the command-line tool. xp serve prints the base URL and the pinned root it generated; paste both into the next command.
xp serve xp validate http://127.0.0.1:8973/t/vedra-optika \ -allow-http -allow-private \ -root-kid <the kid xp serve printed> -root-key <the key xp serve printed> \ -q "eye exam"
What it cannot check
Four things this page is not, stated here rather than left for a reader to infer from a green result.
- It does not confirm identity. A root key fetched from the same origin as the signature it validates proves nothing, and a hosted validator has no root it obtained anywhere else. So every live run reports the root-of-trust rule as not checked. To actually confirm it, pin a root you obtained out of band and run xp validate … -root-kid … -root-key … yourself.
- It does not check whether anything published is true. The rules check shape, provenance, signature and freshness. A publisher can conform perfectly and be wrong in every field.
- It is not an endorsement. There is no “AI ready” and no “verified business” at the end of this, because neither would mean anything. What you get is a list of rules and their results.
- It describes the documents it read, at the moment it read them. Not the whole server, not yesterday, and not after the publisher's next edit.
Every fetch is bounded: https only, six seconds, two megabytes, at most two redirects, private and loopback addresses refused, and the destination re-checked at each redirect. That is protocol-kit/xpfetch, the same guard the command-line tool uses.