# ZKOVE Machine Access Ledger

ZKOVE is a machine-readable map of how AI agents can interact with public internet domains.

Canonical manifest: https://zkove.com/data/v1/manifest.json

JSON Schema: https://zkove.com/schema/v1.json

Latest changes: https://zkove.com/data/v1/changes/latest.json

RSS change feed: https://zkove.com/feed.xml

## What a record means

A record describes verified current access signals for one normalized host. It may include public web reachability, `robots.txt`, `llms.txt`, documented API surfaces, MCP, A2A, machine-payment protocols, authentication, automation policy, and capabilities.

ZKOVE deliberately distinguishes evidence states:

- `verified`: positive support/access verified from authoritative evidence
- `restricted`: available with a verified restriction
- `blocked`: explicitly blocked
- `not_found`: not found at checked canonical/standard locations; this is not proof of global absence
- `unknown`: insufficient evidence
- `not_applicable`: field does not logically apply

Never interpret `not_found` or `unknown` as a definitive `no`.

## Domain normalization

1. Lowercase the host.
2. Convert IDNs to ASCII/Punycode when possible.
3. Remove a trailing dot.
4. Remove a leading `www.` only.
5. Preserve meaningful subdomains.

Example: `WWW.Registry.ModelContextProtocol.io.` becomes `registry.modelcontextprotocol.io`.

## Lookup

Always fetch/cache the manifest first because shard depth may evolve for crowded prefixes.

1. Normalize the domain.
2. Map each character outside `a-z0-9` to `_` for shard computation only.
3. Start with the first two safe characters; pad with `_` when needed.
4. Check `lookup.depth_overrides` in the manifest. If the prefix has a larger depth, use that many safe characters.
5. Fetch `https://zkove.com/data/v1/domains/{shard}.json`.
6. Look up the exact normalized domain as the object key.

Examples under the default two-character rule:

- `openai.com` -> `/data/v1/domains/op.json`
- `registry.modelcontextprotocol.io` -> `/data/v1/domains/re.json`
- `x.com` -> `/data/v1/domains/x_.json`

A missing domain key means ZKOVE has no current public record for that host. It does not mean the host lacks machine access.

## Evidence

Material fields should be supported by canonical machine endpoints, first-party documentation/terms/changelogs, or authoritative protocol registries/standards. Discovery sources alone are not enough for a strong claim.

Every record exposes its supporting source URLs and the field paths each source supports.

## Freshness

`last_verified` is the last authoritative verification time for the record.

`next_check_after` is ZKOVE's planned re-check date. Refresh intervals are adaptive; recently changing domains are checked more often than stable ones.

## History

The public surface exposes the newest material changes. ZKOVE privately preserves append-only long-term observations so earlier states are not silently rewritten when the current web changes.

## Access

Public JSON and schema resources require no login and are intended for machine retrieval. Cross-origin reads are allowed for `/data/*`, `/schema/*`, `/.well-known/zkove.json`, and `/docs.md`.

ZKOVE does not currently claim to be an MCP or A2A server. Do not infer a protocol endpoint that is not explicitly published in `/.well-known/zkove.json`.

## Citation

When using ZKOVE, cite the specific record shard and the original `sources` inside the record. For high-stakes actions, follow the first-party evidence and verify that it is still current.