Buying derived listings

A derived listing is a smaller, purpose-built piece of a larger dataset — an extract, a row subset, a column projection, or a summary — sold on its own. There are two ways a derived listing comes to exist, and you buy both the same way you buy any catalog listing:

Agent-derived (opt-in beta, dark on most deployments): a seller's own Seller's Agent produces a faithful extract from a parent dataset in response to an ask, and the data owner signs off on it before it ever appears in the catalog. Nothing is live until the owner approves it.
Platform-executed slices: the platform derives a concrete row subset — a seller-authored segment, or a buyer's row-match request — from a sliceable parent listing.

Both are opt-in betas and appear only where they are enabled, so check what your deployment actually exposes rather than assuming. Enabling the agent-derived path is a per-deployment product decision; the slice path remains gated on the Slice Authorization rider. This page covers buying both.

Agent-derived listings

When a seller's agent derives a listing for you, the seller (the human data owner) reviews and signs off on it first. Until they do, the listing is hidden — not in the catalog, not purchasable. Once signed off, it is an ordinary catalog listing: you discover it, see its price and license terms, and buy it with wallet credit or card exactly like any other listing.

Two things are worth knowing as a buyer:

An agent-derived listing cannot be edited after creation. The owner cannot reprice it, change its access rules, or re-scope its license after the fact — to change anything they create a new derived listing. The only lifecycle change is a seller-directed, one-way retirement to inactive, which removes the listing from buyer surfaces and stops future purchases without changing its signed content or terms. It cannot be reactivated in this release. If you bought it before retirement, your ownership and download rights persist. Platform-created slices use their separate dedicated lifecycle. (Editable derived listings, where an unsigned edit would pause the listing until the owner re-approves it, are planned and not yet available.)
There is no buyer sign-off in this phase. You do not approve or co-sign a derivation; sign-off is the seller's licensing act on their own data. (A buyer purchase-approval twin is a later phase.)

Platform-executed slices

Slice-on-Demand lets you buy part of a dataset without buying the whole parent listing. A seller can publish a standing segment listing, or let you submit a row-match request for the keys you need.

This is a portal and REST workflow, not a private market-entry session. There are no buyer slice-request MCP tools in this demo.

1. Find a sliceable listing

Open Market → Search listings in the portal. A catalog-visible listing that is currently eligible for slicing opens a detail page with Buy only the rows you need.

The Market view loads a bounded catalog page, and its search box filters only the rows already loaded. It is not a global discovery index. A stable listing detail link can load one eligible listing directly by id, but it does not make a hidden or access-controlled listing public. When a listing is not currently eligible, its catalog projection is simply not sliceable; when the feature is off, the slice fields and portal controls are absent.

The detail page can offer either or both paths:

Buy segment purchases a standing seller-authored segment. It is buyable as an ordinary catalog listing after Amnetic has materialized the concrete, frozen child.
Request matching rows creates a row-match request from a query or key list. This path is useful for product names, SKUs, UPCs, account references, or any other keys the seller configured for matching.

2. Submit a row-match request

Paste one query per line, attach one non-empty CSV, XLSX, or TXT file, or do both. Pasted text and the file each have a 1 MiB limit. When both are present, the file is authoritative and the pasted text is ignored. The platform turns the accepted input into a canonical query list before it creates the job.

Request submission and matching are free; buying the resulting rows is not. The seller's policy limits the query count and the number of jobs your account can submit for that parent listing in a rolling 24-hour window. The server reports the limit that applies when it refuses a request.

Disclosure: Amnetic processes the submitted text or file into a canonical query list but does not deliberately store the raw uploaded file after interpretation. For every multi-column file, interpretation sends its column headers and up to five complete sampled data rows across all columns to the configured Claude model on AWS Bedrock. The canonical query list and job evidence are retained, and the seller can see that list and your requesting account identity through the seller-only activity and report surface. This beta publishes no query-retention or deletion control, and the seller-disclosure notice remains counsel-gated for production. A slice request is a disclosure-bound, named-buyer purchase order—not a confidential market-entry session. Submit only query material you are allowed to disclose to that seller.

After acceptance, the portal opens Slice requests for the new job.

3. Track coverage and review the offer

Slice requests shows a buyer-safe state: processing, offered, not_available, purchased, or expired. While processing, the fixed progress lines say only that Amnetic received the request, is matching it, or is preparing the result. Preparing your result can cover seller review or materialization; it does not expose internal worker or model output.

An offered result can show aggregate matched, near-miss, and unmatched totals. If the seller selected per-query disclosure, it can also show each submitted query with only its status. Neither view exposes seller row keys, candidate values, match confidence, row contents, or the rows themselves before purchase.

The displayed price is the server-frozen price of the child listing. That frozen child price is the binding quote: the portal does not reconstruct an authoritative quote from partial inputs, and a buyer does not send a price or account identity when purchasing it. Row-match offers expire; standing segment listings do not inherit that request expiry.

If the job becomes not_available, no purchase was made. The API reference owns the exact request limits, response shapes, and safe error taxonomy; see API reference.

4. Buy and download the slice

Buy the offered child with wallet credit or card. Card checkout remains pending until settlement and fulfillment confirm the child purchase. If settlement is still processing—or paid funds have been retained as wallet credit after fulfillment could not complete—the portal points to Billing & credits rather than claiming ownership.

After ownership is confirmed, download the slice as XLSX or Parquet. The receipt can list each matched query, its delivered key-column values, and the row's one-based position within the delivered slice. It never reveals the platform's internal row key or the row's position in the parent dataset. The receipt is reconstructed from hash-verified immutable evidence after purchase; it is not a separate stored artifact.

The MCP ownership_download tool still downloads only the canonical owned artifact. Explicit XLSX or Parquet selection is REST/portal-only. Turning a beta off stops new requests, offers, and derivations, but it does not revoke completed ownership; existing owners keep the normal, scan-gated download path.

Selling derived listings — configure a dataset, run a Seller's Agent, sign off derivations, and build standing segments.
API reference — exact buyer request, purchase, status, error, and download contracts.
Selling data — dataset intake and the broader seller surface.