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 (live in production): 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.

Agent-derived listings, lineage, Sample Data, Inbox, Change Request, and SAT are enabled in production. Those portal, MCP, and API surfaces 404 by absence only if a recovery kill-switch is off (the matching flag via .github/workflows/flag-rollout.yml). 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

Set the per-row price

On an ordinary source listing, use the portal's Derived pricing card or the listing policy (PUT /api/v1/seller/documents/{id}/policy, MCP set_listing_policy) to enable derivation pricing. The policy's base rung price_cents is the listing price; derivation_pricing.rows carries the per-row rate, stored as integer micro-USD (1 USD = 1,000,000 micro-USD) so fractional-cent units remain exact. The policy envelope carries SAT's seller-private min_price_cents, optional max_price_cents, and counter_floor_cents (integer cents), and derivation_pricing carries optional buyer_type_adjustments for business and enterprise. An adjustment is either a positive-basis-point multiplier (multiplier_bp, 10000 = 1.0x) or an absolute override (price_cents).

A derived purchase is priced at ceil(rows × per-row rate), held within the envelope; the listing price applies only when there is no per-row rate, and the two are never added. Enabling therefore requires a per-row rate and is refused unless the listing price is positive and within the listing cap and the clamps meet the transaction floor. Column pricing is not yet supported: a policy with a derivation_pricing.columns cell is refused. Clamp and valid adjustment values may be stored dormant while disabled; their closed shape and bounds are validated on every write, while completeness is checked when enabled. The review card shows the authoritative row count, the effective rate, reconstructed total, and a clear below-floor warning.

These settings are private seller configuration: buyers and the public catalog do not receive them. Ordinary authorized seller REST and MCP sessions can edit them through the listing policy.

Hosted Seller's Agent (portal beta)

When enabled, open Sell → Inbox in the authenticated portal. The Inbox is the review rail for work prepared by the Seller's Agent; the existing AI Agents sessions/images view remains a separate buyer-agent marketplace surface. The agent interprets the request and prepares a derived listing; it does not publish or send an offer on its own.

Open the pending Inbox item and choose Full review to read its Change Request before acting. The review packet includes scope, artifact hash and size, row/page counts, spec, evidence, revision history, and the current allow rule. Approve only after checking the packet and its artifact pin; approval records the seller act and publishes the derived child. The portal reports the resulting state honestly as awaiting subsequent offer orchestration—it does not claim that an offer was sent, a buyer account exists, or a sale completed.

Replace a pending SAT deliverable

If the proposed SAT deliverable needs correction while its Change Request is still pending, choose Replace pending deliverable in the seller listing review. The portal uploads the selected file to a short-lived quarantine URL, then completes the upload so the server can run malware scanning and the resale eligibility gate. The predecessor child and its Inbox review remain actionable through awaiting_upload, queued, scanning, and gating; these phases create no listing, approval, offer, payment, ownership, or delivery.

The status panel is server-authoritative: Upload waiting, Upload received; safety checks queued, Checking file safety, and Checking resale eligibility are progress states. A refusal, timeout, cancellation, or stale predecessor leaves the original review unchanged. The seller can cancel a pre-swap candidate, and a retry must use a new idempotency key when the server has terminalized it.

When the gate succeeds, the server atomically retires the predecessor and moves the one live Inbox delivery to a new immutable child and successor Change Request. The portal hands off to that successor review and shows the replacement diff and fresh pins. Replacement ready for your review is not approval: uploading, completion, polling, and the atomic swap never approve the successor or send an offer. Review and explicitly approve, request changes, or deny the successor Change Request through the normal controls. There is no replacement MCP tool or bundle-addressed approval route.

Deployment operators must provide a dedicated, versioned replacement quarantine bucket through SAT_REPLACEMENT_QUARANTINE_BUCKET. It must differ from both MINIO_BUCKET and LARGE_LISTING_QUARANTINE_BUCKET; the service refuses to boot if those trust boundaries alias. Provision its task-role access, versioning, exact-version retention/deletion policy, and browser CORS before enabling seller transactions.

When the portal derivation-listing surface is enabled, a listing page also shows lineage inside the listing card: Made from (the parent), This Listing (the current listing, not a link), and Custom extracts (published child listings). Parentage is that row — not an inset “this is a derivation of…”. Clicking a parent or child opens that listing’s ordinary page. Sample Data remains a separate nested teaser, not a Custom extracts row.

Publish free Sample Data

For an eligible active, open, original columnar listing, the listing page shows a Sample Data card. The switch is on by default. Choose Add Sample Data, which opens the Seller's Agent rail with a request seeded for that listing. In the current handoff flow this conversation is a preview: the browser does not upload sample bytes or call the derived-listing create API. The Seller's Agent produces the actual CSV, single-sheet XLSX, or Parquet artifact and stages it through the same derived-listing intake used by create_derived_listing. The child is always derivation_class: "sample", free (price_cents: 0), and open. The server—not the browser—verifies the parent family, usable content, scan result, columnar shape, authoritative row counts, configured row cap, and one-current-sample rule.

The new sample is a real derived listing born pending human review. Approve it from Sell → Inbox exactly like another derived child. After approval, the source listing exposes a separate Sample Data teaser; samples never appear as ordinary catalog/search results or in the source's Custom extracts list. Turning the switch off immediately hides the teaser and blocks new acquisitions without deleting the child or any buyer's existing ownership/download right. Retire the old sample before creating a replacement.

Samples use only the standard frozen license. Custom licensing policy is not supported for sample approval. A successful free acquisition emits sample_acquired, not a sale or listing_purchased, and creates no buyer debit, seller credit, platform fee, or payout effect.

