Project Journey

It started the way most music archives start: a musician trying to remember where he'd been. After decades of live performance — original projects, tribute work, sit-ins, one-off bills — the honest answer to "how many shows have you played?" was "a lot, but I couldn't tell you." The first impulse wasn't to build a platform. It was to stop losing the record.

Show history was scattered across memory, old flyers, venue calendars, emails, social media posts, and scattered Archive.org recordings. The first mission was simply getting "one row per show" and accepting that some rows would be incomplete.

The spreadsheet became a website. BillTaylorBass.com launched as a public performance calendar and archive — a place for upcoming shows, a searchable history of past ones, and a reference for anyone who wanted to find Bill's projects online.

The goal at this stage was simple and honest: get everything in one place before trying to analyze anything. Accuracy beat polish. Reconciling duplicates, normalizing band names, and tracking venues consistently were the real wins — the kind of discipline that later made everything else possible.

Once the archive was reasonably complete, the obvious next question was: what does it tell me? The v2 era introduced analytics — shows per year, most-played venues, song frequency, band activity over time. For the first time, the data was being queried rather than just stored.

This is also when deterministic IDs, normalization, and repeatable import pipelines became priorities. Every new page (Bands, Songs, Insights) increased the cost of changing the schema. The system was starting to feel the friction of its own growth.

The original data model had a fundamental assumption baked in: one show, one band. It worked fine for solo-headliner entries. It fell apart the moment the archive reflected real-world live music — multi-band bills where Tribute ABB, The Core, and other acts share a stage on the same night.

The "stabilization war" of early 2026 forced a structural decision. Repeated regressions across the editor, canonical tabs, and the public site made it clear that patching symptoms wasn't an option. The model itself had to change.

The v4 canonical model introduced a properly normalized, time-aware schema: Events (the show), Performances (each band's slot at that event), and Participants (each musician's role in each performance). This separation — event from performance, performance from personnel — is the architectural foundation everything else builds on.

With it came deterministic IDs, alias resolution, and a strict contract: Canonical tabs are the only write surface. EXPORT_* tabs are generated compatibility views. The public site reads only published EXPORT_* feeds — never directly from canonical. That boundary is what keeps the public site stable while the data engine evolves.

Something unexpected happened when the v4 model was applied to the archive: the data stopped being a list and started being a graph. When you correctly model who played what, at which event, in which band, alongside whom — relationships between musicians, bands, and venues emerge naturally from the structure.

This is the insight that changed the project's direction. Bill Taylor has shared a stage with hundreds of musicians across forty years of live performance. The canonical archive doesn't just record that — it maps it. Degrees of separation. Co-occurrence networks. Time-aware band membership. The "killer app" shifted from a personal calendar to something much larger.

BillTaylorBass.com isn't the destination — it's the proof of concept and the seed. Nearly 1,000 documented shows, hundreds of musicians, dozens of venues across the Southeast. That network, properly modeled, is the first node cluster in a much larger graph.

The vision is additive: other musicians, bands, and venues bring their own documented histories. The graph grows outward from Bill's network to the broader Atlanta and Southeast scene — and eventually further. The data model is already designed to support it.

The Shared Stage is a global, time-aware music relationship graph — a structured record of who played what, with whom, when, and where. Not a streaming service. Not a ticketing platform. A living map of live music relationships that gets richer the more it grows.

Scene mapping by city and era. Co-occurrence networks. Shared bill connections. Band membership timelines that accurately reflect the fluid reality of working musicians. The goal is to give live music the same kind of structured, queryable history that sports, film, and academia take for granted.

A graph is only as useful as your ability to query it. Phase 8 is a natural language interface on top of the relationship graph — a "Scene Explorer" that lets you ask questions like "show me every musician who shared a stage with Bill Taylor and also played with Allgood Music Company" or "map the connections between the Atlanta jam scene and the H.O.R.D.E. era."

The AI layer doesn't generate data — it navigates the structured data that the canonical model already contains, making the graph accessible without requiring SQL or a data science background.

Manual data entry doesn't scale to a platform. Phase 9 is the automated ingestion layer: venue calendar parsing, lineup detection from social posts and event listings, integration with Setlist.fm and similar sources. Data pipelines that monitor the live music ecosystem and surface new entries for human review and canonical promotion.

The human stays in the loop — automated ingestion surfaces candidates; the editor promotes them to canonical after validation. Speed of collection without sacrificing the accuracy discipline that makes the graph trustworthy.

The end state is a community-powered platform where musicians, venues, promoters, and fans contribute to a shared, structured history of live music. User submissions with moderation. Claims workflows. Confidence scoring. A public graph that anyone can explore and that the community has a stake in maintaining.

Not just a record of the past — a living infrastructure for the live music ecosystem, built on the same canonical-model discipline that makes BillTaylorBass.com work today.