Lineage and impact

How Impact Analysis Should Work for Rules, Mappings and Value Lists

By Dzmitryi Kharlanau · Published · 20 min read

A team proposes three changes:

Contents

Reviewed: 14 July 2026

A team proposes three changes:

  1. Customer Group should become mandatory before Sales Area activation.
  2. CRM Segment should no longer map directly to Customer Group.
  3. Value 01 in the Customer Group list should be replaced with STANDARD.

All three changes concern the same business Attribute.

They do not create the same impact.

The Rule change affects when records can progress.

The Mapping change affects how values are produced.

The value-list change affects which codes are valid and how existing data is interpreted.

A generic dependency graph may return many of the same connected objects:

But the reason each object is affected differs.

That difference determines:

Impact analysis should follow the semantics of the change, not merely the object’s position in a graph.

Martenweave’s current core already treats Rules and Mappings as first-class model objects alongside Attributes, Relationships, datasets, evidence, Decisions and change proposals. It validates references before building generated indexes and exposes lineage, impact and diff operations over the canonical model.

The next step is to make impact propagation sensitive to object type.

A Rule does not propagate change like a Mapping.

A Mapping does not propagate change like a value-list entry.

---

Three objects, three kinds of dependency

A Rule answers:

Under which conditions must something be true?

A Mapping answers:

How does one representation become another?

A value list answers:

Which governed values may represent the Attribute?

These objects often connect to the same Attribute:

ATTR-CUSTOMER-GROUP
├── governed by RULE-CUSTOMER-GROUP-REQUIRED
├── populated by MAP-CRM-SEGMENT-TO-CUSTOMER-GROUP
└── constrained by VALUE-LIST-CUSTOMER-GROUP

Their downstream effects are different.

Rule dependency

A Rule affects:

Mapping dependency

A Mapping affects:

Value-list dependency

A value list affects:

A useful impact engine needs separate propagation policies for each.

---

Begin with an explicit change operation

The object ID alone is not enough.

Consider:

RULE-CUSTOMER-GROUP-REQUIRED

Possible changes include:

Each produces a different blast radius.

A PatchProposal should therefore describe the operation.

Conceptually:

object_id: RULE-CUSTOMER-GROUP-REQUIRED
operation: change
changes:
  severity:
    before: warning
    after: error
  lifecycle_stage:
    before: creation
    after: activation

Impact should be calculated from the changed properties, not only from the object identity.

The same applies to Mappings:

object_id: MAP-CRM-SEGMENT-TO-CUSTOMER-GROUP
changes:
  strategy:
    before: direct
    after: conditional_enrichment

and value lists:

object_id: VALUE-LIST-CUSTOMER-GROUP
operation: replace_value
value:
  before: "01"
  after: "STANDARD"

---

Rule impact begins with behaviour

A Rule change is behavioural.

The first question is:

What records, lifecycle stages or decisions would behave differently after the change?

This is more useful than:

Which objects are connected to the Rule?

Suppose:

Before:
Customer Group missing → warning

After:
Customer Group missing → error

The Attribute and field remain unchanged.

The source Mapping may remain unchanged.

The effect appears when records are evaluated.

Potential consequences include:

The impact engine should classify this as a control-strength change.

---

Rule-change classes

A practical taxonomy can distinguish several forms.

Severity change

information → warning
warning → error
error → warning

Impact areas:

Applicability change

global → strategic suppliers only
Germany → Germany and Austria
Customer → Customer Sales Area

Impact areas:

Lifecycle-stage change

creation → activation
activation → distribution

Impact areas:

Expression change

Country = PT
→ Country in [PT, ES]

Impact areas:

Exception change

temporary default allowed
→ default prohibited

Impact areas:

Rule retirement

Impact areas:

The change class determines which relationship types should be traversed first.

---

A stricter Rule may not require a Mapping change

Consider:

Rule:
Customer Group is mandatory before activation.

Mapping:
CRM Segment plus Sales Area derives Customer Group.

Changing the Rule from warning to error does not necessarily alter the Mapping.

The Mapping still produces the same value.

However, source readiness becomes more critical.

The Mapping should appear in the impact report as:

Review required:
Mapping must produce sufficient coverage under the stricter Rule.

not:

Mapping must be changed.

This distinction matters.

Impact analysis should identify review obligation, not assume remediation.

