Chai With JaiGPU Study Hall
Menu

A reference architecture for monetizing music IP

Which songs should we invest in next?

I built an evidence service on Google Cloud to investigate a catalog's earnings. Here is how I would use that work, alongside merchandise and customer records, to select recordings for a clipping campaign and test whether it earns more than it costs.

Explore the framework

A Databricks medallion approach.
Built and served on Google Cloud.

A / 001

Worked example: private evidence reviews in approved AI clients.

Next commercial test: a campaign with a measured result.

01The investment decision

The evidence behind the campaign selection

An artist's catalog can keep earning after the artist has died. The team still has to choose where to spend time and money on the recordings that remain. Streaming statements are one source of evidence. I also want to investigate whether merchandise purchases associated with a body of work can help identify songs worth promoting.

REFERENCE ARCHITECTURE

From catalog records to a campaign

Catalog · royaltiesCRM · merchandisePartners · files

Source, identity
and access

Permitted, traceable evidence

B→S→G

Bronze → Silver → Gold

Review, receipt
and finding

A review with scope and source receipts

Google CloudMCP + approved clients

Proposed clipping
campaign

Campaign + measurement plan

FIGURE 01 · THE FRAMEWORK

Permitted records become a scoped review. The review supports a campaign selection; dated results return as new evidence.

Evidence reviews: implementedClipping campaign: proposed

Medallion pattern from Databricks · reference implementation on Google Cloud.

In one earnings review, the supplied Spotify records covered different months in the two years. Restricting the comparison to the months present in both years changed the result.

I approach the work in three steps. First, I connect the available data through a unified API that checks the caller's access and preserves source identity. Second, I investigate the records and build domain tools that return a calculation with its coverage and original receipts. Third, I serve those tools through Google Cloud and MCP so the team can use the findings in its working environment and return campaign results for review.

For this example, the proposed action is a coordinated clipping campaign. The team would choose a group of recordings supported by the evidence and publish permitted short clips. We would follow the response through to proceeds the catalog owner can receive. The commercial test is whether the campaign produces additional cash flow after its costs.

ContinueThe sources

02Step 1 / Build the unified data API

An artist's business is spread across other people's systems.

An artist can begin with contacts and files in Google Workspace, then sign a record deal and acquire a new set of reporting systems. A merchandise store keeps purchase history. A promoter holds ticketing records. By the time the artist has a valuable catalog, years of business activity may be distributed across organizations with separate agreements and access rules.

REFERENCE ARCHITECTURE

From catalog records to a campaign

Catalog · royaltiesCRM · merchandisePartners · files

Source, identity
and access

Permitted, traceable evidence

B→S→G

Bronze → Silver → Gold

Review, receipt
and finding

A review with scope and source receipts

Google CloudMCP + approved clients

Proposed clipping
campaign

Campaign + measurement plan

INSIDE 01

Unified data API

Example: supplied royalty export

Origin
Source file + original row or cell
Coverage
Supplied periods + missing-period flags
Identity
Recording / store / period; uncertain matches kept separate
Authority
Source owner + access policy

The review keeps the source reference and coverage attached.

FIGURE 01 · THE FRAMEWORK

Permitted records become a scoped review. The review supports a campaign selection; dated results return as new evidence.

Evidence reviews: implementedClipping campaign: proposed

Medallion pattern from Databricks · reference implementation on Google Cloud.

Start with a royalty export you are permitted to use. Record which organization supplied it, which periods it covers, and what the amount fields mean. To investigate whether merchandise purchases are associated with the same body of work, find who controls those purchase records and establish the permitted use. The first dataset may already be available while the second requires a conversation with a partner. Keep both in the source register, with that difference visible.

Keep the original files in private storage and retain each source version used to prepare an answer. In the reference implementation, I used Google Cloud Storage and preserved references to original spreadsheet cells and statement rows. A corrected royalty export should create a new version. An analyst reviewing the earlier result should still be able to inspect the evidence used for that calculation. Preserve source dates separately from the date a file arrived.

