RSS Amplifier

Agus’s Substack · Jul 25, 2026

A Relation Is a Rotation On a Knowledge Graph

0
Sign in to vote or save

Agus Sudjianto · Agus’s Substack

This is an example follow-up to the fourth post in Knowledge Graphs as Geometry. Last time a relation became a rotation and score by distance, symmetry stops being a trap. That earlier demonstration used six people in a family graph, and this week the same rotation runs a bank’s compliance memory, the geometry an AI agent has to obey when a customer complaint lands on its desk. The tool is knowlytix, which is on PyPI and free to use, with a license key you can can generate yourself by registering at knowlytix.ai/signup.

An agent is handling a customer complaint about an overdraft charge. To answer it, the agent has to state the fee, decide the next step in the workflow and route anything that smells like a regulatory problem to the right desk. A language model will do all three fluently and some of them wrong. If you ask it the overdraft fee it will produce a plausible, well-formatted, confident number, when the policy actually says $35.00. Prompting alone gives you no way to tell the confident right answer from the confident wrong one, which is the failure I call “prompt and pray,” and no better prompt will fix it.

What fixes it is a memory in which a wrong fee lands far away. Rather than a database that only answers whether a string is stored, we want a geometry that answers how well a fact fits, giving a small distance to a fact that belongs and a large one to a fact that does not. That memory is the object Chapter 4 built, where a relation is a rotation and a fact’s plausibility is the distance left over after the rotation. In this post we take that object off the six-person toy graph and run it, without changes, on a bank’s policy example.

Chapter 4 lived in the complex plane. RotatE turned each coordinate by an angle, QuatE turned quaternions so that order could matter, and in both cases the score was the distance from the turned head to the tail. Read against the operator this series is building,

\(F_r(\mathbf h) \;=\; U_r\,\Sigma_r\,V_r^{\top}\,\mathbf h + \mathbf c_r,\)

a rotation model is the case where the stretch Σᵣ is the identity and there is no shift, so the operator is a pure rotation and the comparator is a distance.

knowlytix (pip install knowlytix) builds the same thing in a real vector space. It reads a document, places every entity as a point on a unit sphere in high dimensions (e.g., written R³²) and makes every relation a rotation Rᵣ of that sphere, one for each relation. We call that rotation a rotor (will be discussed in future post in more detail), which is simply the name a rotation goes by once you move past the two dimensions of the complex plane, and it is the word you will see printed in the figures below. It scores a triple by turning the head with the relation’s rotation and measuring the distance to the tail along the surface of the sphere, which is what geodesic distance means:

\(s(h, r, t) \;=\; d_{\text{geo}}\big(R_r\,\mathbf v_h,\; \mathbf v_t\big).\)

That is Chapter 4’s sentence, rotate the head and measure the distance, now written for thirty-two dimensions instead of two. It is the general-dimension version of the turn Chapter 4 pointed toward when it noted that the quaternion’s dependence on order is the same dependence on order that rotations have in any number of dimensions. During training knowlytix uses a standard construction that keeps each relation an exact rotation at every step, so the operator never quietly drifts into a stretch or a shear. There is a richer way to see all of this through geometric algebra, which later chapters in the series develop in full. What runs on the GPU is ordinary matrix arithmetic, and everything below is just turn the head and measure.

The example is a small excerpt of a bank’s policy, covering a fee schedule, the workflow authorizations, the regulatory flags with their escalation targets and the reversal limits by role. The knowlytix build parses these tables into typed triples and trains the geometry once, so the numbers below reproduce on every run.

In this example, the result is 40 entities, 8 relations and 41 triples. Every entity is a point on the sphere, whether it is overdraft, classify, udaap, compliance or one of the dollar amounts. Every relation gets a color, with has_fee_amount in yellow, has_enables in red, has_escalates_to in green and so on. A triple (head, relation, tail) is drawn as an arc along the sphere from the head to the tail in the relation’s color, and that arc is the rotation at work. Follow the yellow arc from overdraft and it lands on 35.0, because the has_fee_amount rotation turns the point for overdraft into the point for 35.0. The figure is knowlytix’s own visualizer, called directly on the store.

