The data contract your vendor never signed

In almost every data audit involving third-party data sources, the contract is the same: an email thread in the inbox of a data engineer who left the team six months ago. There is no formal SLA covering schema stability. There is no change notification process. The data vendor sends data; the data pipeline consumes it; the data team monitors whether it arrives. What the monitoring does not cover is whether what arrives is still what was agreed — because nothing was agreed.

The failure is usually quiet. A data vendor feed used in a reporting pipeline changed a date field from ISO format to a locale-specific one. The schema validation passed because the column type was still a string, the data pipeline ran cleanly, and the outputs continued to look correct. A business user caught the problem three days later when their numbers did not reconcile. The investigation took one day to trace back to the change. The data vendor had released a changelog; they had no contractual obligation to notify anyone.

This post follows the July post on data contracts, which covered the internal version of this problem: the agreement between a data producing team and data consuming teams inside the same organisation. The fix there — schema versioning, schema registry, the Open Data Contract Standard — works because it relies on shared governance and shared organisational authority. Both sides are inside the same structure and can be held to the same standards.

When the data producer is outside your organisation, neither condition holds. The external data producer has no organisational incentive to maintain your schema expectations. Internal governance tools cannot reach them. The fix is not governance. It is negotiation — and most data teams are not in that conversation.

The inherited dependency

A SaaS API evolves on the data vendor's release cycle, not yours. A partner feed schema was designed to deliver data in the format that their system produces, not the one your data pipeline expects. Acquired company data was built for their analytics stack, not the one absorbing it. When the dependency was created, the terms of the relationship were set by procurement: a contract covering uptime, delivery schedule, and support response times. Schema stability, change notification timelines, and data quality thresholds were not on the agenda — not because anyone excluded them deliberately, but because the people negotiating did not know they needed to be included.

By the time the data engineer inherits the data source, the commercial terms are already fixed. What is in the procurement contract is what the data vendor is accountable for. Everything else is informal.

The defensive layer

The engineering response to a data vendor with no schema commitment is a defensive ingestion layer: type coercion, nullability handling, schema drift tolerance. These absorb variability. They do not address it.

The defensive layer creates a second consequence that is harder to see. External data sources acquire a reputation for unreliability and are quietly excluded from decision-critical data pipelines — not through a formal decision, but through the accumulation of incidents where something changed without notice. The data a vendor provides may be irreplaceable, but the instability associated with it makes it easier to route around than to depend on.

The date field incident illustrates the limit of the defensive layer. Type coercion catches a type change. It does not catch a value format change within the same type. The data pipeline accepted the new date values as valid strings; nothing in the monitoring flagged an error. The defensive layer was working as designed. The problem was a class of change it was never built to detect.

The missing conversation

The data engineer can specify exactly what an external data source needs to provide: schema stability, versioning behaviour, a change notification process, a latency guarantee. They cannot represent a commercial ask. The procurement team can draft contract clauses and negotiate SLA terms. They do not know what schema stability means in practice, what acceptable latency looks like for the data pipelines that will consume the feed, or how to translate a data quality threshold into a term a data vendor SLA can carry.

Most organisations have no named function that bridges the two. Data quality requirements remain an engineering wish list — communicated informally at integration time, dropped when the commercial terms are already agreed, and enforced by monitoring rather than by contract. Each new external data source is a dependency established without a data contract and discovered to be fragile when something changes.

The leadership mandate

The CTO owns the question of which external data dependencies are contractual and which are informal. In most organisations, that question is invisible until something breaks. The dependencies that matter most — the data vendor feeds in critical data pipelines, the external data sources that ML models read from — are the ones where the answer is most consequential.

Making it visible does not require a new governance framework. It requires asking: for each external data source in a decision-critical data pipeline, what happens if the schema changes? Is there a contractual obligation for the data vendor to notify the team? If the answer to either question is "we would find out when something breaks", the risk is known — it simply has not been made the business owner's problem yet.

The path forward

For new external data dependencies, the conversation with procurement should happen before the data source enters a production data pipeline. Schema versioning requirements, change notification obligations, and data quality thresholds are contract terms, not engineering preferences. The procurement team needs to know what to ask for; the data engineering team needs to be in the room before the commercial terms are agreed.

For existing external data sources, a retrospective of the critical data pipelines identifies which carry external dependencies without a data contract, what would break if the schema changed, and whether that risk has been communicated to the business owner of that data pipeline.

The external data contract is not a new document to write. It is a negotiation that was supposed to happen at procurement and did not — and that the data team has been compensating for ever since.