Validate as You Build
Most databases give you two bad options for data quality. Either you enforce every rule on every write — and the moment your data is half-loaded, the database fights you — or you enforce nothing and discover the broken records later, in production.
WWKG gives you a third option. You define what good data looks like once, as validation rules. Then where you are working decides how strict those rules are:
- On a staging branch — a workspace branch you create to load a big dataset, run an import job, or let an AI agent work — the rules warn instead of blocking. Every save tells you exactly what is not valid yet, but nothing stops you from finishing.
- On your production branch, the same rules are enforced. A change that breaks a rule is rejected.
Why this matters
Real data work happens in steps. You upload hundreds of files. You run an overnight ETL job. You fill in a record across several screens. An agent makes a multi-step change. In every case the data is supposed to be incomplete while you are working — references point to things you have not loaded yet, required fields are still empty.
A database that rejects every interim step makes that work impossible. WWKG lets the work proceed on a staging branch and shows you, after every save, how close you are to valid. A user interface can show a red “not valid yet” badge that turns green as you go. An AI agent can keep working until everything checks out.
The guarantee
Here is the part that makes it safe: the rules that warn you on your staging branch are the same rules that protect your production branch.
So when your staging branch finally shows zero warnings, you can merge it into production knowing the merge will pass. There is no surprise rejection at the finish line — you already saw, on your last save, that everything is valid. Validation stops being a gate you hope to clear and becomes a guide you follow to a guaranteed-clean merge.
Defining a rule
A validation rule names the shapes (the data-quality definitions) it enforces and which parts of your data they cover:
You can also point a rule at one specific named graph, so different parts of your data can have different rules.
Shapes use the W3C SHACL language — the standard way to describe constraints like “every Person must have a name,” “an age must be a non-negative integer,” or “an email must match this pattern.”
Choosing how strict a branch is
By default, a staging branch warns and a production branch enforces — you usually do not have to configure anything. If you want different behaviour, a branch’s mode is overridable: you can make a staging branch strict, or let a long-lived working branch stay lenient.