Lineage and impact

How Lineage Supports AMS Root-Cause Analysis After Go-Live

By Dzmitryi Kharlanau · Published · 22 min read

A production incident arrives in the AMS queue:

Contents

Reviewed: 14 July 2026

A production incident arrives in the AMS queue:

Supplier cannot be paid.

The ticket contains:

The first assumption is that the migrated bank account is wrong.

An analyst checks the Business Partner and finds:

The bank-data migration appears correct.

Further investigation shows that the Supplier has no permitted Payment Method for the relevant Company Code.

The operational symptom was a failed payment.

The affected Supplier contained bank data.

The root cause belonged to another business Attribute and another part of the model.

Without governed lineage, the analyst may:

With lineage, the investigation can move through a structured path:

Payment failure
→ Supplier and Company Code context
→ payment-control Attributes
→ SAP endpoints
→ source Mappings
→ cutover evidence
→ affected population
Root-cause analysis in AMS should connect an operational symptom to the smallest governed model condition that explains it.

This is not the same as identifying the first technical error message.

It is not the same as finding the first blank field.

It is not the same as locating the last interface that failed.

A production incident may originate in:

Lineage helps the team distinguish these possibilities before changing production data.

---

AMS receives symptoms, not model objects

Business users do not report:

ATTR-SUPPLIER-COMPANY-CODE-PAYMENT-METHOD is missing.

They report:

The Supplier cannot be paid.

They do not report:

The Product Plant extension has no valid MRP Type Mapping.

They report:

MRP did not create the expected purchase requisition.

They do not report:

Payer partner-function lineage is incorrect for Sales Organisation 2200.

They report:

The invoice went to the wrong company.

The AMS process must translate symptoms into model questions.

A useful first step is:

business symptom
→ process step
→ business object
→ organisational context
→ candidate Attributes

Only then should the team descend into:

The technical layer matters.

Starting there too early creates a wide search with weak business context.

---

Root cause is not the same as the failing component

An interface can fail because:

The interface is where the failure appeared.

It may not be where the defect originated.

Similarly, an SAP validation can block a transaction because:

Root-cause analysis needs a dependency path.

Without it, teams confuse:

failure location

with:

defect origin

---

Three layers of AMS investigation

A lineage-based investigation can separate three layers.

Business symptom

What failed in operational language?

Examples:

Operational evidence

What was observed?

Examples:

Canonical model

What should exist and how should it be produced?

Examples:

The investigation compares operational evidence with the canonical model.

The model should not be changed simply because production differs.

The difference may be an implementation defect.

---

Begin with the exact business context

An incident becomes actionable when its context is precise.

For a Supplier payment issue, collect:

For a Product planning issue:

For a Customer billing issue:

The same central object may behave correctly in one context and fail in another.

A Supplier can be valid centrally and unusable in one Company Code.

A Product can exist globally and lack a Plant extension.

A Customer can have the correct Payer in one Sales Area and the wrong one elsewhere.

Root-cause analysis without organisational context produces false conclusions.

---

Example 1: Supplier payment failure

Symptom

A payment proposal excludes a Supplier.

First hypothesis

Bank data is missing.

Operational observation

Canonical lineage

legacy payment instruction
+
Company Code
→ Payment Method Mapping
→ Supplier Company Code Payment Method
→ payment process

Root cause

The migration source contained one central payment instruction.

The target required Company Code-specific Payment Method assignment.

The Mapping did not cover one acquired Company Code.

Corrective action

Incorrect corrective action

Changing bank details because the incident was raised as a payment problem.

The value of lineage is not only faster diagnosis.

It prevents damage caused by fixing the wrong Attribute.

---

Correct one record or correct the model?

AMS teams must distinguish two questions:

How do we restore service for this record?

and:

Why could this defect occur, and which other records are exposed?

The first may require an immediate data correction.

The second may require:

Closing the incident after correcting one record can leave the root cause active.

A lineage trace should identify the model path shared by similar records.

---

Example 2: Product not planned

Symptom

A Product is not included correctly in material planning.

Operational observation

Approved path

legacy planning method
+
Plant
→ plant-specific conversion
→ Product Plant MRP Type

Production path

The Product belonged to a Plant missing from the conversion table.

A cutover default assigned ND.

Immediate correction

Change the affected Product Plant MRP Type after business approval.

Root-cause action

The incident is not merely “wrong MRP Type.”

It is evidence that a temporary fallback remained operational after its intended period.

---

Fallbacks become AMS risk when their expiry is forgotten

Migration programmes often approve temporary paths:

During cutover, these may be necessary.

