What you'll be able to do
- Hold a whole roster in one Business Manager without the permissions hairball scaling with it
- Run the three-scope audience taxonomy that makes every release's data reusable
- Decide what the label owns, what each artist owns, and what happens at roster exit
The short version: A label is an apartment building, not a house: one structure, many tenants, shared infrastructure, separate leases. The build: ONE label BM owns the label's pages, nodes, ad account, and datasets; each artist's canon stays in the artist's own BM with Partner access bridging (DAS 202 Module 2's rule, multiplied). Ads run from one label ad account with identity chosen per message - label voice, artist voice via partnership ads, or scene-node voice. And the audience taxonomy runs three scopes from day one - LABEL-wide, ARTIST-specific, RELEASE-specific - because the label's superpower is that every release's audience can work for the next one.
The apartment building
The DAS 202 architecture was one artist's house. A label is the building - and the difference isn't size, it's SHARING. The label's structural advantage over any individual artist is aggregate audience: the fan who came for one roster act is the cheapest possible discovery for the next. The architecture below exists to make that sharing operational instead of theoretical.
- One label BM, one ad account. The label's pages, scene nodes, datasets, and billing consolidate (DAS 100 Modules 2 + 4: clean access, consolidated learning). Per-artist ad accounts fragment learning N ways and multiply every admin problem by roster size - the single account with per-campaign identity selection does everything the fragmented version does, legibly.
- Artist canons stay artist-owned. The DAS 202 Module 2 rule survives contact with a roster: careers outlast deals, and the label operates artist identities via Partner access + partnership ads, never ownership. The at-signing conversation covers it (the take-home's clause language, label edition).
- The label's own nodes are label property: the label page, the "[label]" updates presence, and - the crown jewel - the scene node (DAS 202 Module 5's "[city][genre]posting" shape), which serves EVERY release forever and belongs to no single artist. Building the scene node is the single highest-leverage account a small label can run.
The three-scope taxonomy (the whole module in one convention)
Every audience gets tagged with its scope at creation, because scope determines reuse:
- LABEL scope: engagers of label + scene nodes, all-roster buyer/listener aggregates, the email list - the shared warm layer every campaign starts from.
LBL - ENG - 180d - ARTIST scope: each act's engagers, viewers, buyers - the DAS 202 pools, held per-artist so they survive roster changes cleanly.
LBL - [ARTIST] - ENG - 180d - RELEASE scope: this campaign's viewers and converters - the sharpest, shortest-lived layer, feeding both parents when it's banked.
LBL - [ARTIST] - [REL] - VV95 - 180d
The compounding move the taxonomy enables: every release campaign warm-starts from LABEL scope + the artist's scope, and every release's harvest feeds all three. Release five launches into an audience releases one-through-four built. That loop IS the label's marketing moat - and it only exists if the tagging discipline does.
›Go deeper: roster exit, handled like adults
The pre-written answers, decided at signing: ARTIST-scope audiences built from the artist's own channels and buyers - the label deletes or transfers per the deal's data clause (jurisdictional privacy rules apply to buyer data; the counsel flag is real here). LABEL-scope aggregates the artist's fans flowed into - these are the label's (a fan of the label is the label's fan; the clause says so plainly). The scene node - label property, full stop, which is exactly why it's built as a scene account and not an artist account. Partnership-ad permissions - revoked on exit day, both directions, with the offboarding checklist making it a form instead of a fight. None of this is hostile; all of it is just decided EARLY, which is the entire difference between architecture and litigation.
From the field
A label with nine acts ran nine ad accounts, three shared logins, and zero taxonomy - every release campaign started cold because nobody could find (or legally untangle) the last one's audiences. The rebuild: one label BM, Partner-access bridges to each artist canon, the three-scope taxonomy applied retroactively over a long weekend. The next release launched warm off LABEL scope for the first time - its opening cost-per-listener ran at a fraction of the label's historical cold starts - and the release after that launched warmer still. Nothing about the roster changed. The building finally had hallways.
Common mistakes
- Per-artist ad accounts (N accounts, N learning phases, N admin messes)
- The label owning artist canons "for convenience" (the exit will price that convenience precisely)
- No scene node - the label's highest-leverage shared asset, unbuilt
- Untagged audiences (scope-less data is unreusable data; the moat evaporates)
- Exit terms improvised at exit (architecture's alternative is litigation)
Take-home
The Roster Architecture Map - the one-BM diagram, the three-scope taxonomy card with naming conventions, the at-signing data clause language (label edition), and the roster-exit checklist.
Sources & dates
Meta Business Help Center - Partner access, partnership ads (accessed July 2026) · DAS 100 + DAS 202 cross-references as cited · architecture is Darkroom practice, presented as such
Learn more
Optional extra credit. Nothing below is required for the quiz, the certificate, or the job - the full lesson is above. This is for the sickos who want more.
- DAS 202 Module 2 - the single-artist architecture this module multiplies