Lean 4 KnowledgeLean 4 Knowledge · 5 min read
“Use a knowledge graph” does not select a data model, a query language, or a trust boundary. An agent might need concurrent structured persistence, a local property graph, or standards-based semantic interchange. These needs overlap, but they do not imply the same architecture.
TypeDB: model roles and relationships explicitly
TypeDB is a useful fit when a domain is organised around entities, relations, attributes, and roles. A relation can involve several participants, and the role each plays is part of the model. For organisational knowledge, a person's participation in a project is richer than an unlabelled connection between two identifiers.
typedb-lean connects this model to Lean structures and typed transactions. Its interface includes schema generation, decoding into structures, query interpolation, and migration support. Transaction modes encode whether an operation belongs in a read, write, or schema transaction. These are concrete interface guarantees; they are not a proof that every fact in a remote database satisfies an arbitrary application ontology.
LadybugDB: embed a typed property graph
A property graph represents nodes and relationships with their properties. An embedded database can suit a local tool or agent that needs graph queries without operating a separate database server. The questions here include path traversal, optional matches, and how nullable values flow through a query.
ladybug-lean describes node and relationship tables in Lean and provides typed Cypher alongside a query builder. The same graph interface can run against LadybugDB or an in-memory implementation. That makes small examples and differential testing easier. The pure backend is a useful development tool, but agreement in tests is not automatically a formal equivalence theorem for every external database behaviour.
RDF: make semantic interchange explicit
RDF suits work where shared identifiers, vocabulary, and standard entailment semantics matter. A triple is small; the interpretation of those triples carries much of the system's meaning. RDFS, selected OWL profiles, and SHACL provide different ways to infer or constrain that meaning.
LeanRDF focuses on those semantics and the evidence behind results. It is not simply another persistence driver. It supplies a formal model, reasoning and query components, and certificate checking. Its documented oxilite integration is one concrete example of connecting an external engine to certification.
A project map is not an integration guarantee
These projects form an ecosystem of complementary tools, not a preassembled pipeline in which every arrow is already implemented. LeanElpi can supply logic programming; Lean supplies types and proof checking; a database supplies persistence. Joining them requires an explicit mapping and a definition of what information crosses each boundary.
Before combining stores, decide how identifiers correspond, which timestamps matter, how null differs from absence, and how a multi-party relation becomes a collection of triples. A lossy translation may erase the very fact a proof needs. Preserve provenance and define a stable snapshot for certification.
Begin with the smallest representation that matches your domain. Use the free mini books on TypeDB and Lean and LadybugDB and Lean for implementation paths. Add semantic certification where a precise claim deserves a precise justification.