Roadie Tour Manager: artist-scoped tour planning and booking

[chubes4]

Product direction

Extend Roadie with EC Tour Manager Pro, an artist-scoped tour-planning capability for self-managed artists and their managers to research, assemble, and operate a tour using Extra Chill's existing artist, event, venue, market, analytics, workflow, and assistant capabilities.

The initial customer is an existing Artist Platform member managing their own artist profile. Roadie is the assistant and product interface; Artist Platform supplies the structured workspace and durable plan. The first job is narrower than automated booking: turn a tentative date window and set of markets into an evidence-backed, editable tour plan.

This issue was researched against the current implementations of Artist Platform, Events, Data Machine Events, Roadie, Studio, Extra Chill Analytics, Data Machine Business, Data Machine, Extra Chill API, and WordPress core on July 20, 2026.

What already exists

Artist identity and access

• Artist Platform already has canonical artist_profile records, multi-artist membership, artist switching, roster invitations, and ec_can_manage_artist() authorization. Tour plans can scope to the existing artist ID and membership model rather than creating another identity system.
  • extrachill-artist-platform/inc/core/filters/data.php:9-20,204-272
  • extrachill-artist-platform/inc/core/filters/permissions.php:65-84
  • extrachill-artist-platform/build/blocks/artist-manager/render.php:31-70
  • extrachill-artist-platform/inc/artist-profiles/roster/roster-data-functions.php:10-53
• Artist data already includes name, bio, genre, home city, website, streaming links, socials, and images.
  • extrachill-artist-platform/inc/core/filters/data.php:204-272
• Artist profiles already display upcoming and past canonical Events records by calling data-machine-events/events-by-term with the shared artist taxonomy slug.
  • extrachill-artist-platform/inc/artist-profiles/frontend/shows-section.php:57-90,123-203

Event, venue, market, and calendar data

• Events already have structured dates/times, venue, address, price, ticket URL, performer, organizer, status, event type, and occurrence dates.
  • data-machine-events/inc/Blocks/EventDetails/block.json:15-98
• Venue records already contain address, city, state, ZIP, country, phone, website, capacity, coordinates, and timezone.
  • data-machine-events/inc/Core/Venue_Taxonomy.php:23-47
• Events can already be queried by date range, time scope, arbitrary taxonomy, search text, venue proximity, status, and ordering.
  • data-machine-events/inc/Abilities/EventDateQueryAbilities.php:40-165
• The calendar already exposes structured event rows and filter facets. Venue maps support bounds, radius, taxonomy filters, coordinates, and optional event rows.
  • data-machine-events/inc/Api/Routes.php:18-285
  • data-machine-events/inc/Abilities/VenueMapAbilities.php:29-146
• Artist event archives already render a chronological route map from known upcoming show coordinates. This is visualization, not optimization.
  • extrachill-events/inc/core/artist-map.php:34-80
  • data-machine-events/inc/Abilities/VenueMapAbilities.php:611-711
• Location terms already normalize municipalities into Extra Chill discovery markets and support city aliases.
  • extrachill-events/inc/core/location-meta.php:76-179
  • extrachill-events/inc/core/location-normalizer.php:344-419
• Venue discovery already searches Google Places; qualification finds event pages and tests whether listings are importable; venue onboarding can create a scheduled scraper flow.
  • extrachill-events/inc/Abilities/VenueDiscoveryAbilities.php:56-188
  • extrachill-events/inc/Abilities/VenueQualificationAbilities.php:30-109,390-433
  • extrachill-events/inc/Abilities/VenueAddAbilities.php:132-248,305-415
• Artist tour-feed preview, moderation, approval, and recurring import abilities already exist. Approved feeds create artist-tagged event flows and run an initial import.
  • extrachill-events/inc/Abilities/ArtistUrlImportAbilities.php:230-264,620-788
  • Related tracking issue: feat: artist self-import — submit a website event feed to spin up a per-artist tour-date import pipeline extrachill-events#193

Analytics and market signals

• extrachill/market-report already combines, per calendar market: total/upcoming events, venues, source-flow coverage, GA sessions, GSC clicks/impressions, and a calendar-coverage opportunity score.
  • extrachill-events/inc/Abilities/MarketReportAbilities.php:31-121,631-658
  • extrachill-cli/inc/Commands/Events/LocationCommand.php:271-398
