Solutions/Data Contracts & Quality
Stop learning about data problems only when someone reports them.
A renamed column, a delayed pipeline, a null where a number should be. By the time someone notices the dashboard looks wrong, they've already stopped trusting it. dScribe puts a contract and a quality check between your producers and consumers, so the problem gets caught before it reaches a report.
Not a ticket after the fact. A contract, versioned, that catches the break before it ships.
- Your data engineers' afternoons disappear into root-cause. The same trace-it-back-through-the-pipeline exercise, every time a number looks off.
- Your downstream teams already made the call before anyone caught it. A decision shipped on a number that was wrong for a day, or a week, before someone happened to notice.
- Producer and consumer teams have no shared definition of “good”. No SLA on freshness or schema, so blame arrives after the damage, not before it.
How it works
Catch the violation before it reaches the report.
A schema change in Databricks does not have to become a surprise for everyone downstream. dScribe links each data product to a versioned contract that defines the schema, quality rules and service levels it must meet. When a run fails validation, the contract surfaces the warning.
Contract versioning
Track every change to the agreement between producer and consumer.
Data contracts are not static documents. When a schema, quality rule or SLA changes, dScribe versions the contract so everyone can see what was promised, what changed and why. Producers and consumers review the new version before it becomes the active agreement, so downstream teams never inherit a break they did not agree to.
- Version history stays attached to the data product, not buried in a file share.
- Review and approve contract changes before they take effect.
- Downstream impact is visible before a new version is published.
How dScribe helps
Define what producers promise before consumers depend on it.
Catch it before it ships, not after a user does.
A renamed or dropped column gets flagged as a contract violation before it silently breaks a downstream report.
Keep the tools you already built. Don't maintain a second layer on top.
No-code metrics, custom SQL, plain-text expectations, or plug straight into Soda, Great Expectations or Monte Carlo. Tagged Info, Warning or Error so it's obvious what needs attention now.
A contract nobody has to take your word for.
Built on the open ODCS standard. Lifecycle status, named consumers, SLAs across six dimensions, versioned and exportable as YAML. Not a proprietary black box.
Live where your data already lives. Nothing new to stand up, nothing new to trust.
The dscribe-dq SDK validates directly against Databricks, MSSQL and SAP HANA/Datasphere, writing results straight back into dScribe.
Marketplace
Publish trusted data products with clear commitments.
Publish datasets, reports and definitions as ready-to-use data products in the Marketplace. Couple each product to a data contract so users can see the producer, intended consumers, schema, service levels and quality commitments before they rely on it. When a commitment is missed, the contract and validation status stay attached to the product instead of disappearing into a separate monitoring tool.
Day to day
Make contract and quality health visible.
Review each contract's current version, validation results, named producer and consumers, and any active violations in one place. Quality health reflects the checks and service levels agreed in the contract, not glossary documentation coverage.
What it's worth
What changes when quality reaches the people using the data.
Catch it before your users do.
Twenty minutes, your Databricks environment, your contracts.
What people usually ask at this point.
Does this replace our existing quality tooling?
No. dScribe can use checks from tools such as Soda, Great Expectations and Monte Carlo, while keeping the results next to the contract, owner and affected data product.
What happens when a contract is violated?
The violation is shown with the affected schema, service level or quality rule, plus the named producer, consumers and downstream impact. The team can fix the issue or publish a reviewed contract version.
How do users know whether a data product is safe to use?
The Marketplace shows the current contract, producer, intended consumers, service levels and validation status alongside the data product before someone depends on it.