Selling derived listings

A derived listing is a smaller, purpose-built piece of a dataset you already own — an extract, a row subset, a column projection, or a summary — sold on its own while the original parent listing stays intact. There are two ways to produce one:

Agent-derived (opt-in beta, dark on most deployments): your own Seller's Agent derives a faithful extract from a parent in response to a buyer's ask, and you (the human data owner) sign off on it before it goes live.
Platform-executed slices: the platform derives a concrete row subset — a standing segment, or a buyer row-match request — from a sliceable parent.

Both are opt-in, dark betas. Their portal, MCP, and API surfaces are absent unless the deployment enables them, so check what your deployment actually exposes rather than assuming. Enabling the agent-derived path is a per-deployment product decision (the Derivation Authorization counsel track, AMN-655/AMN-656, runs in parallel and is not a prerequisite); the slice path remains gated on the Slice Authorization rider.

Agent-derived listings and sign-off

Your Seller's Agent (loaded from src/agent-skills/seller-agent/SKILL.md) downloads one of your parent listings, derives a faithful extract locally, self-verifies it against the ask, and stages it as a derived listing through the create_derived_listing MCP tool. Artifacts larger than the inline 8 MiB cap go through stage_derived_artifact first (presigned single-PUT ≤256 MiB into quarantine; pass the returned stage_id on create) — the platform does not raise MCP transport body caps for large agent uploads. Every listing it creates is born pending sign-off — hidden from buyers, never in the catalog, never purchasable — until you review and approve it. The agent watches its queue with list_pending_signoffs and prepares your review with get_signoff_item.

