Copy-paste these into rdx-federation-stage.smecloudops.com/playground/
Run them in order. Screenshot any results.
These are the money shots. If ANY of these return clearance data
while Runway shows "Unknown," that's the gap made visible.
{
clearancesForIsrc(isrc: "USRC12600343") {
nodes {
status
clearanceType
originalWork
rightsHolder
}
}
}
{
clearancesForIsrc(isrc: "USRC12600494") {
nodes {
status
clearanceType
originalWork
rightsHolder
}
}
}
{
clearancesForIsrc(isrc: "USRC12600224") {
nodes {
status
clearanceType
originalWork
rightsHolder
}
}
}
{
clearancesForIsrc(isrc: "USRC12600092") {
nodes {
status
clearanceType
originalWork
rightsHolder
}
}
}
{
clearancesForIsrc(isrc: "USRC12600495") {
nodes {
status
clearanceType
originalWork
rightsHolder
}
}
}
NOTE: If these error on the sub-fields, try just:
```graphql
{ clearancesForIsrc(isrc: "USRC12600343") { __typename } }
```
That tells you if the query resolves at all.
Compare what RDX returns vs. what the export shows.
Using the same window: March 27 – May 18.
{
mktTimeline(fromDate: "2026-03-27", toDate: "2026-05-18") {
nodes {
mktProducts {
nodes {
title
artistName
streetDate
workability {
score
kpis {
nodes {
name
status
weighting
}
}
}
alerts {
alertType
daysUntilRelease
}
}
}
}
}
}
What to look for:
- Do the workability scores match what the export shows?
- Are there AT_RISK or WARNING alerts on the March 27 releases?
- Does RDX show any KPI statuses that differ from the export?
If clearance queries come back empty, try the repertoire angle.
These look for contributor/participant data that could fill SAA.
{
participantSearch(name: "Sheff G") {
nodes {
name
role
recordingProjects {
nodes {
title
status
}
}
}
}
}
{
participantSearch(name: "ASAP Rocky") {
nodes {
name
role
recordingProjects {
nodes {
title
status
}
}
}
}
}
{
participantSearch(name: "Ray Vaughn") {
nodes {
name
role
recordingProjects {
nodes {
title
status
}
}
}
}
}
NOTE: If participantSearch errors, try introspecting first:
```graphql
{ __type(name: "Query") { fields { name } } }
```
Then Ctrl+F for "participant" or "repertoire" in the results.
Less about workability, more about proving the data pipe works.
If these return rich metadata, it proves SCUBA can replace
manual data pulls for Crawley's insights decks.
{
spotifyArtistById(id: "4TXzFwKOHVRMPSiamcrya0") {
name
popularity
genres
followers
}
}
{
spotifyArtistById(id: "0rPFhJknwkFaMb4tOUdKJ4") {
name
popularity
genres
followers
}
}
{
spotifyArtistById(id: "13ubrt8QOOCPljQ2FL1Kg8") {
name
popularity
genres
followers
}
}
If these return data, screenshot them. That's a same-day
deliverable for Crawley: "I can pull this in 10 seconds
instead of you doing it manually."
Screenshot it. Put it next to the workability snapshot showing
"Unknown." That's your one-slide proof: "The data exists. Nobody
is reading it." Send to Jordan immediately.
That's expected in STAGE. Note it and move on. The query WORKS —
you just need production data. Message to Jordan:
"Query confirmed, need production access to see real data."
That's actually MORE interesting — it means data is updating
in one system but not flowing to the other. Screenshot both.
Screenshot it and save for Crawley. This is a Week 2 deliverable:
"I can automate the data pull for your insights decks."