Transcend

• 

  Screenshot showing GitLab Duo using Transcend

Inspiration

What if your code graph could reason across the entire web of knowledge? Imagine asking a single question — "what algorithms (e.g. knowledge-graph-embeddings) does this codebase implement?" — and getting back not just the class names, but the original 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 — a query that starts in your codebase and reaches out to the world's structured knowledge, because both speak the same language. That's the moment this project is built around, and it's what made me want to push on this idea past the weekend.

It started more quietly than that, though. I spent some time exploring GitLab Orbit — their new knowledge graph, currently in beta — and had a lot of fun digging into what it actually models and how far that could be pushed for the Transcend Hackathon. I started by inspecting Orbit's data model, and as someone who works with knowledge graphs, I found it a genuinely interesting object to look at: a real, production-scale schema for representing a codebase as a graph, especially when context graphs are on the rise.

The inspiration came from a simple question: Orbit's documented query API answers direct, single- or few-hop questions very well — who calls this, what does this import. But a lot of the questions people actually care about ("what breaks if I change this," "is there a circular dependency anywhere in here") aren't single-hop questions at all. They're about transitive structure. I wanted to see whether the W3C semantic web stack — OWL, SPARQL, SHACL — could sit on top of Orbit's graph and answer exactly that class of question, the way these tools are designed to: declare a relationship transitive once, and get arbitrary-depth reasoning for free, instead of hand-rolling recursive SQL for every new question.

The "why" underneath all of it: I love how interoperable the W3C stack is, and how much leverage it gives you once a graph is expressed in it. Express a codebase as RDF and it isn't just queryable on its own terms anymore — it can be federated, live, against any other SPARQL endpoint that exists, from Wikidata to a company's own internal knowledge graph, with no custom integration code per source. Orbit's graph looked like a genuinely good candidate to prove that out on, not just a toy example: a real production schema, and a real opportunity to show the code graph reaching past its own boundary.

What it does

Transcend converts Orbit's indexed code graph into an OWL ontology and RDF graph, and uses that to answer four kinds of question Orbit's native API can't express in a single call:

• Federated reasoning beyond the codebase itself — because the graph is plain RDF, a single SPARQL query can join Orbit's own data live against an external endpoint like Wikidata via the SERVICE keyword. Ask "what knowledge-graph-embedding methods does this codebase implement," and the same query that finds the answer in the code graph can keep going and pull back the original papers, authors, venues, and years for each one — no glue code, no manual research, no separate integration per source.
• Full transitive blast radius — everything that depends on a function, through any number of intermediate calls, not just direct callers.
• Genuine multi-hop circular dependencies — distinguished from trivial self-referential calls, which look similar but mean something architecturally different.
• Whether the indexed graph is even internally consistent with Orbit's own documented schema (via SHACL), and whether the ontology itself is valid OWL 2 DL (via a real DL reasoner) — two questions Orbit's own interface has no way to ask about itself.

The reasoning is exposed three ways: a CLI, a GitLab Duo Agent Platform skill, and a real MCP server backing a custom Duo agent (plus a terminal client implementing the same routing logic, runnable today with no Duo seat needed) — so it's reachable by a human, an agentic coding assistant, or a declared-tool-calling agent alike.

How we built it

I started by converting Orbit's data model into a set of OWL classes — node types and relationships became classes and object/datatype properties, generated from Orbit's own schema export rather than invented by hand. A few hours in, I had the model loading cleanly into WebVOWL, which let me see the relationships live and sanity-check the shape of what I'd built before writing a single line of query logic against it.

On top of that generated base, I hand-wrote a second layer declaring the relationships that actually carry the interesting structure — CALLS, CONTAINS, DEFINES — as transitive, plus a small set of derived risk classes (a "god function" is one with high fan-in and high fan-out at once; a real multi-hop cycle is different from a trivial self-call). That second layer is where the actual reasoning lives, expressed as SPARQL property-paths and rule-style materialization rather than hand-rolled procedural code.

I also wanted to go further than "the SPARQL gives plausible answers" and actually check the ontology's own formal validity — whether a real description-logic reasoner would accept it at all. I wired in HermiT (via owlready2) to run a genuine OWL DL consistency check, and built a SHACL validator to check whether the data Orbit actually produces stays consistent with the schema it's documented to follow. Both of those turned out to matter more than I expected (see Challenges).

Once the graph was real RDF, the federation piece was almost free — that's the whole point of using a W3C-standard format instead of a bespoke one. I'm a contributor to AmpliGraph, an open-source knowledge-graph-embedding library, so I indexed it with Orbit and ran a freestyle query: find every KGE scoring-layer class in the codebase (TransE, DistMult, ComplEx, HolE, RotatE — all under one AbstractScoringLayer interface, found via a single SPARQL FILTER on the materialized graph), then SERVICE-federate the same query out to Wikidata for the original paper, authors, venue, and year behind each one. One pipeline, two graphs, no custom connector for either — documented in full in docs/freestyle_example.md, queries and all.

