Everything on this site is callable and the scan is open. No key is needed to verify anything, by design: a verification layer that requires an account is not a verification layer.
A real response, trimmed to three checks, from the run against dxpe.com. Every check carries its own verdict and its own evidence, so you can reproduce the reasoning instead of trusting the score.
Private and internal addresses are refused before any request leaves the scanner, so the endpoint cannot be pointed at a network you do not own.
The score is ten times the weight earned over the total weight available. A pass earns its weight, a warning earns half, a fail earns nothing. The weights are published so you can disagree with them and re-score our data yourself.
| Check | Weight | What it reports |
|---|---|---|
| machine_access | 3.0 | Whether a client without browser fingerprints is served at all, how much content it receives, and whether a 200 is a real page rather than a block, a "not found" placeholder or an empty shell |
| bot_rules | 2.0 | Whether robots.txt names AI agents and permits them, or leaves the decision to the crawler |
| product_markup | 2.0 | Whether products are stated in machine terms on a real product page |
| price_and_stock | 2.0 | Whether price and availability are machine-readable |
| catalogue_query | 2.0 | Whether the catalogue can be queried rather than browsed, including any MCP surface |
| api_surface | 1.5 | Whether a callable API exists within the surface a machine can reach |
| discovery_map | 1.0 | A sitemap, including a sitemap index |
| agent_description | 1.0 | agents.txt or ai.txt describing what may be requested |
| agent_card | 1.0 | Whether the site describes itself to other agents at a well-known path |
| llms_txt | 0.5 | Whether llms.txt is present and is a real file rather than an error page served with code 200 |
| authorisation | 0.5 | Whether a way to authorise an agent is declared (RFC 9728 protected resource metadata) |
| machine_payment | 0.5 | Whether per-call payment is declared |
A record is a verifiable credential: signed statements about one batch, each carrying how it is known, with evidence bound by sha256 and a status that can be withdrawn. This host publishes demonstration records with synthetic data, clearly labelled, so the format can be inspected without anyone's commercial data being involved.
Retrieve the document from any host that serves it. The document is self-contained and does not call back to us.
Get the publisher keys once from /.well-known/issuer-keys.json, or keep a copy. They are published, long-lived, and rotated with notice.
Verify each signature against its key, then hash the evidence and compare it with the fingerprint in the record. Any change to the evidence breaks the check.
A record that has been withdrawn reads as withdrawn. Nothing disappears quietly, which is the difference between a record and a claim.
The record format is host-agnostic. The same documents verify whether they are served from a container, a CDN or a public canister on a decentralised host such as the Internet Computer, which we offer when a record has to remain verifiable even if we are gone. Customer catalogues are never hosted there and never leave the customer's own systems. Standards in use: W3C Verifiable Credentials, GS1 identifiers, GS1 Digital Link, sha256, Ed25519, C2PA for image provenance.
The public scan is rate limited per address and takes one to four seconds per domain. Private, loopback, link-local and reserved addresses are refused with 400 before any connection is attempted. A domain that times out returns a partial result with the failed checks marked, never a fabricated pass.
We publish what we ask others to publish. The files below are real files, not placeholders, because a site that advises on machine-readiness and ships a placeholder has no standing.
Versioning: the scan contract is versioned by path and additive only. Adding a check does not change the weight or the meaning of an existing one, so a score you recorded last month stays comparable.
We send the endpoint contract, the access model, the log format and the deployment options before any commitment is discussed.
hq@arliwork.com · Shenzhen Capernaum Technology Co., Ltd · PIAKHOUSKI DZMITRY