The Orbiter
Knowledge Graph

1 What is the Knowledge Graph?

The knowledge graph is the core intelligence layer of Orbiter. It maps every person, company, school, and organization into a network of typed, weighted relationships — enabling the platform to find hidden connections between people and surface relevant introductions.

Conceptual visualization of the Orbiter knowledge graph — nodes represent entities (people, companies, schools), edges represent relationships with varying strengths.

The Core Idea

Traditional CRMs store contacts as flat records. Orbiter stores them as nodes in a graph, connected by typed edges that carry meaning: "Alice FOUNDED Company X", "Bob ATTENDED Stanford", "Alice and Bob ATTENDED_TOGETHER at Stanford from 2012-2016."

This structure enables Orbiter's signature features — Leverage Loops (find the shortest, strongest path between two people), Discovery (natural language search that translates to graph queries), and Meeting Prep (automatically surface shared connections before a meeting).

Tech Stack

2 Architecture Overview

Data flows through a 4-layer pipeline: external sources feed raw JSON into Xano tables, which get processed into relational records, then resolved into graph edges, and finally written to FalkorDB.

The enrichment pipeline: from raw external data sources through processing, edge resolution, and into the FalkorDB knowledge graph.

The 4 Layers

System Architecture Diagram

3 Node Types

Every node in the graph shares the base label :Entity plus a specific type label. There are 12 node types, each with distinct properties. The most important are Person and Company.

Primary Node Types

Location Nodes (Hierarchy)

Locations form a 3-level hierarchy: City → Region → Country. Each person's primary location creates edges through all three levels.

Expertise & Funding Nodes

4 Edge Types & Weights

Edges are the soul of the knowledge graph. Every edge has a type (what the relationship is) and a weight (how strong it is). Lower weight = stronger relationship. Weights are critical for path-finding — the algorithm finds paths with the lowest total weight.

Relationship strength hierarchy — lower weight means stronger bond. FOUNDED (5) is the strongest relationship; ATTENDED (40) is the weakest direct connection.

Complete Edge Reference

Work Edge Seniority System

WORKED_AT edges have dynamic weights based on the person's seniority at the company. The formula is:
weight = seniority_rank + (is_current ? 0 : 20)

This means a current C-Suite role (weight 5) is much stronger than a past individual contributor role (weight 40). The +20 penalty for past roles ensures current relationships rank higher in path-finding.

Example: A current VP role has weight 12. A past VP role has weight 32 (12+20). The seniority detection function pattern-matches title strings against known role patterns.

Derived Relationships

Some edges aren't extracted from data directly — they're computed from other edges:

Edge Properties

Edges carry metadata beyond their type and weight:

5 The Enrichment Pipeline

Enrichment is how raw data becomes graph knowledge. When a person is added to Orbiter, they go through a multi-stage pipeline that extracts, normalizes, resolves, and graphs their data. The entire pipeline runs 9 stages per person.

The 9 Pipeline Stages

Stage 1: process-enrich-layer (16 Sections)

This is the largest and most complex function. It takes the raw JSON blobs from external data sources and extracts them into normalized relational tables. It has 16 distinct sections, each handling a different data type:

1. 1
   Basic Info
   Extracts name, headline, summary, location, industry from PDL and Enrich Layer JSON. Updates master_person fields.
2. 2
   Work History
   Parses employment records from JSON. Creates/updates work_history table entries. Deduplicates by company+title.
3. 3
   Education
   Parses education records. Creates/updates education table entries. Handles degree types, fields of study, dates.
4. 4
   Skills
   Extracts skill names from JSON arrays. Creates skill records linked to the person.
5. 5
   Social Links
   Extracts social media URLs (Twitter, GitHub, personal sites). Creates social_link records.
6. 6
   Certifications
   Professional certifications with issuing organizations, dates. Creates certification records.
7. 7
   Languages
   Spoken languages with proficiency levels. Creates language records.
8. 8
   Projects
   Personal and professional projects. Creates project records.
9. 9
   Volunteering
   Volunteer experience with organizations and roles. Creates volunteering records.
10. 10
    Honors & Awards
    Awards, recognition, honors from organizations. Creates honor records.
11. 11
    Publications
    Published articles, papers, books. Creates publication records.
12. 12
    Patents
    Patent filings and grants. Creates patent records.
13. 13
    Courses
    Courses taken or taught. Creates course records.
14. 14
    Recommendations
    Professional recommendations received. Creates recommendation records.
15. 15
    Websites
    Personal and professional websites. Creates website records.
