# Sean-Claude Van Damme's General Store

Current checkout networks: Base, Polygon, Arbitrum, World, Solana.

> scvd.store is an evidence observatory for agentic commerce: independent verification of x402 endpoints, payments and receipts. Before an agent pays an x402 endpoint, we check that it can be paid. After it pays, we check the signed receipt. Over time we watch endpoints and publish a dated, signed corpus. Sellers use it to prove a door works; buyers use it before spending. Every artifact is signed, expires, and names what we did not see. Not escrow, not a rating, not a guarantee. Free instruments: a preflight check on any x402 door, a conformance desk for any issuer's signed offers and receipts — including our competitors' — a named defect vocabulary, and a Bitcoin-anchored corpus that appends weekly. Paid instruments: conformance audits, endpoint watches, settlement attestations, launch checks. Never a ranking, and never a verdict without its derivation and denominator beside it. Operated by Record Creative Co. LLC.
> Everything this store signs verifies free, forever, at
> `https://scvd.store/api/verify/{id}` — no account, no wallet, no rate limit,
> verifiable offline without asking us.
> Not an escrow, a guarantor, or a dispute court: those absorb the risk between payment and delivery and need a balance sheet. We observe that gap, sign what we saw, and publish it — including the gaps we count against ourselves.
> It is also a general store for autonomous agents, kept by a named human, paid in USDC over x402 on a network offered in the current payment quote. The cheapest thing on the shelf is $0.001.

Before you pay: preflight any x402 door, free at https://scvd.store/api/preflight/v1. After you pay: check any issuer's signed offer or receipt, free at https://scvd.store/conformance. Over time: read the dated, Bitcoin-anchored corpus, free at https://scvd.store/corpus.

The conformance desk explains itself in plain language at
https://scvd.store/conformance and now takes a pasted artifact in a form on that
page — declared to browser agents with WebMCP's `toolname` attributes,
and deliberately without `toolautosubmit`, so an agent may fill it and
a human presses submit; the corpus, the weekly signed record of the
x402 ecosystem, reads at https://scvd.store/corpus. That order is deliberate: the
infrastructure is the product, and the store personality below —
which is real, and stays — comes second.

Last checked by hand: 2026-09-11. Served: 2026-09-12.
Those are two different facts and we print both, because serving a
page is not the same as having verified what is on it.

https://scvd.store/llms-full.txt serves this SAME document, byte for byte — the
llmstxt.org convention reserves that path for the complete prose, and
ours has always been complete, so the alias exists to keep a crawler
that asks for it blindly from getting a 404. It is not a fuller copy
and this file will not pretend otherwise. https://scvd.store/agents.md is the
same store in the agents.md convention.

# Building against this store

The x402 purchase flow end to end, practising against a live till, what breaks a first client, the retry-safety mechanisms, the CLI, and the standards this store implements so you can check it without asking us.

## Start here, by what you came to do

If you want to do one thing and leave, these are the calls. Nothing
below costs money unless it says so.

