# YSD-19124 — Teaching-pack marketplace mechanics

- **Status:** approved (2026-08-14)
- **Priority:** EXT — non-blocking (the transfer vocabulary has no verb for
  selling anything, so there is nothing to gate)
- **Decision owner:** @GreyChimp
- **Drafted:** 2026-08-11 by Claude Code (Opus 5)
- **Approval:** approved as recommended by @GreyChimp on 2026-08-14; outcome
  recorded in decision-log.json; review by 2027-08-14

## Question

The checklist asks for teaching-pack marketplace mechanics **only after**
rights, review, and quality controls are settled. Is a marketplace in scope at
all, and if so, what is the unit of sale?

The unit of sale is the whole question. A teaching pack is built out of evidence
anchored in third-party works under grants that permit study and do not permit
resale, so a marketplace either sells something that carries no source material
or it sells something this product has no right to sell.

## Recommendation

Do not build marketplace mechanics, and keep the absence structural rather than
scheduled. If a marketplace is ever wanted, the unit of sale must be the
abstraction — principles, constraints, questions, tasks, criteria — which the
transfer contract already restricts destinations to, and it must be a new
decision recorded here rather than a widening of this one.

## Options considered

- **Sell teaching packs including their evidence** — rejected: the grants that
  permit study do not permit redistribution, and a pack's value is largely the
  evidence.
- **Sell abstractions only, now** — rejected as premature: rights, review, and
  quality controls are the item's own precondition and the evaluation panel
  (YSD-18002) does not exist.
- **Do not build; keep the absence enforced by the vocabulary** — recommended.

## Consequences

- No listing, pricing, payout, or royalty surface exists, and none is planned.
- Third-party teaching packs remain shareable under the existing transfer and
  signing rules, which are not commerce.
- Reopening this needs a new approval, not a backlog ticket.

## Machine-enforced outcome

The approved-destination register stays a closed list of production artifacts,
and any destination outside it is refused at runtime rather than merely absent
from a type.

## Control in force

The absence is now decided rather than merely unbuilt, and it is enforced by
vocabulary rather than by intent: `APPROVED_TRANSFER_DESTINATIONS` contains no
listing, storefront or marketplace destination, and `destinationCapabilities`
throws `UnapprovedDestinationError` for anything not on it. A marketplace cannot
leak rights because there is no verb for selling a study to reach. Any future
marketplace is a NEW decision recorded beside this one, never a widening of it.