How to Use Supply-Chain Data With an LLM Without Hallucinating Exposure
July 23, 2026
Altsets
Research by Altsets Research
Ground LLM and MCP research in directional relationship metrics, explicit missing values, dates, source layers, and evidence labels so conversational analysis does not invent precision.
Data used:Altsets Supply Chain Intelligence: 90k+ entities, 400k+ relationships, 20+ years of history.
Key findings
- The SK ecoplant to SK Hynix edge illustrates why an LLM must keep 36.49% supplier revenue exposure separate from 18.81% customer cost exposure rather than merging them into a generic dependency score.
- MCP can ground a model in external relationship data, but the model still needs explicit rules for missing metrics, direction, multi-hop percentages, dates, public context, and inference.
An LLM should not turn a known supply-chain relationship into a more precise claim than the underlying data supports. The supplied Altsets network gives a simple example. The SK ecoplant to SK Hynix relationship is quantified at 36.49% of SK ecoplant revenue and 18.81% of SK Hynix's cost base.
Other relationships in the supplied graphs are structural-only and do not carry the same percentage metrics. A grounded LLM workflow must preserve that difference. The model can reason over the data. It should not manufacture missing exposure.
The first rule is to preserve direction
Supplier revenue percentage and customer cost percentage describe different sides of a relationship. For SK ecoplant and SK Hynix, 36.49% describes how important the customer is to the supplier's revenue, while 18.81% describes how important the supplier is to the customer's cost base. Those numbers should not be swapped.
They also should not be averaged into a generic dependency score unless the methodology explicitly defines such a measure. Direction is part of the data.
The second rule is that missing is not zero
A structural relationship can still be useful. It can answer who is connected, which direction the edge runs, which companies belong in a network path, and which counterparties deserve follow-up research. It cannot answer economic magnitude when the relevant metric is absent.
An LLM that writes 0% because no metric was returned has changed missing information into false information. The missing-metrics guide covers that distinction in detail.
The third rule is to separate observed data from inference
Suppose the network maps a semiconductor-equipment supplier to a memory manufacturer. Public product research may show that the supplier sells etch or lithography equipment. That supports a plausible functional interpretation.
It does not prove the exact SKU, contract, fab, or current purchase order represented by the edge. A useful LLM answer should label three layers: observed relationship data, public context, and inference. That format makes the answer easier to audit.
MCP helps because the model can query the data instead of relying on memory
The Model Context Protocol is an open standard for connecting AI applications to external tools and data sources. In an Altsets workflow, MCP lets the model ask for company resolution, relationships, metrics, history, or network traces as part of the conversation. That is different from asking a general-purpose model to recall a company's supply chain from training data.
The model still reasons. The relationship data comes from the tool. The current Altsets documentation shows the available research and data interfaces.
Tool access does not eliminate hallucination risk by itself
An LLM can still make mistakes after a correct tool call. Common failure modes include reversing supplier and customer, treating a structural edge as quantified, multiplying percentages across network hops, converting a company-wide percentage into product-specific exposure, attaching a public contract to the wrong named relationship, mixing current and historical data, interpreting missing values as zero, and treating estimated relationship data as audited company disclosure. The solution is an explicit evidence contract.
A useful evidence contract for an LLM
For every important claim, require the model to preserve:
- supplier name;
- customer name;
- relationship direction;
- metric name;
- metric value if present;
- date or snapshot;
- whether the value is observed, estimated, structural-only, or externally validated;
- source for any public context;
- a label for inference.
That structure makes the model's reasoning inspectable. It also makes different LLMs easier to compare because they are being asked to preserve the same factual schema.
Ask the model questions that match the available evidence
A good question is which of a supplier's mapped customers appears more economically important based on supplier revenue percentage. The requested metric exists and the comparison has a clear denominator. A riskier question is how much supplier earnings would fall if one customer cut orders by 10%.
That requires assumptions about pricing, margins, capacity, contracts, other customers, and operating leverage. The LLM can build a scenario. It should not present the scenario as an observed forecast.
Multi-hop analysis needs another guardrail
A model can trace a path through several relationships. It should not multiply directional percentages across those hops and call the result indirect exposure. An upstream relationship into SK Hynix and the SK Hynix to Nvidia relationship can establish a second-order path.
The percentages describe different economic denominators at different companies. Multiplying them creates a new metric that the source data never measured. The second-order exposure guide explains the correct use of the path.
A visual workspace can be a useful verification layer
LLM output is fast. A network view is useful for checking whether the answer preserved the actual structure. If the model says Company A supplies Company B, the visual map can make direction and neighboring relationships obvious.
That is one reason the workspace and MCP are complementary rather than replacements for one another. The workspace supports visual inspection. MCP supports iterative reasoning over the underlying data.
A practical prompt pattern
A strong research instruction is: Use only returned relationship metrics for quantitative claims. Treat missing metrics as unknown. Keep supplier revenue percentage and customer cost percentage directional. Separate dataset facts, public-source facts, and inference. Do not multiply percentages across hops.
That instruction is short because the important constraints belong in the data contract, not in decorative prompting.
When an API is better than an LLM
An LLM is useful for exploratory research and synthesis. An API is better when the task requires the same calculation across hundreds of companies, deterministic filtering, a historical backtest, repeatable portfolio scoring, stored research outputs, or validation tests. The LLM can still explain the results afterward. The computation does not need to depend on conversational reasoning.
The standard for a good AI answer
A good supply-chain LLM answer should leave the reader able to distinguish what Altsets measured, what a public company disclosed, what the model inferred, and what remains unknown. That is more important than sounding confident. For relationship definitions, read the Altsets methodology.
For implementation details and available interfaces, use the Altsets documentation. Browse Supply-Chain Data Use Cases for questions that can be handed to an LLM, workspace, or API without changing the underlying analytical rules.