The v1 spec describes an open directory + planner that works once the collective has scale — many VJs, many spaces, many requests in flight. That's still the destination. Today we don't have that scale, and the three founders who've weighed in disagree about whether we should pretend we do.
This v2 keeps the v1 architecture — same data model, same surfaces — and re-frames it as a role-based portal with curated inbound demand for the small-collective phase. Different stakeholders see different things; requests flow inbound and get matched, they don't browse a public marketplace; house VJs are protected against bidding wars; non-Gooism VJs exist as a referral pool, not the main directory. The open marketplace from v1 becomes Phase 2, unlocked once the collective is big enough that opening it doesn't immediately cannibalize members' existing relationships.
These are the gaps the portal exists to close — not the v1 feature list, the underlying user pain. Every model proposed below is judged on whether it addresses these.
VJs walk into venues without enough information about the rig, the signal flow, the projector count, the stages, the available inputs/outputs, the house quirks. Each show is a forensic exercise about "what does this room actually have" instead of a creative one about "what should the show be." Solved by: structured space profiles, signal plan templates per venue, capability data carried from venue onboarding into every event held there.
VJs need the artist's track list, key tempos, lyrics, visual references, mood direction, and stems where available. Today this is a Slack thread or a Dropbox link or a half-remembered conversation. Solved by: artist profiles with structured media + direction fields, attached to event records, auto-shared with the assigned VJ.
Who owns the projector? Who's getting the backdrop? Who's coordinating with FOH? Who pays the VJ, the venue, the artist? Today this is improvised per event. Solved by: explicit role assignments per event, a programmatic checklist that builds from venue + artist + promoter inputs, a single source of truth all parties can see.
Booking a VJ today is reputation-by-rumor. Has this person done a 4-projector room? Have they worked with this artist's tempo? Have they handled a 500-cap room before? Today this is "ask around." Solved by: portfolio of past Gooism events with venue + artist + scale metadata, optional rating per event, opt-in references.
The v1 spec covers all four problems via the open directories, Signal Planner, and Event Planner surfaces. This v2 doesn't argue with the data model. It argues about who can read which parts of it, who initiates events, and how matching happens — the operating model around the same architecture.
Three founders have weighed in with different operating philosophies. Andrew's input is pending. Each model below has merit; the synthesis in § 03 tries to take the best of all three rather than picking a winner.
Anyone can sign up — venues, artists, promoters, VJs. Each posts what they need (or who they are), the system surfaces matches, parties self-organize. Hands-off, low-touch, scalable.
Demand comes to Gooism with a need. We take the brief, evaluate fit, hand-pick the right VJ from the collective, manage the relationship. Curated, high-touch, quality-controlled.
Artist or promoter brings the project — venue, asset needs, narrative arc. The VJ takes ownership: builds the signal plan, coordinates with venue + artist + promoter, runs the show. Venue isn't the primary client; the show is.
Section reserved for Andrew's perspective on operating model. Will be folded into § 02 and the synthesis once captured. Placeholder — do not treat synthesis as final until this lands.
A role-based portal where each stakeholder sees a different surface, demand flows inbound and gets routed (not browsed), and the open VJ marketplace from v1 stays specced as Phase 2 once the collective hits scale.
Venues, artists, promoters, and VJs each see a tailored portal — not the same homepage with different permissions. Venues do NOT see the full VJ directory by default. Artists do NOT see other artists' direction docs. Promoters see their events, not other promoters'. VJs (Gooism collective) get the most expansive view: requests, profiles, signal plans, AI tools.
Venues, artists, and promoters submit a request via a structured intake form (see § 05 for the Fetz form reference). The request lands in a routing queue that goes either to a designated house VJ, to a hand-curated match (Kevin's model), or to the wider Gooism pool with house-VJ-first protections (see § 07). External venues never browse "all VJs" — they brief, we match.
Each venue can name a house VJ at onboarding. Inbound requests for that venue route to them first. The protection mechanic is one of the four options in § 07 — this is the load-bearing decision the collective needs to land. This is what addresses Fetz's Public Works concern explicitly.
Two tiers in the underlying VJ database:
The requester's first decision isn't "fill out a 19-question form." It's a binary fork:
This is the architectural shift that makes the portal feel like a marketplace rather than a hiring funnel — and matches how anyone actually shops for a service.
Once the collective has enough scale that opening the directory doesn't cannibalize existing relationships (proposed threshold: ~30 active Gooism VJs across 10+ regular venues), the v1 open architecture turns on. The data already exists; the permission gates simply widen. No data migration, no rewrite — an operational toggle.
It addresses Fetz's bidding-war concern directly (house VJ protection), gives Kevin the curation lever he wants (matching is not blind — it's an editor's call), preserves Jack's open architecture as the destination (Phase 2 unlocks v1 spec verbatim), keeps the existing data model untouched, and replaces the long custom-commission form with a package catalog as the primary discovery surface. The cost is one extra dimension on every read query (role-based filter), a routing layer between request and assignment, and a package authoring surface for VJs. All three are well-bounded.
Five distinct surfaces, all powered by the same v1 schema. Permissions are gated at the application layer; the underlying tables are unchanged.
The requester's entry point on gooism.org is a single fork: "Looking for a set package?" — browse the catalog — or "Need a custom buildout / service?" — open the deep brief. The default visual prioritizes the catalog; the custom-brief path is one click away for the unusual cases. This section covers both paths plus the supply-side surfaces (package authoring, VJ profile, space onboarding).
Public-facing on gooism.org. Requester lands on the catalog, not a form.
The fields the system can't infer from the chosen package + a venue lookup. Should be ~6–8 questions, not 19.
That's the entire flow for the common case. Budget is set by the package; venue tech is auto-attached; service type is implicit. The Likert priority grid is reserved for Path B — if the requester is choosing a package, they've already signaled their priorities by which package they picked.
Surfaced from the catalog as "Don't see what you're looking for? Submit a custom brief." Most requesters never see this. It's for: unusual scope, multi-service combinations, asks that span multiple VJs, or projects where the requester genuinely doesn't know what they need.
This is where the Fetz-form structure lives in full — reconciled below, but explicitly framed as the deep-brief path, not the default.
Mirrors Fetz's Visual Art Commission Request Form, generalized for the collective. Used when no package fits or the request is genuinely custom.
What kind of work is being requested. Single-select. Generalized from Fetz's form to cover the collective's full service surface; "VJ performance" stays the dominant case but the broader catalog matters because most of these services already exist within the collective and we want them surfaced.
Surfaced inline based on Section A role selection. Optional but encouraged — sharper inputs here let us match better.
Fetz's "which aspects matter most" matrix is the form's best feature. Free-text creative briefs are wide and ambiguous; this grid forces a 4-way priority signal that's directly usable in matching (e.g. "audio sync = most important" filters strongly toward VJs whose portfolio shows tight sync work). Carry it forward verbatim — but only on Path B. In Path A, the package choice already encodes priority.
This is the new surface that makes Path A possible. Each Gooism VJ publishes packages in their portal — standardized offerings that show up in the catalog. Drives discovery without forcing requesters to guess what's possible.
A single VJ typically publishes 2–5 packages spanning their range (small set / mid set / festival headline / installation, etc.). Collective curators can also create collective bundles — multi-VJ packages (e.g. "AnalogToAI Relay — 4 operators, 50 minutes") that route the request to coordination rather than a single VJ.
Two paths — Gooism collective onboarding (full) and referral pool entry (light). The profile carries identity + portfolio; packages carry offerings.
Distinct from event intake — this is the venue's static capability profile that gets attached to every request from that venue. One-time form, periodic refresh.
The path a request takes from "venue submitted a form" to "VJ confirmed and signal plan in progress." Every step has a default behavior plus an explicit human escape hatch — matching is editor-assisted, not blind.
Pure algorithmic matching needs liquidity to work. At small collective scale, every request deserves an editor pass — even on the open-to-collective path, the system surfaces top-N candidates rather than auto-assigning. Phase 2 may shift to auto-assign once volume justifies it; Phase 1 keeps the human in the loop on every booking.
Fetz's concern: an open platform makes it cheap for venues like Public Works to skip past their house VJ and find someone cheaper. This is the mechanism designed to prevent that. Four options below — the collective should pick one, optionally configurable per venue. None of these are decided.
Fetz's concrete worry: Public Works currently uses him as house VJ. If they discover gooism.org and see a directory of cheaper alternatives, his ongoing relationship erodes. Option D doesn't solve this; A, B, and C all do, with different trade-offs. Whichever we pick should be communicated clearly to venues at onboarding so the protection is visible, not invisible.
Lean toward Option C with Option A as the default — new venues start in first-refusal mode with a 48hr timer, can change to exclusive or open at any time. This protects house VJs by default without locking the system into one posture forever. Open to collective input.
A condensed view of who has access to which capabilities. Where a row says "partial," the access depends on a relationship (e.g. a venue can communicate with a VJ assigned to one of their events, but not with arbitrary VJs).
| Capability | Public | Venue | Artist | Promoter | VJ · Gooism | VJ · Referral |
|---|---|---|---|---|---|---|
| Submit VJ request | — | ✓ | ✓ | ✓ | on behalf | — |
| Browse VJ directory | — | — | — | — | ✓ | — |
| Get matched to requests | — | — | — | — | ✓ | via curator |
| Build signal plan | — | — | — | — | ✓ | — |
| View venue signal plan | — | ✓ | own events | own events | ✓ | — |
| View artist media library | — | own events | ✓ | own events | assigned events | — |
| Communicate in event thread | — | own events | own events | own events | assigned events | — |
| Approve / decline proposals | — | ✓ | ✓ | ✓ | — | — |
| Post gig on behalf of venue | — | ✓ | — | if relationship | if house VJ | — |
| Direct VJ-to-VJ invite | — | — | — | — | ✓ | — |
| Refer to external VJ | — | — | — | — | ✓ | — |
| View full upcoming-events feed | — | — | — | — | ✓ | — |
| Use AI biz-dev assistant | — | — | — | — | ✓ | — |
| Receive ratings | — | ✓ | ✓ | ✓ | ✓ | via curator |
The Gooism rating model isn't a 5-star Yelp surface. It's signal-driven: confirmed completed events, the venues + artists they ran with, and optional commentary from the people who hired them.
One of the v1 features that gets sharpest in v2: the per-event tech checklist that builds itself from the data we already have, then surfaces gaps for the VJ to fill in.
Each completed event surfaces gaps that weren't captured in the original checklist (e.g. "venue has a dimming curve that ate the projector blacks"). Those become reusable checklist items the next time anyone runs that venue, that rig type, or that artist. Lessons compound.
VJs in the collective get an AI assistant focused on growing their business — not the matching layer, the personal-practice layer. Carries forward from the v1 spec but anchored in the v2 role boundary: this surface is VJ-only, never seen by venues / artists / promoters.
The v2 doesn't want a rewrite. The v1 architecture — data model, surfaces, planners, integrations — mostly stays. What changes is the operating model layered on top.
Small collective (~4-15 VJs). Curator-assisted matching on every request. House VJ protection load-bearing. Venues / artists / promoters submit, don't browse. Referral pool emerging but mostly invisible.
Once collective scale supports it (proposed threshold: ~30 active Gooism VJs across 10+ regular venues). The v1 architecture's open directory + auto-matching gates widen. Same data, more surfaces unlocked.
This is a proposal. Reply to Jack directly, or surface in the next collective sync. Items marked "open question" or "pending" don't block reading the rest — they're explicit gaps for the collective to fill. Treat the synthesis in § 03 as the strongest current take, not the decided answer.