---

Rule impact must include affected population

The same Rule can have radically different impact depending on scope.

Example A:

Applies to:
12 strategic suppliers

Example B:

Applies to:
all active suppliers

The graph topology may be identical.

The operational impact is not.

A Rule-impact report should state:

Where actual record counts are unavailable, the report should state that population impact is unknown rather than assign false precision.

---

Rule impact reaches implementation controls

The canonical Rule may be implemented through:

The impact engine should traverse:

Canonical Rule
→ implementation references
→ tests
→ operational procedures

Changing the Rule’s meaning may require every implementation to change.

Changing only one implementation does not necessarily change the canonical Rule.

That distinction exposes drift.

---

Rule impact reaches Evidence

Existing Evidence may verify the previous Rule.

For example:

EVID-MOCK-LOAD3-CUSTOMER-GROUP

Verified:
missing value produced warning

After severity changes to error, that Evidence remains historically valid.

It no longer proves the candidate behaviour.

The impact result should classify it:

Historical evidence:
valid for previous Rule state

New verification:
required

Do not delete or relabel old evidence as though it tested the new Rule.

---

Rule impact reaches local overrides

A global Rule may have contextual overrides.

Global:
Tax Identifier required before activation.

Portugal:
approved exemption with legal evidence.

Legacy migration:
temporary warning until Wave 3.

When the global Rule changes, every override needs reassessment.

Possible outcomes:

This should be a dedicated impact path:

Global Rule changed
→ review all active overrides

Local overrides must not disappear inside a generic neighbour list.

---

Mapping impact begins with the value path

A Mapping change is a lineage change.

The first question is:

How will the target value be produced differently?

Suppose:

Before:
CRM Segment → Customer Group

After:
CRM Segment + Sales Area → Customer Group

The target Attribute remains the same.

The target SAP field may remain the same.

But the transformation now requires:

The impact propagates upstream and downstream.

---

Mapping-change classes

Source replacement

ERP_A field → CRM field

Impact:

Source addition

CRM Segment
→ CRM Segment + Sales Area

Impact:

Target replacement

custom SAP field → standard SAP field

Impact:

Strategy change

direct → lookup
direct → enrichment
default → blocking gap
manual → automated

Impact:

Applicability change

all customers → acquired-company customers only

Impact:

Value-conversion change

A → 01
A → 02

Impact:

Mapping retirement

Impact:

---

Direct and indirect inputs require different impact logic

A Mapping may use several fields.

CRM Segment:
direct value input

Sales Organisation:
conditional lookup input

Customer Status:
filter input

If CRM Segment changes, the target value itself may change.

If Sales Organisation changes, the lookup route may change.

If Customer Status changes, the included population may change.

OpenLineage’s column-level lineage model distinguishes direct derivation from indirect influence, including conditional, join and filter dependencies. This is useful for deciding how an input-field change propagates through a Mapping.

Martenweave should preserve this distinction in Mapping impact:

Value derivation affected
Conditional selection affected
Population affected

rather than one generic upstream field changed warning.

---

Mapping impact must inspect alternative paths

One Attribute may have several Mappings.

CRM population:
MAP-CRM-CUSTOMER-GROUP

ERP_A population:
MAP-ERP-A-CUSTOMER-GROUP

Missing source:
MAP-MANUAL-CUSTOMER-GROUP

Changing one Mapping may:

The impact engine should examine the Mapping set around the Attribute.

Questions include:

---

Mapping impact reaches source datasets

When a Mapping gains another input field, all relevant datasets should be checked.

Example:

New required context:
Distribution Channel

Affected artefacts may include:

Martenweave’s dataset-readiness workflow can compare observed datasets with model expectations and turn gaps into reports, proposals or issue drafts.

A Mapping proposal should trigger readiness analysis against the candidate input requirements.

---

Mapping impact reaches the target population

Changing a Mapping does not affect every target record equally.

The impact report should estimate or classify:

A useful summary might say:

Affected population:
ERP_B customers without Sales Area context

Estimated consequence:
Customer Group no longer derivable

Fallback:
manual enrichment

Readiness:
blocked for Wave 3

That is more actionable than a list of connected datasets.

---

Mapping impact reaches reconciliation

Existing reconciliation may assume:

source value count
=
target value count

A new enrichment or split changes that expectation.

Reconciliation may need to compare:

