Skip to content

Trinity Graph Engine — stack-fit research

Question

Should backend-core adopt Microsoft Trinity Graph Engine (now published as microsoft/GraphEngine) as a next stack element? Tavi Truman's GitHub work was suggested as a source of ideas.

Short answer: not as a core engine right now. The genuinely valuable part is not Trinity-as-a-graph-database (we already have graph via ArcadeDB) — it is the ontology + reasoning layer that Tavi Truman builds on top of Trinity. We should capture that as a capability we want and pursue it in a way that does not bet the foundation on a dormant, single-maintainer engine.

What Trinity Graph Engine is

A distributed, in-memory graph processing engine over a strongly-typed in-memory key-value store ("memory cloud"). Two signature pieces:

  • TSL (Trinity Specification Language) — strongly-typed schema/cell modeling with generated accessors for thread-safe, in-place manipulation.
  • LIKQ (Language Integrated Knowledge Query) — graph traversal with embedded lambda expressions for server-side computation during traversal.

Implementation: C# (~49%) / C++ (~36%), MIT license, ~2.3k GitHub stars. It is a Microsoft Research project, explicitly "not an officially supported product."

Maintenance reality (the decisive fact)

The microsoft/GraphEngine repository is effectively dormant: the most recent commit is from ~December 2023 ("Bump .NET to 8.0"), with no 2024–2026 activity on the main repo. The only meaningfully active development in the ecosystem is outside Microsoft — Tavi Truman / InKnowWorks (see below) — which is a research-grade, ~one-maintainer effort. Adopting Trinity as a core stack element therefore means taking a foundational dependency with a bus-factor near 1 and no vendor support.

What Tavi Truman / InKnowWorks adds (the actual ideas)

Tavi Truman (CTO/co-founder, InKnowWorks) is the de-facto steward of the Trinity lineage. Focus: modern semantic reasoners and RDF/RDFS/SKOS/OWL parsers, provers, solvers, and graph data structures for .NET. Relevant repos:

  • InKnowWorks/IKW-GraphEngine — a maintained fork of Graph Engine.
  • InKnowWorks/RDF-Graph-and-Hypergraph — RDF property graphs and hypergraphs on Graph Engine via TSL + Computed DSL + LIKQ, integrated with BFO 2020 (Basic Formal Ontology), including a BFO 2020 CLIF parser with Z3 mathematical verification of mereotopological semantics. (Small repo — ~6 stars, ~56 commits, little recent movement.)
  • Stated direction: C++ → C# 13 code generator, a TSL compiler upgrade, and advancing Trinity into a platform for semantic technologies and model-based ML.

The compelling idea in his BFO-2020 + Trinity write-up is layering a formal ontology over the graph: encode BFO categories (Continuants vs Occurrents) and relations (PartOf, HasParticipant, …) into TSL, use colored hypergraphs for ontological typing, and run inference engines so the system does genuine reasoning — not just graph traversal. Worked use case: product genealogy / regulatory-compliance tracing across manufacturing processes. The key distinction he stresses: traversal ≠ inference; real value comes from logical axioms, not path-walking.

That distinction is the takeaway for us. Trinity is the substrate; the ontology + reasoning layer is the prize. Those are separable.

Fit against our current stack

Dimension Our stack today Trinity fit
Graph storage ArcadeDB (multi-model graph/document/vector); UDA has a GraphCapable connector Redundant — Trinity-as-graph-DB largely duplicates ArcadeDB
Vector / semantic search Cohere Embed v4, cross-modal LSM_VECTOR index Out of scope for Trinity; no overlap
Connector core Python on dlt, capability mixins, Apache Arrow type system (ADR 0001) Trinity is C#/C++ with native components → a 3rd core runtime
Serving Rust/Axum v2 (rust-api-v2) No fit; Trinity is not a serving layer
Cross-layer contract MCR-F4 neutral schema; middle-core is C# (ADR 0002) Only place C# already lives — but that's the producer, not us
Reasoning / inference None today This is the real gap Trinity points at
Vision (Labs) "Model-Driven Platform", "One Model, Many Projections", knowledge-graph-snapshot business object, "the graph is the thinking tool" Thematically aligned — but with the capability, not necessarily this engine

