The situation
Turning market data into a defensible point of view was a manual exercise measured in weeks. Analysts read widely, held the connections in their heads, and produced a deck. By the time the synthesis was ready the question had often moved on — and the reasoning behind it lived with whoever happened to have done the reading.
How it works
Read the corpus
An LLM pulls entities and relationships out of market sources.
Build the graph
Those relationships become a live network you can navigate.
Trace any claim
Every node opens back to the source underneath it.
Turn structure into options
Candidate directions come off the graph, ready for a decision.
Why this was harder than it looksThe technical detail
An LLM that summarises a document corpus is a demo. It takes an afternoon and it impresses nobody who has to make a decision with the output.
The reason is simple: no executive commits budget on the strength of a paragraph they cannot trace. Ask "why does it say that?" and an unstructured summary has no answer. The hard part of this build was never generating text — it was making the synthesis interrogable, so a confident-sounding claim could be opened up and followed back to its source.
Speed was the easy half. The half that made it usable was letting people see the connections the model had drawn.
What we built
LLM-driven extraction
Over a live market corpus, pulling out entities and the relationships between them rather than producing prose.
A dynamic network graph as the primary interface
A user sees the structure of the market — who connects to what, through which signal — and can drill from any node back to the underlying source.
An ideation path off the graph
Turning observed structure into candidate solution directions, so the output was a starting point for a decision rather than a report nobody owned.
The outcome
- 100x improvement in analysis latency — a multi-week research process answered in real time.
- A visual decision-support system in place of a static deliverable, so the analysis could be questioned live in the room.
We describe this one as a proof of concept because that is what it was. The capability was built and demonstrated end to end; the business case was not carried forward into production. We would rather tell you that here than have you find it out in a reference call.
If you're facing something similar
Most GenAI pilots stall for the same reason: they produce fluent output nobody can verify, so nobody builds a process on it. If you are evaluating a GenAI use case, the question worth asking early is not "how good is the model" but "when someone challenges this output, what do we show them?" Answer that and the pilot has somewhere to go.