The Mapping change should therefore impact:

---

Value-list impact begins with identity and meaning

A value list is often treated as static reference data.

It is part of the model.

A value has at least:

Consider:

code: 01
label: Standard

Possible changes include:

These are not equivalent.

---

Label change

Standard Customer
→ Standard

Potential impact:

Usually no data conversion is required if the code and meaning remain stable.

The impact should be classified as editorial or presentation-related.

---

Code change

01
→ STANDARD

Potential impact:

The meaning may remain stable.

The implementation contract changes.

This is often a breaking physical change.

---

Meaning change under the same code

01 previously meant:
Standard Customer

01 now means:
Default Customer Group for incomplete records

This is more dangerous than a code change.

Systems may continue processing 01 successfully while users interpret it differently.

Impact includes:

The value should usually not be silently redefined.

A new value or explicit temporal version may be safer.

---

Value addition

Adding:

DIGITAL_ONLY

may appear non-breaking.

Potential impact includes:

Compatibility must be assessed per consumer.

An SAP field may accept the new code while a downstream interface rejects it.

---

Value retirement

Retiring:

UNDER_REVIEW

requires several questions:

Retirement is not deletion.

The old value may remain necessary for historical interpretation.

---

Value split

Suppose:

OTHER

is replaced by:

TEMPORARY
UNCLASSIFIED
OUT_OF_SCOPE

Impact includes:

A deterministic conversion may not exist.

The impact report should mark records requiring judgement.

---

Value merge

Suppose:

LOW
STANDARD

become:

NON_CRITICAL

Impact includes:

The change may be technically easy and analytically irreversible.

---

Applicability change for one value

A value may remain valid globally but become prohibited in one context.

Example:

Customer Group 01:
allowed globally

New Rule:
not allowed for Sales Organisation 2000

This change crosses value-list and Rule impact.

The impact engine should identify:

---

Value-list impact reaches Mappings in both directions

Mappings may translate:

source code → canonical value
canonical value → SAP code
SAP code → interface code

Changing the canonical value list can affect all three layers.

Example:

CRM A
→ canonical STANDARD
→ SAP 01
→ interface STD

Retiring STANDARD requires reviewing:

A value list should not be analysed only against its immediate Attribute.

---

Value-list impact reaches Rules

Rules may reference values explicitly:

if Customer Group = STRATEGIC
then Credit Review is required

Adding, changing or retiring values may make Rule expressions:

The impact engine should find:

Rule expression references value
Rule applicability excludes value
Rule default assumes value

This requires typed references where possible.

Free-text references should be detected cautiously and presented as candidates.

---

Rule and value-list changes can interact

Suppose a new value is added:

UNDER_REVIEW

and a Rule says:

Customer Group must be one of:
STANDARD
STRATEGIC
HIGH_VALUE

The Attribute technically accepts the new value.

The Rule rejects it.

The candidate model is inconsistent.

Prospective validation should detect this before merge.

---

Mapping and value-list changes can interact

Suppose a Mapping still produces:

01

but the target value list now permits only:

STANDARD
STRATEGIC

The Mapping becomes invalid.

The impact engine should identify:

Mapping output no longer belongs to target value domain.

This is stronger than saying both objects changed.

It identifies an actual candidate-state contradiction.

---

Rule and Mapping changes can interact

Suppose the Rule becomes stricter:

Customer Group required before activation.

At the same time, the Mapping removes a default.

This may be the correct design.

Operationally, it can increase blocked records sharply.

The combined impact is larger than either isolated change.

A proposal-aware engine should evaluate the complete candidate patch rather than analyse each operation independently.

---

Compound change impact

Real releases often contain several connected changes.

Example:

  1. retire UNDER_REVIEW from Supplier Risk;
  2. create Supplier Review Status;
  3. split the old Mapping;
  4. add lifecycle Rules;
  5. add a new SAP endpoint.

The correct impact is not the union of five unrelated lists.

It is a model transition:

Old overloaded concept
→ two governed Attributes
→ two Mappings
→ two target endpoints
→ separate Rules

The report should describe:

---

Candidate-state validation is essential

Current-state impact answers:

What is connected now?

Candidate-state validation answers:

Will the proposed Rules, Mappings and values form a coherent model?

Conceptually:

current repository
+
PatchProposal
=
candidate repository

Then run:

