Understand AI

Knowledge graphs and workflow graphs, explained for business owners

Tell knowledge graphs from workflow graphs, see each drawn with a fictional example, and decide which relationships and decisions your business should record.

For: Owners and working professionals who have heard 'graph' used in an AI pitch and want to know whether it matters to them.

Format: Explainer + two diagrams + worksheet
Published: September 9, 2026
Last checked: September 9, 2026
Written by: Dryvn AI editorial
Edited by: Dryvn AI editorial
Reviewed by: Not yet reviewed by a named person
Read as: Editorial (Dryvn's practical method)

Two words, two drawings

When someone says "graph" in an AI conversation they usually mean one of two things, and they often do not say which. The first is a knowledge graph: a record of things and how they relate. The second is a workflow graph: a drawing of how work moves. Both are useful. Neither is the bar chart in your monthly report, which is a picture of numbers, not of connections.

The technical roots are plain enough. The W3C's RDF primer describes a graph as a set of statements, each with a subject, a predicate and an object, drawn as nodes connected by arcs, where the subject and object are the nodes and the predicate is the connecting arc [S26]. "Customer 42 owns Unit 2B" is a statement of that shape. A graph database vendor's own definition says the same thing in database terms: nodes for the things, relationships that are named, have a direction and connect exactly two nodes, and properties that hold details on either [S28].

A knowledge graph: what is connected to what

Here is a fictional property-maintenance business drawn as a small knowledge graph. Every box is a thing the business keeps a record of. Every line is a relationship it needs to be able to follow in either direction.

Fictional knowledge graph: a maintenance job and everything attached to it

Text version of this diagram

Customer — owns → Property
Job — at → Property
Job — serviced → Equipment
Document — evidence for → Job
Invoice — bills → Job
Invoice — sent to → Customer

The value shows up when you ask a question that crosses the lines. "Which customers have had the same water heater serviced twice this year?" walks from equipment to job to property to customer. "Show me every photo behind this invoice" walks from invoice to job to document. In a business where those records live in five different apps, the walk is done by a person, by memory, and it is the walk that fails. The handoff assessment is largely a test of whether those lines exist anywhere but in someone's head.

A workflow graph: what happens next, and what if not

A workflow graph is a different drawing. The boxes are steps, not things, and the lines mean "then". It has branches (a decision splits the path), waiting states (the work sits until something arrives), retries (try again, but not forever) and an end. Business process diagrams have had a standard notation for this since 2010, described by its publisher as a flowchart-like notation that is independent of any particular software and precise enough to be turned into software components [S27]. You do not need the standard to draw one; you need the four ingredients.

Fictional workflow graph: the same leak repair, as steps with its decisions · Diamonds are decisions; dashed boxes are waiting states; red dashed arrows go back or escalate.

Text version of this diagram

Request received (start; from tenant) → go to Confirm access
Confirm access (waiting state; waits for customer reply) → go to Access refused?
Access refused? (decision; or no reply in 2 days) → no, access agreed: go to Site visit; yes: go to Retries so far?
Site visit (step; photo + voice note) → go to Correction done
Correction done (step; completion claim) → go to Verified?
Owner decides (escalation to a person; call, reschedule or cancel) → new time arranged: go to Confirm access; cancelled, reason recorded: go to Closed
Retries so far? (decision; limit: 2) → under 2: ask again: go to Confirm access; 2 already: go to Owner decides
Reopened (step; back to the trade) → correct again: go to Correction done
Verified? (decision; someone checks) → pass: go to Invoice; fail: go to Reopened
Closed (end; evidence attached)
Invoice (step; bills the job) → done: go to Closed

Look at the shapes. The dashed box, "Confirm access", is a waiting state, and it is where most work quietly stops. The diamonds are decisions: "Access refused?" leads to a bounded retry ("Retries so far?" with a limit of two) and then to a person ("Owner decides", who can arrange a new time or cancel with a reason). "Verified?" has a fail branch that goes back to "Correction done" through "Reopened". Those branches, limits and escalations are the whole point of drawing the graph: they force you to say what happens when the normal path does not happen. The customer request workflow and the deficiency tracker are both this drawing with the boxes filled in.

A graph is not a feedback loop

Here is the confusion that costs people money. A workflow graph can contain a loop, like the "fail → reopen" branch above, but the graph itself is mostly one-way: request, visit, fix, verify, invoice, done. A feedback loop is a specific pattern where the result of the work changes the next action, repeatedly, until a condition is met. "Send a reminder; if no reply in three days, send a different one; if still no reply, call" is a feedback loop. The systems, workflows and loops explainer covers the difference in depth.

Three drawings that get mixed up
Drawing	Boxes are	Lines mean	Answers the question	Fictional example
Knowledge graph	Things: customers, jobs, documents, equipment	"is related to", with a name and a direction	What is connected to what?	Which photos belong to this invoice?
Workflow graph	Steps	"then", with branches, waits and retries	What happens next, and what if not?	What happens when the tenant does not confirm access?
Feedback loop	Actions and a check	"result changes the next action"	What repeats until the outcome is reached?	Follow up until the estimate is answered or expired.
Chart	Numbers	Nothing; position shows quantity	How much, compared with what?	Revenue by month.

Illustrative example · fictional

Deciding what to record before choosing any software

A fictional two-crew landscaping company keeps quotes in one app, schedules in a calendar and invoices in accounting software. Nothing links them except the customer's name, typed slightly differently in each. When a customer disputes an invoice, the owner spends twenty minutes finding the quote, the crew's photos and the day's schedule.

Before buying anything, the owner fills in the worksheet below. Relationships that must be recorded: quote belongs to customer; job comes from quote; visit belongs to job; photo is evidence for visit; invoice bills job. Decisions that must be recorded: who approved the quote change; who signed off the job as complete; who agreed the invoice date. Owner of each record: the office manager for quotes and invoices, the crew lead for visits and photos. What "done" looks like: an invoice with the approved quote and the crew's sign-off photo attached, with no one having to search for them.

That page is the requirement. Whether it is met by a shared job number in every app, by a small business platform that connects the records, or eventually by a graph database, is a second question, and a cheaper one now that the first is answered. This example is fictional.

How to use this

01List the things you keep records ofCustomers, properties, jobs, visits, documents, equipment, invoices. Usually fewer than ten kinds.
02Draw the lines you need to followFor each pair, ask: do we ever need to go from one to the other? Name the relationship and its direction.
03Draw the steps for one piece of workBoxes for steps, notes for waits, branches and retries. Mark where work actually stops today.
04Write down the decisions that must be keptApprovals, sign-offs, agreed dates. These are the records that settle disputes.
05Only then look at toolsTake the sheet to whoever is selling you software. If they cannot show the walk and the waits, keep looking. See connecting existing software.

Worksheet

Relationships and decisions to record

One sheet per area of the business. Keep it to what you actually need to follow or prove.

Things we keep records of: Customers, jobs, documents, equipment, invoices…
Relationships we must be able to follow: e.g. photo → evidence for → visit; invoice → bills → job
Decisions we must be able to prove: Approvals, sign-offs, agreed dates, and who made them
Owner of each kind of record: A name per kind, not a team
Where work waits today: The steps where an item sits until something arrives
What 'done' looks like: The evidence that has to be attached before a piece of work is closed

Downloads · no email required

Relationships and decisions worksheet
The 'what to record' sheet as a fill-in Markdown file, with a separate fictional example.
Download .md

Questions people ask

What is a knowledge graph in plain language?: A record of things and how they are related, where every relationship has a name and a direction: this customer owns that property, this invoice bills that job. It lets software, or a person, follow the connections instead of searching five apps by name.
How is a workflow graph different from a feedback loop?: A workflow graph draws the steps work moves through, mostly one way, with branches and waits. A feedback loop is a pattern where the result of an action changes the next action, repeatedly, until a condition is met. A workflow graph may contain a loop; it is not one.
Do I need a graph database to use AI in my business?: No. Consistent identifiers across your existing tools already give you most of the benefit. A graph database stores the relationships natively so following many links is fast [S28], which matters at scale. Decide what to record first; choose storage second.
Is a graph the same as a chart?: No. A chart is a picture of quantities. A graph, in this sense, is a map of connections or a map of steps. They share a word and nothing else.

What is an AI system, a workflow and a loop?Learn the difference between a system, a workflow, an automation, an agent and a feedback loop using two everyday business examples, and map one of your own on a worksheet.
How AI uses your documents: search, context and retrievalUnderstand what actually happens when an assistant answers from your company documents, why that is not the same as training, and what to check before you trust the answer.
How multi-model AI systems work, and when one model is enoughSee what happens when several AI models share a job, why disagreement is useful, what it costs, and how to write down roles and checks before you build.
Turn a repeated task into a usable SOPTake a task that lives in someone's head and write it down so a new person could do it on day one, with the approvals, exceptions and evidence of completion spelled out.
BlogThe AI Fabric: A Research Thesis on Loops, Graphs and Everyday CoordinationBrent develops a proposed AI fabric connecting people, context, permissions and ongoing work. The paper examines its research foundations, limits and a method for testing whether it reduces human coordination effort.

Sources

Dates are when each source was last checked by the editor. Sources support specific claims; they are not endorsements.

S26RDF 1.2 Primer · W3C · checked September 9, 2026W3C Group Note Draft dated 26 August 2026. Supports the definition of a graph as a set of subject–predicate–object statements drawn as nodes and arcs, and the use of global identifiers so different people can refer to the same thing.
S28What is a graph database · Neo4j · checked September 9, 2026Supports the definitions of nodes, relationships (named, directed, one type, start and end node) and properties, and the point that a graph database stores relationships alongside the data rather than reconstructing them with joins. Vendor documentation; cited for definitions, not as a recommendation.
S27Business Process Model and Notation (BPMN) 2.0 · Object Management Group · checked September 9, 2026Version 2.0, published December 2010. Supports the point that workflow diagrams have a standard notation, described as a flowchart-like notation independent of any implementation, precise enough to be turned into software components.

R15 · Published September 9, 2026 · Next scheduled review December 9, 2026 · Teaches process management; not legal, warranty, safety or engineering advice. Examples are fictional unless stated. Part of the Dryvn resource library (17 resources).