How AI Powers a Cross‑Domain Fund Lineage Graph for Loss‑Prevention

Abstract

AliExpress cross‑border e‑commerce flows span many services. A single monetary field can be read, transformed, and written under different names across applications. When code changes, four questions must be answered: where the field originates, where it flows, what the change impacts, and what reconciliation or control measures are needed. The AE Loss‑Prevention Platform builds an AI‑centric analysis pipeline that first assembles trustworthy facts from runtime call‑graphs, SQL templates, and a fund‑element registry, then uses a master‑slave multi‑agent workflow to trace reads, writes, and transformations across multiple repositories, persisting field‑flow edges and reconciliation pairs for downstream consumption.

Introduction

Financial‑safety problems appear as mis‑calculated amounts, inconsistent states, abnormal discount allocations, or upstream/downstream data mismatches. Two intertwined problem classes are identified:

In‑application accuracy problems : a code change causes an incorrect value within a single application; requires tracing field reads, processing, and writes.

Cross‑application consistency problems : upstream uses a taxable amount while downstream expects a net amount, or upstream changes generation rules but downstream risk checks still use old rules; requires linking database fields across applications, interfaces, and messages.

Resolving cross‑domain fund risk therefore needs a pipeline that (1) locates code differences, (2) confirms real cross‑application relations via runtime traces, (3) anchors funds to a unified database.table.column coordinate, and (4) enriches this with multi‑repo evidence before exposing the knowledge through deterministic graph queries for scenario recommendation and release gating.

Core Challenges

Cross‑repo link breaks : static analysis stops at remote calls or message queues; field names differ across services, making simple name matching unreliable.

Runtime topology lacks field semantics : distributed tracing shows service‑level calls but not column‑level operations such as copy, compute, aggregate, or conditional conversion.

Manual knowledge maintenance is unsustainable : expert‑maintained flow charts cannot keep pace with rapid code evolution.

Large‑model conclusions need factual constraints : feeding raw code diffs and large‑scale lineage to an LLM can produce hallucinations, overly long inputs, and inconsistent outputs.

Risk identification must be part of the change workflow : analysis results must be structured, explainable, and consumable by scenario recommendation and release‑gate rules.

Overall Design

The system follows a four‑layer architecture: knowledge production, stable consumption, change application, and human governance. Knowledge self‑evolution forms a feedback loop across the layers.

Knowledge Production Layer : assembles facts, performs cross‑repo evidence collection, and enriches field semantics.

Stable Consumption Layer : provides field source tracing, classification, impact‑graph expansion, and reconciliation‑level suggestions.

Change Application Layer : runs impact‑scope analysis, method‑level loss‑risk analysis, scenario recommendation, and release‑gate enforcement.

Human Governance Layer : auditors verify AI‑generated conclusions, discard erroneous edges, and supplement missing relationships.

Guiding principle: model discovers → evidence constrains → graph reuses → humans confirm → feedback evolves .

Detailed System Design

Cross‑Domain Fact Assembly

Entry‑driven runtime sub‑graph construction : start from an entry service, expand upstream and downstream call relations, and prune the graph with depth, fan‑out, and scan limits. Truncated or missing edges are explicitly marked.

SQL‑field and fund‑element anchoring : map call nodes to SQL templates and table columns, then match them against a fund‑element registry to produce a minimal trusted fact set, indicating which applications truly read/write which columns and which columns are confirmed fund elements.

Fact‑boundary constraints : the assembled wide‑table facts are the sole input for downstream AI agents; agents may infer relationships only within the supplied sub‑graph, preventing hallucinated edges.

Master‑Slave Multi‑Agent Cross‑Repo Field Analysis

Master agent orchestration : gathers snapshots from all applications, merges fund‑element instances, creates per‑repo analysis tasks, and aggregates evidence into cross‑application field pairs and multi‑stage flow paths.

Slave agents per repo : for a given field, trace interface/message entry points, method parameters, data‑object mappings, data‑access reads/writes, and all transformations (copy, compute, aggregate, conditional, format conversion). Return stage information and evidence references; uncertain relations become “to‑be‑clarified” items.

Cross‑repo semantic stitching : the master aligns upstream “order payable amount” with downstream “settlement base amount” when interface, object mapping, and SQL evidence close the loop, annotating the transformation type.

Multi‑source edge writing : edges may originate from AI inference, rule‑based mapping, runtime SQL, or human correction, each retaining source label, confidence, and evidence.

