Disciplines · Proposals

YSD-0124 — First source posture

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

6sections2 minread
Markdown source
On this page
  • 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.