Martenweave’s proposal-first principle is designed for this: AI or automation creates a PatchProposal; validators verify it; humans approve before canonical mutation.

---

Existing records must be part of impact

A model can be internally valid after a change while existing records become invalid.

Examples:

The impact report should distinguish:

Model impact:
references and semantics

Data impact:
existing records and datasets

Implementation impact:
systems and controls

Martenweave should reference profiling or migration evidence rather than store every production record.

---

Prospective versus retrospective effect

A change may apply only to future records.

Or it may require correcting historical data.

Example:

New Supplier Risk value:
applies from 1 October

Possible policies:

The impact report must ask:

Without temporal scope, “affected records” is ambiguous.

---

Implementation locations

Rules, Mappings and value lists may be implemented in several places.

Rules

Mappings

Value lists

Impact should traverse implementation references without assuming that one technology is authoritative for the business model.

---

Design lineage and runtime evidence

A canonical Mapping may declare a dependency.

Runtime evidence may show which path actually executed.

OpenLineage distinguishes design-time metadata from runtime Job Run observations and models field-level transformations, including direct and indirect dependencies.

For Martenweave, this suggests a useful separation:

Canonical Rule or Mapping:
approved intended behaviour

Runtime Evidence:
observed execution or result

Impact can be refined by runtime evidence:

But runtime behaviour should not silently redefine canonical truth.

---

Impact confidence

Each impact result should state why it appears.

Confirmed

A typed direct dependency is incompatible with the proposed change.

Strong review

The object depends on the changed concept but compatibility requires testing.

Possible

The connection is transitive, inferred or context-dependent.

Historical

The relationship applies only to previous baselines.

Excluded

The object was reviewed and shown unaffected.

This classification should be accompanied by the path.

---

Path-aware output

Weak result:

Affected:
RULE-001
MAP-004
VALUE-07
INTERFACE-002

Stronger result:

MAP-004
produces value 01
for ATTR-CUSTOMER-GROUP

VALUE-01
is retired by the proposal

Therefore:
MAP-004 output becomes invalid

Another example:

RULE-001
blocks activation when Customer Group is missing

MAP-004
removes the previous default

Therefore:
records without a source value may newly fail activation

The path and reasoning turn graph traversal into impact analysis.

---

Suggested impact report structure

Change summary

Candidate-state validation

Rule impact

Mapping impact

Value-list impact

Compound effects

Required reviewers

Verification plan

---

A worked example: making Customer Group mandatory

Proposal

RULE-CUSTOMER-GROUP-REQUIRED

Before:
warning at activation

After:
error at activation

Direct impact

Mapping review

Dataset review

Operational review

Unchanged

The report should not claim that all connected Mappings must change.

It should state that their coverage must be proven under the stricter control.

---

A worked example: replacing a direct Mapping

Proposal

Before:
CRM Segment → Customer Group

After:
CRM Segment + Sales Area → contextual enrichment

Direct impact

Indirect impact

Rule impact

The existing mandatory Rule may now block more records.

Value-list impact

The target list is unchanged.

The conversion table may still require new combinations.

Target impact

KNVV-KDGRP remains the same.

This is a lineage change without a physical target change.

---

A worked example: retiring UNDER_REVIEW

Current state

Attribute:
Supplier Risk

Value:
UNDER_REVIEW

Candidate state

Supplier Risk:
LOW
STANDARD
HIGH

Supplier Review Status:
PENDING
CLEARED
REJECTED

Value-list impact

Mapping impact

Rule impact

Implementation impact

This is a semantic decomposition, not a simple value deletion.

---

A worked example: renaming code 01

Proposal A

Code remains:
01

Label:
Standard Customer → Standard

Likely impact:

Proposal B

Code:
01 → STANDARD

Meaning unchanged

Likely impact:

Proposal C

Code remains:
01

Meaning changes:
Standard → Temporary Default

Likely impact:

The textual size of the change does not indicate its impact.

---

Test planning from impact paths

Impact results should produce a test plan.

Rule tests

Mapping tests

Value-list tests

Compound tests

Testing should follow the model transition, not just the changed code.

---

Ownership and review routing

Different change types require different reviewers.

