The A.D.A.P.T.
Protocol

Every stream, follow, ticket purchase, merch sale, email signup, playlist save, and video view creates a record of fan support. Artists earn those relationships through years of work.

Different sources answer different questions Ticketing tools report sales, streaming dashboards report listening, and commerce tools report purchases. Comparing them often means separate exports and manual work.

A.D.A.P.T. proposes common data formats and access rules so artists can use records from those sources together.

A shared data foundation A.D.A.P.T. proposes a permissioned data lake for artist and audience data: a place for permitted source records and aggregate data from across music platforms. A common model would describe fields and relationships without requiring every record to match a known person.

What A.D.A.P.T. models The objects are fans, releases, events, transactions, and campaigns, organized around the artist and preserved with their source.

Useful before it is matched Consistent fields, source information, and access rules would let tools use streaming totals, sales, releases, campaigns, and audience data together. Unmatched records remain part of the database.

The connection layer Proposed connectors would import data from ticketing, commerce, email, streaming, and social accounts through supported APIs. Each connection would require permission from the account holder.

The data model Sources use different field names and formats. The proposed model would map them to shared definitions while preserving source records.

Source access varies The proposed connectors would support both aggregate and individual records, subject to each platform’s API, permissions, and available fields. No universal source access is assumed.

Access has limits Each connector must account for the source’s available fields, export terms, and permissions. The standard cannot create access a source does not provide.

Your tools stay in place A.D.A.P.T. is intended to supply data to distributor dashboards, analytics products, and CRMs through shared interfaces.

Why platforms might participate Shared formats could reduce the work required to exchange artist data. The proof of concept should test that with participating platforms.

The proposal covers four areas: source data, processing rules, connections to other tools, and access controls. The proof of concept will test how they work together.

Objects describe the records in the model. Each has defined fields, source information, access rules, and links to related records. These are the proposed starting types.

Relationships describe how records connect. A transaction can refer to a ticket for an event, and an event can refer to an artist. Each link should retain the source evidence that supports it.

Links need evidence A ticket can link to an event using a source identifier. Linking two records to the same person is a separate question and requires suitable identifiers, permission, and a defined method. The white paper will clarify where that work belongs.

Architecture under review Whether relationships should form a separate layer is still being evaluated. The diagram groups data around the artist without assuming a single identity for each fan.

Connected tools would use the data. The proposed interfaces cover exports, data queries, and updates sent to approved applications.

From data to tools The proposed interface would supply approved data to CRMs, analytics tools, and advertising systems. Those applications could build segments and campaigns using the data and permissions available.

Proposed launch path Exports, webhooks, and selected integrations are candidates for the proof of concept. The white paper will define scope and evaluate which actions belong in downstream applications.

Authority must be explicit. The proposed model would distinguish the artist identity from authorized individuals, legal entities, and representatives. Grants would define what each party can read, export, or change.

Permission at every layer The design must support authorization or consent associated with individuals, entities, or multiple parties. The appropriate arrangement, evidence of authority, and handling of changes require legal and technical review.

Multiple parties, defined responsibilities Sources may retain their own records while sharing permitted copies. Access, permitted use, hosting, and portability are separate concepts; receiving a copy does not imply exclusive ownership.

Artist control must respect the rights of the people represented in the data. The technical design must establish what personal data is needed, how permission is recorded, and how access and deletion requests are handled.

Privacy design is still open Source permissions, retention, deletion, and any identity matching need review before implementation. Artist authorization alone should not be treated as permission for every downstream use.

Permissions need enforcement The design must specify how access restrictions and deletion requests reach connected tools.

Who hosts it? CRMs, labels, distributors, and capable managers could provide compatible hosting and services. The host would store and operate the dataset under defined responsibilities, separate from the artist identity and the parties authorized to grant access.

What moves? The specification must define exportable records, schema versions, provenance, permission evidence, and consent context. A transfer would cover permitted data and supporting context, not automatically every application feature, derived output, or service.

Changing providers A proposed transfer process would verify authority, check source restrictions, validate the receiving host, and confirm import completeness. Retention, deletion, and continuing access at the previous host would follow the applicable terms rather than an assumption that every copy disappears.

Shared formats and standard agreement templates could reduce the work of transferring data in and out. They would complement technical access controls, not override source restrictions or establish permission by themselves.

Required design areas Permitted purposes, onward transfers, retention, deletion, revocation, provenance, and responsibilities during host changes must be represented in both the agreements and the enforcement model.

Open questions Individual and entity authority, multi-party consent arrangements, identity matching, and the appropriate legal basis for each use require legal and technical review. These are requirements for the white paper and proof of concept, not settled compliance claims.

The specification The proposed specification will describe record types, relationships, permissions, and interfaces. Documented export formats are part of that work.

The hosting model Hosting is a design proposal, not a live service. Compatible providers could offer storage and services; permitted data and its context should be transferable under defined terms.

Organizational direction A.D.A.P.T. is a nonprofit organization. Its structure and participation model are still being developed.

Current status This is a working technical proposal, not a completed specification or compliance guarantee. Schemas, API interfaces, legal arrangements, and versioning rules remain in development.