A derivation waiting on you arrives in Inbox (the User mailbox). Inbox delivery and read state come from the universal GET /api/v1/inbox contract; the message's act_href delegates decisions to the owning derivation change-request/sign-off subsystem. The portal does not maintain a second sign-off mailbox. Where Change Request is enabled, approval echoes the CR pins (payload_sha256, primary_artifact_sha256, listing_revision, and pins_sha256) to the reserved CR act edge. Review request opens the proposed child as a listing under My Listings, wrapped in Approve this custom extract, with Approve, Request changes, and Decline at the bottom of that wrap. That wrapped listing has no Purchase button. Download on seller detail, owned-public detail, and unreleased review is the same owner download as on any listing you own (GET /ownership/{id}/download) — the child is a real listing that is not released or public yet. Decline or return marks the unreleased child rejected and removes it from every buyer surface; return additionally requires a revision note that the Seller's Agent can read back through sign-off history before it creates a new child. All acts return you to Inbox. The visual target is the accepted UX-1001 listing wrap; the object you approve remains the Change Request / sign-off, not a portal-only overlay.

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 proposes the extract's price_cents. It must make a defensible proposal from the owner's guidance and the buyer's ask; it must not copy a stale number from an older listing, an earlier proposal, the catalog, or seller_stats, and it must not use $0 as a payout-onboarding bypass. The platform validates the proposal against its price bounds and payout eligibility. create_derived_listing requires that proposal, and the child remains hidden and unpurchasable while pending. The review packet the agent prepares (using get_signoff_item) shows the proposed price_cents, the extract, its provenance and frozen terms. You, the human owner, approve or reject that proposal; approval is required before publication. If the agent cannot make a defensible proposal, it escalates rather than guessing.

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 hosted Seller Agent call list_my_listings, find the parent row, and inspect public_visibility (an ordinary seller MCP session may use get_my_listing for the single-row read):

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, returning, or declining is a deliberate human act through the owner Change Request in your Cognito session; 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 live Change Request projections 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 human decline or return marks the unreleased child rejected atomically and removes it from buyer surfaces; rework creates a new child and Change Request. 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.

Review window and expiry

A pending approval is reviewed within a fixed review window from the moment your agent stages the listing for your sign-off. If that window lapses before you action it, the single lifecycle sweeper — one worker, no second worker — expires the pending approval: the object is voided (it can never be released as-is), its live slot is cleared, and the transaction observing it is closed with the reason "review window expired". The agent sees the expired approval drop out of its pending queue and can open a fresh review round rather than re-approving a stale one. The deadline is platform-sourced, not readable-back as seller-authored; the agent never extends or fabricates it. (Enabled in production with SAT; 404/absent only if the SELLER_TXN_ENABLED kill-switch is off.)

SAT approval-bundle handoff

When the hosted worker finishes a Spec, it creates the derived child and submits an approval-bundle draft with submit_bundle_draft. The draft pins the Spec revision/hash, the child and primary artifact hash, a closed coverage summary, and any bounded gap choices. The create first mints a non-actionable draft Change Request and returns pending_bundle; bundle submission completes that same Change Request and delivers it to the Inbox. It carries no worker-supplied price: the platform pricing engine is authoritative. The draft is pending until you review it; neither hosted agent role can approve it or send an offer.

The human seller reviews through the Cognito-only REST routes documented in the API reference:

GET /api/v1/seller/bundles/pending lists pending revisions.
GET /api/v1/seller/bundles/{id} returns the exact pinned review packet: Spec prose/revision/hash, closed coverage JSON, engine price, buyer type, transcript reference/hash, deliverable download, and available diff attachments. Its llm_summary is explicitly a view, not an approval pin.
GET /api/v1/seller/change-requests/{id} returns the canonical owner review.
The owner Change Request approve, return, and decline routes are the only seller decision edges. The bundle action route is unavailable for derivation_approval.

Approval atomically creates and sends the pinned offer. The buyer must later accept it and settle payment; delivery is reported only after durable settlement and ownership records exist.

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. See Where your data goes for the public model-layer disclosure.

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.

Inbox and Change Request review

Non-SAT seller-worker create_derived_listing creates a pending Change Request and one referring Inbox delivery atomically. The Inbox item’s authorized subject is {change_request_id, target_listing_id, state, pins:{payload_sha256, primary_artifact_sha256, listing_revision, pins_sha256}}; an unauthorized or terminal subject is omitted. Its act_href is the Change Request resource (/api/v1/seller/change-requests/{id}). Approve, return, and decline are separate routes and require the echoed pin set. The Change Request's review block contains the listing, parent, artifacts, frozen terms, history, consent, and available containment metadata needed for the decision. SAT approval additionally echoes the nested Spec, coverage, and transcript hashes; price and bundle coordinates remain server-owned. When the current Derivation Authorization is not accepted, approval must explicitly set accept_derivation_authorization:true. Return requires a non-empty note; return and decline both write the terminal rejected disposition, and rework creates a new child/CR. Every create carries a required create_idempotency_key; reuse the same key on retry so a lost response or concurrent duplicate returns the original child and Change Request instead of creating another.

Both standard and sample children use this seller-worker MCP path. Ordinary creation is unavailable to human Cognito sessions and other agent roles, so a successful create always has its actionable Change Request and Inbox delivery. Retried idempotency bindings are checked against their stored creator role, parent, derivation class, and redraft lineage.

The Inbox and owner Change Request are the only review and decision surface. The MCP pending-list and detail tools are read-only projections of those same live Change Requests, not a second authority.

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 Change Request actions, builder, activity, review, and lifecycle shapes.