ChangePrimary reviewer
Rule meaningSemantic owner
Rule implementationSAP or control owner
Mapping sourceSource and migration owners
Mapping targetSAP target owner
Value meaningBusiness data owner
Value codeIntegration and implementation owners
Historical conversionMigration and reporting owners
Local applicabilityLocal data owner

The impact report should produce a review matrix automatically where ownership metadata exists.

---

Release-gate conditions

A candidate change should be blocked when:

Warnings may remain for:

---

Avoid a universal impact score

A single number such as:

Impact score: 82

can help sort work.

It should not become the explanation.

Two changes may receive the same score for different reasons:

The report should expose dimensions:

Semantic impact:
high

Data conversion:
medium

Implementation spread:
high

Population:
low

Reversibility:
medium

Evidence confidence:
high

---

What AI can contribute

AI can help:

It should not decide autonomously:

The deterministic engine should establish exact references and candidate-state contradictions.

Humans decide business compatibility.

---

A focused Martenweave implementation slice

Martenweave already has the required foundation:

The next vertical slice should add typed candidate-state impact policies.

Goal

Evaluate proposed changes differently for Rules, Mappings and value lists.

Scope

Support:

Acceptance criteria

The engine must detect:

  1. Mapping produces a retired value.
  2. Rule references a removed value.
  3. New mandatory Rule has no complete Mapping path.
  4. Mapping adds a source field absent from the dataset.
  5. Local override conflicts with changed global Rule.
  6. Historical Evidence refers to the previous state without being invalidated.

Validation command

martenweave validate --repo examples/customer_bp_model

Existing analysis commands

martenweave impact FEP-S4-KNVV-KDGRP \
  --repo examples/customer_bp_model

martenweave diff \
  examples/customer_bp_model \
  examples/customer_bp_model_candidate

Future proposal-aware operation

martenweave impact \
  --proposal PATCH-CUSTOMER-GROUP-CONTROL-CHANGE \
  --repo examples/customer_bp_model

The last command describes a recommended product direction rather than current guaranteed CLI behaviour.

---

Final perspective

Rules, Mappings and value lists are closely connected.

They are not interchangeable.

A Rule determines whether a value is acceptable or required.

A Mapping determines how the value is produced.

A value list determines which representations are governed as valid.

Changing one can invalidate the others.

The impact engine must therefore reason across the complete triangle:

Rule
↕
Business Attribute
↕
Mapping
↔
Value List

and then continue into:

datasets
SAP fields
interfaces
reports
tests
Decisions
Evidence
local overrides

The practical test is:

Before approving a change, can the programme determine which records will behave differently, which Mappings will become incomplete, which values will become invalid, which implementations must change and which historical results must remain interpretable?

When the answer is yes, impact analysis supports governed change.

When the answer is only:

These objects are connected in the graph,

the system has lineage, but it has not yet explained the consequences.

About the authors

Martenweave is maintained by Dzmitryi Kharlanau.

Martenweave is a backend-first model-governance and evidence layer for SAP migration, MDM, data governance and AMS teams.

It treats Rules, Mappings, values, Attributes, physical fields, datasets, Decisions and Evidence as typed canonical objects so that proposed changes can be validated before they alter approved model truth.

The objective is not to predict every business consequence automatically.

It is to expose enough structured consequence that accountable people know what must be reviewed.

Sources and notes

This article was reviewed on 14 July 2026.

Martenweave Core currently represents generic data-model objects including Attributes, Relationships, datasets, Mappings, Rules, Evidence, Decisions and change proposals. It validates references before building generated lineage and impact indexes and requires human approval for proposed changes.

The current pipeline imports or profiles evidence, validates canonical files, builds generated indexes, detects model and dataset gaps, runs lineage and impact analysis and then routes proposals through human review.

OpenLineage’s current column-lineage specification models which input fields produce output fields and distinguishes direct value derivation from indirect influence. It classifies direct identity, transformation and aggregation dependencies and indirect join, grouping, filtering, sorting, window and conditional dependencies.

OpenLineage’s object model distinguishes design-time lineage metadata from runtime Job Run observations. This is useful for separating approved Rule or Mapping intent from evidence about how a particular implementation actually executed.

The value-list object model, typed change policies and proposal-aware impact command described here are recommended Martenweave directions. They should not be treated as guarantees of the exact current schema or CLI unless separately published and versioned.

Martenweave is independent and is not affiliated with or endorsed by SAP or OpenLineage.

Primary sources

Related articles