1. Overview
Eidoku evaluates generated outputs as candidates in a constraint system. Its objective is not “truth in general” but feasibility under stated constraints. This makes hallucinations visible as violations rather than “low-confidence answers”.
Design goal: replace “plausible text” with an explicit decision boundary:
outputs that do not satisfy constraints are deterministically rejected (or marked UNK).
2. What Eidoku Checks
Eidoku assigns a violation cost to each candidate by combining multiple structural signals. (Exact definitions are in the paper; this page provides the minimal operational picture.)
- Structural: unsupported entity transitions / broken dependency edges
- Geometric: abnormal deformation in local embedding neighborhood
- Logical: entailment/contradiction signals (e.g., NLI-style checks)
Candidate score (sketch): J = Σ (local violation cost) → compare to τc / threshold
3. Pipeline Role
System-1 (LLM) generates candidates
↓
Eidoku computes violation costs under an active profile
↓
Gate: accept if feasible, otherwise reject / UNK
↓
Pass accepted outputs to downstream execution / delivery
↓
Eidoku computes violation costs under an active profile
↓
Gate: accept if feasible, otherwise reject / UNK
↓
Pass accepted outputs to downstream execution / delivery
Eidoku is designed to plug into System-2 FW as a verifier module, but it can also be used as a standalone gate for LLM outputs.
4. Claims
- Eidoku enforces feasibility constraints post-generation (model-agnostic)
- Rejection/abstention is an explicit, valid output state
- Hallucinations are operationalized as structural violations
Non-claims: Eidoku does not prove truth in general, and does not replace domain expertise.
It is a decision gate under explicit profiles.