16. 16
    Avatar
    Profile photo URL extraction and placeholder detection. Updates master_person_avatar.

Stages 2–7: Edge Resolution

After relational data is created, edge resolution functions match records to existing graph nodes and create Cypher queries to build graph edges. Here's how each one works:

Stage 8: complete-person-enrich

The finalization stage. After all edges are resolved, this function:

• Generates the bio_500 — an AI-written 500-word biography using all extracted data
• Creates/updates the Person node in FalkorDB with all properties including the bio
• Generates the name_embedding vector from the bio_500 text
• Stores the embedding on the node for semantic search
• Sets visibility = true (the single visibility gate)
• Creates location edges (LOCATED_IN to City, Region, Country)
• Runs expertise identification (LLM + vector resolution)
• Marks enrichment as complete in enrich_history_person

Stage 9: run-base-company-process

Enriches the person's primary company. Creates/updates the Company node, generates about_500 bio, creates company embedding, processes funding rounds, and links investors (VC_Firm, Angel nodes with INVESTED_IN edges).

6 Vector Embeddings & Semantic Search

Every Person and Company node carries a 1536-dimensional vector embedding generated from their bio text. This enables semantic (meaning-based) search across the entire graph.

Vector embeddings transform text into mathematical points in high-dimensional space. Similar people/companies cluster together, enabling "find people like X" searches.

How It Works

Semantic Search via Cypher

The send-cypher-with-embeddings function enables natural language search:

// User searches: "AI startup founders in San Francisco"
// 1. Query text is embedded into a vector
// 2. Cypher uses vector similarity to find matching nodes:

MATCH (p:Person)
WHERE p.visibility = true
WITH p, vec.euclideanDistance(p.name_embedding, $query_vector) AS score
WHERE score < 0.45  // similarity threshold
RETURN p.name, p.headline, p.current_company, score
ORDER BY score ASC
LIMIT 20

Key Details

7 Visibility & "Juicy Bios"

Not every person in the database is visible in the graph. Visibility is gated by a single criterion: the person must have a bio_500. This ensures only properly enriched people appear in search results and path-finding.

The Visibility Lifecycle

What Makes a "Juicy Bio"

The bio_500 is not a dry resume summary. It's an AI-generated narrative (up to 500 words) that captures:

• Career trajectory — not just current role, but the journey
• Key achievements — companies founded, boards served, awards won
• Education highlights — degrees, notable institutions
• Expertise areas — what they're known for professionally
• Network significance — why they matter in the professional landscape

This bio serves double duty: it's displayed to users AND it's the source text for the vector embedding. A richer bio = better search results.

Completeness vs Visibility

8 Path Finding & Leverage Loops

Path finding is the flagship feature of the knowledge graph. Given two people, Orbiter finds the shortest, strongest paths between them — traversing through shared companies, schools, organizations, and mutual connections.

Path finding discovers how two people are connected through intermediate nodes. The algorithm prefers paths with lower total weight (stronger relationships).

How Path Finding Works

The Cypher Pattern

// Find paths between person A and person B
MATCH path = (a:Person {node_uuid: $source_id})
              -[*1..4]-
              (b:Person {node_uuid: $target_id})

// Exclude expertise and location nodes from intermediate hops
WHERE ALL(n IN nodes(path)[1..-1]
      WHERE NOT n:DomainExpertise
      AND NOT n:SubDomainExpertise
      AND NOT n:City
      AND NOT n:Region
      AND NOT n:Country)

// Calculate total path weight
WITH path,
     length(path) AS hops,
     reduce(w = 0, r IN relationships(path) | w + r.weight) AS total_weight

RETURN path, hops, total_weight
ORDER BY hops ASC, total_weight ASC
LIMIT 10

Path Examples

Leverage Loops

A Leverage Loop is the user-facing feature built on path-finding. When you want to reach someone in your network, Orbiter shows you the strongest paths and suggests who to talk to first. The "loop" refers to the chain of introductions: You → Connector A → Connector B → Target.

9 Expertise System

The expertise system automatically identifies what people are expert in and organizes those expertise areas into a searchable taxonomy. It uses a two-phase pipeline: LLM identification followed by vector resolution.

Two-Phase Pipeline

The Taxonomy Structure

// Expertise forms a 2-level hierarchy in the graph:

(Person) -[:HAS_EXPERTISE]-> (SubDomainExpertise) -[:SUBDOMAIN_OF]-> (DomainExpertise)