• Existing analytics also provide events-surface growth, GSC page/query movement, ticketing outbound clicks, on-site search gaps, event attendance marks, GA page audience/acquisition, and artist-owned link-page views/clicks.
  • extrachill-analytics/inc/core/abilities/get-surface-growth.php:61-93,162-219
  • extrachill-analytics/inc/core/abilities/get-demand-drill.php:53-118,282-370
  • extrachill-analytics/inc/core/abilities/get-outbound-clicks.php:41-99,155-220
  • extrachill-analytics/inc/core/abilities/get-link-page-analytics.php:18-55,74-112
  • data-machine-business/inc/Abilities/Analytics/GoogleAnalyticsAbilities.php:101-167
• Link-page analytics are already artist-owner scoped with ec_can_manage_artist(). Broad GA, GSC, demand, and network analytics are team/admin capabilities and are not safe to expose raw to artist customers.
  • extrachill-analytics/inc/core/abilities/get-link-page-analytics.php:74-112
  • extrachill-analytics/inc/core/abilities/reports-permission.php:3-41

Workspace, assistant, and orchestration

• Artist Platform already has the appropriate customer-facing artist switcher and management hub.
• Studio demonstrates a reusable tabbed React workspace, but it is an internal team surface gated by ec_is_team_member(), not an artist product.
  • extrachill-studio/src/blocks/studio/render.php:30-54
  • extrachill-studio/src/blocks/studio/app/tabs.ts:16-56
• Roadie already manages artist profiles and link pages through cross-site REST calls and propagates acting-user identity. However, Roadie is currently gated by the internal access_roadie capability; artist membership alone does not grant access.
  • extrachill-roadie/inc/tools/class-manage-artist-profile.php:170-258
  • extrachill-roadie/inc/tools/class-manage-link-page.php:105-377
  • extrachill-roadie/inc/permissions.php:67-82,162-188
• Data Machine already supplies pipelines, flows, immediate/delayed/recurring execution, jobs, idempotency, artifacts, agent registration, and ability-backed model tools. No new workflow engine or agent registry is needed.
  • data-machine/inc/Abilities/Engine/RunFlowAbility.php:40-390
  • data-machine/inc/Abilities/Engine/ScheduleFlowAbility.php:30-258
  • data-machine/inc/Core/Database/Jobs/Jobs.php:114-315
  • data-machine/inc/Engine/AI/Tools/ability-tool-projections.php:10-39
• WordPress core already provides REST CRUD, capability mapping, revisions, registered structured meta, and per-user autosaves for a private REST-visible post type. No custom draft/autosave substrate is needed.
  • wp-includes/rest-api.php:267-288
  • wp-includes/meta.php:1380-1534
  • wp-includes/rest-api/endpoints/class-wp-rest-autosaves-controller.php:87-138,305-428

Proven gaps

The missing product layer is now concrete:

• No private artist-owned tour-plan record or tour lifecycle exists.
• No ordered tentative stops, off-days, travel legs, or itinerary entries exist.
• No driving-time, route-corridor, maximum-leg, cost, lodging, or route-optimization capability exists. The current artist route map only connects known shows chronologically.
• Venue data has capacity and event history, but no structured booking contact, room type, production, age policy, typical deal, guarantee, availability/holds, or artist-fit score.
• Artist/event relationships do not encode billing order or roles such as headliner, direct support, opener, or local support.
• No local-support matcher joins artist home market, genre, availability, draw, and bill history.
• No artist-by-market demand dataset exists. GA geography stops at country; GSC geography is a country filter; current market reports measure calendar coverage and broad platform demand, not demand for a specific artist.
• No ticket sales, sell-through, gross, settlement, guarantee, expense, or profitability data exists. Ticket-link clicks and attendance marks are intent proxies only.
• Existing artist roster access is flat. There are no tour-specific roles for manager, booking agent, tour manager, crew, accountant, or read-only collaborator.
• Existing Roadie and Studio permissions are internal-team permissions, not artist-customer permissions.

Product boundary

• Roadie owns the product experience: conversation, guided research, proposals, and actions.
• Artist Platform owns the structured workspace, durable tour plan, and artist/tour authorization.
• Events owns canonical public events, venues, locations, maps, calendar queries, and event imports.
• Data Machine owns asynchronous research/generation runs and operational job history, not tour-plan state.
• Roadie calls Tour Manager abilities through a new narrow artist-facing mode whose permissions resolve from artist/tour membership. Chat memory must not become plan storage.
• Studio remains an editorial handoff, used to draft tour announcements and social campaigns rather than storing itinerary data.
• Extra Chill API remains transport only, adding thin routes only when a client cannot call the owning ability or core REST route directly.

First Roadie workflow: Tour Scout

Ship Tour Scout as the first Roadie Tour Manager workflow. Roadie guides the research and plan-building process while a structured Artist Platform workspace renders the map, market comparisons, venue candidates, and editable stop order.