A knowledge graph stores typed facts rather than sentences. The escalation logic the agent needs is a two-hop walk across two different relations, in which a piece of evidence implicates a regulatory flag and the flag routes to a desk. In this graph unfair_or_abusive_fee is the evidence for the UDAAP flag, and UDAAP escalates to compliance. That chain from evidence to flag to desk is the reasoning the agent performs by composing relations, and composition, as we are about to see, is where the geometry earns its keep.

The one thing this memory adds over a plain lookup table is a distance. Where a plain graph answers only whether a triple was stored, geometric memory system answers how well a triple fits what the policy holds, and it does so with the distance along the sphere from the turned head to the proposed tail, which is small for a fact that belongs and large for one that is fabricated or out of place. The same primitive scores a claimed fact and a claimed workflow step, because both are just triples.

The committed fee scores near zero while a wrong one scores far. The triple (overdraft, has_fee_amount, 35.0), the fee the policy actually commits to, comes back at distance 0.052. Swap in $45, which is the international wire fee and a plausible thing for a model to guess, and the same call returns 1.527. The geometry has placed the true tail almost exactly where the has_fee_amount rotation sends overdraft, and it has left the wrong tail most of a right angle away. The same holds for workflow steps. The legal next state (classify, has_enables, extract) scores 0.006, while (classify, has_enables, draft_response), which skips three steps ahead, scores 1.576. A single distance decides both whether a fact is true and whether a step is allowed, which is what lets one memory gate an agent that has to do both.

Ranking falls out of the same operation. To answer what fee an overdraft carries, knowlytix turns overdraft by the has_fee_amount rotation once, measures the distance to every candidate value and then sorts. The committed value 35.0 comes first at 0.466, and the next candidate, 25.0 (the late-payment fee), sits at 1.311, with the rest farther still. This is the same move that made rotation models cheap to evaluate in Chapter 4, because a rotation preserves length, so you rotate once and compare against a fixed table of points rather than transforming every candidate separately. You turn the head, sort by distance and read off the answer.

It is worth checking that these operators are genuine rotations and not rotations in name only, because everything above depends on it. A rotation has two telltale properties, that it preserves length and that it has a clean inverse, and both can be read straight off the trained memory store.

Take length first. The quantity that would move away from zero if a relation stretched or reflected the space, ‖RᵣRᵣᵀ − I‖, comes in around 10⁻⁵ for all eight relations, which is machine zero for a trained model, and every determinant is +1.0000 to four places, which rules out a hidden reflection. A map that preserves length and has determinant +1 is a rigid turn of the sphere and nothing else, with no reflection, no scaling and no shear. This is why the distance is honest. Because the rotation moves the head to a new point without distorting the space around it, the leftover distance to the tail measures fit and nothing else. It is also why Chapter 4 could move the relation from one side of the distance to the other for free, and the same fact holds here in thirty-two dimensions.

The inverse is the reverse turn. Turning a point by Rᵣ and then by its transpose Rᵣᵀ returns it to where it started, since ‖RᵣᵀRᵣ v − v‖ ≈ 10⁻⁶. This is Chapter 4’s observation that the inverse of a relation is simply that relation run backward, with childOf being parentOf reversed, now holding in thirty-two dimensions. The model gets an inverse relation from a relation without learning it twice.

Chapter 4 ended on a wall. RotatE composes relations by adding angles, and addition does not care about order, so turning by θ then φ lands you in the same place as turning by φ then θ. That means RotatE forces every pair of relations to commute, which is fine for grandparentOf but wrong for kinship, where your parent’s sibling and your sibling’s parent are different people. Only the quaternion’s order-dependent product broke that ceiling, and it did so because rotating in more than two dimensions genuinely depends on order.

knowlytix’s rotations live in thirty-two dimensions, so they are under no obligation to commute, and they do not.

Composing two policy relations in the two orders gives two different rotations. Take the has_applies_when rotation and the has_escalates_to rotation, where applying one then the other differs from the reverse by a gap of 4.55, the quantity ‖RᵣRₛ − RₛRᵣ‖ plotted in the figure, and every other pair lands between 3.1 and 4.3. For the complex relations of RotatE this gap is exactly zero, by algebra rather than by training, which is the flat blue line in the figure. The bank’s relations do not commute because the reasoning they encode does not commute. The flag this evidence raises, and then where that flag escalates, is a specific two-hop route, and running it backward is a different claim. A memory that made every relation order-blind could not keep the two apart.

