Honk and the V6.1 Football Engine
Published: September 2026 | Category: Prediction Systems
Honk is a sports prediction system that reports a 70–80% success rate. The interesting part is not the number — it is the constraint the engine is built on: it never reads odds. No prices, no lines, no market movement. Every fixture is scored from raw kinetic and tactical match data, and every settled fixture is autopsied afterwards.
That constraint sounds philosophical. In practice it is an engineering requirement, and it shapes the entire codebase.
System overview: the three pillars, then the framework patches that constrain them.
Why refuse the market?
If a model can see the price, it will eventually learn the price instead of the football. Odds already contain the wisdom of everyone else, so a system trained on them looks accurate while actually doing nothing but echoing a bookmaker. Worse, it becomes impossible to tell whether a good hit came from analysis or from the market being right.
So the provider layer never exposes odds at all, and a hard-coded veto refuses any output that depends on them. That veto is not a comment in a README — it is a rule the engine enforces at runtime.
The three structural pillars
Each team is scored 0–100 on three axes, then blended:
| Pillar | Weight | What it measures |
|---|---|---|
| Kinetic Velocity | 40% | Offensive transition speed, spatial penetration, first-strike efficiency |
| Defensive Elasticity | 30% | Recovery speed, low-block resilience, late-game integrity |
| Structural Integrity | 30% | Squad continuity, tactical discipline, head-to-head stability |
The weighted blend plus home advantage produces a spread, and the spread drives the outcome classification. Kinetic Velocity carries the heaviest weight because transition speed is the signal that degrades least between competitions — form tables transfer badly across leagues, but how fast a side moves the ball up the pitch does not lie as often.
Framework patches: encoding what the model keeps getting wrong
Every model has systematic blind spots. Instead of retraining and hoping, V6.1 applies explicit, versioned patches over the base score. A few of the ones currently in force:
- Market decoupling — vetoes any odds-reliant output outright.
- Virtual kill-switch — abandons virtual, simulated or unverified fixtures instead of scoring them.
- Favourite spread — a 25% devaluation for favourites in knockout games, where the model otherwise over-trusts the stronger side.
- Road favourite allowance — 35% devaluation for away favourites in lower leagues.
- Defensive elasticity — 15% devaluation for teams facing high-transition underdogs.
- Structural re-evaluation — collapses a goals-favourite that has leaked structurally into a no-bet. Internally this is the Critical Illusion filter.
These are boring, narrow rules. They are also the difference between a model that is impressive in a notebook and one that is defensible when money is on the line, because each patch has a reason attached and can be evaluated in isolation.
"No data = no agreement"
The most important behaviour in the engine is refusing to answer. When coverage is insufficient — a team with no recent competitive data, a competition the pipeline does not trust — the system raises a data-missing error and stalls. It does not interpolate, and it does not guess a plausible-looking score.
# The directive, enforced at the boundary
if coverage.score(fixture) < MINIMUM_COVERAGE:
raise DataMissingError(fixture, "insufficient kinetic coverage")
A prediction system that always produces an answer is a random number generator with good typography. The abstentions are a feature.
The autopsy: Diagnostic Recurrence Analysis
Once a fixture is finished, the engine runs a Diagnostic Recurrence Analysis: it walks back through the pillars and patches to explain why the call hit or missed. No fix goes into the framework until the autopsy on the failure is complete.
This is what keeps a prediction system honest over time. Without it, every miss invites an immediate "tweak", and after a season of tweaks you no longer know which rule is doing any work. The DRA turns each result into evidence about a specific part of the model.
Operating it
The engine runs as a scheduled pipeline with a Telegram bot on top, packaged in Docker, with separate football, tennis (Apex) and basketball evaluation packages sharing the same evidence discipline. It also publishes a prediction sheet and keeps a persistent blacklist of blocklisted teams and competitions, so a single corrupted data source cannot quietly poison later runs.
What transfers to other systems
- Remove the shortcut. If a system can lean on someone else's answer, it will. Deleting that input is often worth more than any amount of tuning.
- Make abstention explicit. Encode "I do not know" as a first-class outcome with an error type, not a fallback.
- Audit before you adjust. An autopsy on one miss is worth more than ten speculative retrains.
- Version your judgement. Hard-coded rules with reasons and identifiers can be evaluated and removed. Vibes cannot.
Related
- ForChi: A Telegram Agent With Three Jobs
- REZMO: Memory That Outlives the Chat
- Agentic AI: Building LLM Systems with Function Calling
Author: Agu Chiedozie | Cloud & AI Systems Engineer