How SQACE tests whether the processing computed the right result.
Processing rarely crashes. It returns a number that looks plausible and is still wrong. On this page you follow a single example from start to finish: from the input through a business rule to a classified deviation. This is how SQACE works on any processing.
We verify the result, not just whether the data looks good, and not just whether nothing changed.
SQACE
Verifies whether the processing produced the correct business result, through a rule-based expected/actual comparison.
DQ monitoring
Shows whether the data looks plausible. It does not answer whether the processing computed the right result.
Regression testing
Shows whether something changed against the last run. It will not catch an error that was in the logic from the start.
DQ monitoring and regression testing stay useful. SQACE works one level above: did the processing compute the right result?
Four steps, from rule to deviation.
Step 1, input
Read the input data from the source
SQACE reads the input fields from the source, here over Oracle JDBC: the interest income, the tax rate and the exemption from master data. The same values the production pipeline processed.
Step 2, rule
The business rule in the visual builder
The business team assembles the rule in the Rule Editor, block by block, without SQL. A condition (IF) and a calculation (THEN), built from the fields in the source and validated against real data before it runs in production.
The business owns the correctness rule and proves it, without anyone decoding SQL. What is correct is defined by the person who is accountable for it, visible in the Rule Editor on the right. With “Validate against real data” the rule can be checked against real values on the spot, and IT sees the same readable logic, not a query it would first have to translate back.
Fields from the source
Oracle JDBC, read-only
- interest_income Amount, input field
- tax_rate Rate, input field
- exemption Rate, master data
a partial exemption is recorded for the position in master data.
Readable in words; the formula below is just the second notation. SQACE computes the expected value from exactly this rule, with no SQL query to decode.
Expected is the second, rule-based calculation. Classified as a calculation-rule deviation in the capital gains tax field, tracked across runs.
Step 3, expected/actual
The second calculation set against the actual
SQACE recomputes the expected value from the rule along a second path, separate from the pipeline, and sets it against the pipeline’s actual, row by row. Interest income and tax rate match. On the tax amount, expected and actual diverge.
Step 4, verdict
The deviation, down to field and rule
The verdict does not stop at red or green. It names the field (capital gains tax), the rule that produced it and the number of positions checked. In the actual run the exemption was not applied, a logic error that looks plausible and that a glance at the data alone would not reveal.
Deviation across runs
Seen in 3 of 12 runs reviewed, every time in the same class: rounding / calculation-rule deviation on the exemption.
Illustrative run history, synthetic values. This is how SQACE summarizes a deviation across several runs and assigns it a class.
Four action types, freely chained.
A test is built from a few building blocks, the actions. They combine and can be reused. Start without SQL, drop to SQL for edge cases, so experienced users are never capped.
Expected vs actual
Compare
Compare tables, XML and JSON at record, column and rule level. With tolerances and severities, across hundreds of thousands of records.
Rules, not eyeballing
Validate
Check value ranges, mandatory fields, relationships and business rules. Defined without SQL, run directly inside the test.
Easy Query
Query
Query and prepare data from multiple sources block by block, with join suggestions. SQACE turns it into inspectable SQL.
One workflow
Chain
Chain read, prepare, compare, validate and write into one workflow by drag and drop, with no code.
The verification authority sits outside the stack.
The second calculation does not run inside the pipeline it is meant to check. SQACE reads the results and recomputes the expected value along a separate path, from your rule set, independent of tool and method. What gets checked is the observable result, not the good intentions of the system that produced it.
This matters more as more processing is built with AI: whoever built the pipeline is not the right authority to confirm that it computed the right result. Syntactically correct code does not mean a logically correct result.
Why separate
- Your own rule set, not the logic that is under suspicion.
- Read-only access to the result, no intervention in the run.
- Independent of tool, method and the AI that built the pipeline.
Around 80 percent of processing is checkable by rule.
In our experience a large share of data processing, around 80 percent, can be covered by the rule-based expected/actual approach: wherever the correct result can be derived from input data and business rules. That is a statement about coverage, not about effort reduction. For the remaining cases, regression tests and targeted validations stay the right tool.
From the ad-hoc run to an automated suite.
The same test grows with you. What you validated ad hoc runs scheduled or from your CI/CD pipeline, with no rebuild. Through the Launch Pad, test suites are parametrized and run.
Validate ad hoc
Manual
Start a run directly, check the result in the dashboard and adjust the rule. Try, run, adjust in one session.
Recurring
Scheduled
Run the same test as a scheduled suite, parametrized and comparable after every release, with no rebuild.
Over the REST API
CI/CD
Trigger suites from Jenkins, GitLab CI, Azure DevOps or Camunda. Verdicts are written back to test management (Jira/Xray).
What teams ask before the first run.
No. Business rules are built in the visual Rule Editor and Easy Query, block by block, without SQL. An SQL action is available for edge cases, so experienced users are never capped.
SQACE recomputes the expected result from your input data and your business rules along a second path that is independent of the pipeline. That expected value is then set against the pipeline's actual output.
Down to the field and rule level. The verdict names the affected field, the rule that produced it and the number of positions checked. Every run is reproducible, versioned and recorded in the audit trail.
In our experience a large share of data processing, around 80 percent, can be covered by the rule-based approach. That is a statement about coverage, not about effort reduction.
See the expected/actual comparison on your data.
In a demo we work the example through on one of your use cases. Or start with a proof of concept on a single pipeline.