DEV Community: TrustGraph

Is "Ontology" the Most Misused Word in AI Today?

Daniel Davis — Fri, 30 Oct 2026 02:23:16 +0000

The word ontology is everywhere right now. There are "just-in-time ontologies," products with ontology in the name, and major platforms adopting the term in ways that don't always match what it means. This video cuts through the noise and explains, from first principles, what an ontology is, what it isn't, and why it matters in the age of AI agents.

Not New, Just Newly Important

Ontologies have quietly powered ERPs, CRMs, business intelligence tools, and data warehouses for years. What has changed is how much they matter now that AI agents are consuming our data.

Schema Is Structure, Not Meaning

Take a simple customer table with an ID, a name, and a birth date. A schema will happily accept a company as a "customer" with a "birth date" in the year 3000. It checks that a name is a string and a date is a date, but it has no idea what the data actually means.

What a Knowledge Graph Really Is

A knowledge graph is simply a set of triples: subject, predicate, object. It's a very large umbrella covering labeled property graphs queried with Cypher or GQL, as well as RDF triple stores from the semantic web era. Underneath, these systems still store data in rows, columns, and indexes, built on engines like RocksDB or Cassandra. The "graph" is largely for humans. At the machine level, it's a data storage system with retrieval patterns and engineering trade-offs.

So What Is an Ontology?

From first principles, an ontology is the collision of schemas and relationships. Schemas define types, values, and structure. Graphs add relationships, a third degree of freedom. Together, they make disambiguation possible. Is "Ford" a person, a car company, a reference to Brave New World, or a verb for crossing a river?

Before AI agents, fixed API payloads meant we always knew. An agent doesn't. Unless the data carries its meaning with it, the agent has to guess.

What an Ontology Is Not

An ontology is not a product, and it is not a knowledge graph, though the two work hand in hand.

Ontologies in JSON

TrustGraph has supported importing OWL ontologies, but internally they have always been stored as JSON. Most teams don't just want to reuse existing ontologies. They want to build custom ontologies that describe their own business without having to learning OWL or RDF in addition to modeling their knowledge and processes. JSON makes that far more approachable and interoperable.

New TrustGraph features are coming soon to help you build your own ontologies directly from your own data and systems.

For more information:

GitHub Repository: https://github.com/trustgraph-ai/trustgraph
Discord Community: https://discord.gg/sQMwkRz5GX
Website: https://trustgraph.ai

Semantic Policy Governance in TrustGraph 2.10

Daniel Davis — Mon, 26 Oct 2026 19:47:03 +0000

San Francisco, CA — TrustGraph 2.10 is here. This release is led by policy-based access control for the knowledge graph: SHACL-AF policies, stored in the graph itself, now decide node by node what each user is allowed to see, with every decision captured as a structured audit event.

Around that foundation, TrustGraph 2.10 adds precise control over how GraphRAG walks the graph, two new fast inference services for classification and decision-making, metadata-aware embedding search, and model discovery across all twelve LLM backends. The Workbench gains an interactive VOWL ontology visualiser, in-app version and security advisory notifications, and server-side RDF type filtering for search.

Whether you are putting a knowledge graph in front of users with different clearances, steering retrieval toward the parts of the graph that matter, or wiring structured decisions into agent workflows at millisecond latency, TrustGraph 2.10 delivers a more governed and more controllable platform.

SHACL-AF Policy-Based Query Filtering

Graph queries can now be governed by policy. TrustGraph 2.10 evaluates SHACL-AF policies stored in the urn:graph:policy named graph against every node a query touches, so the same graph can safely serve users with different access rights.

Policies as data: The PolicyFilter loads SHACL-AF NodeShape policies with sh:prefixes namespace resolution, hydrates candidate nodes, and runs each policy's SPARQL SELECT target in precedence order.
Tri-state determinations: Every node resolves to Allowed, Filtered, or Violation. sh:SPARQLRule CONSTRUCT execution parses sh:ValidationResult for severity, message, and tg-pol:blocks, so determinations are generic IRIs with a blocks flag rather than hard-coded strings.
Enforcement mode: When policies exist in urn:graph:policy, queries require a user_context. With no policies loaded, the graph runs in open mode.
Drop-in service: The new triples-query-policy service wraps any triples query backend with per-node policy evaluation, streaming triples through the filter rather than batch processing them.
End-to-end user context: User context is threaded through the REST API, gateway translators, TriplesClient, the SPARQL service, and GraphRAG.
Auditable by design: Structured policy.evaluation audit events, correlated by request_id, are published to notify:tg:policy-events.
Token minting: Administrators can mint user context tokens with the tg-mint-token CLI for testing and service-to-service authentication.
Built for speed: An LRU+TTL query cache (30s, 256 entries), a compiled SPARQL cache (64 entries), a node determination cache, and parallel policy evaluation and hydration keep policy checks off the critical path.

Two reference datasets, AeroSentinel and Bletchley Park, ship with policy rules and multi-persona verification so teams can see policy filtering at work before writing their own.

Major Features & Platform Upgrades

Guided Graph Traversal

GraphRAG traversal can now be steered with optional parameters:

Grounding seeds bypass LLM concept extraction; graph seeds bypass grounding and entity lookup entirely.
Language filtering restricts traversal to edges with matching language tags.
Per-hop traversal instructions apply type, relationship, and named graph restrictions before reranking, so the cross-encoder only scores eligible edges.

Guided traversal is supported across the full stack: the TraversalStep schema, translators, core logic, processor, Python API, socket client, and CLI (--grounding-seeds, --graph-seeds, --languages, --traversal-instructions).

Cloze Model Classification

A new service auto-trains a masked language model (DistilBERT) from labeled examples stored in config and serves single-label classification with confidence scores.

Multiple independent model instances per workspace.
Stratified train/test splitting and configurable minimum accuracy thresholds.
A new trustgraph-cloze package built on FlowProcessor.
Gateway dispatch, REST API, WebSocket client, and CLI tools (tg-invoke-cloze, tg-list-cloze-models).

Decision Scoring with Laya

TrustGraph 2.10 adds a fast, structured decision-making service that answers in roughly 35ms per call, with three output types evaluated in a single request:

Choice: select from a list of options with per-option probabilities.
Score: a probability distribution over ordered levels such as low, medium, high, and critical.
Noul: a binary yes/no confidence score.

