Steven Hart
Knowledge Architect
From document library to intelligence platform
A knowledge graph design for a private equity intelligence platform, modelling the relationships between investors, fund managers, funds, deals, people, events, and editorial content; then showing what those relationships make possible in the product.
Developed while contracted to PEI Group as Senior Information Architect. While not taken into production, the work was reviewed and supported by senior design and data leadership as a potential future direction.
The user problem
In order to analyse or identify patterns, trends and narratives that exist across PEI content and databases, users have to visit multiple individual pages and do the hard work of making connections and deriving meaning in their own heads: an awful lot of cognitive load.
The data architecture problem
The core problem is that PEI's current architecture stores entities without relationships. For example, funds exist in the fund database, investors exist in the CRM, and articles exist in the CMS. But the connections between them are either manual, duplicated, or missing entirely, and it is the connections that bring the data to life.
In short, the existing platform is built for publishing content and data, not for analysing it.
What my work did
My work encouraged readers to stay on platform by making the value of its data explicit and highly visible.
The existing platform cannot link articles to relevant events or other data, because taxonomies do not match. Manually tagging content in the CMS is slow and inaccurate, because different editors call the same things by different names.
But In the new article page template shown below, you can see 'network intelligence' modules associated with the content, each one pulling in relevant intelligence from across the platform's ecosystem of data and knowledge. These intelligence modules are driven by simple queries over the new data model I describe later in this case study.
The new article page is a window onto the platform, not just a container for static content. And it is now an analysis tool in its own right, providing insights anchored to the topics of the article.
It also drives engagement with the broader platform, for example by giving names of key employees at organisations mentioned or affected by themes of the article, and events they are attending. (This is useful for fund managers looking to meet potential investors, for example.)
How I approached the problem
I created a knowledge graph which, instead of organising content around pages and separate CMS tables, structured data around the objects and relationships of the domain:
Firms (Fund managers; Investors)
Funds and strategies
Sectors and regions
Events and signals
Articles
A knowledge graph creates a structure where meaning is defined by connections, not just content. Insights can be derived from the values and properties associated with each object and relationship, and easily queried.
This makes rich insights available to the interface quickly and easily.
For example, in the snippet above, you can see how an 'Event' object can quickly be associated not only with who is attending, and where they work, but what funds their company manages, the funds they invest into, and articles that mention the fund.
Data modelling and finding the design anchor
PEI's data, and the way it needs to be experienced, is relational: content and data are relevant to users only in the context of their investment strategies, or investment hypotheses for new funds.
The CMS organisation of content forced navigation by content type ('News', 'Awards', 'Events', etc).
But for all key users, the real value is in:
User selects a Strategy, Sector, and Region (SSR)
Platform shows all relevant content, and says why it's important.
The new data model supports that thinking style whereas the old one does not.
Sitting beneath the interface, it allows a simple, but powerful, 'Market Focus' widget on the front end. Users can now explore and discover all content and data by selecting their Strategy, Sector and Region of interest.
This interaction became a design anchor across the new platform.
How the graph supports design
Instead of having to do a lot of reading and bouncing back and forth between pages to find answers and build overviews or detailed narratives, the platform itself can now visualise the results of sophisticated analysis, or give answers to complex questions.
Previously, these were either manual, time-intensive tasks, or just not feasible.
Working out from a named investment strategy (in this case Infrastructure, the larger blue object), a rich network of connections to other objects can be traced and queried, and their data fed up to the interface.
For example:
Investor > INTENDS_TO_INVEST_IN > Strategy
Person > WORKS_AT > Investor
Event > ATTENDED_BY > Person
Article > MENTIONS > Strategy
In more detail: Working with investor intentions
Every fund has a focus: the strategy, sector, and region it says it will invest in. Knowing this in advance, and knowing which investors have intentions to invest in which strategies or sectors, is crucial when planning new funds.
Extracting that picture of who intends to invest in what was difficult in the old model, requiring a lot of drilling down to find the intentions of a particular investor, and then sideways hops to compare the intentions of different investors.
In the new model, it is easy to see who has an interest in any given sector. More than that, the graph reveals a rich network of data behind any investor with a declared interest in a sector, allowing users to see who works at the investor, which events they are going to, what relevant articles have been written, the other funds the investor commits to, and so on.
The graph enables instant comparison of declared or intended focus, and actual investment behaviours. A single graph query returns key patterns across the dataset, immediately.
What this means for the product
The graph is not just a backend model, its design and structure actively drives key product features. Dashboards show market overviews pitched at investors or fund managers; article and event pages tie content to a rich data ecosystem; and market signals become far more visible and accessible without extra effort,
In other words, the information architecture makes direct, significant improvements to user value on every page of the platform:
Challenges
Designing the model exposed me to new vocabulary and framings for some familiar, but non-trivial problems including:
Entity resolution
Identifying when different references describe the same real-world entityData consistency
Applying controlled vocabularies across varied and messy source contentScalability
Ensuring the model can evolve as new data and use cases emergeSynthetic vs real data
Early validation required assumptions that would need testing in production
Outcomes and outputs
This work created a foundation for:
Faster, more reliable insight generation
New product capabilities based on querying and aggregation
A shift in user behaviours: from searching for content, to discovering intelligence.
The head of data and AI called it 'a kick up the arse', and 'exactly the direction' the company needed to go in. The head of design called it groundbreaking. Both responses confirmed what the work set out to demonstrate: that restructuring information at the data layer changes what a product can do.
Steven Hart
Knowledge Architect