# YSD-0124 — First source posture

- **Status:** approved (2026-07-18)
- **Priority:** P0 EXT — blocking (production rollout gated via YSD-0139)
- **Decision owner:** @GreyChimp
- **Drafted:** 2026-07-18 by Claude Code (claude-fable-5)
- **Approval:** approved as recommended by @GreyChimp on 2026-07-18; outcome
  recorded in decision-log.json; review by 2027-07-18

## Question

Local/owned files, approved provider integrations, or both?

## Recommendation

Local/owned files only for the first release (matches YSD-0017/YSD-1030):
resumable upload of creator-owned or rights-cleared local media, plus
metadata-only records for everything else. Provider deep-link registration
(link-only playback, YSD-4009/YSD-5004) enters in a later phase after the rights
resolver is production-hardened.

## Options considered

- Providers first — rejected: provider authorization is region-specific,
  revocable, and legally heavier than local files; it would block the walking
  skeleton on external agreements.
- Both at once — rejected: doubles the rights-policy and security surface before
  either is proven.

## Consequences

- Region-specific legal constraints for providers are documented when that phase
  opens; the fallback when provider authorization is unavailable is an honest
  metadata-only source record (YSD-5007).

## Machine-enforced outcome

Source-class feature flags (YSD-1014) ship with only local-file classes enabled;
provider classes exist as fail-closed unsupported responses.

## Conformance ruling — has the phase opened? (2026-08-14)

A conformance question was raised against this decision on 2026-08-09: provider
deep-link registration was a live, ungated route, `acquisitionCapabilities`
reported the method supported with no condition on it, and nothing in the system
distinguished "the later phase has opened" from "it has not". The link-only
property this decision attached to providers _was_ enforced — no representation
the workspace generates is derived from a provider link — so what shipped was a
correctly-constrained provider integration in a release whose approved source
posture had none.

**@GreyChimp ruled on 2026-08-14 that the phase has NOT opened.** This decision
therefore stands unamended, and the product was brought to it rather than the
other way round:

- `PHASE_GATED_SOURCE_CLASSES` (`policies/feature-flags.ts`) makes
  `provider-deep-link` default-DENY on an axis whose other eleven keys default
  enabled — "known to the product" and "shipping in this release" were the same
  answer here, and are now two.
- `registerProviderSource` and `resolveProviderPlayback` refuse through that
  gate before touching the store, so a closed phase cannot be probed for which
  work ids exist.
- `acquisitionCapabilities` reports `source.provider-deep-link` as unavailable
  with the same reason, so what a client is told and what the write path does
  cannot disagree.
- A deployment opens the phase with
  `STUDY_FLAGS_ENABLE=source-class:provider-deep-link`, which the service logs
  in its startup config summary. That is the recorded act the question asked
  for.

The reason only the owner could settle it: the two readings called for opposite
acts — amend the decision to say providers had arrived, or gate the route until
they have — and a machine can see the divergence without being able to say which
side of it the programme is on.