Chad has talked a lot over the past few years about the need to “shift left” the way that data is managed. The idea is fundamentally simple: eliminate the need to catch problems after they happen and just prevent them from happening. Yet many organizations are struggling to make sense of this because they’ve created entire groups and practices around catching things after they break.

Additionally, it is a non-trivial problem to:

  • Implement Data Contracts in a large, complex existing system.
  • Find problems in the source code before the data is actually written
  • Identify the impact of changes, especially downstream impacts far from the original change, in source code

Gable has been working to solve all of these problems by:

  • Creating contracts based on existing data-generating code
  • Scanning each code change for changes to code that violate data contracts
  • Driving communication between data producers and consumers through automated notification

‍

However, talk is cheap. I’d rather just show you how it works.

‍

1. The Problem We Solve (in One Screenshot)

‍

Consider a standard “order” coming from a REST API.

Every time an order is created, the createOrders endpoint logs an analytics event. In the snippet above, the payload includes numProducts as a string.

That tiny type choice ripples through BI dashboards, ML models, and finance reports. If an engineer “fixes” the field to a number without warning, months of charts and queries can break.

‍

2. Automatic Asset Registration

However, months ago, the team scanned their code with Gable and it:

  1. Registers the data asset (the event) automatically.

  2. Infers the schema directly from the code, not the warehouse.

  3. Flags that numProducts is string.

No Jira ticket, no manual catalog work, just the magic of static code analysis.

‍

3. Draft Contract Generation

Because Gable operates inside CI/CD, it can immediately scaffold a data contract that mirrors the current schema. Teams can accept the draft as‑is or tighten the rules before merging a PR. They can also manually create a contract similar to the one above.

‍

4. An “Innocent” Code Change

An engineer removes .toString()—exactly the sort of silent change that breaks downstream systems that depended on the datatype. It isn’t an irrational choice if orderIds are always numbers. It may even look right and pass a unit test that didn’t care about the type.

‍

5. CI/CD Catches the Violation Immediately

The developer checks in this code and pushes the change. If the organization is protecting its systems with Gable, the pull request generates a warning (or optionally a failure). Gable’s contract check surfaces a type mismatch:
numProducts expected string, found number.

The feedback arrives in seconds, not days.

‍

6. Proactive Slack Alert for Data Consumers

The BI team subscribed to this contract gets a Slack ping with context:

Heads‑up: numProducts changed from string → number in createOrders. Systems depending on the old type may break.

They can either update their models or explain to the engineer why the change shouldn’t be applied.

‍

7. Why This Matters

‍

Without Gable With Gable
Silent data format drift is discovered after systems fail. Violations caught in PR before the merge.
Data engineers firefight, BI teams lose trust. Clear ownership: the producer fixes the code, or consumers agree to adapt.
Governance is reactive and never comprehensive enough. Contracts are enforced automatically in CI/CD.
Problems are immediately understood before they happen. For the same level of safety and shared understanding, you have to do tons of cross-team communication, which is noisy and error-prone.

But I mean – you can’t catch the human suffering in a table. Here is the real value. Consider what happens otherwise:

  • A boss, customer, or interested party sees a malfunction in the new AI, a dashboard or some end-game data insight. This might be immediate or months later, depending on how the data is used.
  • An incident is escalated.
  • Someone has to trace the malfunction to the data, which might be an aggregate of a lot of data.
  • Then, trace that data to the origin system.
  • Then figure out when it started malfunctioning and why (if it wasn’t immediate).
  • Then come up with a theory of the problem and trace it to the change.

‍

Best of all, these systems may cross several teams, and you may “get” to negotiate access to them in order to trace the issue! For the organization, this ends up being a nice warm money-fire just to trace a one-line code change.

‍

a nice warm money-fire warms the team while someone traces the issue back to a one-line code fix

‍

Or with Gable - this suffering can just never happen.

‍

8. Takeaways

  • Shift‑left governance works. Contracts belong with code, not in a separate “data quality” tool, and not just guarding a table or data file.

  • Immediate, contextual feedback prevents costly outages and builds trust across teams.

  • Data contracts aren’t paperwork. With Gable, they’re an executable policy—immediately evaluated on every commit.

Ready to keep your data stack safe from surprise schema changes?

Rachel RoseFigura

May 19, 2025