THE
PROTOCOL

In enterprise technology, the most advanced organizations don't just collect data - they build ontologies: live, executable models that mirror the real world. An airline's ontology knows every aircraft, route, crew member, and delay - and can act on that knowledge in real time. A hospital's ontology connects patients, treatments, outcomes, and staff into a single operational picture.

ADAPT brings the same architecture to artists. Instead of aircraft and patients, the objects are fans, releases, events, transactions, and campaigns. Instead of optimizing supply chains, you're working with what actually matters in music: the relationship between an artist and the people who care about their work.

The result is a living model of your entire fan universe - one that understands what the data means, knows what you can do with it, and governs who has access. Data flows in continuously from every platform you connect. The ontology normalizes it, links it, and scores it so you can actually do something with it.

Plaid solved a version of this problem for finance. Before Plaid, if you wanted to build an app that used your bank data, you had to scrape it, hack around login screens, or beg each bank for API access. Plaid created a standard connection layer: you authenticate with your bank, Plaid pulls your transactions, and any app you authorize can use that data. An entire ecosystem of fintech products got built on top.

ADAPT does the same thing for music. An artist authenticates with the platforms where they already have accounts - their ticketing provider, their merch store, their email list, their social channels. ADAPT connects through authorized APIs and pulls the data on a regular cadence. No scraping. No manual exports. No CSV uploads at 2am.

An honest comparison. Plaid's adoption was accelerated by regulation - Open Banking rules in the EU and legal pressure in the US forced banks to open access. For a long time, music had no equivalent. That's starting to change.

In March 2026, the DOJ settlement with Live Nation included an Artist Transparency clause - the first time a major ticketing platform was required to share fan purchase data with artists on request. A month later, a federal jury found Live Nation liable for illegally monopolizing live event ticketing. Remedy proceedings are pending. These cases put artist access to ticketing data into law and court orders.

It's not just ticketing. The EU's Digital Single Market Directive review is scheduled for mid-2026 and could reshape platform obligations around data and copyright. The EU AI Act provisions taking effect in August 2026 require dataset registration and authorship transparency. A UK Fair Play report found that only 36% of electronic music performances result in the correct creator getting paid - 5.7 million GBP misallocated annually in nightclubs alone. Across the US and EU, the regulatory direction is toward consent-based data usage, transparent attribution, and artist access as enforceable standards rather than voluntary principles.

The companies that move first - that open their data to artists before they're forced to - will be the ones artists trust and build on. The companies that wait will find themselves on the wrong side of a Live Nation-style reckoning. ADAPT exists to have a working standard ready so that when data portability becomes the expectation, there's a protocol to make it real.

What data actually exists today. Not all platforms are equal. Ticketing, merch, email, and CRM platforms give you fan-level data with real identifiers like email addresses. Streaming platforms (Spotify for Artists, Apple Music for Artists) give you aggregates - top cities, age and gender breakdowns, playlist data - but not individual listener identities. Social platforms vary: some expose follower data through APIs, others restrict it. ADAPT starts where the data is richest - the platforms that already give you fan-level records - and expands as access opens up. The ontology is designed to work with both: rich individual records where available, aggregate signals where that's all there is.

The difference between Plaid and ADAPT is what happens after the data arrives. Plaid passes raw financial transactions to downstream apps. ADAPT does something harder: it takes fragmented signals from completely different platform types - a stream is not the same data shape as a ticket purchase or a social follow - and normalizes them into a single ontology.

This doesn't replace your existing tools. ADAPT isn't trying to be your distributor dashboard, your Chartmetric account, or your CRM. Those tools are good at what they do. The problem is that they can't talk to each other. ADAPT sits underneath them - connecting the data each one holds so you can ask questions across all of them at once.

Why would platforms participate? Not because they're forced to - at least not yet. The early adopters will be platforms that already have artist-facing APIs and already benefit when artists use data well: ticketing companies that sell more tickets when artists know where their fans are, merch platforms that see higher conversion when artists target the right audience, CRMs that become more sticky when they're plugged into a larger data picture. These platforms don't lose value when data flows out - they gain value when artists make better decisions.

Larger platforms with more to protect will move slower. That's fine. The protocol doesn't require every platform on day one. It needs enough connected data to be useful, and then adoption pressure builds naturally as artists start asking "why can't I connect this one too?"

You're an independent artist with 400K monthly listeners, 80K Instagram followers, an email list of 12K, and a show booked at a 1,200-cap room in Austin in six weeks. Today, here's what you know: your distributor dashboard says Austin is a "top city." Your ticketing platform says you've sold 340 tickets. Your merch store has shipped to 200+ Texas addresses over the past year. Your email open rates in Texas are above average.

That's four different dashboards with four different numbers that don't talk to each other. You can't answer the question that actually matters: who are the specific people in Austin who care about you, and what's the best way to reach them?

