Who buys it
Operations leadership who need supply chain answers that survive being questioned, and anyone accountable for auditability.
Plant and Procurement Intelligence Pipeline
Graph/query module business case
The evidence foundation inside the integrated plant/procurement pipeline.
Who uses it
Procurement and planning analysts who currently ask a colleague or write a query to get an answer.
The problem
What this costs you today.
Questions that cross systems, such as which supplier feeds which assembly or what a delay touches, are answered by a person who knows where to look. That person is a bottleneck, and the answer carries no record of how it was reached.
The usual alternative is a chatbot over the document store, which answers fluently and cannot show its working. In procurement a confident wrong number is more expensive than no answer.
The mechanism
What changes.
Questions are answered by traversing a graph carrying an ontology layer and per-edge provenance, so every claim can name the collection, field, and source record behind it.
Caveats attach to entities and relationships, so they surface automatically whenever an answer depends on them, including that a projection assumes no approved substitute exists.
Where a relationship genuinely does not exist, the system says the question cannot be answered and explains why, rather than inventing a number.
Measured
What was actually observed.
These figures describe the graph half, which is built, loaded, and running today. The chat layer on top is now in active development in a separate work stream, per the phased approach in docs/2026-09-12-06-HybridChatImplementationPath.md; nothing from that build has been verified in this repository yet, so there is still no time-saving or performance figure for it. The calculator below is illustrative only; do not quote it as a measured return.
| Metric | Observed | Basis |
|---|---|---|
| Parts in the live graph | ~6,200 | Loaded and running today on the hosting VM |
| Assemblies | 288 | Same instance |
| Vendors | 282 | Same instance |
| Used-in edges | 9,400 | Same instance |
| Supplied-by edges | 5,300 | Same instance |
| Weekly position records | ~295,000 | Same instance |
| Ontology layer | 22 entities, 71 relationships, 446 fields, 83 caveats, 215 evidence nodes | Per-edge provenance: every supplied-by relationship has a paired fact node linking to evidence and caveats |
Where the money is
Your numbers, not ours.
Defaults are illustrative placeholders. The graph is built and loaded; the chat layer on top is what we would add. See the caution below.
Every figure above is arithmetic on the values you entered. Nothing is a measured result from a prior deployment, and no customer savings are claimed anywhere on this site.
The honest part
When not to buy this.
- Where the underlying data has no ontology or provenance layer. Without it this is an ordinary text-to-query system with the usual failure modes.
- Where nobody will own ontology and caveat maintenance. A stale caveat asserts diligence that is no longer true, which is worse than none.
- Where open-ended natural language is the requirement. The reliable version answers a defined question set and refuses outside it.
Adoption
What it actually takes.
Prerequisites
A graph with typed relationships and recorded provenance. If that does not exist, building it is the bulk of the work and the expensive part.
Setup effort
Roughly a quarter of engineering for the constrained generation layer and evaluation harness, assuming the graph already exists.
Ongoing cost
Permanent. Ontology entities, field mappings, and caveats drift as source systems change, and must be owned.
Engagement
How this would be delivered.
- Discovery first: assess whether a provenance layer exists or must be built.
- Build the constrained question layer over an existing graph.
Caveat: The graph is built and loaded today, carrying real volume and a working ontology and provenance layer. The chat layer on top — the natural-language question interface — is now in active development; it is not yet functional or verified. Treat the figures as a sizing exercise, not a quote, until that build lands and is tested against a gold question set.
Next step
Run the demo, then tell us your numbers.
The fastest way to test any of this is against your own volumes rather than the placeholders above.