Official sync can no longer be a blind reimport

Today's work in Ultimate Porra looked fragmented at first.

Official knockout assignments were tightened.

Scorer matching started recognizing identity variants more reliably.

Sync with the official source stopped living in the public-facing surface and moved behind the layer that already stores product truth.

And, most importantly, the system gained ways to repair concrete fixture links and fixture cycles without treating the whole competition as something that must be rebuilt from scratch.

That is not just a day of “more maintenance”.

It is a much clearer decision:

once votes, scoring, and user history already exist, official sync can no longer behave like a blind reimport.

Official data changes, but the product already has memory

At the beginning, it is easy to think about an official data integration as a simple pipe.

A match arrives.

The score updates.

If something changes in brackets, names, or bonus detail, import again and move on.

That model works while the product has not yet accumulated too much consequence around each match.

But a real pool product does not only store results.

It also stores:

• what each person voted for;
• which match each vote became linked to;
• which point explanation the product showed;
• and which bracket or standings reading the product exposed at that moment.

From there, a change in the official source stops being just “new data”.

It becomes a correction applied to a system that already has memory of its own.

The problem was no longer refreshing results, but repairing identity

The most interesting change from the day is not really about the scoreline.

It is about fixture identity.

When an official knockout pairing is confirmed late, or when an assignment shifts after users have already voted, the risk is not only that the interface shows an old label.

The risk is that the correct vote stays attached to the wrong match.

That creates an important distinction:

Today's decision was the third one.

Not rebuild everything.

Not hide it in the client.

But identify exactly which links became wrong and repair them with explicit scope.

Sync stopped being the responsibility of the public-facing surface

There was an architecture decision underneath that product decision.

Sync logic stopped sitting in the layer closest to public reading and started leaning on the layer that already knows about matches, votes, results, and history.

That changes the kind of operation the system can perform.

From a surface optimized for publishing or reading, the natural question is: “what do I show now?”

From the layer that preserves product truth, the question becomes this:

“if this bracket changed late, which votes are now attached to the wrong fixture, and how do I repair that without creating new inconsistencies?”

That shift matters because official sync is no longer only about fetching data.

It now also has to respect consequences.

Repair stopped meaning reset

The clearest improvement from the day was dropping the idea of repair as a broad reset.

When a system is still small, the temptation is to reset and recalculate.

But in a prediction product, that can destroy the most valuable thing: the link between the user's saved intent and the match they actually meant to vote on.

That is why the new repair path is built around a different question:

what can be moved safely, what must stay untouched, and which conflicts should block the operation before anything is applied?

That introduces friction.

But it is healthy friction.

It means the product stops rewarding fast intervention and starts demanding repair that can be defended.

Not every fixture change deserves the same treatment.

Not every naming difference justifies rewriting teams that are already settled.

And not every bonus resync should run if the score itself did not really change.

Reversibility stopped being optional

There was another quiet but important idea underneath the work: a serious correction needs a way back.

If sync is now allowed to touch links between votes and fixtures, then the operation is no longer just a refresh.

It becomes a mutation over product memory.

And that kind of mutation deserves two things:

• guardrails before it runs;
• and a way to step back if the diagnosis was incomplete.

That does not make the system heavier for its own sake.

It makes it accept an uncomfortable truth: the official source gets corrected too, and when that happens it is not enough to “run another import”.

A mature pool product stops treating the tournament like disposable data

The lesson from the day is this:

a prediction product does not mature only when it scores better or explains more of the live match.

It matures when it stops treating the official tournament as a stream of data that can keep falling onto a neutral base.

Because the base is no longer neutral.

It already contains votes, explanations, leaderboards, and visible user-facing decisions.

From that point on, syncing correctly does not mean fetching the latest state.

It means bringing it in without breaking the memory the product already built.

And when that requires repairing one concrete cycle, blocking an overly aggressive rewrite, or preparing a reversible escape hatch, the system is saying something valuable:

it is no longer optimized for importing quickly.

It is optimized for correcting truth without undoing intent.

Part of my product and platform notes. Follow the blog or contact me.