Lean 4 KnowledgeLean 4 Knowledge · 5 min read
A knowledge graph can record that Alice works for an organisation. It can also record an impossible combination of facts, an outdated identity, or a relationship whose endpoints have the wrong kinds. Different failures need different tools. A schema handles some; a proof about the whole store can handle others.
Start with types, then let types mention values
Ordinary types already improve a graph interface. A function expecting a person should not accept a company identifier by accident. A relationship can specify the kinds of its endpoints. Dependent type theory, or DTT, goes further: a type may refer to a particular value. Evidence can therefore concern this exact graph, rather than merely graphs in general.
In Lean, propositions have types too, and a proof is a term checked against its proposition. A useful design is a pair consisting of a graph g and evidence of Valid g. The evidence is tied to the graph it describes. Change the graph, and the old evidence does not automatically certify the replacement. This is a practical application of the dependent types explained in Theorem Proving in Lean 4.
Make the boundary do the work
Consider an organisation directory with an application rule: a person may have at most one active primary employer. That rule is a deliberate modelling choice, not a universal fact about employment. A candidate update may satisfy all local field types while breaking that global rule.
A certified insertion operation must establish that the resulting store still satisfies the invariant. It can return a new certified store, or a structured rejection that explains which obligation was not discharged. A language model may propose the update and help interpret the rejection, but its confidence does not substitute for the missing evidence.
Certification is a contract you design
The difficult work often happens before proving anything: choosing identities, temporal boundaries, equality, and the meaning of absence. Is a relationship an enduring fact or an observation at a particular time? Can two sources disagree without making the store invalid? Explicit observation types and provenance can preserve disagreements while keeping your accepted conclusions coherent.
Not every invariant has an automatic decision procedure. A total checker needs a decidable property, a restricted domain, or supplied certificates that it can verify. Lean does not turn every ontology question into a terminating yes-or-no test. Start with a small invariant whose meaning you can explain and whose enforcement you can test.
What the proof actually buys you
The result is conditional: the encoded graph satisfies the encoded property under the assumptions used by the proof. It does not establish that an imported employment record is true, or that your definition captures every business requirement. Keep input provenance, model review, and the proof boundary visible.
Bulletproof Knowledge develops this pattern for agent memory. For the programming background, continue with Propositions and Proofs, then compare certified state with the typed persistence interfaces in typedb-lean.