This is where the escalation chain becomes a geometric object rather than a table walk. Geometric memory in knowlytix composes a multi-hop path by chaining the rotations along it, and it provides a consistency check, called check_holonomy in the API, that compares the rotation you get by walking a path against the rotation of a single direct edge between the same endpoints. When the two disagree, the path and the shortcut are telling different stories, an inconsistency the geometry can flag before an agent acts on it. On this small policy the composed path and the single relation differ by 3.28, and on graphs with genuinely redundant routes the same check catches reasoning that does not close up. This is the order-dependent composition from Chapter 4 doing real work.

The geometry supplies one more thing a lookup table cannot, which is a sense of how strict a relation is. An overdraft has exactly one fee, so has_fee_amount should accept one tail and reject the rest. A workflow state can enable more than one next state, so has_enables should be more permissive. knowlytix gives each relation a learned admissible radius, which marks off a small cap on the sphere around the turned head, and any tail that lands inside that cap counts as fitting.

The radii are modest and they differ by relation, from about 0.56 radians for has_applies_when up to 0.69 for has_role. A tail that lands inside the cap is admissible and one outside it is not, which is why the wrong $45 fee, most of a right angle from the committed value, is rejected while the true $35 sits comfortably inside. The cap is how the same geometry represents a strict, one-answer relation and a looser, several-answers relation without changing the operator. It is a small departure from a pure rotation, since the cap can stretch along some directions, and the machinery behind it is the subject of a later chapter. For now it is enough that the agent gets a calibrated yes-or-no rather than just a raw distance.

The whole memory is a few lines against a built store. You turn the head, measure the distance and read the answer off. The complete notebook, which reproduces every figure and check in this post, is on GitHub.

from knowlytix.knowledge.query import GMSExpertStore, DocGMSConfig
from knowlytix.core.config import GeometryConfig
cfg = DocGMSConfig(store_path="gms_ch2_store", loss_mode="cap",
                   geometry=GeometryConfig(d_v=64, d_u=64, m=32, d=32))
store = GMSExpertStore(cfg); store.load()
# plausibility = distance along the sphere after the relation's rotation
print(store.score_triple("overdraft", "has_fee_amount", "35.0"))   # 0.052  committed
print(store.score_triple("overdraft", "has_fee_amount", "45.0"))   # 1.527  wrong
# rank the tails: turn once, sort by distance
for tail, dist in store.link_predict("overdraft", "has_fee_amount", top_k=3):
    print(tail, round(dist, 3))                                    # 35.0 first
# resolve a surface phrase to a canonical node
print(store.fuzzy_match_entity("overdraft fee"))                   # 'overdraft'

Everything in this post, from the length and inverse checks to the scores, the order-flip gap, the escalation chain and the admissible radii, is a call to the geometric memory store in knowlytix on the bank-policy graph, and it all runs in seconds. knowlytix installs from PyPI and is free to use. You can generate yourself a license key and follow the install instructions at knowlytix.ai/signup, and there is an overview of the library at knowlytix.ai. The graph here is the Chapter 2 primer from the Beyond Prompt and Pray agent tutorial.

A relation is a rotation, and that is less a diagram than the memory an AI agent can be held to. Place the entities on a sphere and make each relation a rotation, and a fact’s plausibility becomes the distance left after the turn, so the committed fee sits at the pole the relation points to, the wrong one lands a right angle away, and a workflow that skips ahead lands nowhere near the step the policy allows.

Knowledge Graphs as Geometry is a free weekly series adapted from my book Knowledge Graph Embeddings as Geometric Operators. The posts carry the intuition and the runnable code, while the book carries the full derivations. The geometric memory shown here is implemented in knowlytix, which is on PyPI and free to use, with a license key you can generate yourself at knowlytix.ai/signup. Subscribe to follow the whole argument, from a single translation to one operator that contains the entire model zoo.

Read the original on agussudjianto.substack.com

Comments

Nothing yet. Say the first thing.

    Sign in to join the conversation.