An LLM that makes things up is a non-starter for finance and legal. Here's how ontologies and knowledge graphs tie every answer to the company's own data.
Large language models are fluent, and fluency is dangerous: a model will state something false with exactly the same confidence it uses for something true. Inside a bank or a law firm, a plausible-but-wrong answer is worse than no answer at all. So the real engineering question is never "how smart is the model", it's "how do we stop it from making things up".
Grounding: every answer tied to a source
Grounding means the agent does not answer from the model's memory. It answers from your documents and your systems, and it cites where each claim comes from. If it cannot find support, it says so instead of guessing. That single rule, answer only from what you can cite, is the difference between a demo and something a regulated team can actually use.
Why RAG alone isn't enough
Plain vector RAG retrieves passages that are semantically similar to the question. That helps, but it is blind to structure. It doesn't know that this clause belongs to that contract, which binds this counterparty, whose obligation falls due on that date. It returns text that looks related, and it will happily stitch together fragments that resemble each other but describe different things. Similarity is not the same as truth.
Ontologies: giving the domain a structure
An ontology is a formal model of a domain: the entities that exist (contract, clause, obligation, counterparty, instrument), their properties, and the rules that connect them. It is the difference between a pile of PDFs and a system that knows what a counterparty is and what an obligation implies. Once the domain's logic is explicit, an obligation has a due date, a clause can override another, an instrument has an issuer, extraction and reasoning become precise instead of fuzzy.
Knowledge graphs: from documents to a graph of facts
Guided by the ontology, we turn documents into a knowledge graph: nodes are the real entities, edges are the relationships, and every fact carries a link back to the exact source passage it came from. Now the agent can traverse precise connections, "which obligations of counterparty X fall due in Q3, and in which contract", instead of hoping the right paragraphs happened to be retrieved. It reasons over facts, not over resemblances.
How Hoplo keeps an agent grounded
- Ontology-guided extraction, entities and relationships are pulled against the domain model, not in free form.
- Hybrid retrieval, the graph for precise structure, vector search for nuance, working together.
- Answer only from context, the agent is constrained to what was retrieved, with a citation for every claim.
- Abstain, don't invent, if the graph doesn't support an answer, the agent says "I don't know" or escalates to a person.
- Constraint checks, answers are validated against the ontology's rules (a due date can't precede a signature date) before they're shown.
- Audit trail, every answer traces back to its sources, so a human can verify it in seconds.
The result: answers you can verify
The payoff isn't a chatbot that sounds clever, it's an agent whose every answer is grounded, cited and checkable. This is the foundation behind Amaril, our finance intelligence layer, and DocZoom, our on-premise document AI: teams in regulated environments trust the output because they can trace it. Keeping an agent grounded is engineering, not luck, an explicit model of the domain, a graph of real facts, and guardrails that make "I don't know" a valid answer. That's how we stop agents from hallucinating.