Appearance
What is Liddr
Liddr is an internal-intelligence platform. It connects the tools your organization already uses — issue trackers, source control, wikis, observability, and more — into a single knowledge graph built from your real work, then lets your team ask grounded questions, read a daily digest, and run initiatives that turn decisions into pull requests.
Instead of context being scattered across a dozen systems and a few people's heads, Liddr gives you one intelligence layer over your docs, code, systems, and decisions — with every answer linked back to the evidence behind it.
How it works
Everything in Liddr follows the same path: you connect a source, Liddr builds a shared knowledge graph from it, and then your team works on top of that graph through Know, Signal, and Forge.
Connect a source → Build the knowledge graph → Know · Signal · Build
(Settings → (your work, searchable (grounded answers,
Connections) by meaning) digests, initiatives)Connect
You start in Settings → Connections by adding a connector for one of your tools — for example Jira, GitHub, or Confluence — and entering its credentials. Liddr supports two kinds of connector:
- Ingest connectors bring org-shared structure, work, and knowledge into the knowledge graph.
- MCP connectors reach personal, record-level, or sensitive data live at answer time, per user, and never enter the graph.
See Sources & connectors for the distinction, and Getting started for the step-by-step.
Knowledge graph
When you connect a source, Liddr learns from its items — issues, pull requests, wiki pages, incidents, documents — and weaves them into a shared graph that you can search by meaning rather than by exact keyword.
The result is a shared picture of your organization's reality: structure (who owns what, how systems relate), work (what's in flight, what shipped), and knowledge (decisions, runbooks, specs). Liddr keeps the graph current automatically in the background as your tools change.
Learn more in The knowledge graph.
Know · Signal · Build
With the graph in place, your team works on top of it:
- Know answers natural-language questions over the graph and cites the exact sources behind every claim.
- Signal delivers a role-aware digest of what changed, what's at risk, and what to look at next.
- Forge moves a piece of work through SDLC stages — discovery, requirements, design, architecture, implementation, review — and can open pull requests against your repositories.
What makes answers grounded
A Liddr answer is grounded when it is built from, and traceable to, real sources in your knowledge graph rather than from the model's general training.
When you Ask a question, Liddr finds the most relevant material in your graph and uses it to compose the answer. The answer comes back with citations — inline references that link to the source (the Jira issue, the pull request, the Confluence page) each claim is drawn from.
If the answer references something that is not in your sources, Liddr flags it as unverified so you can treat it as unconfirmed rather than mistaking it for evidence.
Grounded, not guessed
Every cited claim points at a real source you can open. That traceability is the difference between an answer you can act on and one you have to second-guess.
Who it's for
Liddr is built for teams who lose time reconstructing context:
- Engineers and SREs asking "what changed, where, and why" across repos, incidents, and specs.
- Product and delivery roles tracking what's in flight, what's blocked, and what decisions were made.
- Architects reasoning about how systems relate and how a change ripples through them.
- Leads and managers who want a grounded picture of their area without pinging six people.
How Liddr is different
The defining choice in Liddr is its data model: the organization knowledge graph is shared and has no per-user access control. Anything brought into it is, in effect, visible to anyone who can Ask.
That constraint is deliberate, and it drives a clean split:
- Org-shared, non-sensitive data is brought into the graph. Structure, business rules, project tracking, docs, and team knowledge become part of the shared picture.
- Personal, record-level, or sensitive data never enters the graph. Instead it is reached through per-user MCP connectors, queried live with that user's own credentials, so it stays scoped to the person who is allowed to see it.
This is why, for example, project structure and engineering work flow into the graph, while a user's mailbox or files are reached only through their own MCP connection. The result is a shared intelligence layer that does not leak anyone's private data.
Read more in Org-shared vs per-user data and the Access model.