After go-live, they can become invisible technical debt.

The model should preserve:

AMS should be able to query:

Which active production values were created through temporary fallbacks?

Without this, support teams treat later incidents as isolated data errors.

---

Example 3: Invoice sent to the wrong Payer

Symptom

An invoice is associated with the wrong business partner.

First hypothesis

Customer master was replicated incorrectly.

Context

Approved lineage

legacy billing-account relationship
+
Sales Area
→ Payer partner-function Mapping
→ SAP Customer Sales Area partner assignment

Observed production state

The Sold-to Party was assigned as Payer through a self-partner fallback.

Root cause

The external Payer existed, but its number cross-reference was unavailable during cutover.

The fallback was applied to the full Sales Area rather than only unresolved records.

Impact

Correct response

Do not edit the central Customer identity.

Correct the Sales Area partner assignment and investigate the bounded population that used the fallback.

Lineage identifies the right Entity grain and prevents a central-data change from being used to correct an organisational relationship.

---

AMS needs both upstream and downstream trace

Upstream trace asks:

How did this value get here?

Downstream trace asks:

What uses this value?

Both matter during incident analysis.

For Product Base Unit:

source unit
→ canonical unit
→ SAP Product Base Unit
→ warehouse interface
→ inventory and delivery process

If the warehouse rejects PC and expects EA, the root cause may be:

Upstream trace tests whether PC was created correctly.

Downstream trace tests whether consumers interpret it correctly.

Changing the Product Base Unit to satisfy one interface may corrupt inventory semantics.

---

Example 4: Warehouse interface rejects a Product

Symptom

A warehouse message rejects a Product because unit PC is unknown.

Production data

SAP Product Base Unit is PC.

Migration evidence

The approved source Mapping correctly normalised source PCS to canonical PC.

Interface evidence

The warehouse contract expects EA.

Root cause

Missing outbound interface conversion.

Corrective action

Add or correct interface code conversion.

Model consequence

The canonical Product Base Unit remains unchanged.

This is a strong example of lineage preventing a bad master-data correction.

The failing downstream system should not automatically redefine the governed Attribute.

---

Root cause can belong to a Rule

Some incidents occur because data is present but control behaviour is wrong.

Example:

Supplier became active without a required tax identifier.

Possible causes:

The lineage path includes:

Tax Identifier Attribute
→ requiredness Rule
→ implementation control
→ lifecycle event
→ observed activation

A field trace alone cannot explain the incident.

AMS needs Rule lineage.

---

Example 5: Tax-compliance failure

Symptom

A Supplier invoice is rejected because the tax identifier is stored under the wrong category.

Production state

A tax number is present.

Initial dashboard status

Tax-number completeness: 100 percent.

Canonical model

country
+
tax-number type
+
identifier
→ category Mapping
→ SAP Business Partner tax number

Root cause

The migration used a generic category for a country requiring a specific category.

Consequence

AMS action

The incident demonstrates why completeness is not correctness.

---

Root-cause scope should expand from one record to one path

A single incident can reveal:

AMS should expand scope progressively.

Level 1: record

Is this one record wrong?

Level 2: context

Are records in the same Plant, Company Code or Sales Area affected?

Level 3: Mapping

Did the same transformation create similar values?

Level 4: source

Does one source system or extract contain the defect?

Level 5: model

Is the business definition, Rule or authority decision incomplete?

Do not begin by assuming a global model defect.

Do not stop after correcting one record.

---

Lineage helps calculate the probable blast radius

Suppose one Cost Centre cannot accept a posting.

The trace identifies:

source validity dates
→ Cost Centre Mapping
→ SAP Cost Centre
→ internal orders and postings

The support team can search for records sharing:

This produces a more defensible affected population than:

Check all Cost Centres.

---

Example 6: Cost Centre posting blocked

Symptom

Posting fails on the first business day after go-live.

Production observation

Cost Centre exists.

Its valid-from date begins one month later.

Approved design

Validity should cover the go-live period.

Runtime evidence

The cutover file used source dates without the approved go-live adjustment.

Root cause classification

Implementation or cutover execution drift.

Immediate fix

Correct the affected validity interval after Finance approval.

Broader check

Identify all Cost Centres from the same load batch whose valid-from date excludes go-live.

Canonical model change

Possibly none.

The approved Mapping may already be correct.

The implementation failed to apply it.

This distinction matters.

Changing the model to match the defective execution would institutionalise the problem.

---

Approved design versus observed execution

A mature AMS investigation compares:

Approved path

What should have happened.

Implemented path

