examples/30_workloads/
tier is where the Basics and
Core APIs come together into applications you’d
actually ship. Each is a single runnable file with a heavily commented walkthrough.
The summaries below distil what each one teaches and the one call that carries it.
Most of these workloads lean on VectorCypher’s knowledge graph, so they’re best on
PostgreSQL + Neo4j. Run
make dev in the khora repo to bring them up, and pass
--config examples/khora.standard.yaml to point at that stack. They also run on the
zero-infra embedded backend (pip install "khora[sqlite-lance]" + OPENAI_API_KEY),
where entity-vector search is brute-force (no ANN index), so write-time dedup and some
graph reads are slower.Support-ticket knowledge graph
Ingest ~100 support tickets, then ask two shapes of question. “Tickets about login failures” is a ranked-list problem. Vector search nails it. “Give me context around Acme Logistics” is a neighborhood problem. The answer is Acme’s tickets, the products Acme uses, the agents handling them, the error categories, and other customers on the same products. That’s a 2-hop graph walk, not a similarity search.ORGANIZATION, SKU = PRODUCT, error category =
CONCEPT, agent = PERSON) so the multi-hop walk has real structure to follow.
Namespace versioning
AMemoryNamespace carries two UUIDs: namespace_id is the stable id (same
across every version: hold this in your application code), and id is the
row primary key, distinct per version. The high-level facade
(kb.remember / kb.recall) takes the stable id and resolves to the active
version. The storage layer (kb.storage.*) takes a row id to address a specific
version.
Resume search
The entity-centric workload where dedup is the story: 50 résumés where “Stripe”, “Stripe Inc.”, “Stripe, Inc.” and “stripe.com” must resolve to one node, and “k8s” / “K8s” / “Kubernetes” to another, before you can answer “Stripe alumni who know Kubernetes.” The work lives in theExpertiseConfig: a system prompt that
canonicalizes surface forms at extraction time, plus typed entities and
relationships whose identifiers drive cross-document matching.
ExpertiseConfig is the whole game. entity_types /
relationship_types give the graph its shape, identifiers tell the unifier what
“the same entity” means, and the system_prompt canonicalizes variants the matcher
would otherwise miss. See Expertise & ontologies for
the full surface (attributes, inference rules, confidence). Defaults to PostgreSQL +
Neo4j. The embedded backend has no entity-vector index, so similarity dedup can’t
catch variants the LLM didn’t already collapse.
Multimodal document QA
khora indexes text, so “multimodal” is a pipeline shape, not a separate API: turn each non-text element into text, then ingest everything uniformly. This workload takes a corpus of Markdown docs whose figures are embedded as image links (). Each figure is
described by a vision model (its alt text steers the description), so the picture becomes
searchable text tagged with its image path. Every chunk gets a stable external_id, so a
retrieval-augmented answer can cite exactly which sections and figures it drew on.
external_id per chunk is what makes the answer citable. This one needs a vision-capable
model on top of the usual OPENAI_API_KEY.
Next steps
Integrations
Wire these patterns into CrewAI, LangGraph, Google ADK, OpenAI Agents, or
LlamaIndex.
VectorCypher
How the engine fuses vector, graph, and keyword search behind these examples.