Write-time data quality enforcement

Bad data stops at the door.

Most tools tell you on Tuesday what went wrong on Friday. OpenDQV Cloud validates every record as it is written, against plain-YAML contracts you own, and seals every decision in a tamper-evident audit chain. The bouncer at the door, at enterprise scale.

14 days · 200 ODUs · no credit card · no code to start

Blazingly fastanswers in under a millisecond inside the engine — your network round-trip rides on top, so pick the region next door
3 clouds · 6 regionsAWS, Azure and Google Cloud. You choose where your validation runs
41 starter contractsevery one starts in observation mode. Nothing enforces until you decide
Every decisionsealed on a hash-chained, tamper-evident audit trail
Our approach

Validation beats inspection.
Inspection is all you have today.

Most data quality tools on your stack today inspect: they scan what already got in and report what they find, after the damage is travelling. Validation happens at the door, before a record enters, while there is still a decision to make.

Manufacturing spent seventy years learning this. It even priced the alternative: the rework burden of inspection-after-the-fact has a name, the Hidden Factory, and it quietly consumes 15 to 40% of capacity. Yours included.

The rules have a cost problem of their own. Without a validation platform they live everywhere: once in Salesforce, again in the lakehouse, again in the ERP, again in a loader script — every rule re-implemented per system, drifting apart from the day they're written. Add a system: implement them again. Swap Salesforce for Dynamics: your data migrates, and every rule you spent years encoding is rebuilt from memory.

OpenDQV Cloud makes the rules an asset that outlives the systems they guard. Contracts live once; every system calls the same gate; a migration touches plumbing, never rules — and governance gets one definition of valid, with one evidence trail, across the whole estate. Plumb once per system. Write the rules once, ever.

And you don't rip anything out. Keep the inspection tools you have; add validation at the front door. Validation + inspection = better data quality.

Your sources — anything that writes
SalesforceDatabricksSnowflakecustom appsPython pipelines
OpenDQV Cloud
= bad data stopped at the door
Your inspection tools — keep them all
Great ExpectationsSodaDatabricks DQXdbt tests
OpenDQV Cloud
= better data quality

Said precisely: a synchronous gate wherever your code writes; automatic quarantine scanning where the platform writes for you.

The platform

One engine. Three jobs.

Your own Vanguard Compute Engine, per-second metered, doing the three things data quality actually needs: stop bad records, improve your data quality cycle by cycle, and prove what happened.

Enforce

Block it at write time

A failing record never enters your system. The decision is synchronous, sub-millisecond in the engine, and returned to the caller with the exact rules that failed.

customer_profileBLOCK
caller informedvalid: false + the rules that failed
Improve

Measure, tighten, repeat

Every contract starts in observation mode: it counts what would have failed on your real traffic without blocking anything. Tighten the contract, watch the reject rate fall, promote to enforcement with the numbers in front of you. That cycle is how data quality actually improves.

would-block · 7 days220 records
top failing rulebalance_non_negative
Prove

An audit trail that can't be quietly edited

Every validation lands on a sealed, hash-chained audit log — every seal countersigned by a second, separate system, so the record can be independently verified and never quietly edited. Built for the conversations you have with regulators.

verify_audit_chainintact ✓
chaingenesis #1 → tip, witnessed
Ask

Your AI assistant already speaks to it

Every contract, metric and audit event is exposed over MCP, the open protocol AI assistants use. Data quality stops being the dashboard someone opens on Tuesdays and becomes a question anyone can ask, mid-conversation, and a check any agent can run before it writes.

“What failed in the customer contract last week?”
→ 220 records would have been blocked. Top rule:
  balance_non_negative (112). Want the audit rows?
Built for your regulation

Your regulation is a data contract.

Most data quality problems are a regulation wearing a disguise. 41 starter contracts ship with every trial — each one starts in observation mode, counting what would have failed, until you choose to enforce it. The rule counts below are real: every chip is a rule you can read, edit, or delete on day one — they are starting points you own, not a black box we maintain for you.

No code needed to start. Drop a CSV in the dashboard and get a gap report you can hand to the board — venue by venue, product by product, record by record. Your allergen master, your premises register, last month's rejected submissions — before you write a single rule or plumb a single pipeline.

Natasha's Law (PPDS)

A wrong allergen flag should never reach a label. The starter contract makes all 14 allergen declarations impossible to omit and checks each one against the reference lists you control — blocked before the record enters, with sealed evidence of your due diligence.

contains_glutencontains_celeryingredients_text_required+42 more

Martyn's Law

