Structured arguments, not just claims

When you’re trying to figure out what’s true, you don’t just collect statements — you collect reasoning. “X happened, so Y.” “This case is like that one, so treat it the same way.” “Z is generally true, except when…”

Until now, SummerEyes 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.

This release adds three ways to model that.

Inference arguments

You can now register derived 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— “yes, the premises hold, but the rule doesn’t apply here” — that’s now a first-class move.

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.

There’s a sanity constraint baked in: a derived conclusion can never be more confidentthan its least-confident premise. You don’t get to manufacture certainty by stacking inferences.

Undercut attacks with reasons

When you attack a derivation rather than a conclusion, you can now say why 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.

Distinctions and accumulative reasoning

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: 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.”

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.

What changes for you

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.

For integrations, two optional fields on submit_investigation — inferences and distinctions — let you express richer arguments. Distinctions, when present, automatically produce conditional conclusions in the result. Existing requests continue to work unchanged.