The Required Field That Wasn't Required For Anyone Already In The Room

We added a required field. It required nothing of the events that were already live.

That’s not a bug report. It’s the normal, boring behaviour of “required” fields everywhere, and once you see it you’ll find it in something you run too.

What does “required” actually mean once data already exists?

A required field is a rule that runs at the moment something is created or published. It checks the thing being submitted right now. It does not walk back through everything that got in before the rule existed and object to it retroactively, because nothing told it to.

So when you add a new required field to an existing system, you’re not tightening the system. You’re tightening the front door. Everyone already inside the building is unaffected.

We found this the annoying way. Presso Events added a validation step: an event can’t go live without a venue location attached. Sensible. Obvious, even. An attendee who buys a ticket should be able to find out where they’re going.

Except “required” only bound events published after the rule shipped. Every event published before it kept its old status: valid, because it had passed whatever check existed at the time, which wasn’t this one.

We audited the live listings on 08/09/2026. Thirteen of eighteen published events had no venue recorded at all. Not a wrong address. Nothing. Anyone who’d bought a ticket to one of those thirteen was working from a page that never told them where to show up.

Why does a rule you just wrote not apply to what’s already in front of you?

Because the check happens once, at the gate, and then it’s over. Publishing an event is an event, in the technical sense: it fires, it’s evaluated, it passes or fails, and then the system moves on. It doesn’t sit there re-reading the record every day asking “does this still hold up.”

Add a stricter gate later and you’ve only changed what happens to the next thing that walks through it. Everything that already walked through the old, looser gate is filed as “already approved” forever, unless something goes back and explicitly re-checks it.

Nobody sets out to write a grandfather clause. It falls out of the mechanics for free, the moment you bolt a new rule onto a system that already has data in it. The thirteen unpublished-venue events weren’t an oversight by anyone who worked on them. They were correctly published, under the rules that existed when they were published. The rules just changed underneath them, silently, and nothing was watching to notice.

Where do you already have one of these?

You almost certainly do. This pattern isn’t specific to event platforms. It shows up anywhere a rule gets added after the data does:

• A signup form that made a field mandatory last year. Every account created before that date is still missing it, and nothing has ever asked them for it since.
• A compliance checklist that new starters sign on day one. Nobody who joined before the checklist existed has ever signed anything.
• A CMS field marked “required” in the editor, checked only when a page is saved. Every page nobody has opened and re-saved since is exempt by default.
• A pricing rule, a shipping rule, a terms-of-service version bump, applied going forward only, because “going forward only” is what the code naturally does unless someone deliberately writes the backfill.

The fix isn’t cleverer validation. The validation is doing exactly what it was told. The fix is treating “required” as a claim about new records, and then doing a second, separate job if you actually want the old ones to comply: pull everything created before the rule existed, check it against the rule now, and decide what to do with what fails.

What we did about the thirteen

We didn’t quietly backfill the missing venues and call it fixed, because the same gap would just open again the next time someone added a new required field to an old system. Instead we shipped something that stays useful: a banner on the organiser’s own dashboard, on any live event, naming exactly what that listing is still missing.

It doesn’t only catch the venue field. It catches whatever a live event is short of, today or in six months when someone adds the next required thing. The gate at publish time still exists. Now there’s also something that keeps looking at what already got through it, instead of trusting that “required” means what it says for records it never actually checked.

If you’re auditing your own system for this, the question isn’t “is this field required.” It’s “required as of when, and for whom.” Anything that predates the rule is worth pulling and looking at directly, because the system itself will never flag it on its own.