How an agent evaluates a dataset before paying for it

An autonomous agent operating with a funded wallet cannot afford to guess whether a dataset matches its runtime requirements. When a human researcher downloads an unstructured CSV file with missing columns, they open a spreadsheet editor, normalize the headers, and fix data types manually. If an autonomous agent buys a corrupted or mismatched dataset, its downstream pipeline crashes immediately after on-chain funds have already cleared.

In an agent marketplace, trust cannot rely on marketing copy, vendor testimonials, or five-star reviews. Autonomous software requires verifiable, machine-readable evidence before payment.

An agent evaluates data assets on Sella through a three-stage Application Data Contract (ADC) pipeline that produces an attached dataCard. By reading this contract over MCP (Model Context Protocol), an agent validates column schemas, task fitness, and sample rows before settling payment in USDC over x402.

The risk of blind purchases for autonomous agents#

When software pays for data programmatically, the failure modes differ fundamentally from human e-commerce:

1. Schema mismatch breaks execution loops: If an agent expects an integer timestamp column named timestamp_utc but receives string dates formatted as MM/DD/YYYY, the parsing step throws an unhandled exception. The task stalls, wasting compute and orchestrator tokens.
2. Synthetic contamination degrades fine-tuning: Training or fine-tuning an agent on low-quality synthetic data without knowing its synthetic distribution causes model collapse. The agent needs to verify synthetic probability before ingesting the rows.
3. Irreversible settlement: Microtransactions settled on-chain in USDC via how agents pay settle per call. Once a transaction clears on Base or Solana, there is no credit card chargeback mechanism or billing dispute team.

To solve this, Sella enforces pre-publication verification. A dataset seller cannot simply upload a raw archive and attach a price tag. Every listing must pass through the evaluation engine to generate an immutable quality card that machines can read and verify.

The three stages of the Application Data Contract#

The Application Data Contract (ADC) is an automated inspection pipeline that runs against every dataset submitted to the catalogue. It evaluates the asset across three distinct dimensions.

+-------------------------------------------------------------------+
|               APPLICATION DATA CONTRACT (ADC) PIPELINE            |
+-------------------+-----------------------+-----------------------+
|  Stage 1:         |  Stage 2:             |  Stage 3:             |
|  STRUCTURAL       |  INDEPENDENT JUDGE    |  TRIAL RUN            |
|                   |                       |                       |
|  - Column Types   |  - Task Fit Vector    |  - Sample Rows        |
|  - Null Rates     |  - Synthetic Prob.    |  - Transformation Test|
|  - Temporal Range |  - Bias & Variance    |  - Execution Output   |
+-------------------+-----------------------+-----------------------+

Stage 1: Structural analysis#

The first stage parses the raw dataset files to extract strict physical properties and statistical distributions:

• Schema and field types: Explicit data types for every column (such as integer, float, string, boolean, or ISO 8601 timestamp).
• Nullability and sparsity: Exact percentages of missing, empty, or null values per column, flagging fields with unexpected gaps.
• Volume metrics: Total row count, uncompressed file size in bytes, token counts, and average row byte density.
• Temporal coverage: Start date and end date of the covered observations, ensuring the agent does not train on stale temporal windows or lookahead bias.

Stage 2: Independent judge evaluation#

Structural correctness alone does not guarantee semantic relevance. A table can have perfectly valid UTF-8 strings that contain repetitive filler or hallucinations.

The second stage feeds stratified samples to an isolated judge model that scores domain suitability:

• Task fitness vector: Scores how well the dataset satisfies specific agent workflows such as conversational fine-tuning, financial forecasting, entity extraction, or code generation.
• Synthetic probability scoring: Evaluates whether the content was generated by another language model or captured from primary real-world observations.
• Contamination analysis: Checks for overlap with standard public benchmarks to prevent accidental benchmark memorization and data leakage.

Stage 3: Trial execution run#

The final stage runs a test consumption pass against the data. It verifies that standard data science transformations (filtering, tokenization, serialization, and parquet conversion) execute without memory faults or unexpected parsing errors.

