A native ontology engine
Most stacks bolt a separate graph database onto the side. Jikji builds and serves knowledge graphs inside the binary — a pure-Go engine that derives an ontology from your documents and answers SPARQL 1.1 over it, with no external triple store to run.
The graph records provenance and supports mechanical predicates; generated entity extraction still needs corpus-specific quality evaluation.
From a corpus to a grounded ontology
Point it at a corpus and it derives the schema and the facts — not just triples, but the classes and relationships that hold them together, validated as they land.
Emergent build derives an ontology's classes, relationships, and CURIE prefixes from the source material itself, rather than requiring a schema up front — with optional insight rounds that deepen the structure.
An extraction codec turns documents into typed triples, and a synthesis pass composes higher-level structure over them — so the graph captures meaning, not just mentions.
Grounding validates each new relation against its source text before it is accepted, dropping hallucinated triples, and native linting keeps the ontology internally consistent — so quality does not drift as the graph grows.
Seed a build from a prior ontology and append only what is new — an accumulator deduplicates triples so repeated runs are idempotent. Built to refresh on a schedule through the almanac cron, not to be rebuilt from scratch.
Build or refresh from the CLI — ground new facts, deepen with insight rounds, grow an existing graph:
jikjictl ontology build \ --source ./doc.txt \ --ground \ # validate new triples against their source --insight-rounds 2 \ # deepen the emergent schema --seed-from prior.ttl \ # incremental: grow an existing ontology --out knowledge.ttl
Served in-process, queried with SPARQL
The graph lives in a pure-Go RDF store inside the runtime. Agents query it as a tool, the planner is augmented by it, and operators hit it over the API — all without a separate database.
SPARQL 1.1, embedded
A from-scratch SPARQL engine — lexer, parser, and evaluator — answers SELECT with basic graph patterns, FILTER, OPTIONAL, UNION, MINUS, BIND, VALUES, property paths, sub-selects, and aggregation (GROUP BY / HAVING), with bounded result safety.
Pure-Go RDF store
An indexed in-memory triple store with TTL parsing and serialization, prefix management, and freeze/unload lifecycle — no JVM, no sidecar, no external graph database to operate.
Semantic search & re-ranking
The ontology.search tool blends graph lookup with semantic re-ranking over embeddings, so retrieval leans on structured meaning. Embeddings are opt-in (Jina, OpenAI, or Ollama) and degrade to graph-only when off.
It augments the planner
Beyond facts, the lexicon layer carries situations and workflow templates that inject context into the agent loop — so the ontology shapes how the agent plans, not just what it can look up. Tenant-scoped throughout.
Query the live graph with SPARQL 1.1 — via the lexicon.query / ontology tools or the API:
PREFIX org: <http://example.org/> SELECT ?service (COUNT(?dep) AS ?deps) WHERE { ?service a org:Service ; org:tier "critical" . OPTIONAL { ?service org:dependsOn ?dep } } GROUP BY ?service ORDER BY DESC(?deps)
Rehearse a future; never claim to predict it
The foresight sandbox records scenario actors in the graph, derives a small set of stakeholder personas, runs bounded reactions, and asks a verifier-gated ensemble for a provenance-mapped report.
Grounded inputs
Every report branch must trace to a persona reaction, recorded graph fact, and source seed. Unsupported synthesis is revised rather than accepted.
Bounded simulation
The reference design uses four to six personas over one or two rounds so cost stays bounded and each reaction remains auditable.
An ontology over your data
A knowledge graph is most useful when it sits over real operational data. Jikji pairs the ontology with a governed relational store, pipelines, and caching — the ontology-over-data model behind modern decision platforms, implemented natively inside an agent runtime.
Graph and tables, together
The ontology is a semantic layer over galley's relational store (SQLite, PostgreSQL, or MySQL). Agents reason across both — the meaning in the graph and the rows in the database — in a single run.
Governed SQL access
A SQL tool lets agents query data, but sqlguard enforces a statement and table allowlist — read-only by default — and galley injects a tenant_id predicate so a query is scoped to its own tenant. Analysis never steps outside policy.
Pipelines & caching
Import and export data through pipeline tools, and keep intermediate results in tenant-namespaced caches and a semantic response cache — so repeated analysis is fast and doesn't re-pay for the same work.
Analysis in the loop
Put it together and an agent can pull rows with governed SQL, cross-reference them against the ontology, cache the intermediates, and reason over the result — a versatile data layer that turns operational data into answers.
Data science & ML, in the loop
Pull rows with governed SQL, reuse them from the cache, and hand them to a Python tool running pandas, NumPy, or scikit-learn — analysis and modeling happen inside one agent run, not off in a separate notebook.
The ontology audits the system
Model your own system as an ontology: components are nodes and invariants are checkable predicates over live observations. Checking an observation against its invariant mechanically yields a violation, materialized into the graph — so "the system is healthy" is a claim that must be proven from zero-violation evidence, never self-reported.