Structured arguments, not just claims

2026-04-28T00:00:00+00:00

When you're trying to figure out what's true, you don't just collect statements — you collect reasoning</em>. "X happened, so Y." "This case is like that one, so treat it the same way." "Z is generally true, except when…"</p>

Until now, Housecarl Arbiter treated every claim as a flat assertion: someone said something, and the engine weighed who said it, when, and how it stacked up against other claims. That works for basic fact-checking, but it doesn't capture how arguments actually compose. Real investigations build chains — smaller observations supporting larger conclusions — and disputes happen at every level: sometimes about the conclusion, sometimes about the reasoning that got there.</p>

This release adds three ways to model that.</p>

Inference arguments</h2>
You can now register derived</em> conclusions: claims that follow from other claims by a stated rule. The engine tracks the derivation, not just the result. If a premise is challenged, the conclusion is challenged. If you want to attack the reasoning</em> — "yes, the premises hold, but the rule doesn't apply here" — that's now a first-class move.</p>
The rule types cover the most common patterns of everyday argument: reasoning by analogy, generalizing from an exemplar, deferring to expertise, applying a default with exceptions, using temporal precedence. There's an escape hatch for domain-specific rules too.</p>
There's a sanity constraint baked in: a derived conclusion can never be more confident</em> than its least-confident premise. You don't get to manufacture certainty by stacking inferences.</p>
Undercut attacks with reasons</h2>
When you attack a derivation rather than a conclusion, you can now say why</em> it fails. The analogy isn't sound? The expert is conflicted? The default has an exception that applies here? Each rule type has a typed set of failure modes the engine recognises. The result is more legible argument graphs — you see not just that a step was attacked, but on what grounds.</p>
Distinctions and accumulative reasoning</h2>
Sometimes two claims look like they conflict but really apply in different cases. "The deal is favorable" might be true short-term and false long-term. You can now register a distinction</em>: a labeled feature that separates the cases. Instead of forcing one claim to defeat the other, the engine lets both survive and reports a conditional answer: "if short-term, A; if long-term, B."</p>
Add a distinction and you'll get one conditional conclusion per branch alongside the standard verdict — no flag, no mode. The presence of the distinction is the trigger. It's how analysts, lawyers, and doctors actually reason about hard cases — not by picking a winner, but by carving the question into sub-cases each side gets right.</p>
What changes for you</h2>
For end users, contested investigations are easier to audit: derivation chains are visible, and conflicts now indicate whether they're attacking the conclusion, the reasoning, or a premise.</p>
For integrations, two optional fields on `submit_investigation</code> — inferences</code> and distinctions</code> — let you express richer arguments. Distinctions, when present, automatically produce conditional conclusions in the result. Existing requests continue to work unchanged.</p>`