The problem
Publishing a football alert sounds simple when described as “receive an event and post it.” In production, the difficult part is determining whether the incoming information deserves an action.
A provider may publish a provisional lineup before the official version, report a score before supplying the scorer, mark a friendly as finished before a penalty shootout, reverse the home and away teams, or update one part of the event several minutes after another. A system that treats every field as immediately authoritative will be fast and visibly wrong.
What context, evidence and controls does the agent need to decide whether to send, edit, wait, refresh or ask for human attention?
The operating workflow
The engine coordinates five connected stages. A failure at any stage can create a believable but incorrect final post, so the execution path must remain observable.
Find relevant matches, resolve team identity differences and establish the expected competition and kickoff time.
Collect event state, score, lineup, player and asset information from available providers and persisted context.
Compare new evidence with the current lifecycle, timing expectations, prior publications and known data-quality conditions.
Select the appropriate alert format, construct the visual and use controlled fallbacks when an asset is genuinely unavailable.
Send or edit the Telegram post, record what happened, continue tracking the fixture and recover that context after interruption.
Decision controls
Lifecycle progression
The engine uses a provider-neutral model of fixture progression rather than allowing a single provider label to dictate production behaviour. Forward transitions are assessed against the state already observed, match timing and supporting evidence.
Timing and freshness
Lineups require a different freshness policy from goals or full-time results. A first lineup can be published close to kickoff and then refreshed shortly afterward because providers sometimes replace a partial or provisional dataset. A material change should be surfaced to the operator and corrected by editing the existing post where possible.
Confidence without paralysis
Accuracy controls must not make the system so cautious that useful alerts never arrive. For example, if the scoring team is confirmed but the scorer is delayed, the engine can preserve the confirmed event without inventing the unsupported detail. The confidence policy is designed around the consequence of each field, not a blanket demand for perfection.
Human escalation
Unusual match formats, conflicting evidence and high-impact uncertainty can be surfaced instead of silently resolved. The operator remains able to correct, suppress, refresh or override an action.
How incidents improved the system
The most useful evaluation scenarios came from real matchday failures. Each incident was treated as evidence about the workflow, not just a one-off post to repair.
Provisional lineups published as final
- Observed
- A provider exposed an early lineup that changed after the alert had already been published.
- Diagnosis
- The presence of lineup data was being treated as sufficient evidence of finality.
- Response
- Add completeness checks, retain the usual matchday timing policy, and perform a timed post-publication refresh that reports material differences.
Incorrect full-time transition during a shootout
- Observed
- A preseason fixture was marked complete while the teams continued to penalties.
- Diagnosis
- The provider status did not fully represent an irregular match format.
- Response
- Require lifecycle evidence beyond a single final label in ambiguous formats and preserve operator review for exceptional fixtures.
Late or false second-half alerts
- Observed
- Restart timing, provider inconsistency and simplistic transition handling could produce late or unsupported alerts.
- Diagnosis
- The visible symptom had several possible causes, so guessing from the final post was insufficient.
- Response
- Inspect timestamps, persisted state, provider responses and scheduler behaviour, then evaluate transitions through a provider-neutral shadow model.
Incorrect team or player assets
- Observed
- New teams could lack stored crests and unsuitable external player images degraded the lineup graphic.
- Diagnosis
- Asset preparation and fallback quality were part of the production workflow, not cosmetic extras.
- Response
- Prepare crests proactively from upcoming fixtures and use a deliberately neutral player placeholder rather than an inconsistent image source.
Evaluation approach
I do not reduce the engine to one generic accuracy number. A decision can contain the correct score and still be operationally wrong because it arrived too early, duplicated an existing post or used the wrong publication action.
Were the teams, score, scorer, lineup, formation and competition supported by the available evidence?
Was the action early, acceptably prompt or late relative to the actual event and source availability?
Was the lifecycle transition valid from the last confirmed state?
Should the engine have sent, edited, refreshed, withheld or escalated?
Did the fixture state, schedule and prior publication survive a restart without duplication or missed progression?
New lifecycle logic first records what it would have done without controlling production. An end-of-matchday report compares those decisions with the actual outcome. The operator decides when the evidence is strong enough to graduate it.
My contribution
I shaped the Content Engine around the realities of live production, directed its AI-assisted implementation and continued improving it through daily operation.
System and product direction
- Turn editorial and operational problems into requirements and acceptance criteria.
- Define lifecycle behaviour, evidence thresholds, timing, fallbacks and escalation.
- Review technical trade-offs through their impact on reliability, speed and operator control.
Evaluation and operations
- Test live and replayed cases, inspect execution paths and challenge unsupported output.
- Prioritise incidents by customer impact and verify the final channel result.
- Turn recurring failures into monitoring, regression scenarios and documentation.