Verification checklist for new and changed vendor feeds
Problem
When a vendor changes an export schema, or a new feed is onboarded, the person plugging it into the pipeline usually opens a sample file, skims the columns, checks a few rows look sane, and if nothing looks obviously wrong, wires it into the warehouse. The check happened, but nowhere is it written down. It might be a note in a private message, or nothing at all. Months later a number is wrong, someone traces it back to a schema change on the vendor's side that shifted a column, and the question becomes whether anyone actually reviewed the feed before it went live. There is no record to answer that, only recollection, and recollection is unreliable once the person who did the check has moved teams or left.
Product idea
A single-screen tool for the person onboarding or re-verifying a vendor feed. Upload a sample export or the latest pull, and work through a checklist scoped to that vendor: expected columns present, row count within the usual range, known identifiers reconciling against the existing mapping table, date formats and units matching what the transformation layer expects, and a free-text note for anything unusual. Each item is checked off individually rather than signed as a block, so a partial review is visible as partial rather than hidden behind one tick. Finishing produces a timestamped, named sign-off tied to that feed and that version, exportable as a PDF or CSV row. It does not validate data quality on every load; it is a point-in-time record that a person looked, kept deliberately separate from automated freshness or schema-drift alerting.
Who it is for
Data engineers and analytics engineers onboarding or re-verifying a vendor feed, and the Head of Data who needs to show, when a number is questioned, that the feed behind it was actually checked.
Possible first version
A single web form scoped to one vendor feed at a time: a configurable checklist template per vendor, manual upload of a sample export or CSV, a side-by-side view of expected versus actual columns, a pass or fail toggle per item with a note field, named sign-off with timestamp, and PDF or CSV export of the completed record. Version one has no live connection to the warehouse or ingestion tool. The sample is uploaded by hand, and the resulting record is stored and exported rather than written back into any pipeline metadata system, which is explicitly out of scope for a first release.
- Build classification
- Micro-tool
- Rough effort
- 10-day prototype
- Roles involved
- Data engineer, Analytics engineer, Head of data
- Relevant to
- League office, Federation / governing body, Professional club, Collegiate athletics
- Systems in play
- Cloud data warehouses and lakehouses, Ingestion and ELT tools, Spreadsheets, Messaging apps
- Product framing
- Verify or inspect
Questions we get asked
What do we need before we can start using this?
A sample export or CSV from the vendor feed in question, and someone to write down what the checklist for that vendor should actually contain: the columns expected, how its identifiers map onto your existing records, and the formats the transformation layer assumes. Most of this already exists informally in a data engineer's head. The work is writing it down once, per vendor, rather than re-deriving it from memory every time a check is needed.
Does this replace our schema drift alerts or our ingestion tool?
No. Schema drift alerting is continuous and automated; this is a deliberate, point-in-time human review, and the two are meant to sit side by side rather than substitute for each other. It reads a sample from whatever ingestion or ELT tool you already run and writes its own sign-off record. It does not touch the pipeline itself and does not claim to catch what an automated monitor would.
Our engineers already check a feed before wiring it in. Why formalise it?
If nobody has ever needed to prove that check happened, this tool has limited value and you should not build it. The case where it earns its keep is narrower: after an incident, an audit, or a handover, when someone needs to answer whether a feed was reviewed and by whom, and the honest current answer is a guess. If that question has never come up for you, wait until it does.
Who has to keep this up to date once it exists?
Whoever owns each vendor relationship maintains that vendor's checklist template as the export evolves. This is a real, recurring cost, not a one-off setup. If a vendor changes its schema and nobody updates the template, the tool keeps producing confident-looking sign-offs against a checklist that no longer matches reality, which is worse than having no record at all.
Is this your workflow?
Tell us one sports workflow that still runs on paper, spreadsheets, WhatsApp or an outdated system. We will map it and show you what a simpler product looks like.
Tell us about itMore in Data platform & engineering
- Access permission drift monitor for warehouse and reporting toolsA monitor that compares entity access rules across the identity provider, warehouse and reporting tool, and alerts a named owner when they drift out of sync.
- Attendance reconciliation report across ticketing and till systemsA reconciliation report that turns a ticketing export and a till export for the same fixtures into one defensible attendance and spend figure, with the variance between them shown and explained.
- Chat intake assistant that triages ad hoc data requestsA chat assistant that answers a data request instantly when the metric already exists, and turns anything new into a structured, tracked ticket instead of a message lost in a chat thread.