Transcend: A Dual Reasoning Engine That Goes Beyond the Code Graph

Generated by Gemini, not-so-biologically-accurate metaphor of dual nature of Transcend, with fast, intuitive mode with Orbit native and slow deliberate mode with W3C stack counterpart.

Co-written by Claude Sonnet 4.6

What if your code graph could reason across the entire web of knowledge?

Imagine asking a single question — “what algorithms (e.g., KGE methods) are implemented in this codebase?” — and getting back not just the class names, but the original NeurIPS and ICLR papers that inspired them, their authors, their venues, their year of publication, all retrieved live and joined to your code graph in one pipeline. No manual research. No copy-pasting between tools. Just a query that starts in your codebase and reaches out to the world’s structured knowledge — because both speak the same language.

That’s what Transcend does. It’s a second reasoning engine built on top of GitLab Orbit’s code graph, using the W3C semantic web stack — OWL, SPARQL, RDF — to turn a code intelligence graph into an open, federatable knowledge hub. One that can answer multi-hop questions about your own codebase, and then keep going.

Why I built it — and why AmpliGraph

I’m a contributor to AmpliGraph, an open-source Python library for knowledge graph embeddings. When the GitLab Transcend Hackathon launched, it felt like a natural intersection: a library I know well, a graph indexing platform I wanted to explore, and a question I’d been sitting with for a while.

The W3C semantic web stack was designed around a single powerful idea: represent knowledge in a standard, interoperable format and you can reason across sources that were never designed to talk to each other. Declare a relationship transitive once, and every query gets transitivity for free. Federate a SPARQL query across a code graph, a research database, a vulnerability feed, a company wiki — all from the same query, no custom integration per source.

GitLab Orbit indexes a codebase into a graph and answers questions through a query API: who calls what, what imports what, which modules changed most. Looking at that, I had a simple question: what happens if you build a parallel reasoning engine on top of Orbit’s data using the W3C stack? Can you unleash that interoperability on code intelligence?

That’s how Transcend was born. And the name is intentional — it literally transcends the codebase. As the Wikidata example above shows.

How it’s built: a virtualization layer over Orbit’s own data

The first step was understanding Orbit’s data model deeply enough to use it as a foundation. Orbit stores its indexed graph in DuckDB. I mapped that schema into OWL ontology, then built a virtualization layer: an R2RML mapping — a W3C standard for expressing relational data as RDF — connected via a JDBC-to-DuckDB bridge. The result is a live RDF view over Orbit’s own data. No separate database, no manual export step; just the graph Orbit already built, now addressable by any SPARQL-speaking tool.

The OWL ontology enriches Orbit’s relationships with a small set of carefully chosen axioms. Declaring CALLS transitive means "A calls B calls C" automatically implies "A transitively calls C" — without any query author having to write that logic. The triples load into rdflib and are queried with SPARQL property paths.

That’s the core stack: Orbit data → OWL ontology → R2RML mapping → DuckDB JDBC → RDF triples → rdflib → SPARQL.

Code Graph Ontology

SDLC ontology

Freestyle mode: Transcend goes beyond the codebase

This is the centrepiece, so let’s start here.

Because the code graph is now in RDF and queryable via SPARQL, it can federate with anything else that speaks SPARQL. Wikidata does. DBpedia does. Any endpoint you choose does. And federating means a single query can span all of them simultaneously — no glue code, no custom connectors, just the SERVICE keyword.

I ran a freestyle query starting from: “Find all knowledge-graph-embedding methods in AmpliGraph, list them, then query Wikidata for scholarly context on each one.”

What happened:

Orbit indexed AmpliGraph and materialized 823,017 RDF triples from the DuckDB export. A SPARQL query over the code graph identified all five concrete KGE scoring layer implementations — TransE, DistMult, ComplEx, HolE, RotatE — each under ampligraph.latent_features.layers.scoring.*, each implementing the same AbstractScoringLayer interface. A second federated SPARQL query, using SERVICE wikibase:sparql, joined those results live against Wikidata:

Model Original Paper Venue Year TransE Translating Embeddings for Modeling Multi-relational Data NeurIPS 2013 DistMult Embedding Entities and Relations for Learning and Inference in KBs arXiv 2015 ComplEx Complex Embeddings for Simple Link Prediction ICML 2016 HolE Holographic Embeddings of Knowledge Graphs AAAI 2016 RotatE Knowledge Graph Embedding by Relational Rotation in Complex Space ICLR 2019