Drop your venue and training spreadsheets in and get a site-by-site gap report against all 63 rules — including the enhanced-duty fields: the designated senior individual, SIA notification, documented public protection procedures. Then enforce: records that cannot be saved incomplete, and when the inspector asks how you know, the sealed audit trail.

staff_training_completedcapacity_minimumlockdown_procedure_documented_valid+60 more

MiFID II

LEIs check-digit-verified (ISO 17442 mod-97), ISINs validated, timestamps and cross-field mismatches caught before the report leaves the building — replay last month's rejected file through it in observation mode and count what the ARM would have bounced.

reporting_firm_lei_validinstrument_isin_validtrade_date_matches_execution_date+33 more

DORA

An ICT incident register that is correct as it is written — not repaired the week before the audit.

incident_id_uniqueentity_type_required+28 more

GDPR

Processing records and DSAR requests validated at the door, with every accept and block decision on the sealed chain.

lawful_basis_validprocessing_purpose_required+58 more

NHS DSP Toolkit

Patient-record fields validated at write time — NHS numbers checksum-checked, not just present — and the evidence of it sealed for your DSP Toolkit return.

nhs_number_validdate_of_birth_format+14 more

Also in the catalogue: SOX control tests, HIPAA disclosure accounting, Companies House filings, Ofgem & Ofwat meter readings, the building-safety golden thread, telecoms CDRs, insurance claims, clinical trials — and the contracts you write for the rules only your business has. Read every contract, rule by rule, before you sign up →

How it works

Contract in, evidence out

From signup to your first validated record is about two minutes. The sequence below is the whole product.

STEP 01

Write what “valid” means

A contract is plain YAML, readable by your engineers, your auditors, and your AI. Start from 41 starters or write your own.

# mifid_transaction_report.yaml — starter, 36 rules rules: - field: reporting_firm_lei type: checksum # ISO 17442 mod-97 check digit - field: instrument_isin type: checksum - rule: trade_date_matches_execution_date # or start as simple as email_format
STEP 02

Put the engine in the write path

Call it from your pipeline over HTTPS, or let your AI assistant call it over MCP. Same engine, same contracts, same audit trail.

Not a developer? Drop a CSV in the dashboard instead and read the results — and keep doing it. A weekly spreadsheet run through the same rules lands the same sealed evidence; CSV-in, evidence-out is a supported way to run, not training wheels. The pipeline plumbing can come whenever it earns its keep.

curl -X POST \ https://<your-engine>/api/v1/validate \ -d @record.json # → valid: false, rules: [...]
STEP 03

Promote with evidence

Watch observation counts on live traffic, then flip the contract to enforcement: one deliberate action, recorded on the chain like everything else.

contract: customer_profile mode: observation enforcement # 7-day evidence: 220 would-block # promoted by: you, on the record
Built on an open standard

Your contracts are portable by construction

OpenDQV Core is the MIT-licensed open-source project that defines the contract format. OpenDQV Cloud runs those same contracts on a managed engine, so the rules you write here run anywhere the standard runs.

If you leave, your YAML goes with you. That is the point of a standard, and the reason you can adopt one without asking permission first.

Plainly: the contract format is open source; the Cloud engine is commercial software. The openness is your exit path, and we won't blur that line.

OpenDQV Core on GitHub →

the portability promise
contracts  → plain YAML, exportable any time
audit log  → exportable any time, API or dashboard
records    → in memory; never in audit, backups, or logs
lock-in    → none by design
Pricing you can read

The prices on the page
are the prices

Metered on engine uptime, like the compute you already buy. No sales call at any self-serve tier. No minimum commitment, no termination fee.

Trial
Free

14 days or 200 ODUs, whichever comes first. One XS engine, every feature that runs on it. No credit card.

Start free trial
Standard
£5 / ODU + VAT

Pay for the engine while it is running. Per-second billing, 60-second minimum per start. Stop the engine and the meter stops. Sizes XS (1 ODU/hr) and S (2 ODU/hr).

Upgrade in-product
Enterprise
£8 / ODU + VAT

Same uptime billing, engine sizes to L — each size meters ODUs at its vCPU count (M 4 · L 8 ODU/hr) — SSO (OpenID Connect), 365-day audit retention, continuous-run pinning, direct support.

Upgrade in-product
VPS
from £13 / ODU · POA

Everything in Enterprise, on your own substrate, inside your own network. This one is a conversation, the only one.

Talk to the founder