Requests are auto-routed by input language (English or multilingual). The new trustgraph-laya package runs on ONNX Runtime against onnx-community/laya-multilingual-ONNX, which drops around 2GB of PyTorch dependencies and lets the service run in the standard flow container. It is available through gateway dispatch, the REST API, the WebSocket client, and the tg-invoke-decision-scoring CLI.

Embedding Search Attributes

Graph, document, and row embeddings in Qdrant can now carry optional metadata attributes, such as rdf_type and generic key-value pairs, enabling payload-based filtering alongside vector similarity search.

The primary use case is filtering graph embedding queries by RDF type to return entities of a specific kind.
Row embeddings now use payload-based schema filtering instead of per-schema Qdrant collections.
Support spans schemas, ontology extraction, embeddings processors, Qdrant read/write, query services, the REST API, Python clients, the CLI, and wire translators.

List Models

Any text-completion backend can now report the models it offers, with normalised metadata:

Multiplexed onto the existing text-completion channel via an operation field, which defaults to "completion" for backward compatibility.
Returns ModelInfo with id, name, context limits, modalities, pricing, and local runtime metadata.
Implemented across all 12 LLM backends.
A new tg-list-models CLI command with table and --json output.

Named Graph and TriG Loading

tg-load-knowledge gains a --graph flag for loading triples into a specific named graph, and now accepts TriG files, preserving named graph structure on import. It also extracts rdf:type triples and passes them through the entity context pipeline for type-aware embeddings.

TrustGraph Workbench 2.3.6

TrustGraph 2.10 ships with Workbench 2.3.6, which brings ontologies to life visually and keeps deployments informed about upgrades.

VOWL Ontology Visualiser

A new plugin renders ontologies using the Visual Notation for OWL Ontologies (VOWL), with a force-directed layout and animated simulation:

owl:Class as circles with wrapped labels, owl:ObjectProperty as arrows with auto-sized label boxes, owl:DatatypeProperty as green rectangles, and rdfs:subClassOf as dashed edges.
Bidirectional relationships drawn as curved bezier arcs, and self-referencing object properties (such as substitutes for) drawn as loop arcs above the node.
Pan (shift+drag), zoom (scroll), and draggable nodes.
A click-to-select detail panel with “add related classes”, a search panel, Show All / Clear controls, and tooltips on every element.
Delivered as a plugin integrated into the build pipeline and route config.

Version Check and Upgrade Notifications

The Workbench now checks its version against the TrustGraph config service at startup:

A status bar indicator shows amber for available patches and red for major upgrades, and opens an overlay when clicked.
The overlay shows the version diff, a description, and links to release notes and the deployment guide.
Security advisories are displayed with severity colour coding (red for critical/high, amber for medium), the fix version, and a summary linking to the advisory.
X-Timezone and X-Language headers are sent with the check for locale-aware messaging.
The overlay opens automatically on first detection and remembers dismissed versions, and the check stays silent when version information or the config service is unavailable.

RDF Type Filter for Search

Semantic search can now be filtered by entity type on the server side, building on the new embedding search attributes:

A dropdown selector when the ontology has 15 classes or fewer, and SPARQL-backed autocomplete for larger ontologies, with a “Searching…” indicator.
A new rdf_type parameter on GraphEmbeddingsQueryRequest and FlowApi.graphEmbeddingsQuery().

Workbench Improvements

GraphRAG explainability labels: Node labels are truncated at 20 characters and edge labels at 16, with full text in hover tooltips.
Ontology data loading: The useOntologySchema hook now uses targeted rdfs:label, rdfs:domain, rdfs:range, rdfs:comment, and rdfs:subClassOf queries instead of a broad allTriples query.
Named graph queries: useRawGraphData now searches across all named graphs by default.
Cleanup: The unused legacy Socket interface has been removed from @trustgraph/client.

Performance

SPARQL BGP query cache: A per-BGP cache eliminates redundant triple-store round trips when intermediate solutions resolve to the same (s, p, o) query, cutting triple-store calls by around 70% for typical join patterns.
Policy filter caching and parallelism: Node determination caching plus parallel policy evaluation and hydration.
ONNX Runtime for decision scoring: Around 2GB less container weight, with Laya running in the standard flow container.

Platform Improvements

Schema refactoring: schema/services/ and schema/knowledge/ have been flattened into domain-based modules (llm.py, embeddings.py, triples.py, structured.py, and more) for easier navigation.
Simpler literals: datatype and language now live directly on the Literal type.
Container restructuring: trustgraph-hf is renamed to trustgraph-torch to reflect its role as the torch-dependent services container, and trustgraph-laya is extracted as a separate package.
Resilient Loki logging: A custom Loki handler replaces python-logging-loki, falling back to stderr when Loki is unavailable, retrying periodically, and losing no messages on transient failures.

Reliability and Correctness Fixes

Claude temperature: Streaming now uses messages.create(stream=True) and temperature is passed via extra_body for Anthropic SDK v1.x compatibility.
VertexAI and Google AI Studio: Fixed async model listing and metadata derivation.
GraphRAG label fallback: Label resolution now falls back gracefully when rdfs:label is missing, the IRI name heuristic is removed, and a named graph parameter is supported.
Policy filter hardening: Fixed error propagation and cache reuse in the policy response translator, handled URIRef graph context from rdflib Dataset.quads(), corrected streaming versus batch processing, and hardened SPARQL evaluation and caching.
Ontology extraction: rdfs:label and rdfs:comment are now included in ontology type and property extraction.
User context propagation: user_context now flows correctly from the SPARQL service to triples queries.
IAM mint-token routing: Mint-token is routed through /api/v1/iam, user lookup by username/self is resolved, and the WebSocket user_context key is fixed.
Ontology definition parsing: Removed eval() usage from ontology definition parsing.

Infrastructure & Developer Experience

Testing: Mock signatures updated across the test suite for the new user_context parameter.
Cleanup: Stale test scripts, legacy docs, and root directory clutter removed.
Tech specs: New specifications for policy filtering, embedding search attributes, guided graph traversal, user context, model listing, the cloze model service, and the decision scoring service.

Breaking Changes

Please review these changes before upgrading to TrustGraph 2.10:

Schema directory restructure: schema/services/ and schema/knowledge/ have been flattened into domain modules. Imports from the old paths will break.
Literal fields: o_datatype and o_language are removed from Triple. Use Literal.datatype and Literal.language instead.
Container rename: The trustgraph-hf container and package are now trustgraph-torch. Update container references and docker-compose configurations.
Policy enforcement: Once policies are loaded into urn:graph:policy, queries require a user_context. Deployments without policies continue to run in open mode.