I focused on Orbit Local and the code graph specifically, with Orbit's SDLC graph (merge requests, pipelines, vulnerabilities) very much in mind as the natural next layer — but I don't have access to a repository with Orbit Remote enabled, so I couldn't validate anything against a real, live SDLC export. Where I explored that direction anyway, I built a small, explicitly-synthetic fixture that matches Orbit's real documented SDLC schema, specifically so I wouldn't blur "verified against real data" with "verified against something I made up to test the idea" — they're labeled separately throughout the repository, not blended together.

Challenges we ran into

The most useful challenge wasn't a tooling problem, it was a correctness problem, and it's the result I'm most glad I checked for instead of assuming. While building the materialization rules, I compared the SPARQL answer for circular-dependency detection against a hand-written recursive SQL query — the obvious way most people would write this by hand. The SQL had a guard clause meant to stop infinite recursion. That same guard also silently blocked the one edge needed to close a cycle back to its start node. It ran without any error and confidently returned zero cycles — wrong, not just incomplete, and nothing about the result looked like a bug. The SPARQL property-path equivalent doesn't share that failure mode, because reachability is a primitive the query engine gets right once, rather than logic every query author has to re-derive — it found the real answer, 8 genuine two-hop cycles. I kept the buggy query in the repo next to its fix rather than cleaning it up afterward, because that comparison is the actual argument for why this layer is worth having.

The second challenge was one I caused myself. I added two enrichment axioms to my own ontology — declaring a relationship both transitive and asymmetric, each individually reasonable — and running a real OWL DL reasoner against the combined result caught something I hadn't: under the OWL 2 DL profile, a transitive property is "non-simple," and non-simple properties aren't allowed in certain axiom types, including asymmetry, because it would break the reasoner's decidability guarantees. Not a flaw in Orbit's schema — a mistake in my own modeling choices, caught by a tool built for exactly that purpose before it shipped.

The third was a quieter, easy-to-miss bug: a SHACL shape-generation script I'd written used a Python attribute-access pattern that silently produced the wrong SHACL term (sh:or_ instead of sh:or) to dodge a keyword collision. Every shape it generated parsed as valid Turtle and ran without error — and validated everything as conforming, regardless of content, for a long time before I noticed. Fixing it meant going back and actually checking what the validator had been silently failing to check the whole time.

Accomplishments that we're proud of

Finding all three bugs above myself, before anyone else had to. None of them were visible from the output alone — each one needed a deliberate, independent cross-check (recursive SQL against SPARQL, a real OWL DL reasoner against my own axioms, a regression test against my own validator) rather than trusting that a plausible-looking result was a correct one. All three are documented in the repository next to their fixes, not cleaned up after the fact.

Beyond that: a real, end-to-end benchmark where the SPARQL and hand-corrected-recursive-SQL answers agree exactly across every competency question, on a real open-source codebase, not synthetic data. A SHACL validator that I proved has actual teeth — it cleanly passes real data and correctly rejects a deliberately broken graph, with a regression test guarding against the exact bug that once made it silently pass everything. A working MCP server plus a terminal client that calls it through the real MCP transport, so the GitLab Duo agent integration is something runnable today, not just a system prompt that's never been executed. And a real federated SPARQL query that starts inside a codebase and ends at Wikidata, in one pipeline, with no per-source integration code — the clearest demonstration that "the code graph is now RDF" is a real capability, not a slogan.

What we learned

Mostly: that checking your own reasoning against an independent method is worth far more than trusting that a query "looks right." Three real, distinct bugs surfaced in this project — a recursive SQL bug, an OWL DL profile violation in my own axioms, and a silently inert SHACL validator — and none of them would have been visible without deliberately cross-checking against a second, more rigorous method each time. I also relearned something about W3C tooling specifically: the interoperability is real and valuable (the same ontology loads in WebVOWL, gets reasoned over by HermiT, and gets validated by SHACL, with no glue code between those steps beyond Turtle files), but the tooling around it rewards being precise about exactly what you're claiming — "the SPARQL rule gives the right answer" and "the ontology is valid OWL 2 DL" are different questions, and conflating them would have been an easy, and easy-to-miss, overclaim.

What's next for Transcend

The natural extension is the one I couldn't fully test: fusing code-risk signals with real SDLC process data — which merge requests touch already-risky code, and whether they were reviewed by more than one person — once I have access to a repository with Orbit Remote enabled to validate it against something real instead of a synthetic fixture. Another step forward would be to test more use cases and especially leverage power of ontology for automatic tagging of issues or power of reasoner to mark automatically high risk merges or similar.

Built With

• gitlab
• python