What configuration or code was intended to execute.

Observed path

What data and logs indicate actually happened.

Production outcome

How the business process behaved.

OpenLineage’s object model separates stable Jobs and Datasets from individual Runs, while column-level lineage distinguishes direct value derivation from indirect dependencies such as joins, filters and conditional logic. That separation is useful for comparing a declared model with a particular execution rather than treating runtime behaviour as permanent truth.

For Martenweave, the canonical model holds the approved path.

Operational platforms and incident evidence describe the observed path.

---

Do not make Martenweave the monitoring system

AMS already uses tools for:

Martenweave should not duplicate these systems.

Its role is to connect their evidence to model truth.

The division is:

Monitoring system:
what failed and when

ITSM:
who owns the incident and its service status

Martenweave:
which governed model path explains the data dependency

This keeps the product focused.

Integrations bring input.

Martenweave stores model truth.

Validators check consistency.

AI proposes changes.

Humans approve.

---

Incident evidence should be attached to a claim

A screenshot or log file is not enough.

The model should record what the evidence supports.

Examples:

Claim:
Payment Method is absent for Company Code 3100.
Claim:
Product Plant MRP Type was created through expired fallback MAP-MRP-DEFAULT-001.
Claim:
Payer partner assignment differs from the approved Sales Area Mapping.
Claim:
Cost Centre validity from the production record does not match cutover baseline.

This makes the evidence reusable in later investigations.

---

Example 7: Purchasing block appears unexpectedly

Symptom

Purchase-order creation is blocked for a Supplier.

Initial interpretation

Supplier is centrally blocked.

Lineage context

A Supplier can have:

Production observation

The block exists only for Purchasing Organisation P100.

Upstream path

local procurement status
+
Purchasing Organisation
→ purchasing-block Mapping
→ Supplier purchasing data

Root cause

A local source status code was interpreted as an active purchasing block after the source process had already cleared it.

Response

Again, organisational context narrows both correction and impact.

---

Root cause can be historical model drift

After go-live, the landscape continues changing.

Examples:

The canonical repository may become stale if these changes are not recorded.

An incident can therefore reveal:

production is correct
but model is outdated

or:

model is correct
but production drifted

AMS needs to distinguish the two.

---

Example 8: Custom field retirement

Symptom

A report shows blank Supplier Review Status.

Landscape change

A standard SAP field replaced the former custom field.

Production state

New field is populated.

Report implementation

Still reads the retired custom field.

Canonical model

If correctly maintained, it should show:

Supplier Review Status
→ current standard endpoint

retired custom endpoint
→ historical implementation

Root cause

Downstream report was not migrated.

Correct response

Update the report.

Do not repopulate the retired custom field merely to satisfy the report.

Without endpoint history and downstream impact, AMS may recreate obsolete data structures.

---

Known workaround versus root-cause correction

AMS teams often need a workaround.

A workaround restores service.

A corrective action removes the cause.

Example:

Incident

Product does not plan.

Workaround

Manually set MRP Type to PD.

Corrective action

Complete the Plant-specific conversion and correct all affected Product Plant records.

The incident record should distinguish:

service-restoration action

from:

model or implementation correction

Otherwise, repeated manual fixes appear to be successful problem resolution.

---

Repeated incidents should form a pattern

One missing Profit Centre may be a data error.

Fifty similar incidents in one Plant indicate a Mapping or source problem.

The model can group incidents by:

This creates an AMS knowledge layer based on governed identities rather than ticket keywords.

---

Example 9: Profit Centre incidents

Suppose several tickets report incorrect financial responsibility for Products.

The shared path is:

Product Family
+
Plant
→ Profit Centre derivation
→ Product Plant Profit Centre

Incident clustering shows:

The root cause is not a collection of unrelated Product errors.

It is an expired fallback policy.

The corrective action should include:

---

Problem records should reference canonical objects

An ITSM problem record can remain in the existing service-management system.

It should reference stable model IDs such as:

ATTR-PRODUCT-PLANT-PROFIT-CENTRE
MAP-PRODUCT-PROFIT-CENTRE-DERIVATION
RULE-PROFIT-CENTRE-REQUIRED
FEP-S4-PRODUCT-PLANT-PROFIT-CENTRE

This allows:

The incident system owns service-management state.

The model registry owns model identity and approved meaning.

---

Root-cause categories

A practical classification for data-related AMS problems can include:

Source defect

The authoritative source contains an incorrect or missing value.

Source-authority defect

The wrong source was selected.

Mapping defect

Transformation or applicability is incorrect.

Key or grain defect