Get Started

TrustGraph 2.10 is available now on GitHub.

Load SHACL-AF policies to govern who sees what in your graph, steer GraphRAG with guided traversal, add millisecond decision scoring and trainable classification to your workflows, and explore your ontologies visually in the Workbench.

For more information:

TrustGraph changelog: https://docs.trustgraph.ai/changelog/trustgraph.html
Workbench changelog: https://docs.trustgraph.ai/changelog/trustgraph-ui.html
Documentation: https://docs.trustgraph.ai
GitHub Repository: https://github.com/trustgraph-ai/trustgraph
Discord Community: https://discord.gg/sQMwkRz5GX
Website: https://trustgraph.ai

TrustGraph 2.9: A Config-Driven Workbench, Leaner Core, and Smarter Catalog Loading

Daniel Davis — Wed, 23 Sep 2026 18:08:12 +0000

San Francisco, CA — TrustGraph 2.9 is here. This release is led by the most significant evolution of the TrustGraph Workbench to date: a fully config-driven navigation system, a DCAT catalog welcome experience, embedded semantic search, an in-app documentation viewer, a streaming demo data loader, and IAM administration plugins — all delivered as composable, manifest-driven plugins.

Alongside the Workbench, TrustGraph 2.9 sharpens the core platform: the LangChain dependency has been removed from the flow and embeddings packages, the bulk API now supports named graphs, container images ship with default models pre-loaded, and a series of RDF correctness fixes hardens multilingual and typed-literal handling.

Whether you are tailoring an investigation interface to your domain, publishing a data catalog your users can browse on day one, or trimming dependency bloat from production containers, TrustGraph 2.9 delivers a more configurable and more maintainable foundation.

TrustGraph Workbench 2.2.4

TrustGraph 2.9 ships with Workbench 2.2.4, and the UI changes are the headline of this release. The Workbench is no longer a fixed application — it is a configurable platform assembled from JSON.

Config-Driven Navigation System

Hardcoded routing is gone. The Workbench now resolves all navigation through an IntentRouter driven by JSON configuration files:

routes.json — route definitions
tabs.json — tab layout and visibility
navigation.json — navigation structure
components.json — component bindings

Every screen in the Workbench is now declarative. Teams can reorder, rename, hide, and reorganize the entire interface by editing configuration rather than forking code. Tabs marked as hidden in config disappear from the tab bar while remaining routable by direct URL — ideal for deep-link destinations that shouldn't clutter the main navigation.

Component IDs have been renamed for clarity as part of this transition:

raw-graph → graph-navigator
explore → context-graph-navigator
doc-rag → document-rag
data → table-explorer

Welcome Page with DCAT Catalog

The Workbench now opens with a landing page built for real deployments:

A DCAT catalog display, fetched via SPARQL, showing datasets with thumbnails, keywords, access service buttons, and documentation links.
Structured catalog and dataset sections with visual hierarchy headings.
A “Documents Submitted” section showing processed documents with title, description, tags, and flow/collection submissions.
A graceful fallback to a search box and quick-link cards when no catalogs exist.

Instead of landing on an empty explorer, users now arrive at a browsable catalog of what your knowledge platform actually contains.

Embedded Semantic Search

Search is now a first-class Workbench experience:

Embedding-based semantic search across your knowledge graph.
Type chips, palette-coloured by URI hash, that identify entity types at a glance — and open type nodes in the side panel when clicked.
Keyword pills and thumbnail display for every result.
A RawNodeDetailPanel side viewer for inspecting results in place.
Initial queries read from URL parameters, enabling cross-page search flows.
Available as a workflow card, so search can be composed into any config-driven page.

Documentation Viewer

Documentation now renders inline. The Workbench includes a markdown viewer that resolves dcat:landingPage URLs directly in the app, with custom renderers for image URL resolution, external links, and relative hrefs, plus back-button navigation. Dataset documentation lives next to the data it describes.

Demo Data Loader

A new manifest-driven plugin makes it trivial to load ready-made datasets:

A streaming Turtle parser with bulk import.
Support for knowledge, catalogs, ontologies, queries, tools, prompts, schemas, and structured data.
A progress overlay with phase tracking so users can watch large loads complete.
Markdown-rendered dataset detail pages.
Catalog triples imported into the dedicated urn:graph:catalog named graph — kept cleanly separate from user knowledge.

IAM Admin Plugins

Platform administration moves into the Workbench. A base IAM client API now powers plugins for:

Workspace admin — create, list, enable, and disable workspaces.
User admin — list and manage users and API keys.
API key management — issue and manage keys directly from the UI.

Plugin manifests now support hidden sections, so admin surfaces can exist without appearing in primary navigation.

Smarter Selectors and Thumbnails

Header selector pills for workspaces, collections, and flows now show human-readable names instead of bare IDs, and dropdowns display descriptions.
schema:image support in the useNodeDetail hook and RawNodeDetailPanel (via @trustgraph/trustkit) brings entity thumbnails into search results and node detail panels.

Major Features & Platform Upgrades

LangChain Removed from the Core

TrustGraph 2.9 removes the LangChain dependency from trustgraph-flow and trustgraph-embeddings-hf, replacing thin wrappers with direct library usage:

The token chunker uses tiktoken encode/decode directly instead of langchain.TokenTextSplitter.
The recursive chunker is reimplemented natively with the same separator hierarchy (\n\n, \n, space, empty string).
The PDF decoder uses pypdf.PdfReader instead of langchain_community.PyPDFLoader.
HuggingFace embeddings use sentence_transformers.SentenceTransformer directly instead of langchain_huggingface.HuggingFaceEmbeddings.

This removes roughly 15 transitive dependencies from the flow and HF container images — smaller images, faster builds, and a dependency surface you fully control.

Named Graph Support for the Bulk API

Bulk triple import and export now carry an optional g (named graph) field:

The Triple dataclass gains a g: str = "" field.
Sync and async bulk clients propagate the graph URI.
The graph URI is sent as a plain string for Cassandra compatibility.

This is what enables catalog graph loading over WebSocket — and it's how the Demo Data Loader imports catalog triples into urn:graph:catalog without touching user graphs.

