Data quality for applied AI

Working answer

Data work starts with a model: objects, identifiers, master data, sources, quality rules and correction owners. Integration transports a record; it does not make that record unambiguous or trustworthy by itself. For this task, the initial evidence is “one measure has multiple values”, and the decision boundary concerns errors, corrections and the quality log.

The practical focus is data lineage, quality, accountability and management use. A decision is ready for approval when the object, owner, baseline, permitted action and outcome evidence are explicit; the reference object in this article is sources and transformations.

Applied analysis: Data quality for applied AI

For “Data quality for applied AI”, define the management boundary first. It includes master data and classifications, authority to decide and a document that establishes the current state.

Diagnostic evidence for “master data changes without an owner” must be reproducible. Another participant should use the same source and agreed rule to reach a comparable conclusion.

Completion is supported by evidence for sources and transformations. If the data population or calculation method changes, create a new comparison baseline instead of revising the previous outcome retrospectively.

• Working object: Errors, corrections and the quality log.
• Diagnostic signal: One measure has multiple values.
• Response action: Maintain lineage and versions.
• Controlled risk: Measuring quality without a correction process.

Process and data boundary

Describe the boundary through object records rather than system names. For errors, corrections and the quality log, record meaning, identifier, source, quality owner and update event; for master data and classifications, also document the relationship rule.

Test the link between errors, corrections and the quality log and master data and classifications using an end-to-end example. The team performs “assign systems of record”, traces transformations and identifies where a discrepancy arises, who corrects it and which dependent outputs are recalculated.

• Record 1. Object: Master data and classifications. Required details: identifier, lineage, quality rule and update event. Signal: Users cannot see where a number came from.
• Control record 2. Object: Sources and transformations. Observable signal: Master data changes without an owner. Accountability: semantic owner and quality owner.
• Boundary 3. Object: Data marts and semantic models. Define the source, frequency, permitted transformations and response to “a dashboard does not lead to action”.

Events, data and exchange

An integration design begins not with arrows between applications but with events and accountability. It defines who creates a record, where it becomes authoritative, which checks run before transfer, how duplicates are handled and which action is blocked when records disagree. The reference object here is master data and classifications.

Every exchange has a business owner, technical owner and observable control point. API, messaging, file transfer or another technology is selected after frequency, volume, resilience and error behaviour are known. For the signal “one measure has multiple values”, quality is assessed before transfer and after loading so that the origin of a discrepancy can be located.

• Subject area 5: Errors, corrections and the quality log. Verification basis: system of record, owner authority and the signal “one measure has multiple values”.
• Object 4: Measures and thresholds. Record fields: source, semantic owner, quality owner and refresh rule. Control signal: Errors are corrected only manually.
• Boundary 3. Object: Data marts and semantic models. Define the source, frequency, permitted transformations and response to “a dashboard does not lead to action”.

Accountability boundary

The article addresses “Data quality for applied AI”. The adjacent management issue is sources and transformations. The two may share data or participants while differing in decision horizon, role authority and architecture boundary, so they are documented as separate entries in the decision map.

A signal–risk–action chain defines the subject-specific focus. Here the signal is “master data changes without an owner”, the material risk is “measuring quality without a correction process”, and the testable action is “assign systems of record”. This chain turns a broad term into a concrete decision.

• Decision 1: object — master data and classifications; signal — errors are corrected only manually; action — maintain lineage and versions.
• Decision 2: object — sources and transformations; signal — one measure has multiple values; action — identify key objects.
• Decision 3: object — data marts and semantic models; signal — users cannot see where a number came from; action — assign systems of record.

Quality and correction rules

For master data and classifications, the sequence begins with “maintain lineage and versions”. The owner of the next step reviews its output; an incomplete result is returned with a specific issue concerning data, a rule, authority or an architecture dependency.

Maintain an assumptions log for master data and classifications. Each entry states its basis, owner, review date and the event after which it must be confirmed, changed or closed.

• 1. Action: identify key objects; verifiable result: sources and transformations.
• Decision 2: assign systems of record. The basis for the next step is data marts and semantic models.
• Step 3. Align identifiers and master data. Output: measures and thresholds.
• Define checks and corrections is the action at stage 4. The output documents errors, corrections and the quality log.