One ODU = one vCPU-hour of engine uptime. A size meters at its vCPU count: XS 1 · S 2 · M 4 · L 8 ODU/hr. Observation mode costs the same as enforcement: the meter is the engine being on, not what you ask of it. Worked example: an XS engine (1 vCPU) on UK office hours is ≈ 2,100 ODUs a year — about £10,500/yr on Standard or £16,800/yr on Enterprise; running 24/7 it is £43,800 / £70,080 — and a nightly batch window is a small fraction of the office-hours figure. Auto-stop means idle time costs nothing. Trial → Standard → Enterprise is entirely self-serve.

Put the bouncer on the door

Your first validated record,
about two minutes from now.

Signup → engine provisioned → sample validated. Tell us what breaks; the founder reads every reply.

Start free trial
Questions

Get to know OpenDQV Cloud

What is a data contract?
A plain-YAML statement of what “valid” means for a dataset, field by field and rule by rule. Contracts are versioned, auditable, human-readable, and yours: author them in the dashboard, in YAML, or let your AI assistant draft one.
What happens to the records I validate?
They are processed in memory and never stored in your audit trail, backups, or logs. Only the decision is recorded: pass, would-block, or blocked, with rule names and hashes. Your records keep living in your systems — OpenDQV Cloud is the gate and the evidence, not the database. Full detail in the Privacy Policy and DPA.
Where does my validation data live?
The records you validate are never stored, so there is nothing of them to live anywhere. The validation metadata that is recorded, your audit trail, lives in the cloud region you select at signup (AWS, Azure, or Google Cloud; UK, EU, or US today) and never anywhere else. The region is your choice and it is fixed for the life of your account.
You look small. How do I get comfortable trusting you?
By checking, not believing. The company is a UK limited company (details in the footer); the Terms, Privacy Policy and DPA are published, not "available on request". Traffic is TLS in transit and encrypted at rest on all three clouds; every decision lands on the tamper-evident chain; a software bill of materials is available on request. And the continuity answer is structural, not a promise: your contracts are portable YAML on an MIT-licensed open format — if we vanished tomorrow, your rules and your evidence leave with you. We publish no uptime SLA at self-serve tiers; what you get instead is honest availability behaviour, documented below.
What happens if the engine is asleep when a call arrives?
The engine stops itself when idle — that is the auto-stop that makes the pricing work — so the honest availability story is a wake, not an outage: the first call to a sleeping engine gets a clear try-again answer with a Retry-After header, the engine wakes in about 15 seconds, and the retry succeeds. No call is ever silently passed through unvalidated — our recipes hold the write and retry. Beneath that, the control plane runs on Cloudflare's global edge and every engine runs on AWS, Azure, or Google Cloud in the region you chose — the substrate's availability is theirs, and we inherit it rather than pretending to exceed it. What is ours is the wake, and the honest answer while it happens. And a record that fails validation is never an error — that is the product working.
Can I gate writes into Salesforce or another SaaS?
Yes — three ways, and we are honest about each. Guided entry (the New-record path) can be gated synchronously with a Screen Flow calling OpenDQV Cloud as an External Service — declarative, no code, and we publish the OpenAPI file Salesforce imports to build it. Integration and bulk volume gates in your middleware or API layer before the upsert. Whatever is born inside the platform itself — inline edits, third-party packages — is validated seconds after commit via the change feed and quarantined, because no external service can synchronously intercept a SaaS platform's own save path, and we won't pretend otherwise.
How does it fit Databricks, Snowflake, or a Python pipeline?
Your pipeline code is the door, so it gates cleanly: call the batch endpoint (up to 10,000 records per call) on each chunk before you write — a mapPartitions step in Spark, a pre-load step in your loader, one HTTP step in your orchestrator — then land the passes and quarantine the blocks. Copy-paste snippets for Python, Node, curl, Apex, Salesforce Flow, and dbt are in the dashboard, and inspection tools you already run sit alongside untouched. Full per-platform recipes, readable before signup: the Connect page.
Can my AI assistant use it?
Yes, natively. Every contract, metric, audit event and validation is exposed over MCP, the open protocol MCP-compatible assistants speak. Connect once and “what failed last week?” is a sentence, not a dashboard safari.
Does this actually improve my data quality?
Yes, and that is the point. Quality improves at the source, when the people and systems producing data get fast, specific feedback. The gate gives every producer an immediate answer: which record, which rule, why. Observation mode measures the problem on real traffic, you tighten the contract, the reject rate falls, and only then do you enforce. Dashboards that nobody acts on don't improve anything; a feedback loop does.
What does it cost to try?
Nothing. The trial is 14 days or 200 ODUs, whichever comes first, with no credit card. After that, Standard is £5 per ODU — one vCPU-hour of engine uptime (+ VAT) — metered per second, and the engine stops itself when idle.