Pre-Loaded Default Models

Flow and Docling container images now pre-load their default models at build time. First-request download latency is eliminated — containers answer their very first request at full speed.

Configurable Timeouts

Prompt and librarian client timeouts are now configurable via environment variables, so slow LLM backends and large knowledge operations can be tuned per deployment.

MCP Streamable HTTP

The MCP client has been updated to support streamable HTTP transport contracts, keeping TrustGraph interoperable with the evolving MCP ecosystem.

Reliability and Correctness Fixes

TrustGraph 2.9 includes a set of targeted fixes, several of them hardening RDF and SPARQL correctness:

SPARQL boolean evaluation: BIND evaluation now checks bool before int/float, preventing Python's bool ⊂ int subclass relationship from coercing booleans into integers.
N-Quads literal preservation: parse_nquads now preserves datatype URIs and language tags on literal objects.
Language tag validation: Language tags are validated before being emitted, preventing malformed RDF output.
CLI exception handling: Document embeddings tools now catch the correct exception types instead of silently swallowing errors.
REST triples query: Response format aligned with the explainability response format.
Token cost reporting: A bare except: in show token costs replaced with a specific exception type.
Python version alignment: The requires-python constraint is now aligned with the MCP SDK dependency minimum.

Infrastructure & Developer Experience

CI workflow: Container manifest creation now runs per-container instead of waiting for all builds — faster, failure-isolated releases.
Gateway request keys: Typed aiohttp request keys replace string-based dictionary access for audit annotations, making the audit pipeline safer to extend.
Test modernization: MCP transport compatibility tests updated to remove SDK-internal assertions; PDF decoder tests updated for the pypdf migration.
README refresh: Revised for branding, clarity, RDF/OWL details, and a new video link.

Breaking Changes

Please review these changes before upgrading to TrustGraph 2.9:

LangChain removed: Any code importing LangChain via TrustGraph packages must migrate to the underlying libraries directly — tiktoken, pypdf, and sentence-transformers.
trustgraph-unstructured dropped: The package has been removed. Use the Docling decoder (trustgraph-docling) instead.
Workbench navigation is config-driven: Custom Workbench deployments must now provide the JSON navigation configuration (routes.json, tabs.json, navigation.json, components.json).
Component IDs renamed: Configuration and plugin manifests referencing raw-graph, explore, doc-rag, or data must update to graph-navigator, context-graph-navigator, document-rag, and table-explorer respectively.

Get Started

TrustGraph 2.9 is available now on GitHub.

Configure your own Workbench navigation, publish a DCAT catalog as your landing experience, load demo datasets with the streaming loader, and deploy leaner LangChain-free containers with pre-loaded models.

For more information:

TrustGraph changelog: https://docs.trustgraph.ai/reference/changelog/trustgraph.html
Workbench changelog: https://docs.trustgraph.ai/reference/changelog/workbench.html
Documentation: https://docs.trustgraph.ai
GitHub Repository: https://github.com/trustgraph-ai/trustgraph
Discord Community: https://discord.gg/sQMwkRz5GX
Website: https://trustgraph.ai

TrustGraph 2.8: Async Infrastructure, Hybrid Retrieval, Structured Output, and a Plugin-Based Workbench

Daniel Davis — Tue, 08 Sep 2026 15:39:37 +0000

TrustGraph 2.8 is available now, with a major upgrade to the platform foundation for enterprise knowledge and AI systems.

This release focuses on a practical problem: AI applications must remain reliable when they grow beyond a single demo, a single document library, or a small number of workspaces. That means scalable messaging, dependable retrieval, typed model outputs, observable services, auditable decisions, and an interface that can adapt to different domains.

Async pub/sub: removing a scaling bottleneck

TrustGraph has completed its migration from thread-per-consumer pub/sub to an asynchronous architecture.

In the previous model, a deployment with many workspaces and flows could consume hundreds of threads. TrustGraph 2.8 replaces that design with configurable async receive and send pools.

Async support now covers:

Apache Pulsar through pulsar.asyncio.Client
RabbitMQ through aio-pika
Kafka through aiokafka
The API gateway and reverse gateway

For operators, this means a much stronger basis for multi-workspace deployments. For custom processor developers, it also means migrating extensions to the async model.

Hybrid retrieval for Document RAG

Document RAG now combines two complementary retrieval strategies:

Vector similarity for conceptual relevance.
BM25 keyword retrieval for exact terms, names, identifiers, and domain-specific phrases.

TrustGraph merges the results with Reciprocal Rank Fusion (RRF).

The first keyword-index implementation uses SQLite FTS5 and scopes indexes by workspace and collection. If keyword retrieval is unavailable, TrustGraph degrades gracefully rather than blocking retrieval entirely.

Hybrid retrieval is especially useful for enterprise content, where a user might search semantically in one query and need an exact product code, legal term, technical error, or named entity in the next.

Native structured LLM output

TrustGraph 2.8 carries JSON schemas from prompt definitions through the completion layer into provider-native structured-output APIs.

This reduces the need to parse loose natural-language responses after generation. A runtime compatibility checker determines whether a prompt can use schema-enforced output with the selected backend.

Supported providers include OpenAI, vLLM, Ollama, Claude, Mistral, Azure OpenAI, Vertex AI Gemini, Google AI Studio, Bedrock, TGI, Llamafile, and LM Studio.

For agent builders, this enables more dependable workflows such as:

Data extraction into a validated schema.
Typed tool inputs.
Machine-readable report sections.
UI-ready generated data.
Controlled outputs for downstream automation.

Multimodal and document ingestion

TrustGraph now includes a pluggable image-to-text service with an OpenAI vision backend, gateway support, REST and WebSocket clients, IAM integration, and the tg-describe-image CLI.

The release also introduces a Docling-powered document decoder. The trustgraph-docling package supports PDF, DOCX, XLSX, PPTX, HTML, Markdown, and CSV, with page and hybrid chunking modes.

These services widen the kinds of enterprise information that can enter a knowledge pipeline.

Auditability and observability

TrustGraph 2.8 adds structured audit events for gateway activity and IAM decisions. Events include request and client-IP correlation, and they can be consumed into organization-managed storage and retention systems.

Metrics coverage now spans the platform from infrastructure services through embeddings, reranking, query paths, agent orchestration, gateway authentication, knowledge extraction, and IAM.