Signals in the starting situation

The work starts with an observable situation, not with interface selection. The diagnostic signal for this article is: one measure has multiple values. It should be supported by a real example such as a document, data sample, decision record or registered variance.

The first scope is limited to one object and one decision. Changing every process, master-data set and system at once obscures causality. For the signal “master data changes without an owner”, a representative boundary is a period, business unit or transaction class where the situation can be tested again.

• Diagnostic signal 1: One measure has multiple values. Its record contains an example and impact on sources and transformations.
• Management signal 2: Users cannot see where a number came from. Use condition: a link to an actual example and to data marts and semantic models.
• Diagnosis records “master data changes without an owner”, its recurrence and its impact on measures and thresholds.

Who makes the decision

For sources and transformations, the role model determines more than screen access. In the action “maintain lineage and versions”, it identifies who changes a rule, authorises an exception, accepts risk and confirms the outcome. The accountability matrix is tied to decisions and artefacts rather than abstract departmental participation.

A business–IT disagreement is resolved by the decision owner using agreed evidence. The architect does not replace the business owner, and the project manager does not define the meaning of a measure. For sources and transformations, this separation is especially important because of the risk “treating an anomaly as a proven fact”.

• Business owner: authority is linked to sources and transformations, and participation is tied to “align identifiers and master data”.
• In the decision matrix, architect connects data marts and semantic models with the action “define checks and corrections”.
• Data owner: decision area — measures and thresholds; control action — maintain lineage and versions.
• Project manager is accountable for errors, corrections and the quality log and confirms the action “identify key objects”.

Acceptance criteria

Verification of sources and transformations starts with the baseline. The sample, period, calculation rule, known exceptions and interpretation owner are preserved. After the change, the same scenario is repeated under comparable conditions; a new method or data population is documented as a separate version.

A functioning feature is not yet acceptance evidence. A user must receive the signal “one measure has multiple values” from the agreed source, understand its lineage, make an authorised decision, execute the action through the working environment and observe confirmed actuals for errors, corrections and the quality log.

• 1. Acceptance object: master data and classifications; compare the baseline sample, expected change and confirmed actuals. Test signal: A dashboard does not lead to action.
• Evidence item 2 describes sources and transformations, comparable test conditions and the person accountable for interpretation. Signal: Errors are corrected only manually.
• Test 3 concerns data marts and semantic models. The method, interpretation owner and outcome source are documented. Signal: One measure has multiple values.
• Control record 4: Measures and thresholds; data version, calculation rule, expected change and actual outcome. Signal: Users cannot see where a number came from.

What can distort the outcome

The risk map starts with two conditions: “measuring quality without a correction process” and “treating an anomaly as a proven fact”. Each receives an observable event, decision owner, control and outcome that requires a stop or rollback.

Every assumption has an owner, supporting evidence and a review event. The risk “treating an anomaly as a proven fact” needs particular control here because its status affects the scope, delivery sequence and acceptance criterion.

• Controlled constraint: one data mart without shared meaning. The owner performs “assign systems of record” and provides measures and thresholds.
• For the risk “measuring quality without a correction process”, assign the action “align identifiers and master data” and evidence “errors, corrections and the quality log” in advance.
• Risk review starts with the condition “self-service without a metric catalogue”. The decision uses the action “define checks and corrections” and data about master data and classifications.
• Risk record 4. Condition: Treating an anomaly as a proven fact. Control action: Maintain lineage and versions. Evidence source: Sources and transformations.

Where to begin

The first session examines one real case involving errors, corrections and the quality log. Participants bring a source document or sample, data-flow diagram, current procedure and an example of “one measure has multiple values”.

The session ends with a decision on the next format rather than a wish list. Assign an owner and due date to “maintain lineage and versions”; assign an additional test or stop condition to the risk “treating an anomaly as a proven fact”.

• 1. Action: identify key objects; verifiable result: sources and transformations.
• Decision 2: assign systems of record. The basis for the next step is data marts and semantic models.
• Control record 4: Measures and thresholds; data version, calculation rule, expected change and actual outcome. Signal: Users cannot see where a number came from.
• Criterion 5 uses errors, corrections and the quality log; the result is compared with the baseline using one method. Signal: Master data changes without an owner.