{"slug": "show-hn-lean4-datalog-dsl-based-on-google-zanzibar-for-ai-projects", "title": "Show HN: Lean4 Datalog DSL Based on Google Zanzibar for AI Projects", "summary": "A new open-source Lean 4 Datalog DSL called ZIL, inspired by Google's Zanzibar authorization system, allows developers to model relationships between code, requirements, tests, and tasks using compact relational tuples and Horn rules. ZIL records how Lean declarations relate to project artifacts, enabling queries such as which declaration implements a requirement or which modules depend on a declaration, and supports AI assistants, CI, and documentation tools. The project's relation model mirrors Zanzibar's tuple-oriented approach, with examples showing how rules can derive additional relationships like transitive viewer access or requirement coverage.", "body_md": "ZIL is a small relational language for describing named objects, the relationships between them, and rules that derive additional relationships.\n\nA relation has three parts:\n\n```\nsubject ── relation ──▶ object\n```\n\nFor example:\n\n```\nlean.Parser.parse ── implements ──▶ requirement.parseInput\n```\n\nZIL Lean implements this model inside Lean 4. Lean checks definitions, executable programs, theorem statements, and proofs. ZIL records how those checked declarations relate to requirements, documents, tests, tasks, dependencies, and other parts of a project.\n\nThe same project map can answer questions such as:\n\n```\nwhich declaration implements this requirement?\nwhich theorem validates this component?\nwhich modules depend on this declaration?\nwhich task is waiting for this result?\nwhich declarations should be reviewed after this change?\n```\n\nDevelopers, review tools, CI, documentation tools, and AI assistants can query the same stored relationships.\n\nZIL's relation model is influenced by the tuple-oriented model described in Google's Zanzibar paper:\n\n[Zanzibar: Google's Consistent, Global Authorization System (USENIX ATC '19)](https://storage.googleapis.com/gweb-research2023-media/pubtools/5068.pdf)\n\nSection 2.1 represents an authorization tuple as:\n\n```\nobject#relation@user\n```\n\nTable 1 gives these examples:\n\n```\ndoc:readme#owner@10\ngroup:eng#member@11\ndoc:readme#viewer@group:eng#member\ndoc:readme#parent@folder:A#...\n```\n\nThey describe four useful relation patterns:\n\n```\nuser 10 is an owner of doc:readme\nuser 11 is a member of group:eng\nmembers of group:eng are viewers of doc:readme\ndoc:readme is in folder:A\n```\n\nThe third tuple uses the userset:\n\n```\ngroup:eng#member\n```\n\nThis userset names everyone related to `group:eng`\n\nthrough `member`\n\n. A tuple can therefore refer to another relation, supporting group membership and inherited access.\n\nStandalone ZIL can express the same tuple-shaped facts:\n\n```\ndoc:readme#owner@user:10.\ngroup:eng#member@user:11.\ndoc:readme#viewer@group:eng#member.\ndoc:readme#parent@folder:A.\n```\n\nNative ZIL Lean syntax represents the relations with Lean names:\n\n``` python\nimport Zil\n\nzil_fact\n  node(doc.readme)\n    ⟶[owner]\n  node(user.u10)\n\nzil_fact\n  node(group.engineering)\n    ⟶[member]\n  node(user.u11)\n\nzil_fact\n  node(doc.readme)\n    ⟶[viewer]\n  node(group.engineering)\n```\n\nZanzibar uses relation tuples to describe authorization data. ZIL uses the same compact relational building blocks for authorization models and for wider project relationships:\n\n```\ndocument ───── viewer ──────▶ group\ndeclaration ── implements ──▶ requirement\ntheorem ────── validates ────▶ component\nmodule ─────── dependsOn ────▶ module\ntask ───────── blockedBy ────▶ issue\nclaim ──────── supportedBy ──▶ document\n```\n\nTable 1 presents relation data. Rules describe how additional relations follow from that data. ZIL uses Horn rules, the rule form commonly used by Datalog systems.\n\nFor example:\n\n```\nwhen a group can view a document\nand a user belongs to that group,\nthe user can view the document\n```\n\nIn ZIL Lean:\n\n```\nzil_theorem_rule groupViewer\n  {document group user : Zil.Node}\n  (hViewer : document ⟶[viewer] group)\n  (hMember : group ⟶[member] user)\n  : document ⟶[viewer] user\n```\n\nGiven:\n\n```\ndoc.readme ─────────── viewer ──▶ group.engineering\ngroup.engineering ──── member ──▶ user.u11\n```\n\nrepeated rule evaluation adds:\n\n```\ndoc.readme ── viewer ──▶ user.u11\n```\n\nThe same rule structure can derive project relationships, such as requirement coverage and change impact.\n\nConsider a project containing a parser, a normalization pass, and a theorem about normalized output:\n\n``` python\nimport Zil\n\nzil_fact\n  node(lean.Parser.parse)\n    ⟶[implements]\n  node(requirement.parseInput)\n\nzil_fact\n  node(lean.Normalize.normalize)\n    ⟶[dependsOn]\n  node(lean.Parser.parse)\n\nzil_fact\n  node(lean.Normalize.normalized_sound)\n    ⟶[validates]\n  node(lean.Normalize.normalize)\n```\n\nThese facts form a relationship map:\n\n```\nrequirement.parseInput\n          ▲\n          │ implements\nlean.Parser.parse\n          ▲\n          │ dependsOn\nlean.Normalize.normalize\n          ▲\n          │ validates\nlean.Normalize.normalized_sound\n```\n\nLean checks the parser, normalizer, theorem statement, and proof. ZIL stores their project roles and connections.\n\nA query can ask:\n\n- which declaration implements\n`requirement.parseInput`\n\n; - which components depend on the parser;\n- which transformations have a validation theorem;\n- which downstream declarations should be reviewed after a change.\n\nA rule can derive direct change impact:\n\n```\nzil_theorem_rule propagateImpact\n  {changed dependent : Zil.Node}\n  (hDepends : dependent ⟶[dependsOn] changed)\n  : changed ⟶[affects] dependent\n```\n\nFrom the parser dependency, the engine adds:\n\n```\nlean.Parser.parse\n  ── affects ──▶\nlean.Normalize.normalize\n```\n\nA second rule continues the relationship through several levels:\n\n```\nzil_theorem_rule propagateTransitiveImpact\n  {source middle target : Zil.Node}\n  (hFirst : source ⟶[affects] middle)\n  (hSecond : target ⟶[dependsOn] middle)\n  : source ⟶[affects] target\n```\n\nLocal dependency facts can therefore support a repository-wide review query.\n\nLean verifies terms, types, definitions, computation, theorem statements, and proofs.\n\nZIL stores relationships concerning purpose, coverage, dependencies, evidence, tasks, and review work across the repository.\n\nTogether they support questions such as:\n\n- Which declaration implements a requirement?\n- Which theorem validates a transformation?\n- Which modules depend on a changed declaration?\n- Which claims have supporting documents?\n- Which work items are waiting for a result?\n- Which advertised capabilities have implementation links?\n- Which facts and rules produced an inferred relationship?\n- Which project assumptions changed since the previous work session?\n\nThese relationships can connect Lean declarations to requirements, documents, issues, tests, tools, and external sources across many modules.\n\nZIL uses four primary structures:\n\n**nodes** identify declarations, requirements, claims, tests, files, tasks, users, groups, or other objects;**relations** connect two terms;**rules** derive relations from existing relations;**queries** return matching terms and variable bindings.\n\nNodes use stable names:\n\n```\nlean.Parser.parse\nlean.Normalize.normalized_sound\nrequirement.parseInput\ncomponent.normalizer\nissue.missingTerminationProof\ndocument.design.section4\nassistant.formalization\n```\n\nThe repository pins Lean to:\n\n```\nleanprover/lean4:v4.31.0\n```\n\nBuild the package and run the Lean tests:\n\n```\nlake build\nlake exe zilLeanTests\n```\n\nProgressive native examples are under `examples/lean/`\n\n:\n\n```\nlake env lean examples/lean/01_FactsAndRelations.lean\nlake env lean examples/lean/02_TheoremShapedRule.lean\nlake env lean examples/lean/03_TypedRule.lean\nlake env lean examples/lean/04_MultiStepQuery.lean\nlake build KnowledgeBase\nlake env lean examples/lean/05_ImportedKnowledge.lean\nlake env lean examples/lean/06_ProjectVerificationArc.lean\n```\n\nAll documented example groups are also runnable through the Makefile:\n\n```\nmake examples                 # lean, native, integration, and legacy groups\nmake examples GROUP=lean      # one group; report in .zil/examples-reports/\n```\n\nRegister a fact:\n\n```\nzil_fact\n  node(lean.Parser.parse)\n    ⟶[implements]\n  node(requirement.parseInput)\n```\n\nDeclare a theorem-shaped rule:\n\n```\nzil_theorem_rule implementationCoversRequirement\n  {declaration requirement : Zil.Node}\n  (hImplements : declaration ⟶[implements] requirement)\n  : requirement ⟶[coveredBy] declaration\n```\n\nThe block form expresses the same rule:\n\n```\nzil_rule implementationCoversRequirement where\n  variables declaration requirement\n  premises\n    declaration ⟶[implements] requirement\n  conclusion\n    requirement ⟶[coveredBy] declaration\n```\n\nBoth forms produce the standard `Zil.Rule`\n\nvalue used by the engine and tools.\n\nA query can retrieve the implementation covering a requirement:\n\n```\nprivate def coverageQuery : Zil.Query := {\n  name := `implementationForRequirement\n  variables := #[`declaration]\n  select := #[`declaration]\n  premises := #[\n    .mk'\n      (.ground `requirement.parseInput)\n      `zil.coveredBy\n      (.variable `declaration)\n  ]\n}\n```\n\nThe engine binds variables, matches several premises, removes repeated results, and applies rules until the result set becomes stable within the configured bound.\n\nA relation schema records the expected source and target types:\n\n```\nimplements  : declaration → requirement\nvalidates   : theorem → component\ndependsOn   : declaration → declaration\nblockedBy   : task → requirement\nsupportedBy : claim → evidence\nmember      : group → user\nviewer      : document → user-or-group\n```\n\nA typed rule declares the type of each variable:\n\n```\nzil_typed_rule typedCoverage using Zil.Profile.research where\n  variables\n    declaration : declaration\n    requirement : requirement\n  premises\n    declaration ⟶[implements] requirement\n  conclusion\n    requirement ⟶[coveredBy] declaration\n\n#guard typedCoverage.valid\n```\n\nThe schema reports category mistakes while keeping the underlying rule available for messages and tools.\n\nZIL stores selected project facts with the source code. Developers, reviewers, build tools, documentation tools, issue trackers, and AI assistants can use the same map.\n\n```\nfile.Parser.lean ── responsibleFor ──▶ requirement.parseInput\nlean.Parser.parse ── implements ─────▶ requirement.parseInput\n```\n\nA developer or assistant can inspect why a file exists and which requirement its declarations serve before editing it.\n\n```\nrequirement.totalParser ── blockedBy ──▶ issue.missingTerminationProof\nissue.missingTerminationProof ── assignedTo ──▶ task.proveTermination\n```\n\nQueries can find blocked requirements, tasks awaiting an owner, and capabilities awaiting an implementation link.\n\n```\nlean.Normalize.normalize ── dependsOn ──▶ lean.Parser.parse\nlean.Codegen.emit ───────── dependsOn ──▶ lean.Normalize.normalize\n```\n\nImpact rules return the downstream components that require review when `lean.Parser.parse`\n\nchanges.\n\n```\nzil_checkpoint beforeParserRefactor\n#zil_check_mutation token\n```\n\nChange checks compare graph revisions, contracts, stated goals, and rollback checkpoints before automated work continues.\n\nEach inferred relation can record:\n\n```\ninput project facts\nrule name\nvariable bindings\ntrust level\ninput relation identifiers\n```\n\nThis gives developers and tools a step-by-step explanation of how the engine reached a result.\n\n`ZILX/1`\n\nsnapshots and `ZILD/1`\n\ndeltas allow separate tools to exchange the same project map. One tool may inspect requirements, another implement code, another verify proofs, and another review impact while sharing stable relation names and revision numbers.\n\nAuthorization-style relations can also describe roles in an automated workflow:\n\n```\nrepo.zilLean ── editor ─────▶ group.implementers\ngroup.implementers ─ member ▶ assistant.codegen\nrepo.zilLean ── reviewer ───▶ assistant.verifier\n```\n\nThe tuple model therefore supports project context and role-based access to project operations.\n\nFacts, rules, schemas, contracts, checkpoints, declaration links, and proof-backed rules use Lean environment extensions. Compiled `.olean`\n\nimports restore registered entries and collapse repeated diamond imports into one relation.\n\nThe coverage linter evaluates the stored and inferred relations:\n\n```\n#zil_lint\n#zil_lint!\n```\n\nA formalization contract can record required declarations, required relations, advertised scope, completion state, and revision history:\n\n```\nzil_register_contract contract\n#zil_contract_check\n#zil_contract_check!\n```\n\nContracts give maintainers and tools a shared description of the expected result of a task or file.\n\nZIL records three trust levels:\n\n```\nasserted\ngraphDerived\ncertified\n```\n\n`asserted`\n\nmarks a directly registered project fact;`graphDerived`\n\nmarks an inferred relation;`certified`\n\nassociates a rule with a Lean proposition and proof term.\n\n```\nprivate theorem certificate : True := True.intro\n\nprivate def certifiedRule : Zil.Trust.CertifiedRule :=\n  .mkChecked graphRule True certificate\n\nzil_register_certified_rule certifiedRule\n```\n\nLean checks the proposition and proof term. ZIL records how the checked declaration participates in the project map.\n\nFor inferred relationships, the explanation data records the project fact, source, rule name, variable binding, trust level, and input relation identifiers. Developers and tools can use that data to show how a result was reached.\n\nThe native `zil`\n\nexecutable reads `.zc`\n\nmodels and `ZILR/1`\n\nrevision logs:\n\n```\nbin/zil expand examples/native-cli/formalization-claims.zc -\nbin/zil query-ci examples/native-cli/formalization-claims.zc\nbin/zil revision-summary examples/revision/release.zilr\nbin/zil snapshot examples/revision/release.zilr 2 -\n```\n\nSupported operations include `compile`\n\n, `expand`\n\n, `trace`\n\n, `query-ci`\n\n, `explain-query`\n\n, `explain-authorization`\n\n, `dependency-graph`\n\n, `impact`\n\n, `authorize`\n\n, `revision-summary`\n\n, `snapshot`\n\n, and `causal-check`\n\n(`bin/zil --help`\n\nlists them all). See `examples/native-cli/README.md`\n\nfor the walkthrough.\n\nRelations and rules have deterministic text codecs:\n\n```\nZil.Codec.encodeRelation\nZil.Codec.decodeRelation\nZil.Codec.encodeRule\nZil.Codec.decodeRule\n```\n\n`ZILX/1`\n\nstores revisioned snapshots. `ZILD/1`\n\nstores incremental updates with base and target revisions, fact changes, rule changes, and schema changes.\n\nFacts and rules can be exported to Soufflé Datalog or Prolog:\n\n```\n#zil_export_souffle\n#zil_export_prolog\n```\n\nThese interfaces let external analysis tools and assistants consume the same relational state used by the Lean implementation.\n\nZIL Lean can support:\n\n- Zanzibar-style authorization and group-membership models;\n- maps connecting informal claims to Lean declarations;\n- requirement-to-implementation tracking;\n- theorem and component dependency analysis;\n- change-impact queries across modules;\n- evidence and source tracking;\n- repository coverage checks;\n- explicit task contracts for people and tools;\n- AI assistants continuing work across sessions with revision and checkpoint checks;\n- step-by-step explanations for inferred project relationships;\n- exchange of relation data with Datalog and Prolog tools.\n\nThe repository also contains the standalone ZIL syntax and Clojure/DataScript runtime. It supports `.zc`\n\nfiles, macros, import/export tools, embedded annotations, and adapters.\n\n```\nclojure -M -m zil.cli examples/it-infra-minimal.zc\n```\n\nThe standard exchange layer connects that runtime with the native Lean representation.\n\n```\nZil/                 native Lean library\nZil/Engine/          Horn-rule evaluation and relationship explanations\nZil/Trust/           proof-backed rules\nZil/Exchange/        snapshots and deltas\nexamples/lean/       progressive native examples\nexamples/native-cli/ CLI snapshot example\nsrc/zil/             Clojure runtime and tools\nspec/                language and runtime specifications\n```\n\nExpected repository validation:\n\n```\nlake build\nlake exe zilLeanTests\nclojure -M:test\n```\n\nThe Lean toolchain is pinned to `leanprover/lean4:v4.31.0`\n\n.", "url": "https://wpnews.pro/news/show-hn-lean4-datalog-dsl-based-on-google-zanzibar-for-ai-projects", "canonical_source": "https://github.com/jagg-ix/zil-lean", "published_at": "2026-07-29 02:22:04+00:00", "updated_at": "2026-07-29 02:52:32.856914+00:00", "lang": "en", "topics": ["developer-tools", "artificial-intelligence", "ai-tools"], "entities": ["ZIL", "Lean 4", "Google Zanzibar", "Horn rules", "Datalog"], "alternates": {"html": "https://wpnews.pro/news/show-hn-lean4-datalog-dsl-based-on-google-zanzibar-for-ai-projects", "markdown": "https://wpnews.pro/news/show-hn-lean4-datalog-dsl-based-on-google-zanzibar-for-ai-projects.md", "text": "https://wpnews.pro/news/show-hn-lean4-datalog-dsl-based-on-google-zanzibar-for-ai-projects.txt", "jsonld": "https://wpnews.pro/news/show-hn-lean4-datalog-dsl-based-on-google-zanzibar-for-ai-projects.jsonld"}}