All platform metrics now use the tg_ prefix. The release also reduces metric-cardinality risk by removing workspace and flow labels from infrastructure histograms.

Extending the platform

A generic gateway passthrough mechanism now supports enterprise services outside the core TrustGraph platform. It uses opaque JSON request and response payloads with dynamic service lookup.

This makes it possible to attach organization-specific services, such as attestation engines, without modifying TrustGraph core code.

TrustGraph also continues to improve RDF support:

Language tags and XSD datatypes are preserved.
FILTER(LANG()) SPARQL patterns are supported.
Unicode-aware normalization preserves non-English entity names.
Cassandra now indexes literal RDF objects for graph querying by object value.

Workbench 2.0.3

TrustGraph 2.8 includes Workbench 2.0.3, which moves the UI to a manifest-driven plugin architecture.

Explorers can now be dynamically loaded as plugin packages. Teams can use remote plugins, multi-component bundles, and customer-specific plugins.json configurations.

Other Workbench additions include:

Five runtime themes: Dark, Midnight, Light, High Contrast, and Warm.
A shared themed component library.
3D graph visualization through GraphCanvas3D.
A Threat Explorer for OCSF insider-threat investigations.
Incremental explorer data loading and search-result highlighting.
Automatic prompt-template discovery using the template. configuration prefix.

Upgrade notes

TrustGraph 2.8 contains important breaking changes:

The synchronous pub/sub layer is removed; custom processors must use async producer and registration APIs.
The default API port is now 8888, replacing 8088.
Vertex AI defaults to the global region rather than us-central1.
Existing RDF data that depends on language tags, datatypes, or literal-object lookup should be re-ingested.
The system-health CLI no longer accepts --api-url or --pulsar-url.

Get started

TrustGraph 2.8 is open source and available now:

Part 3: How TrustGraph's Knowledge Cores End the Memento Nightmare

Daniel Davis — Mon, 28 Apr 2025 16:22:54 +0000

In Parts 1 and 2, we exposed the dangerous flaw in most current AI "memory": like Leonard Shelby in Memento, our systems often operate on disconnected fragments, unable to form the interconnected knowledge needed for reliable reasoning. We saw how this reliance on context-stripped, relationship-blind, and provenance-oblivious data dooms AI to a cycle of confident errors and hallucinations, just as Leonard's fragmented note system led him down dangerous paths.

So, how do we break the loop? How do we give AI the ability to truly know, not just recall fragments? The answer isn't a slightly better system of Polaroids and notes. The answer is to build the integrated, structured understanding Leonard tragically lacked: a Knowledge Core.

This is precisely what TrustGraph, the AI Provisioning Platform, delivers through its advanced TrustRAG engine. It moves beyond the limitations of fragmented recall by architecting genuine knowledge:

Mapping the Connections (Solving Relationship Blindness): Unlike Leonard staring at isolated clues, TrustGraph automatically builds a Knowledge Graph (KG). It doesn't just store facts; it explicitly maps the relationships between them (e.g., "Person X works for Company Y," "Event A caused Event B"). This Knowledge Graph is the coherent narrative structure Leonard couldn't form – the understanding of how things connect.
Delivering Contextualized Scenes (Solving Context Stripping): Leonard reviewed one Polaroid at a time, losing the big picture. TrustRAG uses a hybrid retrieval process. Vector search identifies relevant starting points within the Knowledge Graph, but then TrustRAG traverses the graph connections, constructing a subgraph of related entities and relationships. Instead of isolated fragments, the LLM receives a connected scene – a relevant slice of the knowledge core with inherent local context.
Verifying the Clues (Addressing Provenance Oblivion): Leonard couldn't be sure when or why he wrote his notes. TrustGraph's Knowledge Graph architecture is designed to incorporate provenance metadata directly with the facts and relationships it stores (source, timestamp, reliability). TrustRAG can then leverage this, allowing the AI to weigh information based on its origins, escaping the trap of treating all retrieved fragments as equally trustworthy.

Escaping the Memento Loop: The Power of a Knowledge Core

By building and utilizing this structured Knowledge Core, TrustGraph fundamentally changes AI capabilities:

Enables Reliable Reasoning: Provides the interconnected facts and explicit relationships needed for complex reasoning, synthesis, and understanding causality – tasks impossible for Leonard (and fragment-based AI).
Dramatically Reduces Hallucinations: Grounding responses in a verifiable graph of knowledge, potentially weighted by provenance, significantly reduces the chance of fabricating connections or asserting baseless claims.
Offers Explainable Insight: The retrieved subgraph itself acts as an explanation, showing how the AI arrived at its context based on the knowledge core's structure – unlike Leonard's often opaque leaps of faith.

Provisioning Reliable Knowledge, Not Just Infrastructure

TrustGraph isn't just a concept. It's an AI Provisioning Platform that containerizes the entire intelligent system – the LLMs, the necessary tools, and the essential TrustRAG Knowledge Cores – allowing you to reliably provision this complete, knowledgeable AI stack anywhere (Cloud, On-Prem, Edge). We're providing the robust, managed infrastructure for knowledge that Leonard's fragile system lacked.

Stop building AI condemned to relive Leonard Shelby's nightmare. Stop provisioning systems based on fragmented recall and start delivering applications grounded in genuine understanding.

Give your AI the gift of coherent memory. Build with a Knowledge Core.

Explore TrustGraph on GitHub and see how we structure knowledge
Read the TrustRAG documentation for technical details
Join our community and discuss the future of AI knowledge

Provision AI that knows. Provision it with TrustGraph.

Part 2: Why Your AI is Stuck in a Memento Loop

Daniel Davis — Sat, 26 Apr 2025 22:19:42 +0000

In Part 1, we likened today's typical AI "memory" to the plight of Leonard Shelby in Memento: brilliant at accessing isolated fragments (Polaroids, notes, tattoos) but unable to weave them into the coherent tapestry of true knowledge. He remembers that he has a note, but not necessarily the reliable why or the how it connects to everything else. Now, let's diagnose why popular RAG approaches, inherently create this dangerous, fragmented reality for our AI.

Imagine Leonard's investigation. His "database" consists of disconnected snapshots and cryptic assertions. When he tries to solve a problem ("Who is John G?"), he shuffles through these fragments, looking for clues that feel related. This is strikingly similar to how typical RAG approaches use “memory” :