At request time, resolve the caller's organization from its current authenticated membership. Check access to the selected evidence product and to any original receipts the caller requests. A catalog-earnings request can select a period and store, but those selections cannot confer permission to read another organization's records. OAuth provides the connection's authorization flow; the service still has to enforce membership and product scope.

Review tool contract

What the review must return

Result
The observed amount, its source-defined metric, and currency.
Scope
The selected store or recording and comparison periods.
Coverage
The supplied periods and any missing observations.
Lineage
The source revision and references to contributing records.
Follow-up
A permitted path to the original cell or statement row.
A calculation is reviewable when another person can recover the same scope and follow its evidence.
ContinueThe investigation

03Step 2 / Investigate and build domain tools

The same earnings records support two different comparisons.

The retained first-half groupings contained Spotify observations for all six months of 2024 and four months of 2025. April and June 2025 had no Spotify observations in those groupings. January, February, March, and May were present in both years.

REFERENCE ARCHITECTURE

From catalog records to a campaign

Catalog · royaltiesCRM · merchandisePartners · files

Source, identity
and access

Permitted, traceable evidence

B→S→G

Bronze → Silver → Gold

Review, receipt
and finding

A review with scope and source receipts

Google CloudMCP + approved clients

Proposed clipping
campaign

Campaign + measurement plan

INSIDE 02

Domain tools

BronzeRetain sources
SilverCheck identity & coverage
GoldServe review + receipt
OBSERVED REVIEW“Compare Spotify across H1.”
Spotify first-half coverage. Amounts omitted. Used counts the months included in this comparison.
H1JanFebMarAprMayJunUsed
2024Jan 2024: observed and includedFeb 2024: observed and includedMar 2024: observed and includedApr 2024: observed and includedMay 2024: observed and includedJun 2024: observed and included6months
2025Jan 2025: observed and includedFeb 2025: observed and includedMar 2025: observed and includedApr 2025: absent from supplied recordsMay 2025: observed and includedJun 2025: absent from supplied records4months
IncludedObserved, excludedAbsent

The supplied totals cover six months versus four. Missing records are not zero earnings.

FIGURE 01 · THE FRAMEWORK

Next: request the April/June 2025 exports or evidence of completeness and timing.

Evidence reviews: implementedClipping campaign: proposed

Medallion pattern from Databricks · reference implementation on Google Cloud.

Using every supplied month answers how the reported amounts in the available records differ between the two years. Restricting both years to the four shared months answers a different question about those selected periods. The decline was smaller in the second calculation. Keep both results and their month selections visible. Neither establishes that reporting was equally mature in both years, and an absent observation remains unknown rather than zero. The next task is to obtain evidence about reporting coverage before explaining the cause of the difference.

I used the bronze, silver, and gold stages of Databricks' medallion approach to make that investigation reproducible. In bronze, retain the original files. In silver, prepare the detailed records with explicit periods and source identifiers. In gold, publish the two calculations with their coverage and references to the contributing records. The implementation runs on Google Cloud and applies this pattern without a Databricks workspace or runtime.

Build the royalty review around the question an employee asks about a store or recording over a period. Return the calculated amount together with the selected months and source version. Let the employee inspect contributing records and request an original receipt.

Keep source discovery separate from the calculation. I used semantic search to locate relevant sources from their descriptions, then exact source references to select the records. Decimal arithmetic determined the amounts. The language model could explain the result while the calculation remained reproducible from the retained evidence.

Connecting music to merchandise requires another investigation. A product associated with an album could give you a reason to examine that body of work. Review the relationship between the product and the catalog before joining the records. A matching title can refer to different recordings, and a purchase does not establish which songs that customer listens to. Keep unresolved matches separate until you have evidence for combining them.

For the campaign example, inspect the available customer definitions and purchase history, then test whether they support a particular group of recordings and a relevant offer. Save the evidence for each proposed relationship so another person can review the selection. Use the missing evidence to decide what to request from the commerce or catalog team before selecting recordings.

ARCHITECTURE REFERENCEThe Databricks medallion approach ↗

The worked implementation applies this pattern on Google Cloud. It does not run a Databricks workspace.

ContinueThe application

04Step 3 / Put the intelligence to work

Follow a business question to its source records.