Inputs

• Managed artist.
• Tour name.
• Date window.
• Origin and optional final destination.
• User-selected target markets.
• Optional tentative dates and notes.

Workflow

1. Ask Roadie to start a tour plan, then create a private draft scoped to the existing artist ID.
2. Compare selected markets using facts the platform can currently defend: upcoming event inventory, venue inventory, known venue capacities, calendar conflicts, coordinates, and canonical market/location data.
3. Show candidate venues from existing venue records and Google Places discovery, clearly separating known Extra Chill venues from untracked discoveries.
4. Let the user manually select and order tentative stops. Render the existing chronological map pattern and label distance as geographic context, not optimized drive routing.
5. Show candidate local artists by explicit home market and genre only after adding a small artist query for those existing profile fields. Do not present candidates as compatibility or availability matches.
6. Attach canonical venue and event IDs when they exist; keep tentative/private stops private until explicitly promoted into an event submission/import workflow.
7. Persist edits with WordPress core revisions and per-user autosaves.
8. Let Roadie reopen, explain, and update the same saved plan through Tour Manager abilities. Link out to existing artist link-page tools for ticket/presale campaigns and to Studio for announcement/editorial work.

Storage

Use one private, REST-visible tour-plan post type in the Artist Platform domain with:

• Existing artist ID.
• Title, status, date window, and origin.
• An ordered, schema-validated stop collection.
• Canonical venue/event/location references where available.
• Generation/job reference and definition version when Data Machine assists.
• map_meta_cap, revisions, and registered revision-enabled meta.

Keep the plan aggregate in one record initially. Split stops into separate records or a custom table only if shipped query or concurrency requirements prove that necessary.

Permissions

• Read/write: users for whom ec_can_manage_artist() passes, plus administrators.
• Tour-specific roles are deferred until the product needs narrower access than the existing artist roster.
• Add a narrow artist-facing Roadie Tour Manager mode. Do not grant artist customers the existing internal Roadie tool set or Studio, Events-admin, GA, or GSC capabilities.

Analytics policy

The first release may show public calendar/venue facts and artist-owned link analytics. It must not expose raw network GA/GSC, unrelated search terms/pages, individual attendee identities, scraper operations, or person-level journeys.

Do not label the current market opportunity score as artist demand: its formula primarily identifies calendar coverage/scraper opportunity. Artist-market demand, ticket conversion, venue fit, and financial optimization require future data contracts.

Explicitly out of MVP

• Automatic route optimization or drive-time promises.
• Booking outreach, CRM, holds, or contract negotiation.
• Venue-fit or local-support recommendation scores.
• Hotels, transport, riders, day sheets, settlements, budgets, or per diems.
• Ticket sales or profitability forecasts.
• Automatic publication of tentative stops as public events.

MVP success criteria

• An authorized artist member can ask Roadie to create, explain, revise, reopen, and delete a private tour plan.
• A plan can hold and reorder at least three tentative stops across selected markets.
• Each stop can reference canonical location, venue, and event records without duplicating them.
• Market and venue facts shown in the workspace identify their source and do not overstate broad calendar metrics as artist demand.
• The map displays the selected stop order without claiming optimized routing.
• Unauthorized users cannot read or mutate another artist's plan through REST, abilities, or direct post access.
• No new generic workflow, agent, analytics, or autosave abstraction is introduced.

Follow-on phases

Only after Tour Scout usage validates the workflow:

• Driving-time and constrained route optimization.
• Structured venue booking contacts and fit criteria.
• Local-support billing roles, availability, and matching.
• Artist-scoped market demand with privacy thresholds.
• Tour-specific collaborator roles.
• Tasks, documents, logistics, finance, and settlement modules.

Source

Raised by Chris Gardner in Discord on July 20, 2026 and tracked by Chris Huber. Initial concept: combine Artist Platform, Studio/Roadie-style assistance, Events calendar data, Data Machine, and analytics to help tour managers and booking agents schedule tours and find local support.

[chubes4]

Foundation audit: prerequisite ladder

The platform does not need a new Tour Manager substrate. WordPress already supplies private CPT storage, mapped capabilities, registered structured meta, revisions, autosaves, and REST controllers. Agents API/Data Machine already supply agent grants, execution principals, tool policy, pending actions, jobs, idempotency storage, and workflow execution. Events already supplies canonical event, venue, market, date-query, and map primitives.

The prerequisites are hardening and wiring those existing layers.

P0: trustworthy artist ownership and identity

