Rule studio & profiling
Quality rules belong in the hands of the people who know the data. In rule studio your stewards write rules in plain language or SQL, profile the data first so the rule targets how it actually behaves, and simulate against history before anything runs live. Deployment is maker-checker, enforced by the platform, and the approval is sealed on the ledger.
Plain-language authoring compiles to SQL you can inspect, so stewards write the rule and engineers can still read exactly what will run.
Profiling comes before writing. You see null rates, ranges, and value distributions on the actual columns, so rules aim at real behavior instead of assumptions.
Simulation against recent history shows which rows would have failed and how often, so you tune thresholds before the first alert instead of after the hundredth.
Maker-checker approval runs through the one decision door. Nobody deploys their own rule, and the approval is sealed on the hash-chained ledger.
Rules are bound to datasets and CDEs on the knowledge graph, so a rule and its results appear in the lineage of every report the field feeds.
Checks run where your data lives through the platform's connectors. Only metadata and results come back, and nothing is copied out.
Profile
The studio profiles the dataset first, so you see nulls, ranges, and distributions before you write a line.
Write
You express the rule in plain language or SQL. Either way, the compiled check is readable and reviewable.
Simulate
You run the rule against history, see exactly what it would have flagged, and adjust before it goes live.
Approve
A second person reviews and approves through the decision door, and the deployment is sealed on the ledger.
“Can my stewards write and test rules without filing engineering tickets?”
They can. Stewards author rules in plain language or SQL, profile the columns first, and simulate against history, all inside the studio. Engineers stay in the loop because the compiled SQL is there for anyone to inspect.
“Who approved this rule, and what evidence did they see when they did?”
Every rule goes through maker-checker approval, so a second person reviewed the compiled check and the simulation results before deployment. That approval is sealed on the hash-chained ledger alongside the rule itself.
“Can I see what this rule would have caught last quarter before I switch it on?”
You can. Simulation runs the rule against recent history and shows exactly which rows would have failed and how often, so you tune thresholds before the first live alert.
Start with proof, not a promise.
There are three ways in, and each one earns the next. You approve the exit criteria before we spend any more of your time or budget.
A 60-minute working session
Bring one report that is expensive to prove. We walk the mechanism against it. Nothing is required from your side.
A two-week guided sandbox
Your team works hands-on against a synthetic sample bank. It requires zero access to your systems and zero procurement.
A six-week proof on your systems
We use read-only metadata across five systems and one priority report, scored against criteria both sides sign first. The decision it produces is yours.