A gig changes time.
That should be one small fact changing in one small place.
Instead, it can turn into a ceremonial tour of the internet: update the venue website, the artist page, Facebook, Instagram, the ticket listing, whatever other event service is carrying it, then discover that the original poster is still circulating in a local group telling everybody the old time anyway.
The number six is not important. It could be four or eight. What matters is that one real-world event has somehow acquired several separate digital lives, each of which has to be maintained as though it were its own little truth.
That is ridiculous.
Not dramatic, world-ending ridiculous. Just the low-grade kind of ridiculous that technology is supposed to remove for us.
The administrative annoyance is obvious. The worse problem appears when the copies stop agreeing.
Copies are cheap until reality changes
The first listing is easy.
Friday. Eight o'clock. Band. Venue. Ticket link.
Copy it somewhere else and it still agrees. Copy it five more times and, at that moment, you have six perfectly consistent versions of the same information.
Then reality does what reality does.
The support act changes. Doors move by half an hour. The venue swaps rooms. The ticket link changes. The artist cancels. The whole event moves to Saturday.
Now every copy has to be found and corrected.
Miss one and you no longer have duplication. You have disagreement.
That is the more important problem.
Typing the same information into multiple forms is tedious, but tedious administration is survivable. The real damage is trust. If I find three versions of the same event and two say 8pm while another says 7pm, the internet has not made the event easier to discover. It has given me a research task.
Live events are particularly unforgiving because the information expires quickly. A stale business address can be wrong for months. A stale start time can become useless tonight.
Most websites do not contain the fact. They contain a copy of it.
We talk about websites and apps as though they simply contain information. In reality they often contain representations of information whose natural home is somewhere else.
The venue may be authoritative about the door time. The artist may know the definitive lineup. The ticketing system knows whether tickets remain. A promoter may know the event has moved before anybody else has updated their page.
The moment those facts are manually copied into independent systems, every one of those systems needs some way of hearing about change.
This is not a problem unique to gigs. Opening hours, prices, menus, stock, addresses and product information all suffer from versions of the same thing. Live entertainment just makes the failure obvious because the information is temporary, social and prone to late changes.
The principle I keep coming back to is simple: where possible, a fact should have a sensible home, and other places should reflect it rather than requiring somebody to retype it every time.
The difficult part starts immediately after that sentence.
No, I did not invent 'update once'
There is a very tempting founder sentence available here: why hasn't anybody solved this?
Plenty of people have solved parts of it.
Bandsintown's artist widget, for example, can automatically sync published events to a website where the widget is embedded. Culture Reverb currently describes its own approach as “Update Once, Update Everywhere”, with an event update reflected across connected venue, promoter and artist pages. Structured event feeds, APIs, calendars and syndication systems exist in all sorts of forms.
So the question is not whether anybody has ever thought of maintaining information centrally.
It is why so much local event information still gets copied around manually anyway.
Part of the answer is fragmentation. Different audiences live in different places. A small venue may get more response from Facebook than its own website. An artist may mostly use Instagram. Ticketed shows need to exist on ticketing platforms. A pub can sometimes get more practical value from a chalkboard outside than from a technically immaculate data feed.
None of that is wrong.
The problem is when supporting all those destinations means one person manually maintaining every representation.
I do not want one enormous platform to own the truth
The obvious bad solution to fragmented information is to insist that everybody abandon their own channels and put everything into one giant system.
No thanks.
Artists should control their own presence. Venues should have their own websites if they want them. Promoters will use whatever channels actually reach people. Audiences will continue discovering events through search, social platforms, ticket services, recommendations and physical places.
What I want to reduce is re-entry, not distribution.
There is a huge difference between showing the same underlying information in several places and recreating the information independently in each place.
If one event record can sensibly feed a website, an app, a permitted widget or another supported destination, those are representations of one thing. If I have to open six forms and type the new start time into each one, I am maintaining six tiny databases with my fingers.
That is one of the ideas that has shaped Music Kite's Live Hub work: maintain useful event and entity information in a sensible place, then reuse it across supported Music Kite public surfaces and Live Hub outputs instead of turning every output into a separate clerical task.
I am not claiming that principle is unique. It plainly is not. I am saying that once you spend enough time looking at fragmented live-event information, it becomes very difficult to justify the opposite.
The difficult question is authority
The moment you say update once, somebody quite reasonably asks: who gets to update it?
Suppose a venue creates an event and an artist is attached to it. The artist spots that their set time is wrong. Can they change the event? Only their own appearance? Does the venue remain authoritative? What if a promoter created the original listing? What happens when two independently created records turn out to describe the same show?
This is where a convenience feature turns into a data model.
You need identity, ownership, relationships, provenance and permissions. You need some way of distinguishing a legitimate correction from somebody confidently overwriting a fact they do not control.
And the real world will still refuse to become neat. The artist may know something before the venue updates it. A festival timetable can move during the day. A promoter and a venue may both have legitimate authority over different parts of the same event.
The answer is not necessarily one database that is always right. It is knowing where the information came from, who is entitled to change it, and what happens when trustworthy sources disagree.
That is substantially less catchy than update once, update everywhere, but software tends to become more interesting just after the slogan.
Distributing bad information faster is not success
Centralising a fact does not magically make the fact correct.
If the original record is wrong and you distribute it efficiently, you have simply achieved higher-performance wrongness.
Changes still need to propagate properly. Cancellations need to remain cancellations. Old imports should not be allowed to resurrect stale information. If sources disagree, the system needs either a sensible authority rule or an honest way of admitting the conflict.
This is why provenance became central as Music Kite grew.
Where did this fact come from? When was it checked? Was it entered by the venue, supplied by an artist, imported from a provider or found during research? If another source says something different, which one should win?
Those questions sound excessive when all you wanted to say was that a band is playing at eight.
Then the show moves to nine, an old listing changes it back to eight, and suddenly they sound rather sensible.
The point is less administration
I do not want to solve fragmented event information by giving artists, venues and promoters an exciting new daily dashboard full of extra jobs.
That would be a magnificent own goal.
The aim is the opposite. The artist should spend more time being an artist. The venue should run the venue. The promoter should promote. The system should quietly remove repetitive maintenance where it can.
For the person deciding what to do on Friday night, the ideal outcome is simpler still: the information is just right.
They should not need to care which system owns the source record, which API moved the update or how many representations exist behind the scenes. Good infrastructure is often most useful when the person benefiting from it never has to think about the machinery.
One event can appear in many places. That is useful.
It just should not need a separate clerk in every one of them.
A fact should have a sensible home. The people with legitimate authority should be able to maintain it. Other places should be able to reflect it where that is possible. And when the show moves from eight to nine, we should not require a human being to spend the evening correcting the internet by hand.
The gig has already changed.
It would be nice if the information could keep up.