Knowledge graph and semantic intelligence.
Three graphs, and none of them owns the truth.
A proper knowledge graph is about governed semantics, provenance, temporal scope and authorisation — not about buying a graph database. Cobalt ERP runs three, each with a different job and the same discipline: derived, rebuildable, never authoritative.
Curated, tenant, and evidence.
Product and capability graph
Global, curated, versioned and free of any tenant data. Modules, object types, capabilities and engines, facts, events, schemas, permissions, actions and interface surfaces, expected processes, policy-pack types, and the dependencies and supersessions between them. It is what makes capability discovery, recipe validation, change-impact analysis and coverage reporting possible.
Tenant business context graph
Your records, as a graph. Legal entities, books, accounts and dimensions; customers, suppliers, employees and contracts; products, bills of material, lots, warehouses and locations; quotes, orders, deliveries, receipts, invoices and payments; works orders, service cases, assets and tickets — with the relationships between them.
Evidence and decision graph
The lineage: a fact, document or event, into a dataset, through a rule, model, process or ontology version, into a finding, prediction or proposal, and on to the decision a person actually made. This is what makes “why did it say that?” answerable six months later.
Relationships you can traverse, and prune with.
The business graph is the reason an answer about a supplier can reach the orders standing behind it without anybody writing that join by hand. A traversal is scoped by your permissions, and its most valuable job is often subtraction — pruning the candidates the other engines would otherwise waste time on.
- Typed relationships — supplier supplies component, component used in bill of materials, bill produces product, product reserved by sales order, order fulfilled by shipment, shipment billed by invoice, invoice settled by payment.
- Dependency traversal — what stands behind this, and what falls over if it slips.
- Graph context for other engines — point-in-time features for prediction, population scoping for mining, candidate sets for optimisation.
- Lineage — from a figure on screen back to the records and versions that produced it.
- Candidate pruning — the cheapest performance win in the whole system, because the fastest engine is the one that never runs.
Derived and rebuildable. Never transaction or authorisation truth.
The graph does not own the relationships in it — the authoritative modules do. It can be rebuilt from them at any time, and if it disagrees with them, it is wrong. Two consequences follow: nothing reads a balance or a permission from the graph, and links the system inferred are kept separate from links a module asserted, so an inference can never quietly become a fact.
Whenever the answer depends on what something is connected to.
- “Which customers are exposed if this supplier slips?” — supplier to component to bill of materials to product to order to customer, in one traversal.
- “What breaks if we change this?” — change-impact analysis over the capability graph.
- “Where did this figure come from?” — the lineage path through the evidence graph.
- “Is this the same party as that one?” — entity resolution, with the evidence for the match.
- “What else does this contract cover?” — obligations reached through the relationships rather than by reading the file again.
Frequently asked questions.
Do I need a graph database for this?
No, and that is deliberately not the point. What makes a knowledge graph useful is governed semantics, provenance, temporal scope and authorisation. The storage choice follows from the workload rather than leading it.
Can the graph be wrong?
It can be stale, and that is why it is rebuildable and never authoritative. If the graph and the module disagree, the module is right and the graph gets rebuilt.
What is the difference between an inferred and an asserted link?
An asserted link comes from an authoritative module — this invoice settles that order. An inferred link is something the system worked out. They are stored separately and never merged, so an inference cannot be mistaken for a fact.
Does the graph see everything regardless of my permissions?
No. Traversal is scoped by your permissions, and permissions are checked live rather than read from anything cached in the graph.
See this engine on your own records.
Join the waitlist and ask it something real. Every answer names the engines it used and the records they read.
Join waitlist