§5 — The Dependency Model

Stacking is schematic. NBCU anchor occupies the dedicated parcel with its own gate and security envelope. Third Rail is the campus-wide soundstage operation with rotating productions.

§5 — The Dependency Model (the engine of the document)

What this is. The single page that explains why the work cannot be improvised. Every venue, service, tenant, partner, and revenue stream on this campus has dependencies — sales, ticketing, events, food‑and‑beverage, AV, security, staffing, technology, reporting, compliance — that must be designed in at the start, not bolted on later. When dependencies are designed in, growth scales. When they are not, every new opening creates manual work, surprises, and friction. This is what we are designing in.

§5.1 The principle, in one sentence

Every variable touches something. Every payment, every decision, every contract, every hire either reinforces the operating model or it taxes it. Our job is to make sure each addition reinforces.

§5.2 The four ownership types

Every product, service, venue, and tenant on campus is one of four types:

The "Service Requirement" is the design feature that makes the third type work. It is the lease language that says: "Tenant will use the Assembly AV partner for events over X attendees, the Assembly catering partner for in‑complex events, the Assembly security and IT backbone, and the Assembly ticketing platform for ticketed events." It is how we capture revenue from every party on campus, even the ones we don't own — because every party uses our services.

§5.3 What each ownership type depends on

This is where most operators stop. We don't.

Two things stay non‑negotiable across every type: Security and IT. Safety is the number‑one operating priority on this campus. The Assembly security and network backbone is mandatory in every lease and every JV. There is no carve‑out.

§5.4 The Service Requirement — why it matters financially

Without the Service Requirement, a third‑party operator on a 4,000‑person event night pays Assembly: rent. That's it.

With the Service Requirement, on the same event, Assembly captures (through its JV / owned / preferred service partners): AV revenue, catering revenue, ticketing fee revenue, security revenue, IT and connectivity revenue, parking revenue, marketing co‑op revenue. The operator still makes money. But the campus participates in every dollar that flows through it, because the campus is the platform.

This is the difference between a landlord and an operating company. The Service Requirement is what makes Assembly an operating company while still leasing buildings to operators.

§5.5 The Scenario Matrix — how this plays out across the venue mix

The whole campus is built on a single bet: that integration is worth more than optionality. A guest who comes for a soundstage tour, eats at the hotel, drinks in the Jewel Box, walks through the Chihuly room, and sleeps upstairs has spent the day inside one operation. That is the product. Letting any of those moments happen on someone else's P&L — even when the unit economics look fine in isolation — unwinds the thing we are actually selling.

Operating principle (locked): Assembly Atlanta controls every venue inside the complex — by ownership, JV, or service requirement — so the operation feeds itself. Every meal, every ticket, every event, every overnight, every drink, every show recirculates through the platform. A venue we don't control is revenue we don't capture and a guest moment we don't own.

This is why the matrix below tilts toward Owned or JV in nearly every signature category, and why third‑party arrangements always carry a Service Requirement (§5.4). It is also why a clean lease on a marquee venue — "give them the keys, take the rent, sleep well" — is the temptation we keep saying no to. Every clean lease is a wall inside our own building.

These three frames — Owned, JV, third‑party with a service requirement — started as the questions that kept getting waved off in early scoping. They were the right questions then and they are the right questions now. That is why they live here as discipline rather than instinct: every new venue, every new service, every new piece runs through all three frames even when one feels obvious. The matrix below is how we answer them for each row. Each row is a separate decision; the answers will evolve.

Each row of this matrix becomes a one‑page decision memo. Templates and worked examples will live as appendices to this section over time. We will not relitigate decisions that are made; we will revisit them only when conditions change.

§5.6 What the Dependency Model means for daily decisions

When someone proposes a new tenant, partner, or program, we ask eight questions before we say yes:

1. Type: Owned, JV, Third‑Party with Service Requirement, or Pure Lease?

2. Service Requirement: Which Assembly services apply (security, IT, AV, F&B, ticketing, marketing co‑op)? Are they in the lease language?

3. Sales: Who sells it? Through Assembly's central sales team or independently? On what calendar?

4. Calendar: How does this affect the campus events calendar and venue blackout days?

5. Reporting: What does this party report to us, on what cadence, into which system?

6. Compliance: What licenses, insurance, and approvals are required? Where do they live?

7. Brand: Does this fit the Assembly experience standard? What signage, voice, and visual rules apply?

8. Roll‑up: How does the revenue flow into Assembly accounting → Backbone → Gray Media consolidated?

If we cannot answer all eight cleanly, the deal is not ready. This is not bureaucracy. This is what makes a campus an operating company.

§5.7 Why this is here

Because asking these questions is not "being difficult." It is the work. A campus that does not ask them is a campus that gets surprised — by costs, by legal exposure, by revenue leakage, by branded experiences breaking. The dependency model is the safeguard. It is also the reason this document exists.

---