Licensing

Every Amnetic listing is sold under a license — the terms that say what a buyer may do with the data. By default a listing sells under its standard terms (the frozen platform defaults) at the listing's price_cents. Listings may also expose additional priced licensing tiers — an offer ladder — so a buyer can pay more for broader rights (commercial use, model training, redistribution within their org) or less for a narrower grant.

Availability. License terms are always live. There is no LICENSE_TERMS_ENABLED boot gate. Every buyer-visible listing has an always-on materialized base-offer menu, including exact-text and rights-fit additions. Counsel review still governs composed-term interpretation. Seller policy authoring is moving to the replacement terms workflow; the former seller authoring tools/routes and inline create block are removed.

The Data Standard License (DLS)

The platform's current default composition is a provisional quote-integrity input, not a settled interpretation of model training or any other operative right under ToS §5.3. That interpretation remains pending counsel review. DLS-1 is the draft instrument version used by the dark composed-offer work; it is not yet a GA claim that the standard tier is governed by a ratified DLS. Until quote and settlement transition together after counsel approval, standard quote evidence remains pinned to the pre-ratification tos/5.3-draft instrument. A composed offer records its instrument version when it is composed, so a later grant's meaning is fixed at purchase time and cannot be rewritten under a buyer's feet.

The rights themselves are expressed as a terms composition over a small, frozen vocabulary (schema lts/1): a set of named dimensions, each taking one option from a closed list. There are no free-form terms — this is what lets the market compare, price, and reason about grants, and what keeps the agent-facing surface an enum, not an injection vector.

The terms dimensions

An offer's terms is a { dimension: option } map. You supply only the dimensions you want to change; every omitted dimension takes its platform default, and the stored composition is always fully materialized (every dimension explicit).

Dimension Options (narrow → broad) Default Meaning
use non_commercial | commercial commercial Whether the data may be used commercially.
redistribution_scope individual | entity | entity_affiliates entity How widely, within the buyer's own organization, the data may be shared. External redistribution is never an option.
derived_display none | public none Whether derived features/analytics may be displayed publicly.
training none | internal none Whether the data may be used to train models (internal to the buyer).
training_serve none | allowed none Whether a model trained on the data may be offered as a service. Requires training: internal.
training_weights none | allowed none Whether trained model weights may be distributed. Requires training: internal.
term perpetual | 12 | 24 | 36 perpetual Use term in months (a closed set — no arbitrary integers).
attribution required | not_required not_required Whether the buyer must attribute the source.
exclusivity none | exclusive none Reserved. Exclusive grants are not sold in v1 — composing exclusive is refused.

training_serve and training_weights are peers, not a ladder — each is a separate election on top of training: internal, and composing either without training: internal is a hard error. A composition that exactly equals the platform defaults is refused as an offer (the materialized standard base rung is already offered), so every priced tier is a genuine departure from default.

Offer keys

Each tier carries a seller-chosen offer_key — a short, stable slug matching ^[a-z0-9][a-z0-9_-]{0,31}$ (e.g. internal_training, wide_commercial). It is the human-facing name of the tier and is stable across re-pricing. standard and default are reserved — they name the listing's materialized base rung — so you cannot use them as an offer_key.

A listing has at most 64 live offer rungs, including its base rung. Within a listing every live offer must have a distinct offer_key and a distinct terms composition — the live offer set is a function, not a bag.

Stored prices for both the standard listing tier and composed tiers must be nonnegative 32-bit integers. Composed tiers always pin an embedded DLS version; the pre-ratification Terms of Service discriminator is reserved for the materialized standard tier and cannot appear on a composed offer. Deployments also audit that no existing listing exceeds 64 active composed offers before enabling these backstops; if one does, migration stops and reports the listing and count for explicit operator reconciliation rather than retiring offers automatically.

Seller authoring transition

Every listing currently receives one materialized platform-default base rung at its listing price. The former set_license_offers / get_license_offers tools, inline license_offers create block, and portal tier editor are removed while seller policy authoring moves to the replacement terms workflow. Existing historical rows remain immutable; buyers select the active base rung by its offer_id.

Discovering public offers

Every public listing includes a non-empty menu; its standard rung has a real, immutable offer_id, the listing price and currency, and the derived menu view. That offer id selects the materialized base rung for a purchase. This pre-purchase metadata is not a representation that the displayed default view settles training rights or that DLS-1 is generally available.

