LogicStudio: logic IDE splits loose matching from strict deduction

The paper's starting point is a concrete failure the author cites: adding a single dictionary entry — "upper: shoe upper (noun)" — to a rule-based machine translation system broke its regression tests badly, because the extra sense multiplied the parsing search space. The same pattern shows up in search, where a query about using FFmpeg without dependency problems tends to return container, package-manager, or source-build answers while burying the "one static build, just run it" answer. The author calls this "cyberspace debris" — knowledge that has lost its conditions of application.

Against that backdrop, the design places a three-layer toolchain: LLint as a small UNIX-pipe logic linter where --parse proposes propositions (the LLM's job), --edit lets a human accept or reject them, and saved results go into a JSON Lines proposition dictionary. LogicStudio sits above it as an IDE for the logical tree of a text, much as a code editor works with an abstract syntax tree. Storing those propositions and rules in a .wm file turns a dictionary into a world model — the author notes one can run Hayek.wm against Keynes.wm, diff them, and see where the two viewpoints collide.

The paper is explicit that none of this is verified yet, and the open problems it lists are the real stakes. Whether loose matching stays reliable across a multi-step chain, whether writing application conditions just recreates the old dictionary-maintenance burden, and whether confidence numbers from an LLM are calibrated enough for the branch-confidence formula to mean anything — these determine if the idea holds up. The author's suggested first step is narrow: pick a small domain like software install procedures and compare an LLM alone against the LLint setup on how often each reaches the right answer, flags leaps, and needs a human to step in.