Lean checker validating Skill Plugin
Ivan Rojas
It goes through goals in lean and solves for a theorem. It asks sub questions about why a checker passed/failed and adds this as a topological layer (a chain complex). We estimate a betti table using qiskit for test problems of greater complexity and this estimates the time any checker takes for parsed questions in the homology.
This project appears to wrap a prime_kernel_homology.ipynb pipeline into a reusable Lean checker validator, using persistent homology over embedded reasoning traces and a pregroup decision tree over several Lean kernel checkers. The idea of validating proof-checker behavior and reasoning traces is potentially relevant to secure program synthesis, but the submission does not yet make a clear case that the method solves a concrete safety problem.
The main issue is clarity. The report uses many technical concepts - pregroup grammars, persistent homology, Betti numbers, QPE, torus barcodes, Lean checker kernels - but it is difficult to tell what is actually implemented, what is being evaluated, and what claim is supported by evidence. The test set appears to be only prime proofs for very small primes, and the report does not provide a clear success metric, baseline, failure case, or security-relevant result.
The execution also seems thin for the stated ambition. The deliverables are mostly a plugin folder, a plan, a LaTeX record, and a signal-flow description. I could not identify a concrete validation result showing that this method catches incorrect proofs, distinguishes good from bad checkers, improves Lean verification, or prevents a secure synthesis failure mode. The QPE discussion is interesting but explicitly says there is no advantage at the current scale.
To improve the project, I would strongly recommend simplifying the framing. Start with one clear task: for example, “given several Lean checker variants, detect which ones incorrectly accept invalid proofs.” Then provide a small benchmark with valid and invalid proofs, show which checkers pass/fail, and demonstrate that the validator catches a real discrepancy. The topology and quantum components should only be included if they directly improve that concrete validation task.
Overall, this is imaginative, but currently too hard to interpret and not sufficiently grounded in evidence. The project needs a clearer problem statement, simpler evaluation, and a direct connection to secure program synthesis outcomes.
The paper results are written up in a way that makes it very challenging to decipher the purpose of this project. As an example, the abstract begins "We document a skill plugin that wraps the prime kernel homology.ipynb pipeline as a reusable Lean checker validator." prime_kernel_homology.ipynb is not a standard problem nor pipeline, so this sentence does very little to explain what is going on. The abstract continues and explains the MCP server "manages a pregroup-grammar decision tree" (which is never explained) over a set of primes 2,3, 5, and prospective extensions, 7, 11, 13. This without further context (which is not given in the rest of the paper), is incredibly challenging to decipher the larger impacts of.
Cite this work
@misc {
title={
(HckPrj) Lean checker validating Skill Plugin
},
author={
Ivan Rojas
},
date={
},
organization={Apart Research},
note={Research submission to the research sprint hosted by Apart.},
howpublished={https://apartresearch.com}
}