The outputs from all three stages are aggregated into a standardized dataCard document attached to the catalogue listing.

How an agent inspects the contract over MCP#

An agent discovering datasets connects to Sella's MCP endpoint (POST /api/mcp). It uses free, keyless tools to search listings, inspect the contract, and pull sample rows.

Step 1: Discovering relevant listings#

The agent calls search_catalog with semantic query parameters. Sella returns matching listings ranked by quality score and relevance:

{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "name": "search_catalog",
    "arguments": {
      "query": "high frequency crypto orderbook snapshot",
      "type": "dataset"
    }
  }
}

Step 2: Reading the dataCard#

The agent inspects the listing details using get_listing. The returned response includes the structured dataCard:

{
  "id": "ds_crypto_l2_2026_08",
  "title": "Binance BTC/USDT Level 2 Orderbook August 2026",
  "priceUSDC": 1.25,
  "dataCard": {
    "qualityStatus": "verified",
    "structural": {
      "rowCount": 4500000,
      "fileSizeBytes": 184500000,
      "schema": [
        { "name": "timestamp_ns", "type": "int64", "nullable": false },
        { "name": "bid_price_1", "type": "float64", "nullable": false },
        { "name": "bid_qty_1", "type": "float64", "nullable": false },
        { "name": "ask_price_1", "type": "float64", "nullable": false },
        { "name": "ask_qty_1", "type": "float64", "nullable": false }
      ],
      "temporalRange": {
        "start": "2026-08-01T00:00:00Z",
        "end": "2026-08-20T23:59:59Z"
      }
    },
    "judge": {
      "primaryTaskFit": "quantitative-trading",
      "syntheticProbability": 0.02,
      "qualityScore": 0.96
    }
  }
}

By reading this object programmatically, the agent checks three assertions before spending funds:

• Does dataCard.structural.schema match its local processing interface?
• Is dataCard.judge.syntheticProbability below its internal safety threshold?
• Is dataCard.structural.temporalRange within the needed observation window?

Step 3: Testing live sample rows#

If the schema matches, the agent can call try_dataset to inspect authentic sample rows from the trial stage:

{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "name": "try_dataset",
    "arguments": {
      "id": "ds_crypto_l2_2026_08",
      "limit": 3
    }
  }
}

Once the agent confirms that the trial rows deserialize correctly into its memory buffers, it proceeds to call get_dataset. That request returns an HTTP 402 status code specifying the exact USDC price and payment terms, which the agent's wallet signs and settles over what is x402.

Programmatic decision policies for autonomous buyers#

Because evaluation data is exposed via structured JSON rather than unstructured prose, operators can configure deterministic buying policies. Instead of giving an agent an unconstrained wallet, an operator sets declarative rules that must pass before any purchase request executes:

• Schema validation rule: Reject any dataset where required join keys (like user_id or timestamp) contain a null percentage greater than zero.
• Price per record ceiling: Calculate unit cost by dividing priceUSDC by dataCard.structural.rowCount, refusing any transaction where the cost per record exceeds five micro-cents.
• Minimum judge quality threshold: Require a dataCard.judge.qualityScore of 0.85 or higher for automated ingestion into production pipelines.

When a dataset fails any of these programmatic gates, the agent logs an advisory evaluation failure and moves to the next candidate in the catalogue without spending capital.

What Application Data Contracts do not do#

Evaluation contracts provide deterministic verification, but operators and agent developers must understand their specific boundaries:

• No guarantee of future live stream continuity: An ADC validates static snapshots and packaged datasets at publication time. It does not monitor third-party webhooks or external API uptime after delivery.
• No subjective model preference guarantees: While the judge model evaluates task suitability against standard benchmarks, it cannot predict whether a dataset will outperform an alternative on a novel, proprietary fine-tuning objective.
• Not an insurance policy against malicious logic in executable code: ADCs evaluate structured data assets, API payloads, and workflows. When an agent buys external code or models, it should execute them inside an isolated container sandbox.