Knowledge graphsmadelegible

FactGem was a knowledge-graph data-fabric company built on Neo4j. The product let organizations connect disparate data sources into a single, unified graph model, so questions that used to require crossing many systems could be asked in one place.

I led design on one part of that product: the visual model builder. This case study is about that work and what it taught me.

Building a knowledge graph means defining entities, the relationships between them, and how each maps onto real source data. Done in code, it is an engineering task. The people who actually understood the data, analysts and domain experts, were usually not engineers.

The job was to let those people build and map a graph model directly, against a shared data dictionary, without writing a line of code. A translation problem: turn an abstract, technical act into something a domain expert can do by direct manipulation.

Make the schema visible, not implied.

The builder let someone lay out entities and relationships on a canvas, then bind each to fields in their source data. The dictionary defining the shared schema was visible and in reach, so modeling and mapping happened in the same place.

The moves that mattered: make the schema visible rather than implied, use direct manipulation so structure is drawn rather than declared, and disclose complexity progressively so a first model stays simple.

A graph model is a contract between messy source data and a clean, shared dictionary. The visual builder existed to keep those two in agreement while non-engineers did the mapping.

The work I do now is the same instinct one layer over. A design-system contract keeps a design system and the agents consuming it in agreement. Different domain, two decades apart, the same orientation: I work at the seam where two representations have to be reconciled.

For graph and data-tooling roles, FactGem is direct evidence: I have shipped design for making abstract data structures usable by the people who understand the domain.

For everything else, it is proof that the way I work now is not a recent pivot. Design the system, then build the system. It is how I have worked for over twenty years.