Note on our own docs: despite the expectation that we already document Trinity, there is no Trinity-specific material in the AgentArmy GitHub Pages docs or the Labs (Obsidian) vault as of this writing. The adjacent material is the Labs knowledge-graph-snapshot core business object, the "graph is the thinking tool" framing, and the Universal Data Adapter ADRs — all compatible with a future reasoning layer, none committing to Trinity.

Why not adopt it as a core element now

  1. Bus-factor / support risk. Microsoft's repo is dormant and unsupported; the live work is one external maintainer. Wrong risk profile for a foundational layer.
  2. Redundant with ArcadeDB. We already have graph storage + a GraphCapable connector. Trinity would duplicate the part we have and not, by itself, deliver the part we lack (reasoning).
  3. Runtime/language friction. It injects a C#/C++ engine with native (historically Windows-leaning) components into a Python-core + Rust-serving stack, against ADR 0001's "Python where strongest, Rust where strongest."
  4. Operational footprint. An in-memory "memory cloud" is RAM-hungry; backend-core targets cost-conscious Azure Container Apps/ACI. Heavy for current scale.
  5. Maturity/churn. Research-grade, with a TSL compiler rewrite (C# 13 codegen) still ahead — breaking changes likely.

Recommendation

Do not adopt Trinity as a core stack element. Instead:

  1. Name the capability, not the engine. What we actually want is an ontology + reasoning layer (OWL/RDF semantics + true inference over our knowledge graph), distinct from graph storage. Record it as a desired capability against the Labs knowledge-graph-snapshot object.
  2. Keep the bet reversible — evaluate behind the UDA. If/when we need reasoning, model it as a UDA connector capability (e.g. a ReasonerCapable / OntologyCapable mixin) rather than a core swap, so any engine choice (Trinity or otherwise) stays additive and replaceable — consistent with ADR 0001.
  3. Borrow the ideas now, the dependency never (yet). Adopt Tavi Truman's concepts without the runtime: ontology-driven schema design; BFO continuant/occurrent typing for knowledge-graph entities; and the traversal-vs-inference discipline (don't market path-walking as reasoning).
  4. Comparison set before any commitment. If reasoning becomes a real requirement, weigh better-supported options first — RDF/OWL triplestores with standard reasoners, or a reasoning service alongside ArcadeDB — against Trinity, on support, ops cost, and stack fit.
  5. If leadership wants proof, time-box a spike. A spike-researcher PoC: stand up a small ontology + a handful of inference rules over a knowledge-graph-snapshot sample, and produce a build-vs-buy writeup. Cheap, bounded, and decision-grade — without committing the foundation.

Sources

  • Microsoft Graph Engine (Trinity) — repo: https://github.com/microsoft/GraphEngine · project: https://www.microsoft.com/en-us/research/project/graph-engine/ · docs: https://microsoft.github.io/GraphEngine/
  • Trinity paper — "Trinity: A Distributed Graph Engine on a Memory Cloud": https://www.microsoft.com/en-us/research/publication/trinity-a-distributed-graph-engine-on-a-memory-cloud/
  • Tavi Truman (GitHub): https://github.com/tavitruman
  • InKnowWorks/IKW-GraphEngine: https://github.com/InKnowWorks/IKW-GraphEngine
  • InKnowWorks/RDF-Graph-and-Hypergraph (TSL + LIKQ + BFO 2020 + Z3): https://github.com/InKnowWorks/RDF-Graph-and-Hypergraph
  • Tavi Truman, "Trinity Graph Engine and BFO 2020 Ontology Integration": https://www.linkedin.com/pulse/unlocking-power-knowledge-graphs-trinity-graph-engine-tavi-truman-tnonc
  • Related internal context: docs/adr/0001-universal-data-adapter.md, docs/adr/0002-mcr-f4-data-platform-contract.md, Labs vault (Model-Driven Platform, knowledge-graph-snapshot).