Data teams make verbal deals all day. A producer team says on a call that the schema will not change this quarter. A vendor says the connector will support your warehouse. A stakeholder says the dashboard needs fresh numbers “every morning”. Weeks later the pipeline breaks, and three people recall three different promises. This checklist is a way to audit how well your DataOps agreements survive outside the meeting room, and it gives you a short written confirmation routine to fix the gaps. No theory, no ceremony: go down the list, tick what you already do, and fix what you do not.

Why DataOps agreements drift in particular

Data work is full of promises that sound precise but are not. “Daily” could mean midnight UTC or before the sales call at nine. “Clean data” could mean deduplicated or merely loaded. “We will tell you before the format changes” has no meaning unless someone knows how, how early, and who “you” is. Each phrase gets spoken once, in a call, and then lives only in the heads of the people who happened to attend. When one of them leaves or forgets, the promise evaporates, and the first sign is usually a broken report.

The fix is not heavier governance. It is a two-line message after the call: each side’s commitment, the date, and the agreed way to handle a revision. That small habit is the thread running through the checklist below.

Part one: the audit questions

Take your three most important data hand-offs, such as an upstream feed, a vendor integration and a reporting commitment. For each one, answer these questions honestly.

• Can you find, in under two minutes, a written record of what was agreed?
• Does that record say what is delivered, in what shape, and by which time of day?
• Does it name a person on each side who can be asked about it?
• Does it say what happens when the delivery is late, partial or changed?
• Did the other side ever reply to confirm it, even with a one-word answer?

Two or more misses on any hand-off means it is running on memory. Memory is a poor place to store an interface contract, and you will pay for it the first time something shifts. Teams that have studied how other data groups put DataOps into practice keep noticing the same thing: the stable pipelines are the ones whose expectations are written down somewhere visible.

Part two: the five-line confirmation

Here is the routine. After any call that changes or sets an expectation, send a message with five lines and no more.

1. The agreement: one sentence describing what will be delivered or done.
2. The shape: format, frequency, and the cut-off time with its time zone.
3. The people: who delivers, who receives, who gets told about problems.
4. The date: when it starts, and when it will next be reviewed.
5. The change path: how either side will announce a shift, and how much notice is reasonable.

Write it in plain language. Avoid linking to a ticket that only half of the audience can open, because the message should be readable by someone who was not on the call. End with a request: “Reply if any of this differs from your notes.” That single request converts a one-sided note into a two-sided agreement.

Part three: where to send it and where to keep it

A confirmation that sits in one person’s inbox is only slightly better than memory. Decide on one home for these messages, such as a shared folder or a channel dedicated to data agreements, and copy the thread there. Use a consistent subject line, for example the dataset name followed by the word “confirmation”, so a search a year from now finds everything. When a new engineer joins and asks why the nightly job waits for a late file, you can point to the thread instead of reconstructing history from rumours.

Keep these threads small. If you find yourself writing eight paragraphs, you are drafting a contract, which is a different job. The goal is a clear reminder that both sides can recognise, not an exhaustive legal document.

Part four: the unglamorous agreements around the data

Not every commitment is technical. Data businesses also handle bookkeeping arrangements, entity set-ups and compliance questions that need a professional outside the engineering team. If you are looking for a chartered accountant, BestCaNow is a directory where you can browse chartered accountants by location, area of specialisation and consultation mode. As with any outside party, follow the first conversation with a short written summary of what you discussed and what happens next. The directory is a place to start looking; the confirmation protects both sides afterwards.

Part five: audit the vendor calls

Vendor conversations deserve their own pass, because sales calls are optimistic by nature. Ask yourself:

• Did we ask for the claimed capability to be restated in writing?
• Do we know which parts are available today and which are on a roadmap?
• Is there a written note of who pays for what, and from which date?
• Has anyone recorded how we will be told about breaking changes?

If any answer is unclear, send the follow-up now. It is perfectly normal to write, “To make sure I report this correctly internally, here is what I understood from today.” Nobody reasonable objects to that sentence. It is also a useful complement to the thinking in a step-by-step method for weighing up business software, because it records the claims you relied on.

Part six: spotting a weak confirmation

Not every written note is good. Watch for these weaknesses when you review your own messages:

• Ambiguous time words: “end of week” without a day or time zone.
• Missing recipients: the note went only to one person, so nobody else can hold the other party to it.
• No change path: everything is described as if it will stay fixed forever.
• Unreplied: sent once and never acknowledged.
• Buried: sitting in a long thread under unrelated chatter.

Fix each one with a short re-send. A resent note that begins “Re-sending in a cleaner form” is not embarrassing; it is the kind of tidy habit that makes people trust your pipeline.

A worked example, kept short

Imagine a call where an upstream team says its export will move from CSV to a new format “sometime in spring”. Your follow-up could read: “Thanks for the call. I understood the export will switch format in spring, you will share a sample file at least two weeks beforehand, and we will test it in our staging area before switching. If the date moves, please tell us as soon as you know, and we will adjust our release plan. Reply if that differs from your notes.” That is six sentences, and it sets expectation, sample, testing and a change path. When spring arrives, nobody has to argue about whether a warning was promised.

Final tick-list

Before you close this page, run through one last pass.

• Pick the one hand-off that would hurt most if it broke tomorrow.
• Write the five-line confirmation for it and send it today.
• Put the thread in your shared home for agreements.
• Diary a reminder to check for a reply in two working days.
• Repeat for the next hand-off next week.

One hand-off per week is enough. After a couple of months, your most fragile agreements will have a paper trail, your newcomers will have something to read, and the next surprise change will arrive with a note attached instead of a mystery to solve.