Data Observability Platform (Dobsy) — Chandra Mouli Kambhampati

At a glance

Problem Data quality was caught late and inconsistently — each business unit ran its own ad hoc monitoring, and adding a single new check meant a full engineering release cycle.

Role Owned the data-quality and observability product pillar from the ground up — drove product strategy and requirements for self-serve configuration and the compute approach, while Engineering owned technical implementation and architecture.

Key insight The requests worth building for weren't always the ones asked for directly — recognizing which one-off asks were really shared platform needs mattered more than answering each request as its own project.

Scale today 300+ self-serve monitors across 6 business units, safeguarding data integrity for roughly 400M+ people and companies.

The problem

I worked on this as part of a team client-staffed by Tiger Analytics on Equifax’s data platform organization, owning the data-quality and observability side of the platform — distinct from the metadata and model-observability work a colleague on the same team owned.

Before this platform existed, data-quality monitoring at Equifax was fragmented — individual business units ran their own efforts to varying degrees, with no shared enterprise observability layer connecting them. Adding a single new data-quality check meant a full engineering release cycle for something that should have been configuration, not a project. At a company handling sensitive, regulated consumer credit, employment, and identity data, across business units shaped by years of acquisitions, that gap carried real downstream risk.

Beforefragmented, siloed monitoring per business unit

Afterone shared observability platform

Conceptual illustration — not a depiction of Equifax's actual monitoring landscape.

The approach

The core of what I built, starting from an early version of the platform and maturing into what’s now called Dobsy, was self-serve: business and data teams configure their own monitors directly, without waiting on an engineering release. I don’t create those monitors myself — I built the platform capability that lets other teams do it.

That layer sits on a data warehouse organized into raw, refined, and trusted layers, decoupling raw data access, metrics, and reporting into independent, self-service entry points. A root-cause-analysis toolset lets users trace an anomaly across pipeline stages using masked samples rather than raw records, so diagnosis doesn’t require exposing protected data.

Ingestionraw furnisher data arrives

Processingvalidated against expected schema

Warehouseraw → refined → trusted

Self-serve accessmonitors, alerts, RCA

Conceptual flow, reconstructed for clarity — not a depiction of Equifax's internal architecture.

Decisions and trade-offs

Built self-serve monitor configuration as a platform capability, not a single feature — removing the engineering-release bottleneck for every new check.
Drove the product case for computing directly against the underlying data lake, rather than a slower write-then-read pattern, to reduce latency.
Treated masked-sample-only data retention as a fixed privacy baseline, not a trade-off to negotiate — the product work was making that constraint fast enough to be useful, not deciding whether to honor it.
Repeatedly turned one-off business-unit requests into shared platform capability rather than one-off fixes (see below).

The technical implementation behind the compute change — the underlying pipeline and infrastructure — was engineering’s work; my role was making the product case for it and validating that the result actually delivered the latency and reliability the platform needed.

EWSreporting ask

UKdiagnostic work

USISdata-layer shift

Three separate business-unit requests, each recognized as evidence of a shared platform need rather than a one-off fix.

Execution

Not everything needs to wait for a scheduled report. Quality metrics are also computed in parallel as data moves through the pipeline, with anomalies published to a real-time notification channel rather than waiting for a batch cycle — the same mechanism that lets the team catch things like inconsistent SSN and date-of-birth formatting before they propagate downstream, rather than after.

Outcome

Today, more than 300 self-serve monitors run across 6 business units, safeguarding data integrity for a directional figure of roughly 400 million people and companies across the US, Australia, Brazil, and the UK. In one region alone, close to 5 million model outputs are monitored in real time every day.

The clearest proof of the platform’s value came under pressure. When a cloud migration initially strained trust with a major customer — particularly around the integrity of credit-score outputs, including VantageScore — anomaly and distribution-shift detection already built into the platform provided the evidence and visibility that helped restore the customer’s confidence, supporting a re-adoption accelerated by three to six months against the original timeline.

Learning

The lesson I keep relearning here: at real enterprise scale, you can’t standardize by decree. Six business units, each with its own legacy systems and its own compliance requirements, will never adopt a platform the same way — some wanted heavy self-serve configuration, others were shaped by metrics computed further upstream, and at least one eventually wanted the underlying data layer more than the interface built on top of it. The discipline that mattered most wasn’t picking one model and enforcing it everywhere; it was recognizing, case by case, which requests were genuinely one-off and which were early signals of something the whole platform needed — and building for the second kind.