The problem
A graph database answers what is connected. The questions a sales team actually asks are about what is probably true: will this deal close, what kind of company is this, which fact about the account matters.
The useful evidence often sits one link away. Whether we know the CTO lives on the account, not on the deal, so a model trained on the deals table never sees it unless someone joins and flattens the data first, and keeps that pipeline in step with every new contact.
How it works
Contacts and deals link to their company. A dotted path such as company_id.industry reads a link forward; $refs.contacts.company_id reads it backwards, from the company to its people. Put either in the where of a query with a predict, and the linked facts become evidence for the prediction, with $why naming which ones moved it.
The same shape classifies a node from its neighbours: predict a company's industry from whether a CFO works there. Forward paths chain as deep as the schema goes. What is not part of this is traversal of unknown length, such as reachability or shortest paths, and graph algorithms; for those, use a graph database.
For the full architecture, see the technology overview. For the broader narrative across multiple use cases, read The Predictive Application.
See it live
This use case runs in Company AI, a reference application you run yourself. There is no hosted demo, so the link opens its illustrated tour and source on GitHub: Company AI tour on GitHub →
Frequently asked
Is this a graph database?
No. Aito reads links forward, to any depth your schema has, and backwards with $refs, and predicts over them. It does not search for paths of unknown length, such as reachability or shortest paths, and it has no graph algorithms such as PageRank. What it adds is the part a graph database lacks: a calibrated prediction over the links, with the evidence behind it.