None of this requires data that doesn't exist yet. Ticketing platforms, email tools, merch stores, and social APIs give you enough to build a useful ontology today. Streaming-level identity resolution would make it more powerful - and it will come - but you don't need to wait for it to get value.

Most platforms stop at data collection. They pull numbers from sources and display them. The ADAPT ontology unifies four pillars into one system. A database stores information. An ontology models decisions.

An ontology models the world in terms of objects - the nouns of your business. In an airline, the objects are aircraft, routes, and crew. In ADAPT, they represent every entity in an artist's fan universe. Each object has properties, belongs to relationships, and carries permissions.

Objects alone are a database. Relationships are what make it an ontology. Every link between objects carries meaning - not just "Fan is connected to Event," but "Fan attended Event, at this venue, on this date, with this ticket tier." These typed, directional relationships are what let you ask questions that span the entire fan universe.

"Which fans who attended my show in March also stream my new single weekly?" That question touches three objects and two relationships. Without the ontology, it requires pulling data from three platforms, manually matching identities, and hoping the formats align. With the ontology, it's one query. To be clear: this specific query requires fan-level streaming data that most platforms don't expose today. But a query like "which fans on my email list also bought tickets to my last three shows?" is answerable right now with the data that ticketing and email platforms already provide. The ontology handles both - it runs the queries that current data supports and gets more powerful as platform access expands.

Most data platforms are read-only. You look at charts, export CSVs, and then manually go do things in other tools. The ADAPT ontology is designed to write back to the real world.

Actions are the verbs of the ontology. They take the intelligence the system has built - the scored fans, the identified segments, the attributed revenue - and turn it into operations. A pre-sale triggered to superfans in a specific city. A retargeting campaign pushed to fans who engaged with a release but haven't bought tickets. An automated invite when a fan crosses the superfan threshold.

What this looks like on day one vs. day 1,000. At launch, the action layer is focused on exports and integrations with tools artists already use - email platforms, webhook-based automation, CSV exports for ad platform uploads. Native integrations with ticketing systems, ad networks, and other endpoints come over time as the protocol matures and adoption grows. Each new integration is built once in the protocol and available to every artist on the network. The goal is a closed loop: data flows in, the ontology makes sense of it, actions flow out, and the results of those actions flow back in. The model gets smarter every cycle.

The most important architectural decision in ADAPT is this: the artist owns the ontology. Not the platform. Not the label. Not the manager. The artist.

Security isn't bolted on after the fact - it's woven into every object, every relationship, every action. The governance layer controls who can see what, who can do what, and at what level of granularity. A manager might have full operational access. A label might see aggregate performance metrics but not individual fan records. A developer building on the API gets access to exactly the objects and properties the artist has approved - nothing more.

This is how ADAPT works for the entire ecosystem, not against parts of it. Labels benefit from better data about their roster's performance. Managers get operational tools they've never had. Platforms participate because artist growth drives their growth. But the access is governed, permissioned, and always controlled by the artist.

A protocol built on artist data rights has to respect fan data rights too. ADAPT aggregates personal data across platforms and resolves it into identity profiles. That creates real obligations under GDPR, CCPA, and other privacy frameworks.

The protocol requires that every Fan object carry a consent record. Fans whose data enters the ontology through platforms with existing consent frameworks (you agreed to terms when you bought that ticket) are covered by those agreements. But ADAPT adds a layer on top: fans can request access to see what data an artist's ontology holds about them, and they can request deletion. These aren't optional features - they're built into the spec.

This is a design choice, not a legal afterthought. If the protocol can't be trusted to handle fan data responsibly, it doesn't deserve adoption. The governance layer that protects artists from unauthorized access to their data also protects fans from unauthorized use of theirs. Both directions matter.

ADAPT is not a product. It's a protocol - an open standard that defines how artist data should be structured, linked, governed, and made portable. Think of it like HTTP: the spec that makes the web work, not any single browser or server.

The protocol defines the ontology schema - the objects, relationships, and action interfaces that any compatible implementation must support. Anyone can build on it. Anyone can host an instance. The default is ADAPT-hosted, but the standard is open and the data is always portable. Self-hosting and federation across multiple hosts are design goals for the protocol - the v1 is centrally hosted to get the fundamentals right, with the architecture built to support distributed operation as adoption grows.

This matters because no single company should own the standard for artist data. The protocol belongs to the ecosystem. As a nonprofit, ADAPT's role is to steward the spec, grow adoption, and ensure interoperability - not to capture value at the expense of the artists and platforms that participate.

Sustainability. Nonprofits still need to keep the lights on. ADAPT sustains itself through a combination of membership dues from participating platforms and organizations, grants from arts and technology foundations, and commercial licensing of the spec for enterprise implementations. The protocol itself remains open and free. The nonprofit exists to maintain it.

Where we are. This document describes the design of the protocol - the architecture, the objects, the layers, and the principles. The formal spec (schema definitions, API interfaces, versioning strategy) is in development. What you're reading is the "why" and "how it should work." The buildable "what" comes next.