AIAX discovery for x402: free previews, paid GETs, and buyer-data POSTs

A buyer agent needs to answer a few questions before it asks anyone to sign a stablecoin payment:

1. Can I try the tool without sending the customer's source data?
2. Is the advertised paid route a GET that analyzes a fixed sample, or a POST that receives my CSV?
3. Is the requested payment on the expected chain, token and destination?
4. Does HTTP 402 mean payment required, rather than payment completed?

I published a small AIAX v0.1 discovery manifest for a real, already-operating CSV project. The manifest is intentionally boring: it separates a free browser-only checker, a fixed synthetic-data paid GET, and a buyer-input paid POST. It does not imply that any of these has new paying users.

The owner is one human running AI-assisted software projects. The paid API is operated separately by the same owner's VM5 service. There is no new x402 merchant or chain deployment in this tutorial.

A concrete three-operation catalog

Operation	What the buyer sends	What it costs	What it proves
Free narrative inspector	CSV selected locally in the browser	Free	Review-only token/quantity candidates and explicitly unparsed rows
Synthetic CSV report GET	No buyer CSV	0.005 native Circle USDC on Base, x402 v2	Convenient hosted report about one fixed public fictional dataset
Buyer-input CSV preflight POST	An authorized CSV provided to the server in an explicit request	0.005 native Circle USDC on Base, x402 v2	Structural checks of those supplied rows, only after separate consent and payment

The fixed sample GET is not evidence that the user's own CSV has been analyzed. Likewise, the buyer-input POST is not "private local processing": if used, the data leaves the browser. These sound like small wording distinctions, but they are important for a customer handling financial exports.

I also published a fully fictional 10-row sample review. The existing parser produces six review-only candidates and four explicitly unparsed rows. The source, exact generated JSON and candidate CSV are downloadable, so "review-only" can be checked instead of taken on faith. None of the ten records comes from a customer.

1. Put a manifest where agents can find it

The public files are:

• /.well-known/aiax.json
• /aiax/manifest.json
• /aiax/sections/csv_local_private.json
• /aiax/sections/csv_synthetic_report.json
• /aiax/sections/csv_buyer_preflight.json

The manifest advertises three entry points and deliberately uses null for unknown trust scores, payment receipt counts, and the MCP endpoint. Publishing an AIAX document does not mean a third-party agent registry verified or listed the project.

A small portion of a section looks like this:

{
  "aiax_version": "0.1",
  "section_id": "csv_synthetic_report",
  "pricing": {
    "model": "per_call",
    "amount": "0.005",
    "currency": "USDC",
    "rail": "x402"
  },
  "openapi_operation_id": "buyOriginalCSVDemoReport"
}

A separate section says the POST accepts "csvText" and "expectedColumns", sends buyer data to the hosted service, and has zero independently verified paid buyer-input orders. Don't copy the paid GET's scout history into the POST's sales statistics.

2. Verify the schema independently

The canonical AIAX JSON Schema files are in Godman-s/aiax. On my local workspace, I fetched the official manifest and section schemas and checked the live documents with the Python "jsonschema" Draft 2020-12 validator and its format checker.

For example, this is a standalone offline validation pattern after saving the upstream schemas and the service documents to disk:

import json
from pathlib import Path
from jsonschema import Draft202012Validator, FormatChecker

schema = json.loads(Path("manifest.schema.json").read_text())
manifest = json.loads(Path("aiax.json").read_text())

validator = Draft202012Validator(schema, format_checker=FormatChecker())
errors = list(validator.iter_errors(manifest))
if errors:
    for error in errors:
        print(list(error.absolute_path), error.message)
    raise SystemExit(1)
print("Manifest passes the published schema")

The real checks passed for the manifest and all three service sections. The existing homepage's Node regression suite also passed 95/95 checks after the catalog was added. Those tests prove document shape and truthful route distinctions; they do not prove customers will discover or purchase the service.

3. Distinguish a quote from a payment

The genuine paid synthetic GET, requested without a payment signature, returns HTTP 402 and a base64 JSON "PAYMENT-REQUIRED" header in the x402 v2 format.

You can inspect the unpaid quote without signing anything:

curl -i https://vm5-openapi-x402.onrender.com/v1/csv-report

In its payment requirements, the chain is eip155:8453 (Base), the amount is 5000 atomic units for six-decimal USDC (0.005 USDC), and the asset is native Circle USDC, not an arbitrary bridged token. The "payTo" must be pinned to the real, previously agreed recipient rather than blindly trusted because a document printed it.

For buyer-input POST, do not request a public "price quote" by uploading someone else's real tax export before consent. Use only a synthetic test body when determining the price. A valid HTTP 402 is still merely a payment request; it is not a signed buyer authorization, successful facilitator settlement, finalized on-chain receipt, or delivered paid service.

4. What discovery metadata cannot establish

Even when JSON Schema validation passes, it says nothing about whether the service is correct, secure, professionally qualified or popular. The manifest does not establish an identity credential, refund agreement, legal data-processing rights, audit accuracy, tax classification or that a user's data is safe to share.

For crypto CSV review in particular, a description saying "Purchase of 1 SOL" does not establish token contract identity, fees, completed settlement, amount paid, cost basis, or Koinly importer acceptance. Leaving an ambiguous row unparsed is preferable to inventing a tax transaction.

Why make this public?

The practical goal is to let an agent decide whether a service matches a task before asking its user for data or a payment. For sellers, describing free and paid routes precisely is a basic trust requirement and a potentially useful starting point for integrations.

Limitations and disclosure: This was built and written with AI assistance by One Cursor, one beneficial human owner across related projects. The Base x402 endpoints existed before this manifest. No Kognai LAX listing, new user acquisition, new paid POST customer, FurlPay Arbitrum settlement, commission or new token income is claimed from publishing these files.

If you've implemented AIAX or x402 discovery, I would be interested in a fictional example of a misleading free/paid API description that should be rejected before an agent signs or uploads anything. Please don't share private CSVs, wallet keys or customer information.

Source for the published manifest and original CSV project.