The value was attached to the wrong record or organisational level.

Rule defect

The intended control is incorrect or incomplete.

Rule-implementation defect

The canonical Rule is correct, but implementation differs.

Target-configuration defect

SAP cannot store or process the intended result correctly.

Interface defect

Downstream or upstream conversion is wrong.

Execution defect

The approved design did not execute as expected.

Fallback defect

A temporary or approximate path was used incorrectly.

Model-documentation drift

Production changed legitimately, but the canonical model was not updated.

Isolated record defect

One record differs without evidence of a systemic path problem.

This classification helps route the problem to the correct owner.

---

Root-cause confidence

Not every investigation reaches certainty immediately.

Use statuses such as:

Confirmed

Evidence directly supports the cause.

Probable

The path and pattern strongly support the cause, but one verification remains.

Possible

The object is connected, but evidence is incomplete.

Rejected

The hypothesis was tested and disproved.

Unknown

No defensible cause has been established.

This is better than recording the first plausible explanation as fact.

---

Negative findings are valuable

Suppose an analyst proves:

Supplier bank data is not the cause of the payment failure.

That conclusion should be retained.

Otherwise, the next incident may repeat the same investigation.

Negative knowledge can state:

Bank Account path:
verified

Payment Method path:
nonconformant

A good model registry preserves both the root cause and important rejected hypotheses.

---

Example 10: Delivery scheduling error

Symptom

Deliveries are planned on an unexpected date.

Candidate causes

Lineage investigation

The unloading point migrated correctly.

The relevant receiving calendar was not connected to the ship-to context.

Root cause

Incomplete relationship and contextual assignment, not an incorrect unloading-point text.

Correction

The business symptom involved scheduling.

The root cause belonged to relationship lineage.

---

Relationships matter as much as fields

Many AMS incidents come from incorrect relationships:

A field can be correct.

Its attachment to the wrong Entity or context can still cause failure.

Lineage needs Entity and Relationship objects, not only FieldEndpoints.

---

Time is part of the root cause

Effective dates can explain incidents that look like missing data.

Examples:

A trace should support:

What was the approved path on the date of the incident?

Current-state lineage alone may produce the wrong answer for historical incidents.

---

Model baseline and production change history

A defensible investigation should identify:

The team can then compare:

model at approval
vs.
implementation at deployment
vs.
data at incident time

This helps isolate whether the defect entered through:

---

AMS changes can create new drift

An urgent correction may solve an incident and create inconsistency.

Examples:

Therefore, post-incident review should ask:

Did the workaround change model behaviour?

When yes, create a PatchProposal or ChangeRequest.

Do not let emergency support changes become undocumented governance.

---

AI in AMS root-cause analysis

AI can assist with:

AI should not autonomously:

A connected object is a hypothesis candidate.

It is not automatically the cause.

Recent research on automated cloud root-cause analysis continues to show the difficulty of reliable autonomous diagnosis, including failures from incomplete exploration and hallucinated interpretation. This reinforces the need for evidence-bound analysis and human confirmation rather than unconstrained agent conclusions.

---

Root cause is not graph centrality

The node with the most connections is not necessarily the cause.

A central Business Partner Attribute may appear in many paths.

A small local conversion table may contain the actual defect.

Similarly:

Lineage narrows the investigation.

Evidence establishes causality.

---

A practical AMS investigation workflow

1. Capture the symptom

Use business language and concrete transaction context.

2. Identify the object and organisational grain

Supplier Company Code, Product Plant, Customer Sales Area, Cost Centre in Controlling Area.

3. Locate candidate Attributes and Relationships

Do not begin only from tables.

4. Trace upstream

Identify source, Mapping, fallback, Rule and migration evidence.

5. Trace downstream

Identify process, interface, report and affected consumers.

6. Compare approved and observed state

Find differences in values, path, versions and context.

7. Test hypotheses

Preserve confirmed and rejected hypotheses.

8. Calculate affected population

Use shared Mapping, source, context, fallback or load batch.

9. Restore service

Apply bounded operational correction where necessary.

10. Decide whether the model must change

Create a proposal only when the approved model is incomplete or wrong.

11. Add prevention

Validation, test, monitoring, source remediation or fallback expiry.

12. Preserve evidence

Link problem record, Finding, Decision and accepted correction.

---

Root-cause brief

A concise AMS brief can contain:

Symptom:
Product not planned in Plant PL30.

Affected concept:
Product Plant MRP Type.

Expected path:
Planner method + Plant → approved conversion → SAP MRP Type.

Observed state:
Fallback ND used because PL30 conversion was missing.