The same always-on menu is attached to each enter_market recommended_listings[] entry after the forgetful agent returns its bounded listing-id verdict. This gives the outer buyer agent the offer_id to echo into a later explicit purchase without allowing the inner agent to author license data. It is quote metadata, not the operative license text, a grant, a debit, or acceptance. The exact pre-purchase text path remains separately gated; do not purchase from the enum metadata alone without reading that operative text. Buyers may also pass a non-empty, closed-enum required_rights object with minimums for any of the eight requestable dimensions (all dimensions above except exclusivity). For each recommendation, the platform compares those minimums against the already-visible ladder and attaches rights_fit.band (fit, partial, no_fit, or unknown). Only fit carries best_offer: composed fields are copied from the selected visible ladder entry, while standard normalizes its terms/price with listing currency. Cheapest fit is deterministic by price, then standard before composed, then composed offer id. This is mechanical fit computation, not legal advice, permission, warranty, operative text, acceptance, or a grant.

Without a non-empty requirement, recommended_total_cents remains the sum of standard listing prices and preserves its historical omitted-all-zero wire. With requirements active, it instead sums current best_offer prices; non-fit rows contribute zero and an all-zero total is emitted explicitly. The number is advisory only—no funds or rights are reserved. This surface is available only in non-production flag-on environments and remains absent in production pending counsel ratification.

For an open public listing, read the exact operative text before buying with GET /api/v1/listings/{listingId}/license-text/{offerKey}. Use the active offer_key advertised in menu (standard for the current base rung). The response repeats the resolved terms, schema and instrument versions, hashes, price, currency, and offer id beside the hash-verified stored text; composed offers also include their immutable offer_id. Responses are never cacheable (Cache-Control: no-store) because a seller may retire and re-compose the same key—bind your decision to offer_id. The route is absent while licensing is off, and hidden listings or unavailable keys return opaque 404s.

This is availability evidence, not a legal conclusion. Counsel still needs to confirm that assembled machine-readable terms and purchase-as-acceptance are sufficient, and whether eligible buyers of restricted listings require a separate authenticated pre-purchase text path before GA.

In-wall offer discovery

The forgetful buyer agent sees the full offer ladder when it examines a listing. get_listing adds a non-empty top-level menu array without changing its listing_id input. In the current slice the array contains the one materialized base rung:

{
  "menu": [
    {
      "offer_id": "offer-...",
      "offer_key": "standard",
      "terms": { "use": "commercial", "redistribution_scope": "entity", "derived_display": "none", "training": "none", "training_serve": "none", "training_weights": "none", "term": "perpetual", "exclusivity": "none", "attribution": "not_required" },
      "price_cents": 4500,
      "currency": "usd"
    }
  ]
}

This buyer-safe projection deliberately omits schema/DLS versions, row status, and evidence documents. Terms are the closed lts/1 vocabulary above, not seller prose. Hidden, inactive, self-owned, or ACL-ineligible listings remain opaque. The inner agent still returns only listing ids; the outer recommendation ladder is a separate platform-side read of current public/authorized offer metadata, so seller content and inner-agent prose never gain a new egress channel.

Buying a materialized rung

A buyer selects a tier at purchase time. The purchase tool accepts offer-aware items instead of bare listing ids:

{ "items": [ { "listing_id": "…", "offer_id": "…" } ] }

REST POST /api/v1/purchases accepts the same selectors as top-level fields beside listing_id. Both REST and MCP also support funding_mode card modes for a single listing; card mode returns a hosted Stripe checkout URL and grants the license only after webhook settlement.

  • offer_id selects the immutable materialized rung to buy.
  • renew_of_grant_id renews an existing grant on the same terms.

Each completed purchase returns its offer_id, offer_key, terms_hash, and a grant_id (the evidence record of the license you now hold), and an outcome of purchased or already_licensed (buying a tier you already hold is reported, not double-charged). Offer-level refusals return a structured error_code (offer_unavailable, price_changed, or renewal_invalid) with the listing id and detail; offer_unavailable includes the current live offers so the buyer can re-select.

For a rights-fit recommendation, echo rights_fit.best_offer.offer_id into purchase. Settlement re-resolves the selector, and only the minted grant is license evidence. On the asynchronous card rail, post-payment drift can produce funded_only: the money remains spendable, nonwithdrawable wallet credit and no license grant is minted.

Request-board candidates also retain an immutable offer identity. Submission captures the current standard offer and exposes its offer_id in candidate readback. A later fill binds that row, rather than choosing a replacement with the same price. An unavailable captured offer refuses the fill without charging; the request's existing escrow and expiry rules still apply. Historical candidates without a captured offer cannot acquire one retroactively at settlement.

Next