Field Source & Impact‑Scope

Bidirectional expansion : after receiving a database.table.column query, the service expands upward to locate origins and downward to locate consumers, with optional deeper expansion to avoid premature truncation.

Source classification : distinguishes table sources, cross‑domain processing entry points, and configuration leaves, reflecting real business semantics.

Processing type & reconciliation level : edges record copy, compute, conditional, aggregate, lookup, and format‑conversion types; complex paths raise the suggested reconciliation level, with reasons and impact paths provided.

Change‑Dual‑Task Intelligent Analysis

Impact‑scope analysis : starts from the actual code diff, locates changed files, methods, and DB fields, checks for fund‑element hits, pulls relevant upstream/downstream lineage summaries, and outputs affected fields, paths, scope, and evidence sources.

Loss‑risk analysis : examines each changed method for amount calculation, precision handling, conditional branches, idempotency, write range, upstream/downstream metric changes, and whether the method lies inside a fund‑field sub‑graph. Failures to fetch diff or lineage are reported explicitly.

Dual‑task summary merging : combines impact‑scope results (what is affected) with loss‑risk results (what could go wrong) into a unified change summary.

本次变更
├── 改动了哪些方法
├── 命中了哪些资金要素
├── 字段来源于哪里
├── 可能影响哪些下游
├── 存在方法级资损风险
└── 建议采用什么核对或布控措施

Scenario Recommendation, Release Gate, and Human Governance

Rich fund‑element injection : scenario‑recommendation agents receive the changed field together with its origin steps, multi‑source info, downstream consumption, processing type, reconciliation status, and code‑diff evidence, enabling distinction between intra‑app accuracy risk and cross‑app consistency risk.

Release gate : high‑risk changes require developer confirmation, reconciliation, or control measures before proceeding.

Human in the loop : auditors validate AI‑generated edges, discard or correct them, and the corrected knowledge immediately feeds back into source tracing and change analysis.

Knowledge Self‑Evolution Mechanism

Four update sources continuously evolve the graph:

Incremental discovery : new entry analyses, traffic spikes, or code changes add new edges, field pairs, and processing types.

Consumption feedback : tracing, impact analysis, and scenario recommendation expose missing or conflicting edges.

Human correction : developers and loss‑prevention engineers confirm, discard, or amend relationships.

Historical reuse : high‑confidence historical edges and repo mappings are preferentially reused, with versioned provenance retained; conflicts are flagged for human review.

Delivered Capabilities

Fund‑element governance : unified database.table.column coordinate, instance management, basic info, and reconciliation coverage.

Field source & impact‑scope : upward source lookup, downward consumer discovery, optional deeper expansion, source classification, and reconciliation‑level suggestions.

Stable snapshots are generated via rule‑based graph algorithms without invoking LLMs, guaranteeing repeatable results for high‑frequency queries.

Effect Comparison

Traditional workflow : manual code review and upstream/downstream inquiry → limited visibility of fund‑field impact.

After adopting cross‑domain lineage : direct view of fund‑field impact, precise method/field/path identification, pre‑release check suggestions → reduced manual effort and clearer, explainable risk.

Traditional : expert‑maintained flow charts → fragmented knowledge.

Cross‑domain : AI‑discovered field relations with multi‑downstream visibility and path‑based reconciliation advice → structured linkage of fund elements, scenario recommendation, and reconciliation control.

Traditional : duplicated analysis pipelines, scattered rules.

Cross‑domain : unified knowledge reused across tasks; deterministic graph serves high‑frequency queries while LLM focuses on complex semantics.

Current Limitations

Coverage gaps : caches and configuration‑based fund paths are not yet integrated; low‑traffic links may lack runtime evidence.

Quality assessment pending : AI may produce erroneous associations; processing‑type labeling accuracy needs improvement; method‑level read/write structuring and a quantitative evaluation framework are still under development.

Conclusion & Outlook

By coupling static code diffs with dynamic runtime facts, constraining AI inference within assembled wide‑table facts, and orchestrating master‑slave agents across repositories, the platform delivers a sustainable, self‑evolving cross‑domain fund knowledge graph. It answers the four essential questions for any change: where the field originates, where it flows, what the change impacts, and what reconciliation or control measures to apply.

Future work will expand coverage to caches and configuration items, refine field‑relationship and processing‑type detection, and strengthen the feedback loop between source tracing, reconciliation control, and release gating, moving from risk discovery toward precise recommendation and automated mitigation.