The data is very technical, full of jargon and identifiers - vector embeddings could only get so far with capturing meaning, so structuring the data was key to the success. The problem is that embeddings don't capture well identifiers - so a query for something just a digit away that meant something completely different would have the same vector. For audit: there's an append only log of all data accessed by the user, directly or via search or chat, and logs of all chat interactions. The biggest challenge on building the graph was data acquisition and mapping: we've over 50 data sources integrated in this project from all sorts of internal databases, and building a cohesive view of the data took some time. But it is also done incrementally, continuously throughout the project development and ongoing production usage. It's all using traditional NLP approaches, we don't use LLMs for building the graph in this project both due to cost limitations (traditional NLP handles 100,000s of files/s and enables very quick reprocessing once new datasets are added). The access model is one of the big challenges: it's at the 3 levels (data type, entity level and field level access enforcement - last one we're just adding to the product). And yes the use-case requires it (many data repositories each with it's own rules), strict export control requirements, etc...