// Example:
(Mark Pedersen) -[:HAS_EXPERTISE]-> (Graph Databases) -[:SUBDOMAIN_OF]-> (Data Engineering)
(Mark Pedersen) -[:HAS_EXPERTISE]-> (Redis)          -[:SUBDOMAIN_OF]-> (Data Engineering)
(Mark Pedersen) -[:HAS_EXPERTISE]-> (Cypher)         -[:SUBDOMAIN_OF]-> (Data Engineering)

Why Vector Resolution Matters

10 Discovery & Text-to-Cypher

Discovery is the natural language search interface for the knowledge graph. Users ask questions in plain English, and the system translates them into Cypher queries that run against FalkorDB.

How It Works

The LLM (Claude) receives the full graph schema — all node types, edge types, properties — and generates a valid Cypher query from the natural language input. This is different from semantic search (which uses embeddings) — text-to-Cypher enables structural queries:

11 Multi-Tenancy & Data Layers

The graph has multiple layers of data organization — understanding the header system and the master vs personal graph distinction is key.

The Header System

Every Xano API request that touches the graph uses two headers:

Master Graph vs Personal Graph

Scale Plan

Current: ~2,143 people enriched. Target: 25,000 contacts + 50,000 enriched from financial/investment data. Mark's plan is to import contacts from all users' LinkedIn exports, plus enrich a large dataset of people from the financial/tech ecosystem using Fundable deal data.

12 Mark's Design Philosophy

The knowledge graph reflects specific architectural opinions from Mark Pedersen. Understanding these helps explain why certain decisions were made.

13 Production Stats & Health

Current production metrics as of March 2026. The QA enrichment pipeline addresses many of the issues identified here.

Known Issues in Production Pipeline

QA Pipeline Results

The QA pipeline was tested across 20 people (180 stages total):

14 Glossary

Quick reference for terms Mark uses when discussing the knowledge graph.

bio_500 / "Juicy Bio"

AI-generated 500-word biography of a person. Used for display AND as the source text for vector embeddings. The single visibility gate.

about_500

Same as bio_500 but for companies. AI-generated 500-word company description.

name_embedding

1536-dimensional vector stored on Person/Company nodes. Generated from bio_500/about_500 using OpenAI text-embedding-3-small.

node_uuid

Universal identifier for graph nodes. For Person nodes, matches master_person.id. For Company nodes, matches master_company.id.

visibility

Boolean flag on Person nodes. True = person appears in search/discovery. False = hidden. Gate: bio_500 must exist.

FalkorDB

Redis-based in-memory graph database. Uses Cypher query language. Hosted on GCP. Graph name: "live".

Cypher

Graph query language (same as Neo4j). Used to create nodes, edges, and query the graph. All graph operations are Cypher queries sent via HTTP.

send-cypher

Xano function that sends a Cypher query to FalkorDB via HTTP API and returns the result.

send-cypher-with-embeddings

Like send-cypher but also handles vector operations — generates embeddings from text and includes them in the Cypher query.

send-cypher-with-paths

Specialized function for path-finding queries. Returns structured path data with node/edge details for each hop.

Weight

Numeric value on edges representing relationship strength. LOWER = STRONGER. Used by path-finding to prefer strong connections.

Edge Resolution

The process of matching relational records (work history, education) to existing graph nodes and creating typed edges between them.

Leverage Loop

User-facing feature: find the shortest, strongest chain of introductions to reach a target person through your network.

Discovery

Natural language search feature. Text-to-Cypher: user asks in English, LLM translates to graph query.

Bio-Bond

Mark's ontology model. "Bio" = entity identity (person, company). "Bond" = relationship with type, strength, and decay.

PDL (People Data Labs)

External data source providing professional profile data (work, education, skills). Broad coverage, lower depth.

Enrich Layer

External data source providing deeper profile enrichment. Stored as enrichLayer_json on master_person.

Fundable

External data source providing financial/investment data — funding rounds, investors, deal flow.

master_person

The single source of truth table in Xano for person identity. All enrichment data links back to a master_person record.

master_company

The single source of truth table for company identity. Contains domain, industry, staff count, and links to graph node.

enrich_history_person

Tracks enrichment pipeline status per person per data source. The "processing" flag prevents duplicate enrichment runs.

Stuck Processing

When enrich_history_person.processing = true but the function has crashed. The person is "stuck" — won't be re-enriched until manually reset.

Qdrant

Separate vector database used for user documents and emails. NOT part of the knowledge graph — don't confuse with FalkorDB vectors.

X-Data-Source / X-Branch

HTTP headers on Xano API calls. X-Data-Source: "live" (which data environment). X-Branch: "v1" (API version).