Specification
Mappings as an executable rulebook, validated against real data.
SQACE turns business mappings into a versioned, executable rulebook and validates them against a real data example before the data pipeline is built.
30 minutes, on your own use case.
The problem
Mappings are described in Excel, then never validated.
Every data pipeline begins with a mapping specification. The usual form is Excel: source field, target field, comment. Because that form is static and produces no calculation, business experts cannot check whether the mapping actually produces the correct result for real input data.
Pipeline development then begins from a specification that has not yet been hardened against data. The first iterations only surface after the initial implementation, which costs effort and time and erodes trust.
The SQACE solution
Specification as an executable rulebook.
In SQACE, mappings are described as executable rulebooks. Business experts formulate the logic in a business language, without SQL or Python skills. SQACE computes the rules on real input data and shows the expected result per record.
This produces a mapping specification that is not just documented, but validated. That validated specification becomes the basis for the later pipeline implementation, and at the same time the test reference for verification.
Where this sits: this use case starts before the pipeline is built, when the specification is created and validated. Release verification later uses the same rulebook as the test reference, before a finished pipeline goes live.
Scenarios
Where teams validate mappings with SQACE.
Specify business mappings for ETL/ELT pipelines
Mapping rules are defined, computed against input data and signed off with the business, all before the data pipeline is built.
Describe valuation, tax and risk logic as rules
Logic is broken down into individual, checkable rules. Each rule is documented traceably and verifiable in the audit.
Validate the mapping on a concrete input-output example
Business experts see immediately how the rule computes on real data. Corrections are made directly in the rulebook, not in an Excel appendix.
In concrete terms
- Mapping validation on the concrete result, not just on the text.
- Business expert acceptance from the start, because the result becomes visible.
- Rulebooks as a reusable test reference for the later data pipeline.
At a glance
| Specification form | SQACE rulebook | Excel / pseudo-code |
|---|---|---|
| Expressiveness | Executable | Static |
| Validatability | Automatic on a data example | Manual |
| Audit fitness | Direct | Limited |
| Reuse | Test reference for the pipeline | Document with no link to the test |
Compliance
Compliance evidence as a by-product.
Supervisory data-quality requirements, such as BCBS 239 (principles 3 and 4), call for documented and traceable calculation logic. MaRisk AT and BAIT/VAIT require the separation of specification and implementation. SQACE rulebooks are specification and executable evidence in one artifact, without dissolving that separation.
How rulebooks are versioned and handed over is described in Security & architecture.
FAQ
Frequently asked questions
Do business experts have to program?
No. The rule language is readable for business experts. Complex functions are modeled by SQACE consultants where needed.
How does SQACE relate to tools like Erwin or Solidatus?
Modeling tools describe data flows at the structural level. SQACE describes business logic at the data level and executes it. The two tools complement each other.
What data volumes make sense for mapping validation?
For validation, several thousand to a few hundred thousand records are usually enough. Full-population runs are possible.
Does the rulebook become the actual pipeline?
No. It is specification and test reference. The data pipeline is built separately, usually in the existing ETL/ELT tool. SQACE then verifies the pipeline against the rulebook.
Can existing Excel mappings be adopted?
Yes. The rules are migrated and validated step by step, usually with consultant support.
How is the rulebook handed over to development teams?
As an artifact with example records, expected results and an audit trail. Development teams work against the same reference as the later verification.