Your agent never prices the extract. The platform prices the transaction through its pricing engine; the agent proposes no number and sets none, and the price it carries into create_derived_listing is the engine-quoted price the platform provided — never a figure the agent chose, estimated, copied from a stale surface (an older listing, an earlier quote, the catalog), or invented as a $0 payout-onboarding bypass. The review packet the agent prepares (using get_signoff_item for the listing fields, plus the engine quote's price and rules_version carried from when the platform priced the extract) is what you approve — so the price is the platform's, not the agent's. If a price or rules_version is missing, that is a platform error — the agent escalates rather than inventing one.

What the parent must be. create_derived_listing checks four facts about the parent, each with its own refusal:

it is active — durably so, not merely as far as your status badge shows. Refused as "parent listing is not active".
its content passed scanning. Refused as "parent listing is blocked by content scanning".
it has stored content. Refused as "parent listing has no stored content".
that content has a usable content digest. Refused as "parent listing has no usable content digest".

The first is the one that surprises, because the parent's status already reads active while the platform is still processing it. The two answer different questions: status says what you asked for, and public_visibility says what the catalog serves. A freshly created listing is normally {"visible": false, "reason": "pending_publication"} for a short period while it is processed.

So when a derivation is refused as not active, have the agent read the parent with get_my_listing and look at public_visibility:

pending_publication — still being processed. Wait and re-read, rather than retrying create_derived_listing blindly; retrying will keep producing the same refusal until processing finishes.
not_active — the parent genuinely is not active, and waiting will not change it. Publish the parent first.
visible: true — the parent is active, so not active is no longer the explanation; look to the other three refusals.

But public_visibility is not the derivation precondition — do not treat it as one. It is a diagnostic for the active check, and it is neither necessary nor sufficient:

A restricted parent is derivable. restricted_access only means you set a non-open purchase ACL, and derivation never requires an open parent. Do not reopen a deliberately restricted listing to make it derivable — that widens it to the whole public catalog and buys you nothing. (restricted_access also masks the answer to the active question, so if a restricted parent is still refused as not active, it is still processing: wait and re-read.)
visible: true is not sufficient. It says nothing about scanning, stored content, or the content digest, so a visible parent can still be refused for one of the other three reasons.

The child does not inherit the parent's access rules. The child's ACL comes from the purchase_acl_mode you pass to create_derived_listing, and it defaults to open. Deriving from a restricted parent therefore produces an open child unless you say otherwise, so set the child's ACL explicitly whenever the parent is restricted.

A derived child's access groups are resolved once, at creation, and then frozen. When you create a child with allow or deny over access groups, the platform immediately resolves those groups to the member accounts they hold at that moment and stores that account list on the child. The group ids are not kept on the child, so from then on the child's audience is fixed:

An allow child ends up stored as an account-scoped listing over the freeze-time members. Adding someone to the group afterwards does not let them buy that child, and emptying the group does not withdraw it.
A deny child stays deny, over the freeze-time member accounts. Adding someone to the group afterwards does not revoke them for that child, and removing someone does not let them in.

This is the same immutability that stops you editing a published child's price or content: a derived listing is a licensing commitment, and its audience is part of that commitment. Membership edits keep working normally for your ordinary listings, which do follow the group live.

Two practical consequences. First, get the group's membership right before you create the child — afterwards the only way to change who may buy it is to retire it (POST /api/v1/seller/slice-children/{listing_id}/deactivate) and create a new one. Second, a group that currently holds no marketplace accounts cannot be pinned, so creating a child over it is refused rather than silently producing an unsellable (or wide-open) listing; invite the members and let them create their accounts first.

A listing created before the content-digest fix cannot be a parent yet. Any listing create_listing produced before raw-byte provenance covered the inline-text path has no content digest, and is refused as "parent listing has no usable content digest" however long you wait — public_visibility will happily report visible: true throughout. Clearing that is a one-time operator maintenance step (amnetic-internal resale backfill-file-digests), not something you or your agent can do. Listings created since the fix get their digest at creation.

The agent cannot sign off — you do. Sign-off is your licensing act: the moment you take responsibility for selling this extract. There is no sign_off MCP tool. Approving is a deliberate human act through your own Cognito session on the REST edge (POST /api/v1/seller/documents/{id}/signoff); an agent API key structurally cannot perform it.

Your approve must name what it is approving. The approve body carries artifact_sha256 — the primary_sha256 the review packet showed you — and the server refuses (409 artifact_stale, echoing the current hash) if it does not match the child's primary artifact. So an approve is never ambiguous about which bytes it covers, and it cannot be replayed against a different artifact.

To be clear about what that pin does not do: it is not a guarantee that a human read the review. Your agent receives the same hash back from create_derived_listing and hands it to you, so knowing the hash does not prove anyone opened the detail. Reviewing before you approve is your judgement, and get_signoff_item exists to make that review cheap — the listing, its parent, its artifacts by hash and size, the license terms it will carry, and its sign-off history, all without needing the file itself.

An agent-derived listing cannot be edited after creation. Its content, price, ACL, offers, and slice policy remain frozen; attempts to change them are refused with "derived listing is frozen" (the REST edge returns 409 platform_slice_frozen). The sole lifecycle exception is a seller-directed, one-way retirement: call update_listing with only status: "inactive" (or PATCH the listing with {"status":"inactive"} as the only effective recognized update). Retirement removes the child from the sign-off queue and buyer surfaces and stops future purchases, while preserving its immutable record, sign-off history, and prior buyers' ownership and download rights. It cannot be reactivated in this release. A decline does not retire it automatically; retire only as a separate, explicit owner instruction. Platform-created slices do not use this exception and keep their dedicated unsold-child lifecycle. The child carries the standard license composition frozen at creation, surfaced as frozen_terms on the review packet, so a buyer is only ever quoted the terms you signed. To change a derived listing, create a new one — including to rework one you declined. Editable derived listings — where an unsigned edit pauses the listing until you re-approve it — are planned and not yet available.

Sign-off is not one-and-done — two live conditions can silently withdraw a signed-off child. Even after you approve it, the money path re-checks two facts on every purchase attempt, and refuses the sale if either has lapsed:

the parent listing is still active — deactivating a parent withdraws every signed-off child derived from it; and
the consent source recorded on the child is still current. Amnetic records derivation consent against the general Terms of Service you accepted at signup, so there is nothing extra to keep current and this condition does not lapse. It exists because a deployment can instead record a separate per-account Derivation Authorization instrument, where a new instrument version supersedes your acceptance and every derived child stops selling until you accept the new version.

The refusal is deliberately opaque: the buyer's purchase fails as listing not found, exactly as a listing that never existed would, with no explanation naming the cause and no notice to either party. The child can still appear in the catalog (publication only tracks your approve), so a buyer's experience is a listing that looks available but will not sell. Restoring the lapsed condition — reactivating the parent, or accepting the current instrument version — makes the child purchasable again with no re-approval. Purchases already completed are unaffected.

Two one-time conditions gate agent-derived listings; both are steady-state, the same class as any seller's payout setup:

Consent to derive. Amnetic records this against the general Terms of Service you accepted at signup, so there is no extra acceptance step and your agent can derive immediately. A deployment can instead be configured to record a separate per-account Derivation Authorization instrument; where it is, you accept that instrument once through your own session (POST /api/v1/seller/derivation-authorization/accept), and the first create_derived_listing before you do returns an actionable error naming the instrument, its version, and the accept URL. Either way it is one-time, never per-derivation, and the accept and status routes stay available in both configurations. Neither source is the slice rider: whichever one applies replaces the earlier rider framing for the agent-derived path, which the Slice Authorization rider does not gate.
Payout onboarding. A priced derived listing requires completed Stripe payout onboarding, exactly as an ordinary paid listing does.

Both are checked before anything about the parent. If either is outstanding, that is the refusal your agent sees first — the four parent-eligibility refusals above never mask it, even when the parent is also wrong. So an agent should finish the onboarding the error names before it starts diagnosing parents, and can read a parent refusal as confirmation that the onboarding that call needed is already done. (Payout onboarding is only checked for a priced child, so a $0 access-restricted child never consults it.)

Better still, neither has to be discovered from a refusal at all: both are account-level and readable up front, so your agent should call seller_readiness before it builds an artifact. It returns a derivation_authorization row and a payout_onboarding row, each with a ready flag and a remedy. It is read-only and cannot accept either instrument on your behalf. The lapse condition above shows up the same way: once a new instrument version supersedes your acceptance, the derivation_authorization row reads not-ready, which is the one place that state is visible to your agent before a buyer hits the opaque refusal.

Platform-executed slices

Slice-on-Demand lets you sell useful row subsets of a dataset while keeping the original parent listing intact. You can create a standing segment listing for many buyers, accept buyer-specific row-match requests, or enable both. The portal guides the workflow through Sell → Slicing.

1. Start with a dataset listing

Upload a CSV, XLSX, or Parquet dataset through the portal or REST API. Amnetic converts CSV and XLSX intake to canonical Parquet and can derive their data dictionary; native Parquet requires a dictionary. The dictionary columns are the vocabulary used by the slice policy, profiler, segment builder, and row matcher. See Selling data for the intake requirements.

In Sell → Slicing, choose the original dataset as the Parent listing. A platform-created slice child is frozen and cannot become another editable slice parent.

Workbook worksheets are not slices

A multi-sheet XLSX creates one workbook root plus one ordinary Parquet listing for each data-bearing worksheet. Those worksheet listings are source components, not row subsets produced by Slice-on-Demand: creating the workbook does not call a slice endpoint, require the Slice Authorization rider, or create a slice manifest. Each worksheet has the seller-confirmed uniform worksheet price and can be purchased independently from the whole values-only workbook, with no proration between them.

Because a worksheet component is itself an ordinary Parquet dataset listing, it may later be configured as a Slice-on-Demand parent if it otherwise satisfies the eligibility rules. Any resulting row subset is then a separate frozen slice child of that worksheet listing.

2. Authorize slicing and set the policy

Open Policy and read the server-pinned Slice Authorization rider. Rider acceptance is an account-level human authorization: the portal records the current server version, and no MCP tool can accept it for you. The draft rider is intended to authorize Amnetic to read the parent dataset and produce derivative row extracts on your behalf. In Auto mode, the standing policy is intended to adopt each generated child as seller content; in Seller review mode, approving the individual request is the per-slice adoption act. This posture is not effective for production until counsel ratifies the rider.

The authorization is prospectively revocable. Disabling a listing's slice policy—or a new rider version superseding the version you accepted—stops new slices. It does not revoke slices already sold or a buyer's existing ownership.

Turn on Enable slicing, choose whether to allow buyer row-match requests, then save the policy for this parent listing:

Buyer row matches compare each buyer's submitted query list with one to three configured key columns and can become a buyer-specific offer.
With buyer row matches unchecked, the policy uses kinds: []: you can still combine typed facets, ranges, agent adjudications, and a key list to create a shared standing segment, but buyers cannot submit row-match requests.

Then set the per-row rate, mandatory price floor, optional ceiling, disclosure mode, review mode, and request bounds. A seller-authored segment may carry an explicit price when created; leaving it blank uses the policy pricing rule. Aggregate only shows buyers coverage totals; Per query additionally shows each submitted query's status. Auto review can proceed directly to an offer; Seller review pauses before child materialization so you can approve or decline.

The server owns validation and quote math. Treat pricing warnings as real: requests and coverage matching are free to the buyer, so Slice-on-Demand is a bounded coverage oracle before purchase. The delivered extraction is paid, and the mandatory floor prevents a one-row result from becoming a free byte retrieval path. Set pricing and request bounds so repeated coverage probes or reconstruction do not undercut the parent dataset. The exact policy fields, pricing formula, warnings, and validation rules remain in Selling data and the MCP tools reference.

For buyer row-match requests, the current demo enforces each job's query and selected-row bounds and the buyer-and-parent rolling 24-hour job cap. A cumulative-row policy value can be recorded, but cluster-wide, cross-listing, and cumulative-row enforcement are deferred; do not rely on them as current anti-probing controls.

3. Build and preview a standing segment

Open Segments. Amnetic profiles the selected parent and shows its row/column metadata plus bounded facet values and ranges. A profile refresh is asynchronous: requesting it only queues work, so reload later and compare the profile time.

Build a selection with any combination of:

filters added one at a time from the Add a filter column picker — low-cardinality text or Boolean facets (or a free-text match box for high-cardinality text columns) and numeric or date ranges;
a Segment agent instruction (described in plain language).

Apply instruction only compiles natural language into a closed filter grammar, producing a deterministic, reviewable selection plan. It does not preview rows or create a listing, and unsupported or unsafe model output is refused rather than applied. (File-based key-list matching is available over the REST slice-preview multipart surface — see the API reference — not the portal.)

Choose Preview selection to run the authoritative server-side waterfall. Review its selected-row count, bounded sample, and Edge cases. Sample checkboxes and Keep, Drop, or Use agent decisions become explicit last-applied pins. Any filter, instruction, key, file, or pin change makes the old preview stale; preview again before creation. The platform selects parent rows—it never synthesizes replacement data.

After a current preview selects rows, enter a display name and optionally an explicit price of at least $1.00. Leaving price blank uses server policy pricing. Create segment listing queues materialization and returns a job id; it does not mean the child is already live. The resulting standing segment is a shared listing whose purchase access rules are copied from the parent when the child is created.

The current beta does not propagate a later parent purchase-ACL change to an already-materialized segment child or re-check that parent ACL when the child is purchased. Custom children never appear in the parent's slice summary. The child can remain discoverable through ordinary catalog or detail surfaces and purchasable under its stale copied ACL. Before tightening parent access, disable Slice-on-Demand for the parent and retire any unsold standing segment that can be retired. Do not rely on the parent ACL change alone to restrict an existing child; completed ownership remains unaffected. Production remains blocked on this ACL resynchronization and purchase fail-close work.

4. Monitor buyer requests

Open Activity for the selected parent to see its request log, authoritative 30-day sales metrics, requester identity, request summary, result, price, and seller-only match reports. A match report can include the full canonical query list, matched row references, match class, confidence, and the disclosure mode snapshotted for that buyer. That report is yours alone; the buyer projection is strictly narrower.

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. Amnetic does not deliberately store the raw uploaded file after interpretation, but it does retain the canonical query list and job evidence. This beta does not publish a query-retention or deletion control. Treat the requester identity and canonical queries as seller-visible material and use them only for the slice transaction; production remains counsel-gated on the operative notice and rider.

Open Review for row-match jobs held by Seller review. Amnetic stores the match report, selected-row checkpoint, and frozen quote before a child or buyer offer exists. Approve & offer authorizes materialization and the buyer offer; Decline ends the request without creating a child. A stale or duplicate decision is refused and the portal reloads authoritative state.

The demo's named requester identity and per-parent rolling job cap help you notice repeated probes. They are not a claim of cluster-wide, cross-listing, or cumulative extraction metering.

5. Understand the slice lifecycle

Every completed slice is a new, manifest-backed child listing with immutable selection evidence, economics, and delivery references. A row-match child is scoped to its buyer and offer window. A standing seller segment can be bought by multiple eligible buyers and has no row-match expiry. Manifested slice children have canonical Parquet delivery and a generated XLSX format for portal/REST download after purchase.

You cannot edit a platform-created slice child into a different slice or silently reprice it. An unsold standing segment can be retired through the dedicated lifecycle API; after retirement, only a later seller creation request creates a fresh job and child at the then-current price. A completed purchase wins over retirement, so paid artifacts and download rights remain intact.

The beta does not propagate a parent's composed or custom-priced license tiers to a generated child. The standard slice-license posture remains provisional and counsel-gated; do not represent a child as carrying a parent license tier unless its purchase evidence expressly says so. See the API reference for exact builder, activity, review, and lifecycle contracts.

Buying derived listings — see the coverage, offer, purchase, and receipt flow from the buyer's side.
Selling data — dataset intake and detailed slice-policy rules.
MCP tools reference — create_derived_listing, stage_derived_artifact, list_pending_signoffs, get_signoff_item, and the slice tools.
API reference — exact seller sign-off, builder, activity, review, and lifecycle shapes.