What "Production-Ready" Means for a Data Pipeline

Ask two engineers on the same team when an ingestion pipeline is finished.

The first says it is finished when it runs correctly on the source. The second says it is finished when it runs correctly on the source, handles malformed records, has tests, has a documented output contract, and can be picked up by someone else. Both answers are reasonable. They differ by a factor of three in effort and by an order of magnitude in maintenance cost.

The disagreement is rarely had out loud, which is why it produces a different pipeline every time depending on who was assigned and how much schedule pressure they were under. Writing it down is a one-page document and a meeting. It is also the cheapest intervention available on delivery quality, and the one most often skipped in favour of buying a tool.

1. What the bar actually is, artefact by artefact

A definition of done that says "code, tests and documentation" is not a definition, because every one of those words means something different to each reader. The bar has to be specific enough that two people can look at the same pipeline and agree on whether it clears.

• Code: runs on the full source, not on a sample. Handles the failure modes named in your team's list. Configuration externalized rather than hardcoded.
• Tests: every transformation has a test for a valid input, a null input, and a malformed input. The malformed case asserts the behaviour, not just the absence of a crash. Coverage target stated as a number your team agreed on.
• Data quality checks: completeness, uniqueness of the claimed key, value ranges, expected volume. Failures recorded per record rather than logged and forgotten.
• Output contract: a machine-readable schema of what the pipeline emits, checked in CI. Nullable fields state the conditions under which they are null.
• Configuration: every path, threshold, credential reference and error policy lives outside the code.
• Orchestration: schedule, dependencies, retry policy, and what happens on failure, including who is notified.
• Documentation: answers what it reads, what it produces, what happens to a bad record, what happens if it runs twice, and how to add a field.

2. Who decides when the engineer and the manager disagree

This is the part a checklist cannot solve, and it is where most definitions of done quietly die.

The engineer wants to add the tests. The delivery manager needs the pipeline on Thursday. Both are doing their job. If the answer is decided case by case, the definition of done is decorative, because it loses every time there is pressure, and there is always pressure.

Three arrangements work, in ascending order of maturity:

• The bar is not negotiable, the scope is: The definition of done applies to whatever ships. If Thursday is immovable, fewer sources ship on Thursday. This is the cleanest rule and the hardest to hold the first few times.
• Named exceptions with an expiry: Something ships below the bar, the gap is written down with a date, and the date is tracked like any other commitment. Honest, and it works as long as the list gets reviewed. If nobody reviews it, this is just the previous arrangement with extra paperwork.
• A tech lead with the final call: One person owns the bar and can say no. Requires that the organization actually backs them the first time they use it, which is the real test.

What does not work is collective ownership with no arbitrator. When everyone owns the bar, the bar is set by whoever is most tired that week.

One framing that helps in the conversation with delivery: the bar is not a quality preference, it is a cost decision about a later quarter. Shipping below it moves work forward in the calendar and multiplies it. That argument lands better than an appeal to craftsmanship, because it is in the currency the other person is managing.

3. Building your team's failure-mode list

The generic bar above applies anywhere. The part that makes a definition of done yours is the list of failure modes your sources actually produce, and it has to come from your own incidents rather than from an article.

Build it once, in an hour:

• Take the last 10 production incidents on ingestion: Tickets, alerts, or the memory of whoever was on call.
• For each, write the one sentence that describes what the code should have done: Not what went wrong, what the handling should have been. "A record with an unparseable date should have been flagged and skipped, not aborted the batch."
• Group them: Most teams end up with 5 to 8 distinct modes, and the same three account for the majority of incidents.
• Put the list in the definition of done, as the things every pipeline is expected to handle.

Two properties make this list valuable in a way a generic checklist is not. It is specific to the sources you actually ingest, so nobody can argue it is theoretical. And it is short, because your incidents cluster, which means the bar stays achievable.

Review it after each incident that is not on the list. Either the mode is new and it joins, or the handling was there and failed, which is a different problem.

4. Writing it on one page

Longer than a page and it stops being read. The structure that holds:

• The list of artefacts, with the specific bar for each, in the form of section 1 rather than in the form of adjectives.
• The failure modes your sources actually produce, named. Every team has its own list, and it comes from your incident history rather than from a generic article. Five to eight items.
• What is explicitly out of scope, which prevents the definition from expanding into an unbounded quality manifesto.
• The exception process, in two sentences.

Write it with the two engineers whose work the team already respects, not alone. A standard extracted from practice gets adopted. A standard handed down gets routed around, and the technical content is often identical in both cases.

Date it, and put a name on it. An undated document with no owner decays into folklore within a year.

5. Enforcing it in review, not in documentation

A definition of done that lives only in a wiki has no mechanism. The enforcement has to sit in the path the work already takes:

• Pull request template that lists the artefacts as checkboxes: Cheap, visible, and it makes the omission deliberate rather than accidental.
• CI checks for the parts a machine can verify: tests pass, coverage threshold met, schema validates against a sample output.
• Review as the human gate for the parts it cannot: whether the tests assert anything meaningful, whether the documentation answers the five questions, whether the failure modes on your list are actually handled.

The CI part matters more than it looks. Anything a machine checks stops being a conversation, which removes it from the negotiation entirely and leaves the human review free for the judgement calls.

6. What happens the first month

Two things, and both are worth expecting out loud before they happen.

• Delivery slows down: The team is learning the bar while delivering against it, and the first few pipelines take longer. If nobody says this in advance, the slowdown becomes the evidence that the initiative failed.
• Somebody tests the exception process immediately: That first exception decides whether the definition is real. Granting it correctly, with a written gap and a date that gets tracked, establishes the mechanism. Granting it informally establishes that the bar is optional.

After that, the visible effect is not that pipelines get better in a way anyone notices. It is that they stop varying. Estimates start holding, review gets faster because reviewers know what they are looking for, and the pipeline written by whoever was available looks like the pipeline written by anyone else.

What to take away

Two engineers finishing the same work at different points is not a discipline problem. It is a specification problem, and the specification is one page.

Write the bar artefact by artefact, in terms specific enough that two people agree on whether it clears. Decide in advance who arbitrates under pressure, because the answer decided case by case is always the same one. Enforce it where the work already passes, in the pull request and in CI, rather than in a document nobody opens.

The teams that skip this and buy tooling instead end up with the same variance, applied faster.

PrettyWhale.ai produces the full artefact set from a source sample: code, unit tests, data quality checks, output schema, configuration, orchestration and documentation. The definition of done stops being something to enforce and becomes what arrives by default. The bar still has to be written, because somebody has to review the output against it.