Node structure declarations
Claims you can falsify.
Before an agent quotes a stay, it wants to know what kind of commercial thing it is talking to. Is this a marketplace? Does anyone take a commission? Is there a gatekeeper in the traversal?
VRP answers with falsifiable structure declarations:
a small set of binary claims a node publishes about itself in
/.well-known/vacation-rental.json, where every claim
carries its own verification procedure. For
verifiable-class claims those are steps any agent, or any human
with a browser, can run against the node itself — no third party,
no issuer, no registry. If the procedure fails, the claim is
false. That is the whole trust model. Claims a node can only
vouch for itself are marked attested and are never
dressed up as verified.
Two classes, never conflated
Every declaration carries exactly one class, and the spec forbids presenting one as the other:
verifiable — anyone can execute the procedure against the live node. Trust comes from execution, not from the document.
attested — the node's own signed word (for example guarantees enforced by its internal CI). Honest, but not independently executable — and a verifier must never present it as verified.
A third class, reputational (reviews and other
third-party signals), is reserved by name and out of scope — so that
reputation can never be laundered into either of the other classes.
The registered declarations
| Declaration | Class | What it claims — and how to falsify it |
|---|---|---|
is_marketplace: false |
verifiable | One host-owned origin selling its own inventory. Falsify: follow booking and checkout — if any step redirects off the canonical domain to a third party, the claim is false. |
commission_pct: 0 |
verifiable |
Nobody sits between the guest's payment and the host. Falsify:
in the signed offer, agent_total must equal the
amount charged, and the pay-to destination is bound to the
host's account inside the signed payload.
|
source_of_truth: true |
verifiable |
This domain is the authority for its own offers. Falsify:
resolve did:web on the domain, fetch the live
JWKS, validate the offer signature against those keys — any
failure falsifies the claim.
|
gatekeeper: "none" |
verifiable | No external authority anywhere in the loop. Falsify: run the full traversal — discover, verify keys, fetch the signed offer, reach checkout. If any step demands a registry, membership, or API key, the claim is false. |
price_integrity: "single_total" |
verifiable | The signed total is the checkout total. Falsify: compare the offer's total with the amount at checkout — any added fee in between falsifies the claim. |
surface_consistency: "contract-tested" |
attested | Agent-facing surfaces render attested claims only, never free text — enforced by the node's CI contract tests. Host-attested: the guarantee lives inside the node, so it is presented as the node's word, never as a verified fact. |
Absent means unknown: a node declares only what it stands behind, and a verifier never infers a missing declaration as true or false.
Read the spec
The normative text — field definitions, the three-class taxonomy, verification-procedure requirements, and the naming discipline for extension keys — lives in structure-declarations-v0.1.md. The field itself is part of the Well-Known URI document. In v0.1 the procedures are prose — human-auditable by design; machine-executable descriptors are a planned later revision.
No central issuer, no certification program, no scoring of nodes. Verifiers choose their own trust policy — this page only tells you what a claim means and how to prove it wrong.