Research
Reasoning assurance
Reasoning assurance is the science of specifying what good reasoning requires, verifying whether AI systems meet those specifications, monitoring them at runtime, and improving them against the same specifications. Because the systems under test are stochastic, the guarantees available are evidential rather than deductive: claims about reasoning that can be stated precisely, tested, and falsified.
The failures I am most concerned with lie in the implicit layer: assumptions an argument never states, norms a context never announces, beliefs an interlocutor does not share, reasoning a model reports but does not perform. Consistency checks are insensitive to these, because nothing in the visible output is incorrect. My work aims to make that layer explicit, and then checkable.
I have worked on these questions for about a decade: more than 40 peer-reviewed publications across AI, NLP, and cognitive science, $5M+ as principal investigator on DARPA and IARPA programs, and released tooling including delhi, an epistemic model checker. I practiced intellectual property law for nearly ten years beforehand, which shapes how I approach evaluation: cross-examination is a well-developed methodology for testing whether a stated line of reasoning survives adversarial pressure.
What good reasoning must satisfy
I organize the work around four properties, stated as specifications rather than desiderata, and evaluated at every level from a single model to an agent to a multi-agent system.
Legibility & faithfulness can you inspect it?
A model's stated reasoning should be derived from its evidence, not merely consistent with it. These are distinct properties, and the distinction is empirically accessible: conclusions should change when, and only when, the reasons change. I formalize faithfulness as derivation in assumption-based argumentation and test it by perturbation, alongside work on structured and vector-symbolic representations (VSAX) and neuro-symbolic argumentation (ACS 2022).
Contestability can you challenge it?
A conclusion is trustworthy to the extent that it can be argued with: challenged, defended, revised. I build computational argumentation systems (IntelliProof, AAAI 2026; ArgLib) and benchmarks that test whether models engage with arguments rather than merely produce them. Requiring a model to generate arguments for both sides can elicit reasoning it does not otherwise produce (EMNLP-W 2024).
Manipulation robustness does it survive attack?
Whether an adversary can bend a model's reasoning, and whether the model is bending its user's. This is cognitive security (CogSLLaM, AAAI-SS 2026): persuasion, jailbreaks, and the subtler behavioral nudges that shift a user's judgment without their awareness. The evaluation instruments are vulnerable too — small, task-irrelevant additions to context can reverse what a benchmark concludes.
Social reasoning does it model other minds?
Systems that act among people must reason about what others believe, intend, and expect, including norms and conversational timing (EMNLP 2024; AAAI 2026). I state these as epistemic specifications — knowledge versus belief, belief update under events, higher-order false belief — and check them with a model checker rather than by reading transcripts by hand (delhi).
The method
My projects follow a common loop. Its central constraint is that any intervention which improves a system has to be re-checked against the specification that motivated it.
-
01
Formalize
State what the reasoning capability requires, in logic. I have written specifications of this kind for norms under uncertainty, affordances, pragmatics, epistemic states, and argument structure.
-
02
Build
Turn the specification into running machinery: model checkers, symbolic reasoners, executable logic programs, and libraries others can use. A specification that cannot be executed cannot be tested against a system.
-
03
Evaluate, adversarially
Test the system against the specification under adversarial conditions rather than favorable ones. Behavioral: does the output satisfy the specification — invariance, consistency, capacity, faithfulness? Mechanistic: do the internals account for the behavior, under probing, attribution, and intervention?
-
04
Improve, then re-verify
Intervene at runtime (steering, supervision, monitoring), in training (specifications as verifiable rewards), or by construction (neuro-symbolic compilation), and evaluate the result against the specification it started from.
-
05
Distill
Determine what the network has actually learned and separate it from what is incidental. This is what bounds the claims a system can support.
A single specification serves three roles — a probe that tests a system, a monitor that observes it at runtime, and a compilation target for building it — so the formalization done in step 1 is reused at each later stage rather than redone.
A specification a system fails to satisfy is itself informative. Detecting that a representation has become inadequate, revising it, and constructing a new abstraction is a recognizable pattern in creative and abductive reasoning, and it is also an assurance problem: it asks what a reasoner should do when verification fails. This is why I treat creative reasoning as part of the program rather than adjacent to it, and it connects directly to earlier work on agents that repair their own formal models under novelty (SPOTTER, AAMAS 2021; RAPid-Learn, ICDL 2022).
Where this goes
Scientific practice is, in effect, institutionalized reasoning assurance. A hypothesis has to survive peer review and replication within a community, which draws on the same three capacities this program formalizes: creative reasoning to generate the hypothesis, argumentative contest to challenge it, and social reasoning to coordinate the community doing the challenging.
Systems now proposed as automated scientists generate plausible conclusions that are difficult to check — the failure described above, at the scale of a field. An automated scientist worth relying on would be one whose hypotheses can be contested and whose reasoning can be verified, which raises the question this program is ultimately organized around: who verifies the automated scientist?