Context
Master data is the silent foundation of every process, and that is exactly why nobody notices when it slowly rots. A minimum order quantity that contradicts the rounding value, a supplier that in fact no longer exists: errors like these produce no error message, they produce wrong purchase orders, wrong reports and wrong results in every AI undertaking that builds on this data.
So far, checking is done by hand or with database queries that only IT can write. Every check applies to one system. Whatever does not match between two systems, nobody sees.
Approach
One central application that the systems where the data really lives can be connected to: SAP S/4HANA and SuccessFactors, SAP HANA, Salesforce, Databricks, Microsoft Fabric, files in AWS S3 or Azure, plus any REST interface. Whoever does not want to connect a system sends their data in through a push interface. The application reads, checks and reports. It never writes into the source systems.
AI is there in every step and decides alone in none.
What the application does
Connecting. Create connections and test them at the push of a button. Credentials are stored encrypted and are never readable again, not even for the assistant. Tables and files are read in automatically with their fields, with a preview of the real data.
Rules. 65 standard rules come with it: IBAN, VAT ID, postcodes, email, country codes, currencies, commercial register and more, bundled into eight business profiles such as address data or bank data. Four rule types cover the rest: mandatory field, format, allowed values, consistency between fields. 18 transformations clean up values before the check, for example whitespace, upper and lower case or leading zeros.
Finding rules. For every table the application proposes matching rules, in two stages: first by field type and description, then the AI reads the fields and gives its reasons for which rule fits what. Every assigned rule carries its origin, manual or AI proposal. The quality of the proposals is measured against a test model with target results, not asserted.
Phrasing rules. The assistant can be docked in every area and knows what is currently open. Whoever describes a rule in their own words gets a pattern, a rule type and parameters proposed from it. Where something is unclear, it asks back. Every change goes through a card in which all values are visible and editable, and is only saved on confirmation.
Checking. A check configuration bundles tables and fields and is released before it may run. It freezes fields and rules so that later changes do not distort old results. A run starts immediately, on demand or from outside through the push interface, processes the data in blocks and shows the progress live.
Result. From the run down to the single violation in five levels, with the checked value and the original value. One quality score per run, a dashboard with the score of the last seven days, a trend per table and a list of what needs attention.
Reporting. At the push of a button the AI writes the report on the run: conclusion, severity, findings with their cause (is it the data or the rule?), recommendations with priority. Every finding links to the affected records. Reports have versions, comments and a print view. The report names only what is in the result and reproduces no personal values.
Operation. Sign-in with the company account, three roles, a server-side filtered menu. Nothing is physically deleted. Every AI request is logged with model, tokens, cost and duration, evaluable by area and by day.
How it is built
The check engine deliberately works without AI: a rule decides the same way every time, on parallel worker processes, in blocks of 5,000 rows. The AI modules sit alongside it: finding rules, assistant, report. All three deliver proposals, never facts in the database.
| Component | Technology | Decision |
|---|---|---|
| Interface | React, TypeScript | One workspace per topic, the assistant docks on everywhere |
| Backend | SAP CAP, PostgreSQL | Thin services, business logic in domains, foreign systems only through the integration layer |
| Check engine | Node.js workers | Deterministic, block by block, two runs in parallel, crash protection via heartbeat |
| AI | Claude via Anthropic or AWS Bedrock | Switchable by configuration; Bedrock keeps the data in EU regions; cost logged per request |
| Connectors | OData, HANA, Salesforce, Databricks, Fabric, S3, Azure, REST | One adapter per system, read-only |
| Platform | SAP BTP | Sign-in, destinations, credential store and database from the platform |
Learnings
- Checking and understanding are two jobs. The engine checks, the same way every time. The AI explains why something violates a rule and what to do about it. Both in one module would have made both worse.
- Proposal with confirmation instead of automation. Because no AI module saves anything itself, it may have a say everywhere. The trust comes from the card, not from the model.
- AI costs belong in the product. Whoever sees every request with tokens and price decides differently about prompt length and caching than someone who gets the bill at the end of the month.
- Rule finding has to be measurable. Without target results, the claim that the AI finds the right rules is an assertion. With a test model it is a number.