An employee asks what changed in Spotify earnings over a selected period. The AI client requests a royalty review for that store and period through MCP, the Model Context Protocol. Before returning evidence, the service checks the caller's current organization membership and access to the selected product.

REFERENCE ARCHITECTURE

From catalog records to a campaign

Catalog · royaltiesCRM · merchandisePartners · files

Source, identity
and access

Permitted, traceable evidence

B→S→G

Bronze → Silver → Gold

Review, receipt
and finding

A review with scope and source receipts

Google CloudMCP + approved clients

Proposed clipping
campaign

Campaign + measurement plan

INSIDE 03

Application & action

ClientApplication / ChatGPT
ServiceCompute Engine HTTPS gateway
Cloud Run
EvidencePrivate GCS products
  1. 1Request a scoped reviewFrom client to service. Check authenticated organization membership before evidence access.
  2. 2Read published productsFrom service to private evidence products. Read permitted data for the review.
  3. 3Result + receipt referenceFrom service back to client. The receipt reference can be followed by a separate authorized fetch.

Hermes: current private-data acceptance is the next test.

FIGURE 01 · THE FRAMEWORK

The review composes published products. Follow the receipt reference with a separate authorized fetch of supporting records.

Evidence reviews: implementedClipping campaign: proposed

Medallion pattern from Databricks · reference implementation on Google Cloud.

In the Google Cloud implementation, the request passes through an HTTPS gateway on Compute Engine to the service on Cloud Run. The runtime reads published evidence products from Cloud Storage and composes the review. Preparation of the source files happens before those products are published. An approved client receives the requested result and references to the evidence it may inspect.

The response should keep the calculated amount beside its period coverage and source revision. A follow-up can request an original receipt under the same access checks. Verify the amount against the published calculation and check the receipt against its original row or cell. Those checks establish the evidence behind the selected answer. Connecting the client and exercising its permissions is a separate part of acceptance.

In the worked implementation, selected private-data reviews were exercised in ChatGPT and the application. Hermes was exercised with an earlier synthetic version. For each client, test an ordinary question without supplying the tool name or expected figure, then follow the answer to its evidence. Include revocation in the access tests. Broader employee adoption still requires testing the work with the people who will use it.

RUNTIME REFERENCEGoogle Cloud Run ↗

Cloud Build and Artifact Registry support releases. The visual simplifies the request path.

ContinueThe campaign

05Continue step 3 / Run and measure the campaign

Record the campaign so its economics can be reviewed.

The proposed next action is a coordinated clipping campaign. Thirty to fifty songs is an illustrative portfolio size. Select the actual recordings from the catalog and audience evidence, establish permission to publish the creative material, and assign someone to coordinate the campaign. The brief should explain why each recording was selected and where its clips will lead listeners.

REFERENCE ARCHITECTURE

From catalog records to a campaign

Catalog · royaltiesCRM · merchandisePartners · files

Source, identity
and access

Permitted, traceable evidence

B→S→G

Bronze → Silver → Gold

Review, receipt
and finding

A review with scope and source receipts

Google CloudMCP + approved clients

Proposed clipping
campaign

Campaign + measurement plan

INSIDE 03

Application & action

Proposed campaign record

Identity
Campaign + recording + creative version
Publication
Destination + date + spend
Observation
Response + reporting window + source
  1. 1Set baseline + window
  2. 2Observe response + proceeds
  3. 3Reconcile rights share + costs
FIGURE 01 · THE FRAMEWORK

Next: request dated partner statements for the campaign and reporting window. Bring this evidence back through stage 01.

Evidence reviews: implementedClipping campaign: proposed

Medallion pattern from Databricks · reference implementation on Google Cloud.

Use a campaign ID to group the work. Give each creative version an identifier and each publication its own identifier. Retain the recording ID so the team can connect a clip to the intended recording. Record the publication date and destination alongside the spend.

Choose the baseline before launch. Where feasible, stagger publication or identify a suitable group of recordings that will not receive the campaign during the comparison period. Keep the same observation windows visible when comparing results. This is how the team would investigate whether a change followed the campaign rather than another release or event. A rise after publication alone does not establish an effect.