Root cause:
Expired fallback and incomplete plant-specific Mapping.

Affected population:
1,140 Product Plant records.

Immediate action:
Correct priority Products.

Systemic action:
Add PL30 conversion and remove expired fallback.

Evidence:
Cutover run, production profile and planning failure.

Owners:
Production Planning Data Owner and Plant PL30 lead.

This is more useful than a collection of screenshots and SQL results.

---

Root-cause evidence requirements

A confirmed model-related root cause should ideally identify:

Not every low-priority incident requires the full package.

Recurring, high-impact and governance-related incidents do.

---

Verification after correction

A fix is not complete when the error disappears for one record.

Verification should check:

For a Mapping defect, verify another representative population.

For a Rule defect, test positive, negative and exception scenarios.

For an interface defect, verify both payload and business outcome.

---

AMS metrics derived from lineage

Useful metrics include:

These metrics show model health more clearly than raw ticket volume alone.

---

Incident volume does not equal model importance

A frequently used Attribute may generate many low-severity tickets.

A rarely changed tax or bank Attribute may generate one severe incident.

Prioritisation should include:

The model graph supplies context.

The service process supplies urgency and impact.

---

What Martenweave should implement next

Martenweave currently provides the relevant foundation:

The next useful vertical slice should be an incident-to-model investigation workflow.

Goal

Turn an AMS symptom into a bounded, evidence-backed model investigation without turning Martenweave into an ITSM platform.

Scope

Given an incident note or ticket export:

Acceptance criteria

For a Supplier payment incident, the workflow must distinguish:

bank-account issue

from:

Company Code Payment Method issue

For a Product planning incident, it must distinguish:

Product missing

from:

Product Plant planning Attribute incorrect

For a warehouse unit error, it must distinguish:

canonical Product Base Unit defect

from:

outbound interface conversion defect

For a retired custom field, it must distinguish:

missing production data

from:

downstream consumer still reading historical endpoint

Existing commands

martenweave search "MRP Controller" --repo ./model

martenweave trace \
  ATTR-PRODUCT-PLANT-MRP-CONTROLLER \
  --repo ./model

martenweave impact \
  FEP-S4-PRODUCT-PLANT-MRP-CONTROLLER \
  --repo ./model

Future focused operation

martenweave investigate \
  --from ./incidents/INC-10482.md \
  --repo ./model

The investigate command describes a recommended product direction rather than the current documented CLI contract.

---

Final perspective

AMS root-cause analysis becomes difficult when model knowledge is scattered across:

Lineage does not replace technical investigation.

It gives the investigation a governed structure.

The useful path is:

business symptom
→ operational context
→ business Attribute or Relationship
→ expected lineage
→ observed production state
→ divergence
→ affected population
→ corrective action

The practical test is:

Can the AMS team explain why this Supplier could not be paid, why this Product was not planned, why this invoice used the wrong Payer or why this Cost Centre rejected a posting—and determine whether the cause is isolated, systemic, technical or model-related?

When the answer is yes, lineage is supporting operations rather than remaining migration documentation.

When the answer is:

We corrected the field and closed the ticket,

the service may be restored while the root cause remains active.

About the authors

Martenweave is maintained by Dzmitryi Kharlanau.

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

It connects model truth, lineage, impact, evidence, Decisions and reviewable proposals so that support incidents can be investigated against an explicit model rather than reconstructed from scattered documents.

Martenweave Workbench is a local browser interface for assessment, investigation, reports and controlled changes. It reads through the local API and does not store canonical model truth independently of the model files.

Sources and notes

This article was reviewed on 14 July 2026.

Martenweave Core currently uses canonical model files as the source of truth, disposable generated indexes, deterministic validation and proposal-first AI-assisted changes. Its documented pipeline includes evidence import, gap detection, lineage, impact analysis and human review.

The current Martenweave CLI exposes health, scorecard, trace, impact, search, query, repository diff and dataset-readiness operations. These provide the foundation for incident-oriented investigation without requiring Martenweave to replace existing monitoring or service-management tools.

OpenLineage’s object model separates stable Jobs and Datasets from individual runtime Runs, while its column-level lineage model distinguishes direct transformations from indirect dependencies such as joins, filters and conditional logic. These distinctions are useful when comparing approved model paths with the execution evidence associated with one production incident.

The incident-to-model workflow, root-cause categories and proposed investigate command described in this article are recommended Martenweave improvements. They should not be interpreted as guarantees of the current canonical schema, Workbench behaviour or CLI unless separately implemented and published.

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

Primary sources

Related articles