A knowledge graph is a way of writing down what you know as facts that connect. Instead of a document that describes a domain in prose, you record the domain as entities — the people, projects, documents, and concepts that make it up — and the typed relationships between them. Who owns what. What depends on what. Which document proves which claim. The result is a map you can not only read but query, because the relationships are explicit rather than buried in sentences.
This template is a starter knowledge graph with six of the entity kinds that show up in almost every domain: a Person, a Project, a Document, a Concept, a Tool, and an Organization. They are wired together with the typed edges that make a knowledge graph more than a diagram — owns, depends, proves, related, and more. It is built for anyone who needs to see how a domain hangs together: a researcher mapping a field, an engineer tracing how a system's parts relate, an analyst modelling an organization, or a team building an internal wiki that can answer questions instead of just storing pages.
What makes FlowGraph a genuine knowledge-graph tool, and not just a box-and-arrow canvas, is what sits underneath each card. Every entity is a knowledge atom carrying provenance and a confidence level, and every edge carries a typed relationship — so you can ask questions and get answers grounded in the graph, with receipts, rather than guesses.
What's in this knowledge graph template
The graph has six entity cards and seven typed edges. The point of the template is not the specific entities but the pattern of typed relationships connecting them — that is the part you reuse. Here is what each entity represents and how it is wired.
Person. A person is often the natural center of a knowledge graph — the one who owns things and belongs to things. On this graph the Person card owns the Project, and is related to the Organization. Those two edges already encode a fact worth querying: this person runs that project and is connected to that org.
Project. The Project is the busiest node, which is usually true in real graphs — work is where entities meet. It is owned by the Person, it exports a Document, it depends on a Tool, and it is owned by an Organization. Read those edges together and you get a full sentence of structure: a person's project, backed by an organization, built with a tool, producing a document.
Document. The Document is an artifact the project exports, and it is the target of a proves edge from the Concept. That proves relationship is the one that separates a knowledge graph from an org chart: it records not just that two things are linked but that one is evidence for the other. A document that proves a concept is a citation made structural.
Concept. A concept is an idea, a theme, or a claim the domain turns on. Here the Concept is related to the Document and proves the Document — capturing the way an idea both connects to and is evidenced by the material around it. Concepts are what let a knowledge graph reason about meaning, not just about who reports to whom.
Tool. The Tool is something the Project depends on — a piece of software, a method, an instrument. Modelling tools as first-class entities, rather than notes on a card, lets you later ask which projects share a dependency, or what breaks if a tool is retired.
Organization. The Organization owns the Project and is related to the Person. Ownership at the org level, layered over ownership at the person level, is exactly the kind of overlapping relationship prose struggles to state cleanly and a typed graph states without ambiguity.
The edge types are the real content here. Owns is possession or accountability. Depends is a requirement — one thing needs another. Proves is evidence — one thing supports another. Related is a general association for links that do not fit a sharper type. Exports is production — one thing produces another. Choosing the right relationship for each edge is what makes the graph queryable: you can later ask "what does this project depend on?" and get a precise answer, because the dependency was typed when you drew it.
How to use it in FlowGraph
- Open the template. Click Open in FlowGraph to load the knowledge graph as a live, editable graph. Viewing, editing, and rearranging are free with no account — reshape the whole graph before you decide to save anything. The signup moment only arrives when you want to save it to a vault or query it with AI.
- Add entities. Rename the starter cards to the real people, projects, and documents in your domain, and create new cards for every entity that matters. Each card is a knowledge atom, so it carries provenance and a confidence level — a fact you are sure of and a fact you are guessing at can live in the same graph without pretending to be equally certain.
- Type the relationships. Connect your entities with the edge that actually fits — owns, depends, proves, related, and the others. Resist the urge to make everything "related." The sharper each edge type, the more the graph can answer later, because a query is only as precise as the relationships it runs over.
- Grow it by import. You do not have to build the whole graph by hand. Import documents or a codebase and FlowGraph will expand the graph from what it finds — turning files, functions, and references into entities and edges you can then curate. The import gives you a first draft of the structure; you keep the parts that are right.
- Query with AI. With your own AI key, ask a question in plain language and get an answer grounded in the graph, with the entities and edges that support it cited as sources. Because the AI reasons over your actual cards and their typed relationships, the answer is traceable back to the graph rather than invented. The AI proposes; you verify and decide.
- Keep it governed. Every card you add, every edge you type, and every AI suggestion you accept lands as a governed edit that carries a receipt of who changed what and when. The graph stays reversible and attributable, so as it grows into hundreds of entities it stays trustworthy rather than turning into a tangle nobody can vouch for.
Why a living graph beats a static knowledge map
A knowledge map drawn in a diagramming tool looks like a knowledge graph but cannot do the one thing that matters: it cannot be queried, because its edges are just lines. There is no difference, to the software, between an "owns" line and a "depends" line — they are both pixels. So the map can be read by a human and nothing else, and the moment the domain changes it is out of date with no way to check.
In FlowGraph the relationships are typed and the entities are real objects, so the graph is machine-readable and answerable. You can ask which projects depend on a tool, which documents prove a concept, or who owns what across the whole organization, and get an answer grounded in the actual edges. Each entity carries provenance and confidence, so the graph is honest about what is known versus assumed — and you can import documents or a codebase to grow it far faster than you could ever draw it by hand.
And it stays trustworthy as it scales. Every change is governed and reversible, and every edit carries a receipt, so a graph of hundreds of entities remains something you can vouch for rather than a pile of unattributed claims. It opens with no account and stays local-first and yours; you sign up only when you want to save it to a vault or query it with AI.
Frequently asked questions
What is a knowledge graph?
A knowledge graph represents facts as entities — people, projects, documents, concepts — connected by typed, labeled relationships. Rather than describing a domain in prose, it records the domain as a network you can both see and query, so the connections are explicit data instead of implications buried in sentences.
The typed relationship is the key idea. In a knowledge graph an edge is not just a line but a stated fact — "owns," "depends on," "proves" — which means the graph can be reasoned over. Ask it a question about how two things relate and it can answer from its own structure, because the relationship was recorded as a fact when the edge was drawn.
What makes FlowGraph a knowledge graph tool?
Every card in FlowGraph is a knowledge atom that carries provenance and a confidence level, and every edge carries a typed relationship rather than being a bare connector. That combination is what makes the graph answerable: because the software knows what each entity is and how each edge relates, you can ask questions and get answers grounded in the graph, with the supporting entities and edges cited as receipts.
It is also governed end to end. Every addition and every AI suggestion you accept flows through a single write path that stamps who changed what and when, and stays reversible. So the graph is not just queryable — it is trustworthy, which is what you need when a graph grows past the point where any one person can hold it in their head.
How do I grow the graph?
Add entities as cards, connect them with the relationship that actually fits — owns, depends, proves, related — and be deliberate about the edge type, because that is what you will query later. Build out the corner of the domain you know best first, then let the shape of the graph show you where the gaps are.
You can also grow it automatically. Import documents or a codebase and FlowGraph expands the graph from what it finds, drafting entities and edges you then curate. And with your own AI key you can ask FlowGraph to propose new connections or fill in missing entities — always as proposals you review, so the graph grows fast without ever growing untrustworthy.