Appearance
How Liddr builds knowledge
When you connect a source to Liddr — your issue tracker, your docs, your code, your designs — Liddr doesn't just keep a copy of it. It reads what's there, understands it by meaning, and organizes it into a single connected picture of your organization: a knowledge graph. Know and Signal both draw on this one graph, so every answer comes from the same grounded understanding of how your organization actually works.
This page explains, at a conceptual level, what becomes part of that graph, how it stays current, and why the answers you get cite their sources.
From a source to understood knowledge
Each connected source moves through the same path:
- Read. Liddr reads the items in the source — documents, issues, pull requests, files, and so on.
- Break into passages. Each item is divided into smaller passages, so a question can be matched against the exact part of a document that's relevant rather than a whole file at once.
- Index by meaning. Each passage is indexed by what it means, not just the words it contains. This is semantic search: a question about "how we handle refunds" can find the right passage even if it never uses the word "refund." Matching on meaning, not just keywords, is what lets Know find the right context across very different sources.
- Connect. Related items are linked to one another — a pull request to the issue it closes, a design to the ticket it implements, a decision to the people and systems it involves. These connections are what make it a graph rather than a flat pile of search results.
What becomes part of the graph
The graph holds the connected items that make up your shared organizational knowledge: documents, issues, code, decisions, people, and systems, along with the relationships between them. Every item keeps a link back to where it came from, so it can always be traced to its source.
The graph deliberately holds only organization-shared structure, work, and knowledge. It is a shared resource with no per-user filtering, so personal and record-level data is never brought into it. That kind of data reaches Know live, under your own credentials, through MCP connectors instead — see the Access model for the full reasoning.
One graph, many surfaces
Know and Signal read from the same knowledge graph. There's no separate index per feature — connect a source once, and everything that uses the graph benefits from it.
It stays current automatically
Your sources change constantly, and the graph keeps up. As connected sources are updated — issues move, docs are edited, code is merged — Liddr refreshes what it knows so the graph reflects the current state of your organization rather than a one-time snapshot. Re-reading a source only updates what actually changed, so keeping things fresh is efficient and safe to do often.
When an item is removed or archived in its source, it stops contributing to what the graph "knows" right now, so it no longer appears in answers — while its history is preserved for traceability.
Answers cite their sources
Because every answer is built from real items in your graph, Know can show you exactly what it drew on. Each claim links back to the underlying document, issue, or file it came from, so you can verify any answer against its source rather than taking it on faith. This is the difference between an assistant that guesses and one that grounds every statement in your own organization's knowledge.
Grounded, not generated
Liddr answers from what's actually in your connected sources, and shows you where each answer came from. If the graph doesn't contain the supporting evidence, Liddr won't invent it.