On this page
The starting point
In 2023, I started using AI for sports prediction analysis. The workflow was simple: ask the AI to retrieve information about a game, analyze it, and make a recommendation.
What followed became one of the most instructive experiences I’ve had with AI systems. Sports have clearly defined inputs (rosters, recent performance, matchup stats) and clearly defined outcomes, which made them a useful feedback environment. When the AI was wrong, the failure was visible and specific. That specificity made failures fixable, and fixing them repeatedly is what turned this into a real study of prompt engineering and AI fluency.
The project has been running and evolving since 2023. The analysis is ongoing, and the prompt system is still being improved.
The first failure: hallucinated rosters
The first major problem showed up quickly. The AI was referencing players who were no longer on the teams being analyzed: athletes who had been traded, released, or retired. It was pulling from training data that was months or years out of date and presenting it with complete confidence. There was no flag that the information might have changed and no acknowledgment of uncertainty. It filled the gaps with what it “knew,” and what it knew was wrong.
AI doesn’t know what it doesn’t know. Without explicit instructions to verify current conditions, a model treats its training data as present-day fact and presents wrong information with the same confidence as correct information.
Analysis built on wrong roster data produces wrong conclusions. The more important realization was that this wasn’t a fluke; it was structural. The model had no built-in way to distinguish current from outdated information, so the gap had to be addressed at the prompt level.
Updating the system
I started changing the prompt structure to address the specific failures I was seeing. It wasn’t one fix; it was a series of targeted adjustments, each tied to an observed failure mode:
- Added explicit instructions to verify current roster status before producing any analysis
- Required the model to flag uncertainty instead of silently filling gaps
- Structured prompts to require step-by-step reasoning instead of direct conclusions
- Tested different prompt versions side by side to see which produced more reliable output
Each iteration followed the same pattern: identify what specifically went wrong, decide whether it was a data problem or a reasoning-structure problem, change the prompt to address that exact failure, test the result, and document what changed. The sports analysis was the feedback loop.
Closing the loop: controlling what the AI knows
The most significant shift came when I stopped relying on the AI to retrieve information and started providing the data directly. Instead of “research this team and analyze,” the workflow became: I source the current stats, rosters, and context myself, put that data into the session, and tell the model explicitly to use only what’s provided.
When the AI controlled its own retrieval, any data point could come from any source or time period, with no verification on my end. Sourcing the data myself first meant:
- Every data point was current and verified before the AI touched it
- The AI’s job became analysis, not retrieval, which is a much more controllable task
- I could see exactly what information the model was working from
- The model had no path to introduce outdated or fabricated data
The key instruction: “Only use the information provided in this conversation. Do not search or supplement from outside sources.” That single constraint eliminated an entire category of failure by removing the AI’s ability to introduce unverified data.
This is data integrity, the same principle that applies to any analytical system: garbage in, garbage out. Controlling what goes in is the most direct lever on output quality.
The techniques that emerged
Over multiple years of testing, the prompt system grew more sophisticated. Five techniques came out of that iteration:
Step-by-step reasoning gates
Prompts require specific steps, such as roster verification, form analysis, and matchup context, before any recommendation. The model can’t skip validation and jump straight to an answer.
Hard source constraints
Explicit rules about what the model can draw from. If it wasn’t provided in the session, it can’t be used, and that constraint is stated at the start of every analysis prompt.
Verified vs. assumed separation
The model must clearly separate what it knows from the provided data from what it’s inferring, and label every inference, so uncertainty is visible instead of buried in confident-sounding output.
Prompt versioning
Multiple versions of the same prompt, tested side by side. Versions that produce inconsistent, overconfident, or unverified output get revised; reliable ones are kept and built on.
Failure documentation
Every significant failure gets logged: what the model did, what it should have done, and which prompt change fixed it. That log is the foundation for the next iteration.
The result is a prompt system where the AI’s reasoning is structured, its information sources are controlled, and its uncertainty is explicit. Prediction accuracy improved, but the more lasting output is a practical framework for making AI workflows reliable.
Core lesson: AI is only as good as its data
The clearest thing this project established is that AI capability and AI reliability aren’t the same. A model can be sophisticated and still produce wrong output if it’s working from wrong, outdated, or uncontrolled information. The gap between “can analyze” and “will analyze accurately” comes down almost entirely to the quality, currency, and sourcing of the inputs.
That framework now shapes how I evaluate any AI tool or workflow:
- What information does the AI have access to, and who controls that access?
- How current and verified is that information? Is it sourced and checked, or retrieved without validation?
- Is the reasoning transparent? Can I see the steps, or just the conclusion?
- Is the model constrained from filling gaps with assumptions, or will it confidently produce output when it should be flagging uncertainty?
These questions are the difference between AI output you can act on and AI output that creates false confidence in wrong conclusions.
Cybersecurity relevance
AI tools are increasingly built into SOC workflows, threat analysis, and incident response. The same failure modes that showed up in sports analysis appear in AI security tools, and the stakes are much higher.
- Hallucination in security tools: an AI-assisted SOC tool that produces wrong MITRE ATT&CK classifications, incorrect threat-actor attribution, or fabricated IOCs creates dangerous blind spots. Knowing what causes hallucination, how to detect it, and how to reduce it applies directly to evaluating and building these tools.
- Input validation: sourcing and verifying data before it enters an AI workflow maps directly onto security data pipelines. Unvalidated log data, stale threat feeds, or unverified context cause the same class of failure as unvalidated sports stats.
- Behavior control through prompting: controlling what a model can reason from, which steps it must complete, and what it must flag as uncertain is access control for AI. It determines what the system can and can’t produce.
- A culture of iteration: the test, identify, fix, document cycle applies to any AI integration in a security environment. AI tools in security should be tested and iterated on, not deployed and trusted blindly.
Understanding how AI fails, not just how it works when it’s working, is what makes it safe to deploy in high-stakes environments. I applied this directly in my AI-powered SOC triage tool, which feeds the model structured fields extracted from real alerts rather than letting it guess.