Selling slices of a dataset

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.

This is an opt-in, dark beta. Its portal and API surfaces are absent unless the deployment enables them, and production enablement remains blocked until the Slice Authorization rider is counsel-ratified and the production path is deployed.

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.

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:

low-cardinality text or Boolean facets and numeric or date ranges;
an Extraction-agent helper instruction;
an optional CSV, XLSX, or TXT key list of at most 1 MiB.

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. The optional key file is uploaded for preview and matching, so attach only material you are authorized to process.

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 frozen 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 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.