The Polaroid Snapshot (Context Stripping): Just as Leonard's Polaroids capture only a single moment divorced from what came before or after, document chunking for vectorization strips vital context. A retrieved sentence saying "Project Titan deadline is critical" loses the surrounding discussion about why it's critical, who set it, or what happens if it's missed. The AI gets the snapshot, not the scene.
Cryptic Notes & Missing Links (Relationship Blindness): Leonard's notes might say "Meet Natalie" and "Don't believe Dodd's lies." Vector search can find documents mentioning "Natalie" and documents mentioning "Dodd," but like Leonard, it lacks the explicit map connecting them. Does Natalie know Dodd? Is she part of the lies? The relationships aren't inherently encoded in the vector similarity. Finding similar topics doesn't mean understanding their causal or structural connection, leaving the AI to guess these critical links.
Trusting Faded Ink (Provenance Oblivion): Leonard must trust his fragmented notes, even if they were written under duress, based on misinformation, or are simply outdated. Standard RAG often does the same, treating all retrieved text fragments as equally valid assertions. It frequently lacks a robust mechanism to track provenance – the source, timestamp, or reliability score of the information. An old, debunked "fact" retrieved via vector similarity looks just as convincing to the LLM as a fresh, verified one.

The Leonard Shelby Effect in AI:

When AI operates with only these disconnected, context-stripped, relationship-blind, and provenance-oblivious fragments, its reasoning becomes dangerously flawed:

Hallucinating Connections: Like Leonard assuming connections between unrelated clues, the LLM invents relationships between text fragments simply because they were retrieved together.

Contradictory Actions: Acting on conflicting "facts" because it can't verify which source or connection is trustworthy or current.

Inability to Synthesize: Unable to build a larger picture or draw reliable conclusions because the foundational links between data points are missing or inferred incorrectly.

We are building AI systems trapped in a Memento loop: forever re-reading fragmented clues, capable of impressive recall but incapable of forming the durable, interconnected knowledge needed for reliable reasoning and true understanding. They are architecturally destined to make potentially disastrous mistakes based on an incomplete and untrustworthy view of their "world."

If we want AI to escape this loop, we need to fundamentally change how we provide information. We need to move beyond retrieving isolated Polaroids and start building systems that can understand the whole, interconnected story.

How do we provide that interconnected narrative? How do we build AI memory that understands relationships and provenance? Stay tuned for Part 3 where we reveal the architecture for true AI knowledge.

Have you seen an AI confidently stitch together unrelated facts like Leonard building a flawed theory? Let us know:

🌟 TrustGraph on GitHub 🚢
Join the Discord 👋

Part 1: The Memento Problem with AI Memory

Daniel Davis — Fri, 25 Apr 2025 21:58:31 +0000

We're drowning in takes about AI "memory." RAG is hailed as the silver bullet, promising intelligent systems that learn and retain information. But let's be brutally honest: most implementations are building agents that are drowning in data and suffocating from a lack of knowledge.

These systems excel at retrieving fragments – isolated data points plucked from documents and observations stripped of their origins. Ask it a question, and it surfaces a text snippet that looks relevant. This feels like memory - like recall.

But it isn't knowledge.

Real knowledge isn't just storing data points - it's understanding their context, their provenance (where did this information come from? is it reliable?), and their relationships with other data points. Human memory builds interconnected information networks while current AI "memory" approaches just hoard disconnected digital Post-it notes. We are mistaking the retrieval of isolated assertions for the synthesis of contextualized understanding.

Think of Leonard Shelby in Christopher Nolan's film Memento. Suffering from anterograde amnesia, Leonard can't form new memories. To function, he relies on a system of Polaroids, handwritten notes, and even tattoos – externalized fragments representing supposed facts about his world and his mission to find his wife's killer.

Today's RAG systems often operate eerily like Leonard. They receive a query and consult their "Polaroids" – the vector embeddings of text chunks. They retrieve the chunk that seems most relevant based on similarity, a fragment like "Don't believe his lies" or "Find John G." Unfortunately, like Leonard, these RAG systems lack the overarching context and the relationships between these fragments. It doesn't inherently know how the note about John G. relates to the warning about lies, or the sequence of events that led to these assertions being recorded.

And this fragmentation is where disaster strikes. Leonard, working only with disconnected clues, makes fatal misinterpretations. He trusts the wrong people, acts on incomplete information, and is manipulated because he cannot form a cohesive, interconnected understanding of his reality. His "memory," composed of isolated data points, leads him not to truth, but deeper into confusion, madness, and catastrophe.

An AI that can quote a source but doesn't inherently grasp how that source connects to related concepts or whether that source is trustworthy isn't remembering – it's echoing fragments, just like Leonard reading his own fragmented notes.

This fundamental flaw leads to confident hallucinations, an inability to reason deeply about causality, and systems that can misled. We're building articulate regurgitators, not truly knowledgeable thinkers.

We need to stop celebrating glorified search indices as "memory" and start demanding systems capable of building actual knowledge. Until then, we're just building better mimics, doomed to repeat the mistakes born from disconnected understanding.

Next time in Part 2: We dissect why this fragment-recall approach fundamentally breaks down when AI needs to reason, synthesize, or understand causality.

Does your AI feel like it knows things, or just recalls text like Leonard Shelby reading his notes? Reach out to us below:

🌟 TrustGraph on GitHub 🧠
Join the Discord 👋

The Symphony of the AI System

Daniel Davis — Mon, 14 Apr 2025 20:33:53 +0000

Beyond the Monolith: Why the Future of AI is a Symphony, Not a Soloist

For years, the science fiction dream and much of the AI hype cycle has revolved around a singular goal: building the one, giant Artificial General Intelligence (AGI). A single, monolithic model capable of learning, reasoning, and solving any problem like a human. It's a captivating vision, but is it the only path forward? Or even the right one for practical, powerful, and responsible AI?

It's not. The pursuit of a single, all-encompassing model overlooks the messy, beautiful complexity of intelligence itself and ignores the profound limitations inherent in monolithic approaches. The true future of advanced machine intelligence lies not in a singular soloist, but in a symphony of tightly interconnected, specialized software components working in harmony.

The Cracks in the Monolith

Trying to build a single AI model to "solve" human-level intelligence faces immense hurdles:

Garbage In, Garbage Out: Training such models requires unfathomable amounts of data and human intervention to evaluate the quality of the inputs and outputs which is subject to individual biases.
Brittleness & Lack of Nuance: A single model, can struggle with specialized tasks outside its core training distribution. It's the ultimate "jack of all trades, master of none," potentially failing when encountering edge cases.
Operational Nightmares: Deploying, managing, updating, and securing a single, gigantic model across diverse environments (cloud, on-prem, edge) is incredibly complex and inefficient. How do you provide fine-grained updates or tailored capabilities?
Explainability & Auditability Black Holes: Understanding why a monolithic model made a specific decision can be nearly impossible, hindering trust, debugging, and crucial safety checks.
Concentration of Power & Risk: Placing all intelligent capabilities into a single entity creates immense concentrations of power and systemic risk.

The Rise of the System: Intelligence as an Interconnected Network

Nature offers a better blueprint. The human brain isn't a homogenous blob; it's a highly specialized, interconnected system of regions communicating dynamically. Complex tasks emerge from the coordinated activity of these specialized parts. Similarly, the future of advanced AI lies in building systems that mirror this principle.

Imagine an AI architecture that functions less like a single giant brain and more like a biological nervous system – what we might call a Synaptic Automation System. This system possesses key characteristics:

Modular Expertise: Instead of one model knowing everything, the system leverages specialized "Intelligent Cores" – components encapsulating deep expertise, algorithms, or processing for specific domains. These cores are the seeds of adaptable skill.
Dynamic Synthesis & Deployment: The system doesn't just run pre-built applications. Based on the available Cores and the task at hand, it dynamically generates and deploys the necessary processing modules on the fly. Think of it assembling a specialized task force exactly when needed.
Emergent Learning & Adaptation: Faced with unique situations, the system doesn't just rely on past training. It can generate custom learning modules to analyze new data, identify patterns, and evolve its understanding over time through integrated feedback loops, constantly refining its capabilities.
Inherent Connectivity & Communication: Like synapses firing, components constantly communicate, sharing context and triggering actions across the system. This allows for holistic reasoning and complex workflow execution far beyond simple pipelines.
Transparency & Trust: Crucially, because the system generates plans and modules dynamically, it can also be designed to make these processes transparent. The 'reasoning' behind an automated workflow can be audited, allowing for verification, compliance, and crucial safety checks.
Safety First: Built-in mechanisms constantly monitor the system's actions, detecting potential harms or deviations from desired boundaries, enabling adaptive responses to ensure responsible operation.
Universal Presence: This entire intelligent system isn't locked to specific hardware. It's designed as a fabric that can be deployed consistently across any cloud, bare-metal servers, or edge devices, bringing intelligence wherever it's needed.

TrustGraph: Embodying the Synaptic Vision

This isn't just theory. Platforms like TrustGraph are pioneering this Synaptic Automation System approach. By focusing on dynamically connecting modular Intelligent Cores, synthesizing processes on demand, enabling continuous learning through feedback, ensuring auditability and safety, and running universally across infrastructures, TrustGraph demonstrates the power of this interconnected model over the monolithic dream.

The Symphony Takes the Stage

The future of impactful AI won't be a single, monolithic oracle attempting to know everything. It will be a dynamic, adaptable, and interconnected system – a symphony of specialized components working together seamlessly. This approach offers a path towards more scalable, resilient, trustworthy, and ultimately more powerful machine intelligence capable of tackling the world's complex challenges. It’s time to move beyond the monolith and embrace the power of the network.

🌟 TrustGraph on GitHub 🧠

Join the Discord 👋

Watch tutorials on YouTube 📺️

Stop Thinking AI Agents, Start Engineering Autonomous Knowledge Operations

Daniel Davis — Wed, 09 Apr 2025 19:24:21 +0000

Beyond the Buzz: Why Autonomous Knowledge Operations Matters More Than Just AI Agents

The tech world has been ablaze with talk of AI agents. We see demos of agents booking flights, writing code snippets, or summarizing articles. It's exciting, capturing the imagination with glimpses of AI performing tasks previously requiring human operations. But as we move from demos to deployment, simply thinking in terms of "agents" falls short.

The real paradigm shift isn't just about creating smarter tools (agents); it's about building systems capable of continuous, reliable, and goal-directed operations that are powered by deep contextual understanding. This is the philosophy of TrustGraph’s Autonomous Knowledge Operations.

What's the Difference? Isn't an Agent Autonomous?

An AI Agent, in its common definition today, is often:

Task-Oriented: Designed to perform a specific, often short-lived task (e.g., answer a question, draft an email).
Reactive: Primarily responds to direct input or triggers.
Component-Level: Can be thought of as a sophisticated function call or a smart script.
Potentially Isolated & Knowledge-Poor: Might operate with limited context or struggle to access and reason over the complex web of information within an enterprise.

While powerful, these agents often lack the deep knowledge integration, robustness, persistence, and manageability needed for mission-critical business functions. Running a complex business process isn't like asking an agent to write a poem; it requires continuous awareness, adaptation, reliability, and critically, intelligent use of relevant knowledge.

Autonomous Knowledge Operations, is a broader, more systemic approach where autonomy is directly fueled by intelligent information:

Goal-Oriented & Continuous: Focused on achieving and maintaining a desired state or objective over time. Action is driven by understanding the goal within its knowledge context.
Proactive, Persistent & Knowledge-Driven: Actively monitors, plans, and acts by constantly interpreting its environment through a rich knowledge base. It runs continuously, learning and adapting.
System-Level: Encompasses not just agents but the entire infrastructure, knowledge pipelines (RAG, KG, VectorDBs), integration points, and feedback loops required for sustained, intelligent operation.
Fueled by Deep Knowledge & Context: Leverages rich, relevant, and timely information drawn from enterprise sources. This requires sophisticated RAG pipelines with both vector databases and knowledge graphs.
Observable & Manageable: Designed with built-in monitoring, logging, tracing, and controls to ensure reliability, understand the knowledge-driven behavior, and allow for intervention or adjustments.
Reliable & Scalable: Built on enterprise-grade infrastructure capable of handling failures, scaling resources, and meeting performance demands for both computation and knowledge processing.

Why This Shift in Thinking Matters

Focusing solely on "agents" leads to several potential pitfalls in enterprise adoption:

The "Demo-to-Production" Gap: Cool agent demos often bypass the hard parts: robust knowledge integration, error handling, scalability, security, and monitoring needed for real-world value.
Context Starvation: Agents without deep, structured context – the kind derived from integrated Knowledge Graphs combined with Vector DBs – struggle with complex reasoning and nuanced tasks common in business. This is a knowledge access problem.
Infrastructure Nightmare: Managing dozens of agents and their disparate, potentially inconsistent knowledge sources, ensuring reliability, and providing consistent data access is an operational burden.
Lack of Trust: How do you monitor, debug, or guarantee the performance of agents acting on potentially incomplete or misunderstood information? Observability into the knowledge retrieval and reasoning process is non-negotiable.

Building for Autonomous Knowledge Operations: The TrustGraph Philosophy

This is precisely the philosophy behind TrustGraph. We realized that the conversation needed to evolve beyond just the agent itself to encompass the entire knowledge-driven system. TrustGraph is an Autonomous Knowledge Operations Platform designed to provide the foundational elements missing from simple agent frameworks:

Enterprise-Grade Infrastructure: It provides the scalable, reliable backend needed to run operations continuously, managing both computation and knowledge flows.
Integrated RAG (KG + VectorDB): It automates the deployment of sophisticated RAG pipelines, acknowledging that deep context and reliable autonomy stem from leveraging both semantic similarity (vectors) and structured relationships (knowledge graphs).
Unified LLM Access: It abstracts the complexity of dealing with multiple LLM providers, allowing the system to focus on applying the best reasoning to the available knowledge.
Full Observability Stack: It builds in logging, metrics, and tracing from the ground up, including insights into the RAG process, because trusting autonomous systems requires understanding how they arrive at decisions based on knowledge.

By focusing on the knowledge-driven operation rather than just the agent, we can build systems that don't just perform tasks but achieve persistent business outcomes reliably, efficiently, and intelligently.

The Future is Systemic and Knowledge-Rich

AI agents are a vital component of the future. But the true transformation lies in weaving these components into robust, knowledge-aware, observable, and continuous Autonomous Knowledge Operations. This requires a shift in mindset and tooling – moving from building smart tools to engineering intelligent, self-managing systems powered by deep understanding. That's the future we're building towards with TrustGraph.

🌟 TrustGraph on GitHub 🚀

Join the Discord 👋

Watch tutorials on YouTube 📺️

How-to Use AI to See Your Data in 3D

Daniel Davis — Mon, 30 Dec 2024 22:28:01 +0000

We all know the struggle. You're drowning in massive amounts of unstructured data, trying to make sense of the complex web of relationships hidden within.

That's where TrustGraph's Data Workbench 3D visualizer comes in. Forget clunky interfaces and limited perspectives. We're bringing the power of 3D visualization to your data analysis, giving you an intuitive, immersive, and interactive way to uncover hidden patterns and relationships.

Why 3D Matters for AI Developers

Everyone knows the power of GraphRAG. But everyone also knows the limitations of data visualizations in 2D. With 3D, you can:

Uncover Hidden Relationships: In a 2D graph, nodes can clutter the screen, obscuring vital connections. 3D lets you see the true depth of your data, revealing relationships you might otherwise miss.
Intuitive Navigation: Our brains are wired to understand spatial relationships. Navigating a 3D visualization is naturally more intuitive than panning and zooming across a flat surface.
Enhanced Understanding: The spatial layout of nodes in 3D can reveal clusters, hierarchies, and anomalies that are hard to spot in only 2D.
Interactive Data: Let’s be honest, a 3D visualization looks cool! Impress stakeholders with compelling and interactive visualizations that show the hidden gems of wisdom in your data.

Getting Started: Your 3D Data Journey

Before we can use the 3D visualizer, we must first deploy TrustGraph.

Step 1: Setting Up (If you haven't already)

Navigate to Configuration Portal to select all the components for your build.

Follow all the instructions on the Finish Deployment tab get TrustGraph running. The Data Workbench will be accessible at port 8888.

Step 2: Data Ingestion

Navigate to the Data Workbench now running on port 8888. Use the Data Loader 📂 to upload your documents. TrustGraph supports .pdf, .txt, and .md files. The data extraction agents will automatically process the files, extracting key information to build the knowledge graph and vector embeddings.

Step 3: Query the Data through AI Chat

No need for Cypher or SPARQL queries! Once your data is processed, you can perform GraphRAG queries with natural language in the System Chat.

The System Chat will query both the knowledge graph and vector embeddings to generate a response. In addition, the Data Workbench will display a set of nodes from the knowledge graph on the left side of the screen. Clicking any one of these nodes will allow you to explore semantic relationships.

Step 4: Exploring Your Data in 3D

Now comes the fun part! Once you’ve selected a node, you can generate a 3D visualization by either clicking GRAPH VIEW in the Data Explorer window or by simply clicking Data Visualizer from the Data Workbench set of tools.

Once in the 3D visualizer, you can interact with the data:

Zoom, Pan, and Rotate: Use your mouse to explore the space. Zoom in to examine clusters in detail or rotate to gain a new perspective on relationships.
Click and Drag: Click and drag on an individual node to reshape the graph.
Node Exploration: Click on individual nodes to see additional related nodes.
Relationship Explorer: Click on a relationship connecting two nodes to see a pulse travel, depicting the directionality of the semantic relationship.

Ready to Explore Your Data in 3D?

Ditch analysis in 2D, embrace the third dimension, and unlock the hidden potential of your unstructured data with TrustGraph’s 3D Visualizer.

Give it a try today! Include the Data Workbench through the Configuration Portal in your build and experience the future of data analysis.

We're excited to see how you leverage this powerful tool to push the boundaries of AI! Join the TrustGraph community to push data analysis to the future!

The Future of Agentic Systems Podcast

Daniel Davis — Fri, 15 Nov 2024 15:19:04 +0000

The founders of TrustGraph, discuss their journeys with big data, knowledge graphs, and data engineering. Knowledge graphs are hard to learn - no matter what Mark says, and he gives everyone a crash course on them, why querying graphs is tricky, and what makes for reliable data services. The conversation ends with a discussion of what makes for "explainable AI" and the future of AI security.

The 2024 State of RAG Podcast

Daniel Davis — Thu, 07 Nov 2024 16:25:11 +0000

Daniel Davis of TrustGraph and Kirk Marple from Graphlit discuss the 2024 state of RAG. Whether it's RAG, GraphRAG, or HybridRAG, a lot has changed since the term has become ubiquitous in AI. Where are we, where are we going, and where should be going are all answered in this discussion.