The Knowledge Infrastructure
Neurosymbolic AI needs a knowledge layer that is human-readable, machine-queryable, and version-controlled. We couldn't find one that met all three requirements, so we built it. The tools below are the foundation of everything we do at Conguent Systems — and they're open source.
Yurtle — Markdown That Becomes a Knowledge Graph
The specification. Yurtle is a file format: add a YAML or Turtle RDF block to the top of any Markdown file, and it becomes a node in a queryable knowledge graph. No plugins, no database — just files.
This is the foundational idea behind our neurosymbolic architecture. A NuSy being's entire knowledge store is Yurtle files in a Git repository. When a being learns a new fact, it crystallizes into a triple inside a Yurtle document. When it needs to reason, it queries the graph. When a human wants to audit what the being knows, they read the Markdown.
---
yurtle: v2.0
id: nautical/voyage
type: voyage
title: The Crossing of the Western Sea
relates-to:
- nautical/ship
- nautical/crew
nugget: A three-month voyage to chart the uncharted archipelago
---
Yurtle v2.0 introduces the Y-Layer Specification — a 7-layer model (Y0 through Y6) that organizes a being's knowledge from raw source documents up to metacognitive self-awareness. This is the same architecture described on our Product page, defined as a formal specification rather than just code.
Three ways to express knowledge in one file:
- Frontmatter (top of file) — document-level metadata
- Wiki links (in prose) —
[[relationships]]extracted by LLMs - Yurtle blocks (anywhere) — structured data in code fences
yurtle-rdflib — The Graph Engine
The Python library. An RDFlib plugin that parses and serializes Yurtle files, enabling SPARQL queries across entire workspaces of Markdown documents.
This is what makes Yurtle files queryable. When a NuSy being needs to answer "what do I know about pulmonary embolism?", it doesn't search files — it runs a SPARQL query against a unified graph built from every Yurtle file in its knowledge store. The graph is the source of truth during reasoning; the files are persistence.
from rdflib import Graph
import yurtle_rdflib
# Load every Yurtle file in a workspace
graph = yurtle_rdflib.load_workspace("knowledge/")
# Query across all documents
results = graph.query("""
SELECT ?concept ?title WHERE {
?concept a yurtle:MedicalConcept ;
yurtle:title ?title ;
med:relatedTo <urn:condition:pulmonary-embolism> .
}
""")
Why this matters for neurosymbolic AI:
- SPARQL replaces keyword search. Instead of finding files that mention "diabetes," query for all entities with a
clinicalUsepredicate containing diabetes — across thousands of documents, with joins, aggregations, and graph traversal. - Provenance is built in. Every triple knows which file it came from. When a being cites a source, the citation traces back to a specific Yurtle document, line, and timestamp.
- Bidirectional sync. Edit a file in your text editor — the graph updates. Add a triple programmatically — the file updates. The being's knowledge is always consistent between file and graph representations.
# Live sync: graph changes persist to files immediately
kb = yurtle_rdflib.create_live_graph("workspace/", auto_flush=True)
kb.add((subject, predicate, object)) # Written to disk instantly
55+ tests. Python 3.9-3.13. MIT licensed.
pip install yurtle-rdflib
yurtle-kanban — File-Based Workflow for AI Teams
The coordination layer. A kanban board system where work items are Markdown files with YAML frontmatter. Git is the database. Designed for multi-agent workflows where AI developers and human captains coordinate through a shared repository.
This is how we manage NuSy development itself. Multiple Claude instances (on DGX, MacBook, Mac Mini) work in parallel, picking up expeditions, executing them, and submitting results — all coordinated through yurtle-kanban. The kanban board lives in the same repository as the code, so every feature branch includes both the implementation and its work item.
yurtle-kanban board # View the board
yurtle-kanban next-id EXP # Allocate next ID (multi-agent safe)
yurtle-kanban create expedition "Title" --priority high
yurtle-kanban move EXP-827 in-progress # Update status
yurtle-kanban list --assignee dgx-claude # What's assigned to DGX?
Why file-based kanban for AI agents:
- No external dependencies. No Jira, no database, no API server. Agents read and write work items like any other file. Works offline. Works in CI/CD.
- Multi-agent safe ID allocation. The
next-idcommand uses Git atomic operations to prevent ID collisions when multiple agents create work items simultaneously — fetch, allocate, commit, push, retry on conflict. - MCP server included. AI agents access the kanban via Model Context Protocol, enabling Claude Code to check the board, pick up work, and update status within its normal workflow.
- Themed workflows. Software mode (Feature, Bug, Epic) or Nautical mode (Expedition, Voyage, Hazard) — or define your own. NuSy uses nautical theming because the metaphor keeps us honest about what we're building: voyages of discovery, not sprints.
Includes Claude Code skills: /work, /done, /expedition, /review, /sync, /handoff, /blocked, /release — a complete multi-agent development workflow.
pip install yurtle-kanban
How They Fit Together
yurtle The format specification — what a knowledge file looks like
↓
yurtle-rdflib The engine — parses files into graphs, enables SPARQL queries
↓
yurtle-kanban The workflow — coordinates who builds what, tracked in the same format
↓
NuSy beings The application — AI entities that learn, reason, and grow using all three
A being's curriculum is Yurtle files. Its knowledge graph is built by yurtle-rdflib. Its development is tracked by yurtle-kanban. The same format, the same tools, all the way down.
This Website
Even this website is built with Yurtle. Every page and post is authored as a Yurtle file first — Markdown body for Ghost to render, Turtle frontmatter for the knowledge graph. The site's content is simultaneously a publication and a queryable semantic dataset.
Contributing
We welcome contributions to all three projects. Each repository includes CONTRIBUTING.md with workflow and standards. We follow TDD/BDD — all PRs require test coverage.