Collect results over months because listening activity and reported proceeds may arrive on different schedules. Preserve the reporting periods and source dates with each export. When a corrected statement arrives, retain the new version and reconcile the affected result. Matching calendar months still requires checking whether the reporting is sufficiently comparable for the question being asked.

Evaluate the proceeds the catalog owner can receive under the relevant rights share, after campaign costs. Include merchandise income only where that owner has an agreement to receive it. The commercial test is additional cash flow attributable to the campaign. Correct arithmetic and a working AI interface support the review, but they do not establish that outcome.

Use unresolved findings to request the next records from partners. A distributor may need to supply an updated statement; a commerce partner may hold the purchase history needed to assess a proposed audience. Agree on access and return those records to the same investigation process. The team can then reconsider the selection before committing to the next campaign.

WHAT THE NEXT REVIEW MUST RECONCILE

Activity
What we published, when, and for whom.
Response
What listeners and customers did.
Economics
Who earned what, after costs.
Decision
Whether the result justifies doing it again.
ContinueThe next decision

06What changed in my thinking

Why I started looking beyond streaming revenue

I began by asking how a company could make its private data usable by employees and AI agents. Working through the catalog led me to a more specific commercial question. Streaming reports could show what the recordings earned, but I also wanted to understand whether purchases elsewhere in the artist's business could help us decide which songs to promote.

REFERENCE ARCHITECTURE

From catalog records to a campaign

Catalog · royaltiesCRM · merchandisePartners · files

Source, identity
and access

Permitted, traceable evidence

B→S→G

Bronze → Silver → Gold

Review, receipt
and finding

A review with scope and source receipts

Google CloudMCP + approved clients

Proposed clipping
campaign

Campaign + measurement plan

THE RETURN PATH

Proposed return: campaign and recording identifiers, reporting window, partner source version, and permitted organization. Inspect the return to see the next data request.

Evidence reviews: implementedClipping campaign: proposed

Medallion pattern from Databricks · reference implementation on Google Cloud.

Merchandise associated with an album gives us something concrete to investigate. I would check which recordings the product refers to and examine the purchase history we are allowed to use. A verified link to that body of work gives the campaign team a reason to consider its recordings. We would still need to test whether those customers are an audience for the music. A purchase alone does not establish that.

The clipping campaign would put that selection to the test. I would track the selected recordings through publication and then through the reporting periods that follow. The commercial question is whether the catalog owner receives additional proceeds after campaign costs. Merchandise income belongs in that calculation only when the owner has a share of it. The review would need to distinguish earnings caused by the campaign from changes that would have happened anyway.

The next data request would come from that review. If we cannot follow a result because the records sit with a store or distributor, we know which partner to approach and what to ask for. We can bring those records back into the same system and reconsider the selection. I want to use the evidence around the songs to choose a campaign, then use its results to improve the next one.

The next chapter is the build.

Prepare the next request for your catalog.

I will use this reference architecture for a series of long build videos. I will work through the data preparation and domain tools, then the work needed to connect an investigation to a campaign. You can follow the decisions and adapt the implementation to the music and business you control.

For a merchandise investigation in your own catalog, ask the commerce partner for the product IDs associated with the album and the permitted purchase records for a stated period. Ask the catalog team to verify which recordings those products refer to. Name the selection decision that this evidence would help you make. Save each response with its source version and update the investigation before selecting recordings.

The music IP series is planned. The link opens my YouTube channel.

About the worked example

This reference architecture draws on an implementation documented in October 2026. The worked examples use retained source evidence and verification records from that project. Private financial values are omitted. The chart explains the process using a representative catalog.

The implemented example includes a review tool that returns source references with its calculations. Selected requests were verified in ChatGPT and the application interface. These checks support the worked example; they do not establish that every client or business question has been tested.

The clipping campaign is a proposed application of the framework. Customer-to-recording relationships and campaign results still need to be established. Current private-data acceptance in Hermes and firm-wide adoption also remain to be tested. Databricks supplies the medallion pattern described here; the worked implementation runs on Google Cloud.

Return to the beginning ↑