"Garbage In, Garbage Out" Isn't About Training Data Anymore — It's About the Ticket You Pasted Five Minutes Ago

Why this matters

You've heard "garbage in, garbage out" so many times it's become elevator music for AI training data — background noise you tune out. Here's what nobody says out loud: the ticket you pasted into an agent ten minutes ago is a training set too. One row. No averaging, no second chances, no million other examples to drag it back toward the truth.

The diff that traced back to one dead link

This is a composite of a pattern I've watched play out enough times at PhoenixDX to stop calling it a fluke. An engineer hands an agent a genuinely good ticket — clear acceptance criteria, a code pointer, a link to "the auth spec." The agent reads the spec, writes a migration that matches it field for field, tests pass, review looks clean. Two days later someone realizes the linked spec was the pre-refactor version. The real schema changed three sprints ago and the doc never caught up. The diff wasn't wrong because the agent reasoned badly — it was wrong because the one document it was told to trust was stale, and it had no way of knowing that. Prompt: fine. Model: fine. Input: rotten.

The reframe: your context is a dataset, and N=1

Get burned by that a couple of times and your mental model shifts for good. Stop treating a PRD, a ticket, and a pile of code excerpts as "context you paste into a prompt." Start treating them as a dataset — the entire training set for one inference. Every failure mode you already know from data engineering has a direct twin here: staleness, missing provenance, schema drift, silent gaps. The only thing that's different is scale. A training set has millions of rows, so a few bad ones wash out in the average. Your agent's context for this one ticket has exactly one row. Bad row, bad run. No averaging, no regularization, nothing to save you.

Day 1 scope: this is the lens, not the tooling

This series runs 30 days, and by the end you'll have a real ingestion and retrieval pipeline feeding your agents — chunking, embeddings, freshness checks, provenance tracking, all of it. Today has none of that. Today is just the lens: learning to look at a ticket the way a data engineer looks at an incoming CSV, before you write a single line of pipeline code. Skip this step and jump straight to tooling, and you'll end up automating checks you don't actually understand yet.

Four data-quality checks, mapped onto agent context

• ▹Freshness — is this doc, ticket, or code excerpt still true? A Confluence page linked from a ticket six months ago describes the API as it was six months ago, not as it is now. An agent has zero built-in skepticism about a timestamp; every sentence in its context reads as equally current unless you tell it otherwise.
• ▹Provenance — where did this fact come from, and can you actually trace it? "Use the retry logic from the payments service" is not provenance. A link to the specific file and commit is. If a claim in your context can't be traced to a source, you can't tell the agent when that source has changed — and neither can it.
• ▹Schema conformity — does the ticket even have the fields the agent needs to do the job? A ticket missing acceptance criteria, a rollback plan, or an affected-systems list isn't just thin prose — it's a record with nulls in required columns. The agent fills those nulls with a plausible-sounding guess, the same way a model trained on data with missing labels does.
• ▹Completeness — is there a silent gap the agent is about to hallucinate over? This one's sneakier than a missing field: it's the thing nobody wrote down because "everyone knows that." Everyone on the team does know it. The agent doesn't, and it won't ask — it'll invent something consistent-sounding and keep going.

Why this is worse than bad training data

When a training set has a mislabeled example or two, the model barely notices — millions of other examples keep pulling the gradient back toward the truth. There's no dilution to lean on here. If the one spec you linked is out of date, that staleness isn't 1-in-a-million, it's 1-in-1: it is the entirety of what the agent knows about that decision for this run. This is the part experienced engineers underrate the most, because they're trained to reason about robustness at scale. An agentic coding run has no scale. It has your ticket, your PRD, and whatever code you pasted in — and that's the whole population.

Your 5-minute pre-flight checklist

Before you hand a ticket to an agent, run this like data validation, not prompt cleanup:

• ▹Freshness pass: for every linked doc or spec, check the last-modified date. Older than the last related code change? Flag it or re-verify it before the agent ever sees it.
• ▹Provenance pass: for every claim in the ticket that isn't a direct link (file path, commit, line range), ask "how would I verify this right now?" Can't answer in ten seconds? Neither can the agent.
• ▹Schema pass: does the ticket carry the fields this kind of task actually needs — acceptance criteria, affected files or systems, rollback or migration notes? A blank field is a null the agent will quietly impute.
• ▹Completeness pass: read the ticket as if you had none of the team's unwritten context. What would a new hire need spelled out that isn't there? That gap is exactly what the agent will fill with a guess.

What's next

Day 2 starts building the ingestion layer that runs these four checks automatically instead of by eye — so "is this doc stale" stops being something you eyeball and becomes a property the pipeline computes before the agent ever touches the context.

Extend your knowledge

• ▹Try the pre-flight checklist on the next real ticket you hand to an agent, before you invoke it — note which of the four checks actually catches something.
• ▹Look at your team's ticket template and check it against the schema conformity criterion: does it force acceptance criteria, affected systems, and rollback notes, or are those optional and usually skipped?
• ▹If you've read classic data-quality material (e.g., work on data contracts or the DAMA data quality dimensions), map its checks one-for-one onto "context handed to an agent" — the parallel holds further than these four.
• ▹Skim your last 3-5 merged agent-authored PRs for any linked doc or spec that turned out to be stale — that's your evidence base for whether this problem is actually costing you time.