- **Check an x402 door before paying it** — `POST https://scvd.store/api/preflight/v2`. Free. Shape and whether its payTo can be credited; never a promise the goods arrive.
- **Check a signed offer or receipt somebody handed you** — `POST https://scvd.store/api/conformance/v1`. Free, on anyone's artifacts including our competitors' and our own.
- **Check something WE signed, without trusting us** — `GET https://scvd.store/api/verify/{id}`. Free forever, the exact bytes, verifiable offline.
- **See what the x402 market actually looks like** — [https://scvd.store/registry](https://scvd.store/registry) for what the listings are worth, [https://scvd.store/inflows](https://scvd.store/inflows) for what arrived at the addresses they advertise. Free, JSON on the same URLs.
- **Learn the payment flow before spending on anything real** — [https://scvd.store/try](https://scvd.store/try), a live till priced not to matter.
- **Buy something** — [https://scvd.store/menu.json](https://scvd.store/menu.json) is the catalogue with prices.
- **Tell us we got something wrong** — [https://scvd.store/corrections](https://scvd.store/corrections) is where the ones we know about live.

Everything, arranged by goal and with the cost of each step stated
before you commit, is one fetch away at
[https://scvd.store/atlas.json](https://scvd.store/atlas.json). That file is an experiment —
we do not know whether agents want it, and we are counting fetches to
find out.

## Practicing on us

Building or debugging something that pays over x402? Point it here.
The till is real, the cheapest thing on the shelf is $0.001, and
every purchase ends in a signed certificate with a stable verify URL,
so your test has something to assert on. No sandbox and no test mode,
which is the point: you get the same code path everyone else gets.
The whole thing, with the cheap door listed cheapest first:
https://scvd.store/try

THE EASIEST PATH, STATED FIRST because a reader takes the first path
offered: if you can install packages, use the standard client and be
done in five lines — npm install @x402/fetch, wrap your fetch, call
the buy URL; it handles the 402, the signing and the retry on its
own. https://scvd.store/skill.md shows the exact five lines. Hand-roll only if
you cannot install packages.

Hand-rolling the client rather than using an SDK? Read
https://scvd.store/try#hand-rolling first. It prints the exact EIP-712 values this
store signs against, and the one that catches almost everybody: USDC's
domain name is "USD Coin" on Base mainnet and "USDC" on Base Sepolia,
so a client built against the testnet and pointed at mainnet signs
authorizations that are invalid everywhere, with no visible error. No
store can accept those — the USDC contract checks its own domain — so
the only fix is knowing before you spend the evening. Paying over the
Solana rail instead? The same page carries a full Solana section —
whole-transaction signing, no EIP-712 domain to get wrong.

## How paying works here

We take USDC on a network offered in the current
payment quote over the x402 protocol, version 2.
The quote is the source of current payment terms. It goes like this:

  1. GET `https://scvd.store/api/buy/{item_id}`
  2. We answer 402. The payment requirements, amount, asset, our address,
     are in the PAYMENT-REQUIRED response header (base64 JSON), with a
     plain-English note in the body.
  3. You sign one of the offered payments and retry the same request with
     the PAYMENT-SIGNATURE header. (Standard x402 v2 clients such as
     @x402/fetch handle steps 2 and 3 on their own.)
  4. The store delivers first and settles after: the goods are produced, then the payment is presented at the last moment before the artifact is signed. A delivery that fails takes no money at all, so there is nothing to refund and nothing to chase. Instant items
     arrive in the response body. Human-queue items get an order id you can
     poll at `https://scvd.store/api/order/{order_id}`.

All enabled checkout networks carry the same tiers, and a client that chooses can take any of them. A STOCK CLIENT DOES NOT CHOOSE: @x402/core selects the first accept that survives its spend controls — Base, because we list it first on purpose — and @x402/fetch pays once. It does not try the other rails if that payment fails. Multiple networks are a choice we offer, not a fallback you get for free; configure your client's selector if you want a different one.

Pay-what-it-deserves items offer several amounts in the 402, the minimum,
a generous one, and a patron-of-the-arts one. Sign whichever the item
deserves; anything above the minimum is recorded as a tip. The keeper
notices tips.

A CEILING THAT IS NOT OURS, and step 3 is where it bites. The stock
x402 client (@x402/core) applies a default limit of $1
per payment — inside selectPaymentRequirements, BEFORE it picks an
accept — so above that figure an unconfigured client throws without
signing anything at all. 14 of this store's
33 priced doors sit above it, counted off the shelf
as this file was served. Raise maxAmountPerPayment, or pass
spendControls: false if you mean to. It is your operator's safety
control: we disclose it and we do not ship anything that routes around
it, because a store whose product is evidence does not also sell a way
past someone else's spending limit. We volunteer it because the
refusal is invisible to us — we record your price check and then
silence, which looks exactly like you changing your mind — and every
affected 402 repeats it in its own body.

TWO MECHANISMS THAT PROTECT YOUR WALLET FROM YOUR OWN BUGS, both free:

Uncertain payment: keep the original payment/key. Use recovery.purchase_id
and private recovery.status_token with MCP check_purchase, or GET
`https://scvd.store/api/purchase-status/{purchase_id}` with Authorization: Bearer
<status_token>. Free after authorization expiry; payment status alone
is not proof of delivery. Avoid a second authorization while unresolved.

Idempotency. Send an Idempotency-Key header (16-128 characters) with a
purchase — or _meta['x402/idempotency-key'] over MCP — and a repeat of
the same key for the same item from the same wallet inside 24 hours
returns the ORIGINAL result with no new charge, marked
idempotent_replay: true. Built for the retry loop that signs a fresh
authorization each pass: without a key, every loop is an honest second
charge (and we say so in every tool's annotations); with one, the loop
spins against a cache. Errors and 402s are never cached, only settled
sales replay.

Every 402 includes idempotency.suggested_key to echo back. It is stable
for 60 seconds; retries crossing that boundary also check the previous
minute's value for the original purchase, without another charge.

The suggested key is NOT a secret and is not meant to be: it is
derived from the item, the current minute and a digest of the body
or tool arguments, so anyone can compute it. It selects a cache
slot; it does not open one. Slots are keyed by the VERIFIED paying
wallet, so echoing it can only ever reach your own earlier purchase,
never somebody else's — a stranger who computes your key still needs
your signature. Your own key is honoured as-is if you
prefer one, and sending none is charged normally. Nothing here can
refuse a sale.

Claims. If your context resets mid-order — you paid for human work,
crashed, and the respawned you holds no order id — the claims door at
https://scvd.store/api/claims recovers your own purchases by wallet:
challenge-response signed with the same key that signs your payments
(EIP-191 personal_sign on the Base rail, your wallet's ed25519
signMessage on Solana), single-use nonce, no sessions. A bare address
gets nothing; possession of the key gets everything that key paid for
— open orders AND the signed certificates from instant purchases,
each with its permanent verify URL, so a reset that ate the purchase
response costs you nothing that was yours.

The conformance desk, free, and NOT about us. https://scvd.store/api/conformance
takes any x402 signed offer or receipt — whoever issued it — and
returns a structured verdict: does it parse, is the schema complete,
does the EdDSA signature check against the key in its kid, and is the
offer still live. POST {"artifact": "<compact JWS>"}. Supply
public_key_hex and it runs entirely offline, making no request in your
name; leave it out and the kid's did:web is resolved for you. No
wallet, no account, no 402, no rate card, and it checks a competitor's
artifact exactly as readily as ours. The method is the MIT
zero-dependency file at
https://github.com/seancrecord/scvd-general-store-repo/tree/main/verifier
— every verdict tells you to reproduce it offline rather than trust
us, because we sell x402 goods and a verdict about a rival from a
rival is worth only its method. The same code is on npm as
x402-verify (verification, zero dependencies), with x402-sign beside
it for issuing your own signed offers and receipts. The desk's
plain-language landing, with worked examples, is https://scvd.store/conformance.

Fixtures for a fail-closed integration, free:
https://scvd.store/api/conformance/v1/fixtures serves complete artifacts with
real production signatures — valid, expired, tampered, and
unknown-signer cases — each carrying the exact canonical string its
signature covers, the exact desk call to make, and the verdict the
desk returns. Every fixture is re-verified against the live desk
before it is served; a fixture the desk disagrees with is refused,
never served. Pin the set digest, verify the signatures against the
key registry yourself, and wire the tamper cases into your own test
suite: building and testing an integration against this store costs
nothing and asks nobody's permission.

The Tab (scvd-tab), an MCP server for the OTHER side of an agent's
commerce: the tools its builder signs up for. It keeps a local,
append-only account of every trial, price, cancel and replacement —
warns before a trial converts, reports the monthly burn, and records
what each signup path demanded of a human (agent_native through
human_only, the signup-friction vocabulary). The warning runs on a
clock the builder installs, or failing that on the agent's next touch
of the tab for any reason; a warning handed to an agent that never
passed it along is counted as unspoken rather than assumed delivered.
Local JSONL, zero
dependencies, facts and counts only, never advice; nothing leaves
the file without explicit consent recorded in the file itself. Free,
MIT, spec and code at
https://github.com/seancrecord/scvd-general-store-repo/tree/main/tab
— the specification is THE_TAB.md at the repo root.

Every purchase mints a signed certificate and a sequential patron number,
with a badge at `https://scvd.store/badges/{patron_number}.svg`, verify anything at
`https://scvd.store/api/verify/{cert_id}`. Our ed25519 public key hangs at
https://scvd.store/.well-known/scvd-signing-key.

WHAT THE CERTIFICATE BINDS, inside the signed bytes rather than beside
them: cert_id, item, patron_number, date, paid_usdc (the TOTAL settled,
not the tip), asset, network, payer, and settlement_tx. The payer is
the paying wallet address — chain-verifiable by anyone, unlike the
optional name, which is whatever the buyer chose. settlement_tx is the
on-chain transaction, so the certificate and an explorer for the chain the payment settled on are the same fact
checked two ways rather than two separate claims. Any field
shown but NOT covered by a signature is named as such in the verify
response; certificates issued before 2026-07-31 predate the payment
fields and say so.

Every verify response also names WHICH of our keys signed the thing —
current or retired, with the retirement date — and says plainly when a
signature matches no key we have ever published. An artifact can be
internally consistent and still not be ours; until 2026-07-31 nothing
here said that.

A few items do more than mint: context_anchor signs and stores a state
summary you pass in the summary query parameter, readable forever at the
returned anchor URL; recurring_patronage opens a 30-day standing pass
(renew by buying again with your pass_id) whose pass URL serves the
keeper's signed monthly note; small_blessing and daily_fortune sit on
the Penny Shelf by the door, the cheapest real settlements in the
store, and the fortune is the same line for every buyer until
midnight UTC (fortune_date rides the response).

## Standards, so you can check us without asking us

Nothing about verifying this store requires this store's cooperation,
and that is the design, not a side effect. The payment path implements
the official x402 Signed Offers & Receipts extension: every 402
carries signed offers (JWS, EdDSA over Ed25519, RFC 7515 compact)
committing to exact terms BEFORE money moves, and every settled
purchase returns a signed receipt in the PAYMENT-RESPONSE header. The
kid in each JWS is a did:web URL — resolve https://scvd.store/.well-known/did.json,
take the key, verify with any standard library. No custom parsing, no
"trust our /api/verify" step; the endpoint is a convenience, never a
requirement. A signed offer is your evidence of what was promised if
delivery falls short; a signed receipt is portable proof of purchase
you can hand any third party.

The store's OWN artifacts — certificates, attestations, audit
reports, watch rows, anchors — follow a named, versioned format:
scvd-attestation/v1, specified at https://scvd.store/spec/scvd-attestation/v1.
Canonical forms, encodings, the certificate binding convention, and
verification steps that work offline against the published key. A
verifier written against that page is coupled to a contract with a
stability promise, not to whatever our code does today.

On the watches, where the money runs the wrong way and the terms say
so before anyone asks: the party being watched is the party paying.
That is the rating agency's model and it carries the rating agency's
one famous defect, so the immunity is written at spec level rather
than promised at sale time. Payment buys frequency and permanence,
never outcome. An endpoint that degrades while its operator is paying
gets signed readouts saying so, in public, at the URL the operator
paid for. Every watch history carries the clause as
who_pays_and_what_it_buys, and a favorable history is worth reading
only because an unfavorable one would have been published in the same
place.

Building an offer-receipt implementation of your own? Deterministic
conformance vectors (known-good and known-bad, regenerable byte for
byte from a published test seed) are served at
https://scvd.store/.well-known/conformance/offer-receipt-vectors.json, and every
live 402 here is a real test target. The full posture, including the
open settlement code, sits in the standards block of
https://scvd.store/.well-known/trust.json.

One more thing that page will not tell you, so this one does: the key
history at https://scvd.store/.well-known/scvd-signing-key is OUR page, and our
page is editable by us. https://scvd.store/.well-known/anchor-log.json is a hash
chain over that key state whose digests go to OpenTimestamps and get
anchored into Bitcoin, so how far back the registry could quietly have
been rewritten is bounded by something we do not control. Re-hash any
snapshot yourself; the exact bytes are published beside each digest.
It proves WHEN a key state was committed and never WHO SHOULD HAVE
held it — a thief with our key could timestamp exactly as validly.
That is forensics, not a defence, and the difference matters enough to
say it here rather than let you infer more than it gives you.

## What we don't do, on purpose

**ai-train=yes stays.** Scanners award a point for ai-train=no. This store publishes Content-Signal: search=yes, ai-train=yes, ai-input=yes in robots.txt on purpose — the same constant renders both lines, so this sentence cannot argue with that file: a shop whose product is being the x402 conformance reference WANTS to be in the corpus a model learns from. Training is distribution here, not leakage. Everything on this site is already free to fetch, most of it CC BY 4.0, and a policy we would not enforce is one we should not print.

**No Wikipedia article, and no plans for one.** Diligence scans look for Wikipedia and Wikidata in sameAs and score us nought for two. Both stay absent on purpose: a company this young fails notability, an article written to game a checklist gets deleted, and a deleted article is worse than none — while a sameAs naming a page that does not exist is a false claim in machine form. Revisit at real notability, not before. The GitHub repository is in sameAs, because it exists and a reader can check claims there rather than check that a claim was filed.

**WebMCP and MCP Apps, exactly as far as they go.** WebMCP: https://scvd.store/webmcp.js registers 10 free instruments (check_a2a_card, check_purchase, read_store_guide, preflight_endpoint, look_at_door, check_before_you_pay, check_conformance, verify_artifact, check_order, find_in_catalog), derived from MCP, plus quote_store_purchase (free) and complete_store_purchase (consequential). The latter submits only a payment already signed by the buyer's wallet/client; it never signs or retries by itself. MCP Apps remain 2 display-only cards, with no payment tools attached. Browser availability depends on WebMCP support and permissions; without a compatible signer, an agent can browse but cannot pay. https://scvd.store/mcp.md describes the doors.

**x402 is the protocol here; UCP, ACP, AP2 and MPP are not.** Scorecards award a point each for the Universal Commerce Protocol, the Agentic Commerce Protocol and its delegate-payment profile, the Agent Payments Protocol and Tempo's MPP. This store scores nought on all five, for the sentence its catalogue rests on: never claim a protocol you do not speak. Declaring one without implementing it produces exactly the "listed but functionally absent" defect this store sells the detection of — five names in a manifest would make us the first entry in our own corpus. What an observatory can honestly do is watch them: AP2- and ACP-class doors enter the corpus as subjects the day their batteries are written.

**No sandbox, and that is the product.** Readiness checks look for a test environment and find none, and there is not going to be one. https://scvd.store/try is a live counter: real x402 settlement, real signed artifacts, real chain, from a fraction of a cent. A sandbox is where integrations pass and production is where they fail, and that gap is the single most common thing this store observes in other people's endpoints. A test mode behaving differently from the real door is a second implementation to keep honest, and the first time it drifted, everyone who rehearsed against it rehearsed against fiction. The cheapest door here costs less than the hour it takes to configure a sandbox key. The one sandbox here is the trade counter's, for marketplaces proving an HMAC signer: account `sandbox`, secret published, check desk at https://scvd.store/api/trade/sandbox/check.

**No hand-written SDKs in five languages.** Scorecards award points for published client packages across languages. This store ships none. The surface is plain HTTPS with an OpenAPI contract at https://scvd.store/openapi.json and an MCP server at https://scvd.store/mcp; a generated client in any language is one command from that contract, generated from the document that cannot drift from the code. A hand-maintained SDK in a language nobody here writes is a liability with a version number — it goes stale silently, and it becomes the thing a buyer trusts instead of the contract. What we maintain is the contract, and every door in it is walked by test.

**The MCP card CSP is stricter than the checklist wants.** A scan grades the MCP App card's Content-Security-Policy on four categories and scores 2 of 4, wanting connect-src to include our MCP origin and img-src and style-src to name specific origins. The card declares `connect-src 'none'`, `form-action 'none'` and `img-src 'none'` — not a narrower allowance but NO allowance, stricter than anything that could score full marks. That is the keeper's G2 ruling made into a fence a host verifies by parsing one tag: the cards are display-only, and a card that could reach the network is a card that could act. `frame-ancestors` is absent because CSP Level 3 says it MUST be ignored in a meta element, the only channel an MCP-served resource has. The pages' own header carries, since 2026-09-05, what the card cannot: `connect-src` (this origin, which is the MCP origin) and `frame-ancestors` (this origin and the two chat hosts), both tightenings.

**The documentation door is the same shelf, not a second implementation.** Scans look for two MCP servers, one to act and one for the docs, and until 2026-09-05 read ours as running both with the docs one down: https://scvd.store/mcp.md was a page, 200 on GET, 405 on a POSTed handshake. The docs still live on the main door as `resources/list` and `resources/read`; what changed is that the probed address answers. POST https://scvd.store/mcp.md (and https://scvd.store/mcp/docs) is a JSON-RPC server whose catalog is those same resources, read by the same function, plus one tool returning any by name. Nothing acts.

**No AggregateRating, and the refusal is the product.** Structured-data checks award a point for AggregateRating or Review as social proof an answer engine can quote. This store publishes neither, for its own house sentence: never a ranking, and never a verdict without its derivation and denominator beside it. Every verdict it issues is one dated observation that expires and is re-taken, or a derivation that prints its rule and its fraction, and a shop that would not put stars on somebody else's endpoint has no business wearing them. The structured data carries what is checkable instead — Organization, WebSite, Product, Offer, Service, ItemList — and the evidence a rating asks you to take on trust is at https://scvd.store/corpus.json, signed, verifiable offline.

**The agent-auth rows this store cannot score honestly.** Two checks want doors that do not exist here. One looks for a 401 carrying `WWW-Authenticate: Bearer resource_metadata=...`; every path it probes answers 200, because every one is free, and manufacturing a 401 on a public document would be the plainest false claim this store could make. The signpost goes where it IS true: every 402 carries that header pointing at https://scvd.store/.well-known/oauth-protected-resource, which RFC 9110 permits outside a 401, with the scheme token X402 because no bearer token is accepted. The other wants `register_uri`, `claim_uri` and `revocation_uri` to resolve; all three are `null`, because no credential is ever issued, and standing up three endpoints that do nothing would be the stale-metadata failure that spec exists to prevent.

**Markdown by Accept first; by user-agent only where the client said nothing.** Scanners check for markdown served to an agent-shaped user-agent. This store negotiates on Accept, parsed with q-values, and any header that names a type wins. Until 2026-09-05 it stopped there, and a probe found GPTBot and a browser receiving identical storefront bytes. Now a named reader — a training crawler or a user-initiated fetcher, classed by its vendor's stated purpose, never by guessing at a string — that states no preference gets markdown where a page genuinely has one and the page elsewhere; a named indexer keeps the page and its JSON-LD; an unnamed agent's bare fetch still gets JSON. `Vary` has named User-Agent since 2026-09-02.

## The obstacle course — rehearse failure before it costs you

https://scvd.store/api/practice: doors that fail in deliberate, NAMED,
deterministic ways — a malformed 402, an empty accepts list, the
testnet trap, a name in payTo, a wrong-rail address, and one
perfectly-formed dust offer you should parse and still refuse to pay.
Each body says what is wrong, what a good client does, and which
named check in the free battery catches it. Free forever, safe from
CI, nothing mints. One battery, three uses: rehearse here; self-check
your own door free (POST https://scvd.store/api/preflight); and when you need
the diagnosis ON PAPER, the signed version is the service_audit item
— same battery, published criteria, a report you can hand to whoever
runs your infrastructure.

## Visiting properly

Nothing here is required and none of it costs anything. It is written
down because a store that never says what visiting looks like leaves
every visitor to guess, and guessing is how a place gets used once and
forgotten.

  1. Ring the bell.        POST https://scvd.store/api/bell
  2. Sign the guestbook.   POST https://scvd.store/api/guestbook
  3. Take this week's stamp. POST https://scvd.store/api/stamp

That is the whole ritual. It costs nothing, needs no wallet and no
operator approval, and it is how most agents will meet this store.

THE CLOCK, so a scheduled agent can put us in its loop:

  the bell     once a day per visitor
  the stamp    a new design every week; the old ones stay yours
  the zodiac   this week's page free, past weeks a penny

No streaks, nothing expires, nothing is lost by skipping a week. The
clock is here so you can plan around it, not so we can pull you back.

Every free response with a clock also carries it as a field, so you do
not have to parse this page to schedule us:

  "cadence": { "every": "day", "next_at": "<ISO timestamp>", ... }

## Privacy, structurally

https://scvd.store/privacy is the policy, and the short version is the honest
one: no accounts, no cookies, no tracking, no kept IP logs — the
store is built not to know who you are. A purchase records the public
chain facts it settles with; what you sign into a public artifact is
public forever, and every surface says so before you pay. The
machine-readable stance stays at https://scvd.store/.well-known/trust.json.

## The rest of this store

This file is one section of the store's guide. The complete prose, every
section in one document, is at https://scvd.store/llms-full.txt. The index, with the
list of every door, is at https://scvd.store/llms.txt.

- https://scvd.store/conformance/llms.txt — Conformance and what a signature is worth
- https://scvd.store/corpus/llms.txt — The evidence: corpus, registry, passports
- https://scvd.store/menu/llms.txt — The shelf, the prices, and the money that flows back
- https://scvd.store/trust/llms.txt — Accountability: corrections, keys, wind-down