• fix: enforce artist ownership inside native abilities #137 — enforce artist ownership inside native abilities; close write/PII/analytics bypasses.
• Consolidate artist↔user membership contract — 3 representations, fragile serialized-LIKE reverse lookup, divergent accessors #46 — make ec_can_manage_artist() use the validated bidirectional membership relationship and make mutations reconcilable.
• fix: self-defend artist access administrative abilities extrachill-users#211 — protect administrative artist-access abilities.
• fix: map artist object access to WordPress primitive capabilities #139 — correctly map artist object access to WordPress primitive capabilities so core REST, revisions, and autosaves can authorize artist members.
• fix: validate artist profile-term bindings across sites #138 — repair and validate profile ↔ artist-term bindings and preserve stable identity through the Events site.

Until these land, private artist-owned state and customer-facing Roadie tools do not have a trustworthy resource boundary.

P0: trustworthy Roadie caller and entitlement

• fix: propagate caller identity before resolving chat tools data-machine#2905 — carry the authenticated acting caller into tool resolution and fix dropped loop metadata.
• fix: align Roadie tool scope and access with canonical agent grants extrachill-roadie#83 — scope Roadie tools to Roadie mode, preserve canonical agent grants, and fail closed without an acting caller.

Agents API grants should remain the entitlement primitive. Artist membership should authorize the selected artist resource. Those are separate checks and should not be replaced by a new role/subscription table.

P1: safe mutations and durable cross-site interaction

• enhancement: include invocation input in action-policy resolution data-machine#2906 — pass normalized invocation input into existing action-policy resolution.
• fix: make Roadie conversations and approvals network-consistent extrachill-roadie#84 — make Roadie conversation history and pending-action resolution network-consistent.
• fix: carry ownership and idempotency through direct workflow jobs data-machine#2907 — carry caller/agent ownership and idempotency through direct workflow jobs; authorize direct job reads.
• fix: preserve route-affinity trust and response invariants extrachill-api#121 — preserve route-affinity trust, collection routing, status, and headers.

This lets Roadie use the existing preview/approve/apply contract and existing job engine instead of relying on prompt prose or introducing a second action/queue system.

P1: trustworthy Events evidence

• fix: preserve event date and identity indexes across all mutations data-machine-events#486 — keep event date and identity indexes synchronized across block/taxonomy mutations.
• fix: prevent cross-city venue identity collisions data-machine-events#487 — prevent same-name venues in different cities from being merged.
• fix: harden public event-query and timing semantics data-machine-events#488 — harden public event-query status, geo-empty, and upcoming/ongoing semantics.
• fix: preserve canonical venue and event contracts in adapters extrachill-events#278 — preserve canonical venue/event fields through Extra Chill adapters.

These are prerequisite data-integrity fixes. Route or market advice should not build on stale dates, ambiguous venues, unsafe query controls, or lossy response contracts.

First domain-state primitive, only when implementation starts

Use one private Artist Platform-owned post type with:

• Custom mapped capabilities resolved through the corrected artist-membership primitive.
• One exact registered object-meta schema for canonical user-editable state.
• show_in_rest, revisions, autosaves, and revision-enabled meta.
• One ownership-enforcing mutation ability requiring expected_version and caller-generated operation_id.
• Conflict response on stale version and replay-safe response for a repeated operation ID.
• Data Machine job ID/version linkage only when asynchronous work is launched.

Core does not provide final-write optimistic concurrency, so expected-version compare-and-swap plus operation replay is the one genuinely missing domain-state primitive. It should be implemented for this concrete domain, not as a speculative generic workspace framework.

Explicit non-prerequisites

Do not build:

• A generic Tour Manager engine or workspace table.
• A second artist identity service.
• A Roadie-specific entitlement database.
• A new tool projection, confirmation, workflow, job, revision, or autosave system.
• Tour roles before a shipped operation needs narrower access than full artist manager.
• Itinerary, finance, booking CRM, routing, or local-support schemas as “foundation.”

[chubes4]

Local-support matching is now scoped into implementation issues:

• Artist availability and canonical scene opt-in: feat: add artist-controlled local support availability #158
• Event-scoped requests, interests, consent, and notifications: feat: add event-scoped local support requests and artist interest extrachill-events#420
• Artist and organizer UI: feat: add local support opportunity and shortlist UI extrachill-events#421
• Canonical performer billing roles: feat: model structured event performers and billing roles data-machine-events#616

This preserves the ownership boundaries documented here: Artist Platform owns artist preferences, Events owns the booking interaction, Users remains generic, and Data Machine Events owns canonical lineup semantics.