Code structure from Orbit. Scholarly context from Wikidata. Reasoning across both — in a single pipeline, with no custom integration code per source.

The Orbit code graph also surfaced a structural note worth knowing as an AmpliGraph contributor: HolE._compute_scores has a self-referential call — one of 59 across the codebase — that may indicate a recursive scoring path or a copy-paste artifact, and is worth reviewing before modifying that class.

Now imagine this at scale. Connect not just Wikidata, but your internal architecture decision records, your dependency vulnerability feeds, your company knowledge graph, your API documentation. Every source that speaks SPARQL becomes part of the same reasoning fabric. The code graph stops being an island and becomes a hub — and the W3C stack makes that possible without writing a new integration for each one.

Generated by Gemini, pictures the idea behind Transcend.

What else it answers: multi-hop questions Orbit can’t reach in one call

Beyond freestyle, Transcend answers three classes of structured question that Orbit’s native API doesn’t handle in a single query:

Full blast radius. Not just direct callers of a function, but every function that depends on it through any chain of calls. SPARQL property paths (?x :CALLS+ ?target) return the full transitive closure automatically — because CALLS is declared transitive in the ontology, this is what every query gets, not a special case.

Circular dependencies. Genuine multi-hop cycles in the call graph — mutual recursion between modules, dependency loops not visible from any single node. Detecting these requires traversing paths through the graph, not looking up a value.

God functions. Code that’s simultaneously heavily depended-upon and heavily coupled outward — the combination that makes a change risky in both directions.

The bug hiding in the obvious solution

I validated Transcend’s answers by running a benchmark: the same three questions, three ways — single-hop SQL, hand-written recursive SQL, and SPARQL — against AmpliGraph, and checking whether the results agree.

Two of three agreed with the expected difference: single-hop SQL on _load_dataset finds 12 direct callers; both recursive SQL and SPARQL correctly find all 14, the extra two being transitively reachable only.

The third didn’t agree. The hand-written recursive SQL for circular-dependency detection had a guard clause to stop infinite recursion — completely standard practice. That same guard also blocked the one edge that closes a cycle back to its start node. The query ran without error and returned zero cycles. Not “result may be incomplete.” Just zero. Confidently wrong.

SPARQL doesn’t have this failure mode because reachability is something the query engine implements correctly once, not something each query has to re-derive. It found the real answer: 8 genuine two-hop cycles, all mutual recursion between a data-loader class and its backend helper.

I kept the buggy SQL in the benchmark alongside the fix rather than cleaning it up. The bug is the argument.

The ontology catching my own mistake

Building the OWL ontology surfaced a second story — this time about my own code. I added two enrichment axioms to CONTAINS: transitive (so "directory contains directory contains file" implies containment at any depth) and asymmetric (so it can't loop back on itself). Each made sense in isolation.

Running an OWL DL reasoner (HermiT) on the combined ontology caught a constraint I’d missed: under OWL 2 DL, a transitive property is “non-simple,” and non-simple properties can’t appear in asymmetry axioms — doing so breaks the reasoner’s decidability guarantees. Not a logical contradiction, but a genuine formal violation of the profile.

The fix was separating the two axioms into a DL-safe subset. The reasoner found it before it shipped. I added SHACL validation (--validate-shacl) for the same reason: a live check that the graph the pipeline actually produces still matches the schema it's supposed to conform to. Against real AmpliGraph data it conforms cleanly; against a deliberately broken test graph, it correctly rejects it.

The honest next step

Orbit also indexes SDLC data — merge requests, review history, deployment events. Fusing code-risk signals with process signals — which merge requests touch already-risky code, and were they reviewed by more than one person — is the more complete version of this project. I built and verified the reasoning logic against a synthetic fixture matching Orbit’s documented schema; connecting it to real production SDLC data is the genuine next step.

Try it yourself

The repository includes real captured terminal output — not staged screenshots — showing the install check, the SHACL validator, the benchmark comparison, and the freestyle Wikidata federation pipeline. Clone it, run it, and you’ll see it for yourself.