Valuation pipeline resolution: featured tracks, composition-side royalties (PRO/MLC), MLC registration check, onchain catalog lane

[sweetmantech]

Tracking issue for raising the resolution of the catalog valuation pipeline — closing the coverage gaps the public $16K baseline exposed, each one auditable back to a named data source. (Business context, once: LATASHÁ audited her public baseline twice in 48h — first "between features etc it seems a little odd" (correct: 29 appears_on releases uncounted), then "does this include mechanical royalties through PROs, MLC… and when the song is purchased?" (correct: composition-side and sales income are $0 in the model). The public-model-invites-audit loop is working; this issue is the fixes it produced.)

2026-07-09 scope expansion (sweetman): originally featured-tracks only. After LATASHÁ's second audit question (PRO/MLC mechanicals + purchases) and the episode-2 publish, scope now covers the near-term coverage items: featured tracks, composition-side royalties (modeled from already-measured streams), MLC registration/black-box check, and the onchain catalog measurement. Statement-gated lanes (actual purchases/downloads, sync, live) stay out of scope until the statement-ingest consumer flow exists — noted under Out of scope.

Goal

The valuation stops being one number and becomes a ledger of income lanes, each labeled measured / modeled / not yet counted, with every lane's data source public and linked. Concretely:

• marketing/lib/valuation/resolveArtistAlbums.ts (today L36: include_groups: "album,single") also resolves appears_on releases, and the measurement/read path counts only the artist's credited tracks on those releases — valued as a featured-artist share (a royalty on someone else's master, never full NLS).
• The same measured streams also produce a composition-side (NPS) band — statutory mechanicals + estimated performance royalties × writer's share × a publishing multiple — as a second labeled number next to the master-side band.
• An onchain catalog lane measures primary/secondary sales + creator royalties from public chain data (Zora, Sound.xyz, and peers) for artists with onchain releases.
• The methodology contract (catalog-value-estimator skill references/methodology.md) defines each lane's model first; the code implements it (documentation-driven, docs → implementation).
• The valuation-formula drift guard (golden fixture pair api#765 / marketing#44) stays green — any formula change lands lockstep in both repos.

PRs (updated 2026-07-09 — merge order top to bottom; none opened yet)

PR	Item	Base	State
tbd — skills	Methodology contract v2: featured-track share, composition-side (NPS) model + statutory rate sources, onchain lane definition, lane labels (measured/modeled/uncounted) in catalog-value-estimator references/methodology.md	main	⬜ not started — contract-first, leads everything
tbd — marketing	Featured tracks: add appears_on to resolveArtistAlbums, filter to the artist's credited tracks, apply the featured-share band, surface the own/featured split	main	⬜ not started — the original item; smallest diff, ships first after the contract
tbd — marketing	Composition-side band: compute NPS from the already-measured streams (statutory mechanical + estimated performance rates × writer's share × publishing multiple); render as a second labeled band	main	⬜ not started — zero new data pulls; pure model + UI
tbd — api	MLC registration check: query The MLC's public works database by title/writer (or ISRC via matching) and report registered / not-found per work	main	⬜ not started — new external source (The MLC), read-only
tbd — design note → api	Onchain catalog lane: indexer choice + wallet/contract resolution design, then measure primary/secondary sales + creator royalties per artist	main	⬜ not started — needs the design note first (see Open item)
tbd — api (only if the shared formula changes)	Lockstep golden-fixture update for the drift guard	main	⬜ conditional — required iff a lane touches the shared formula/fixture

Merge sequencing: skills (methodology contract v2) → marketing featured-tracks → marketing composition-band (independent of each other after the contract; either order) → api MLC check (independent) → onchain design note → api onchain lane. Any change to the shared valuation formula lands in the same window as its api/marketing lockstep-fixture twin (the drift guard exists to make a lone-repo formula edit fail CI — feed it, don't fight it).

Open — featured tracks (the original item)

• Include appears_on releases in valuation resolve and value them as a featured-artist share. (→ _tbd marketing PR; contract in tbd skills PR)
  • Why: resolveArtistAlbums.ts requests include_groups: "album,single" only, so featured appearances are invisible to the measurement job and the valuation. Confirmed live 2026-07-09 against the same auth-free proxy the flow uses: GET /api/spotify/artist/albums?id=2lW1SPnxy7JqGV84TcSINi&include_groups=appears_on → 29 releases for LATASHÁ (incl. Honey Dijon "Black Girl Magic" 2022, Witch Prophet "DNA Activation (Deluxe)" 2021). Found by the artist auditing her own public number (her quote, 2026-07-08).
  • Data source: the existing Spotify artist-albums proxy (GET /api/spotify/artist/albums?…&include_groups=appears_on — auth-free, already deployed) + the existing measurement-jobs playcount capture. No new external source.
  • Fix (contract-first):
    1. skills PR — extend references/methodology.md: featured tracks are valued as the featured artist's royalty share on someone else's master (a labeled share band, not full NLS), and the estimate must report own-catalog vs. featured value separately. Decide and document the default featured-share band there, not in code review.
    2. marketing PR — resolveArtistAlbums: fetch appears_on (decide compilation while in there) alongside album,single; keep the 200-release cap honest (a comp-heavy featured artist can blow past it — state what's dropped). Measure/read only tracks where the artist is credited (per-track artist filter at the read step — the whole host album must not count). Compute: apply the featured-share band from the contract; surface the split in the result + assumptions block.
    3. Cost control: each resolved album costs actor spend + 5 credits/read (resolveArtistAlbums.ts header comment) — 29 extra albums for LATASHÁ is fine; a Various-Artists-comp-heavy discography is not. Gate or cap appears_on volume deliberately and say so in the assumptions.
  • Done when: re-running LATASHÁ's valuation resolves her 29 appears_on releases, measures only her credited tracks on them, and returns a band with the featured contribution separately labeled; the drift-guard suites are green in both repos; the assumption stack shows the featured share as a visible, auditable constant.

Open — composition-side royalties (added 2026-07-09, her second audit question)

• Model the composition-side (NPS) band from the streams we already measure. (→ _tbd marketing PR; contract in tbd skills PR)

  • Why: the pipeline prices the sound recording only. The same measured streams also generate composition income — US streaming mechanicals (paid via The MLC) at statutory rates set by the Copyright Royalty Board (Phonorecords IV, 2023–2027 — crb.gov), plus performance royalties (paid via PROs — ASCAP/BMI/etc.). For self-published writer-artists (LATASHÁ writes her own songs) this is a whole second asset, and publishing catalogs trade at higher multiples than masters (methodology.md §4 already notes this). Today the model answers "no" to a question it could answer with a labeled band.
  • Data sources (all public, no new scraping):
    • Streams: the existing measurement store (already captured — zero new pulls).
    • Mechanical rates: CRB Phonorecords IV statutory rate structure (crb.gov); The MLC's published royalty/rate explanations (themlc.com). Model as a labeled per-stream mechanical band (document the derivation in methodology.md, same style as the $0.0035 master rate).
    • Performance royalties: no public per-stream rate — model as a labeled ratio to mechanicals (industry-standard assumption, documented with its source in the contract PR).
    • Writer's share: default assumption band (self-published vs. co-writes), labeled; overridable per artist.
  • Fix: skills PR defines the NPS stack (streams × mechanical band + performance estimate × writer's share → NPS × publishing multiple band); marketing PR computes and renders it as a second band, clearly labeled modeled and composition-side, never merged into the master-side number (methodology.md already forbids merging NPS into NLS).
  • Done when: a valuation returns two labeled bands (recording side / composition side), each with its own visible assumption stack; the LinkedIn/X answer to "does it include PRO/MLC money" changes from "no" to "yes — modeled, here are the assumptions."

• MLC registration / black-box check per work. (→ tbd api PR)

  • Why: beyond modeling dollars, we can verify whether the artist's works are even registered with The MLC — unregistered works accrue unclaimed ("black box") mechanicals. For an artist-facing report this is found money, not just valuation resolution.
  • Data sources: The MLC Public Search API (programmatic search of the works database by title/writer/publisher — see The MLC data programs) and the Bulk Database Feed (full works DB in the DDEX BWARM format — themlc.com/bulk-database-feed, standard explained at kb.ddex.net; registration contact bulk.data@themlc.com; The MLC's GitHub: github.com/TheMLC). Start with the Public Search API (per-work lookups fit our per-catalog scale); the bulk feed is the scale-up path.
  • Fix: api-side lookup keyed by work title + writer name (we have both from the Spotify metadata), reported per-track as registered / not found / ambiguous — a neutral observation in the report, per the estimator skill's risk-observation rules.
  • Done when: LATASHÁ's report lists per-work MLC registration status with the query used, and the valuation surfaces "N works not found in The MLC database" as a labeled observation.

Open — onchain catalog (added 2026-07-09; the $500K she actually cited)

• Design note first: onchain catalog measurement lane. (→ tbd design note, then api PR)
  • Why: her exact objection — "I made a half a million on digital assets and NFTs" — names income that is fully public and more auditable than any DSP statement: mints, sales, and creator royalties on music-NFT platforms are onchain events. Nobody else in the valuation space measures this lane; we are uniquely positioned to (onchain music is the founder's home turf). For LATASHÁ (ex-Zora head of community) this turns her own claim into our measurement.
  • Data sources:
    • Zora: docs.zora.co — Coins SDK with a public REST API for current-era data; historical NFT-era contract events via the Zora chain explorer API (explorer.zora.energy/api-docs) and standard RPC event indexing (her era spans mainnet Zora NFT contracts too).
    • Sound.xyz: docs.sound.xyz — GraphQL API over indexed Sound Protocol events incl. metadata (getting started; API key required).
    • Cross-platform / long tail (Catalog, Manifold, direct contracts): Dune queries or in-house event indexing keyed by the artist's verified wallet(s); design note picks the approach.
    • Wallet resolution: the artist's public wallet(s)/ENS — for cast members, confirmed directly (consent-first, same as the streaming measurement).
  • Fix: a short design note decides (1) indexer strategy (platform APIs vs. Dune vs. own indexer), (2) wallet/contract resolution + verification, (3) what counts as catalog income (primary mints, secondary creator royalties; exclude flips she didn't earn on), (4) fiat conversion policy (price at tx time — needs a historical price source, name it in the note). Then the api PR implements the lane, labeled measured with tx-level provenance.
  • Done when: for a consenting artist with known wallets, the report shows onchain catalog income (primary + secondary royalties) with per-platform subtotals and links to the underlying transactions; LATASHÁ's number is measurable against her "half a million" claim.

Out of scope (stated once, deliberately)

Actual purchases/downloads, sync, and live income are statement-gated (distributor sales reports, PRO/MLC member statements, DDEX DSR files) — no public source exists. They become a statement-ingest consumer flow ("connect your distributor / upload a statement → calibrate the model"), which is its own tracker when we take it on; the recoup-catalog-ingest engine already normalizes these formats. Until then the model reports them as labeled $0 — not yet counted, which is the honest answer episode 2 already gives publicly.

Source references

• Gap verified in code + live: marketing/lib/valuation/resolveArtistAlbums.ts (include_groups), computeCatalogValuation.ts, nlsBandFromSpotifyGross.ts (the assumption stack the new lanes join).
• The audits that drove this: LATASHÁ's quote tweet 2026-07-08 (features → confirmed gap) and her 2026-07-09 follow-up in the same thread (PRO/MLC mechanicals + purchases — composition-side and sales lanes).
• The published answer this issue backs: episode 2, "the back end, opened up" (X post · YT · LinkedIn — the first comment links this issue as the public receipt).
• Methodology home: catalog-value-estimator skill, references/methodology.md (recoupable/skills).
• External data sources: The MLC (data programs / Public Search API · Bulk Database Feed · BWARM standard · github.com/TheMLC) · CRB (Phonorecords IV statutory rates) · Zora docs (public REST API · chain explorer API) · Sound.xyz docs (API getting started) · Dune.
• Related integrity work: valuation-formula drift guard api#765 + marketing#44 (tracked in chat#1863).
• Strategy grounding: strategy/recoup-rostrum-baseline/recoup-permissionless-data-architecture.md (the public-data doctrine + verification loop) and rostrum-royalty-tracking-architecture.md (the statement-side landscape, incl. The MLC row).