Paraconsistent Logic and AI models

Beginners
1

Hi everyone. Im not much of a programmer, but I have some studies into logical systems and philosophy of language. Here are some thoughts on current limitations of LLMs and AI models. Care to join and share your point of view and offer some perspective on why I might be onto something or just completely wrong?

A true Epistemology for Artificial Intelligence

By Daniel Fonseca

Philosopher, writer, and investigative journalist .

It’s worth mentioning that the idea for writing this article came from a conversation with an artificial intelligence (grok) in which the responses were nothing more than crazy hallucinations. Funny, of course, but still, machine hallucinatio ns.

The aim of this article is to reflect on the model adopted by Big Tech companies for programming Large Language Models (LLMs) and to point out its limitations – evidenced by the high number of machine hallucinations – and to propose a hybrid model for LLM programming based on a combination of Kantian Judgment Theory and paraconsistent logic (or fuzzy logic). The proposal of this article can be summarized as follows: a hybrid LLM model that is not limited to mere statistical calculati o n s .

The current limitations o f LLMs

The current model of LLMs can be summarized as follows: given a prompt, the AI performs a matrix calculation to predict the next words that answer what was proposed in the prompt. The business model of Big Tech companies is that if an LLM is large enough, it will eventually achieve the holy grail of AGI. The problem with this view is that it confuses the category of quality with that of quantity – let us remember the old Aristotle who already said that they are different things and one does not replace the other. It is, therefore, a business model based on a logical fa llacy .

In his Sophistical Refutations, Aristotle identified the confusion of two categories as being the same thing as a logical fallacy. Two distinct predicates cannot belong to the same category. That is, the size of a neural network, even an artificial one, is not the same as the production of intelligence. This fact is observable in biology: a whale’s brain has more neural connections than a human’s, but a human is more intelligent than a whale.

The problem with Big Tech is described in that anecdote about the monkey and the typewriter: given enough attempts, a monkey pressing random keys on a typewriter will eventually produce its own Iliad. Big Tech bases its business on the fallacy that if it creates sufficiently complex statistical algorithms for predicting the next word, artificial intelligence wil l emerge.

Perhaps it’s just ironic that companies with tens of thousands of engineers don’t know Aristotle and therefore don’t understand that it’s impossible to arrive at a conclusion based solely on statistical calculations. Oh! How much we need a philosopher among these e n g i neers!

What is the proposal for a true epistemology of Artificial I ntelligence?

The intention here is not to say that Artificial Intelligence will surpass human intelligence, but rather to provide a foundation in the Philosophy of Language and the Philosophy of Logic to establish a new paradigm for artificial intelligence. The aim is to propose a hybrid model for AI that goes beyond mere statistical calculation, establishing the true limits of AI and proposing a programming model with a layer preceding the statistical calculations derived from training artificial neu ral networks.

Artificial intelligence will never be intelligent, because that is a quality that arises from billions of years of natural selection and evolution of biological beings. And it will never be artificial, because, since it is nothing more than an algorithm, it will always need someone to program it. Or, in Aristotelian terms: the predicate of A is not the same as the predicate of B, that is, the intelligence emerging from biological beings is not the same as the intelligence of digi tal machines .

As Thomas Aquinas said, rereading Aristotle: a creature cannot be endowed with more substance than its own creator. And this is what Big Tech companies sell as business models: a computer more intelligent than its own creator. This business model certainly serves for financial speculation, but in the real world, it’s nothing more than a fallacy. Computers may be better at performing some specific tasks than human beings, but they will never be human or artificial life forms. What Big Tech proposes is the same dream as Pinocchio: a creature that gains its own life and becomes human. It’s a pity for the Big Tech business model that there’s no fairy godmother to make this d r e a m come true.

A Hybrid AI Model: or an AI that doesn’t drea m l i ke Pinocchio.

Boolean Logic and P araconsistent Logic

From Plato’s later dialogues and, especially, in Russell’s Philosophy of Language, it has been almost universally accepted that truth is an attribute of judgments according to the identity between proposition and the real world. Since AI computers are merely complex algorithms, they can never assign a truth value to what exists and what does not exist in the real world, as this task will always be subject to what has been programmed. AI engineers have created a good solution to this problem: reinforcement training. But, note, dear reader, that the truth value is obtained through the statistical extrapolation of a truth value giv en by a human being.

The problem with removing the human component from assigning truth value is the same as believing that a book can read itself and teach itself what it has learned by reading itself. Science uses double-blind tests so that it is not the same author who proposes the status of scientific truth to a study. The person analyzing data cannot be the same agent who proposes the data. And this limitation of current generative AIs is what produces an abysmal amount of machine hallucinations. It is a violation of the scientific method: a truth value assigned by itself to itself through complex stat istical calculations.

The logical, unavoidable, and necessary consequence of this limitation is that AIs will never reach the much-desired level of General Artificial Intelligence, because an algorithm is nothing more than an algorithm, that is, the execution of a specific computational task from an input that generates a statistical ly predictable output.

So far we have established two key points of this hybrid AI model: 1) that the size of the LLM will not give rise to superhuman intelligence and 2) the cause of machine hallucinations lies in the machine learning model employed by big tech companies, that is, reinforcement learning is what generates machine hallucinations, because if predictive statistical calculations of the next word of a proposition are made large enough, any prop osition can be reached.

If the reader has already executed the same prompt several times, they may have noticed that each time there is a slightly different response. This happens because current AIs are programmed so that in their matrix calculations there is a certain degree of uncertainty in the output. It’s an attempt to emulate human creativity. A solution that seems good, but is another factor generating machine hallucinations. Inevitably, this degree of uncertainty intentionally added to matrix calculations generates logical explosions not predicted by mere mathematical prediction. The problem, in technical terms, is believing that binary Boolean logic allows degrees of uncertainty beyond the mere assignment of truth values that are distinct from “true” or “false”.

The solution proposed by Big Tech engineers, which aims to emulate human creativity, is flawed from its very premise. Language is an inconsistent system, that is, non-linear. In this sense, all the programming logic of an AI must be based on paraconsistent logic .

The central point for programming AIs using paraconsistent logic lies in the possibility of reducing the statistical calculation of predicting the proposition to a triviality – that is, to a trivia l and inconsistent system.

In short, the problem with using Boolean logic in a language system lies in the logical explosion where everything can be inferred from everything else through a mere non-scienti fic Aristotelian syllogism.

In a practical example, consider the prompt: “Is water at 35 degrees hot or cold?”. The Boolean matrix calculation will determine that the algorithm compares the propositions stating whether the water is hot or cold with its database and, based on this, generates an answer that considers only the statistical value given by a combinatorial analysis of whether 35 degrees is equivalent to “being hot” or “being cold”. This calculation does not allow the answer to be “at 35 degrees the water is lukewarm”, because the concept of lukewarm is a contradictory concept that, in the logical systems currently employed by AIs, generates a logical explosion (that is, an i nvitation to hallucination).

Something being “warm” is a truth value not allowed by Boolean binary logic, because it is something intermediate between the truth values “absolutely true” and “absolutely false,” 0 or 1. The paraconsistent approach, on the other hand, allows intermediate values between “absolutely true” and “absolutely false.” In programming, it is possible to say that water at 35 degrees has a truth v alue of 0.5 hot and 0.5 cold.

Unlike current AIs, a paraconsistent AI allows assigning non-absolute truth values to a proposition. Paraconsistent logic is a model of logic that does not collapse when given an explosive proposition in the face of a contradiction that is only a contradicti on in a Boolean binary system.

In the example given above, of lukewarm water, a Boolean system collapses when trying to define an absolute truth value (necessarily true and necessarily false) when trying to define something as lukewarm. It’s worth repeating that, in the current AI system, given the limitations of binary logic, water is only allowed to be hot or cold. The concept of lukewarm is unthinkable with in this binary computing logic.

An even more serious example of binary logic programming is found in the proposition: “Why is water cold at 20 degrees, lukewarm at 35, and hot at 50 degrees?” The Boolean logic model of matrix statistical calculation lacks sufficient mathematical tools to answer “why” questions or questions whose answer requires a subjective perception analysis. What current AIs do is search their database for similar propositions and infer an answer from them through a statistical calculation of equivalence betwe en the prompt and the algorithm.

This limitation is another invitation to hallucinations, since the classical logic adopted by AIs presupposes consistent systems free from contradiction. This prompt for comparison between different temperatures, which has a hidden premise—namely, a subjective judgment—is a contradiction that generates a logical explosion in the statistical matrix calculation of the gene rative AI’s predictive algorithm.

Another factor that invites the machine hallucinations generated by Boolean logic in statistical matrix calculations lies in the fact that “reasoning,” or what big tech companies sometimes call “deep thinking” or “think harder,” is based merely on creating hypothetical answers from inference models focused on what Aristotle called the “copula” of a premise. The central problem is that in classical logic systems, a contr adiction trivializes the argument.

The problem with Boolean logic is that, through a contradiction (A = 1 and “not-A” = 0), trivialization occurs; that is, for current AIs, every subsequent premise is deducible from the previous premise. In other words, the model in which the AIs are programmed defines that the “next word” is determined by a statistical calculation of relevance comparison between the “previous word” and the database. The recurring hallucinations of current AI models lie in the fact that mere statistical calculation makes any proposition liable to be true. Therefore, different prompts can generate opposite and contradictory answers. It is the logical explosion of the p urely statistical inference system.

It’s worth noting that paraconsistent logic doesn’t persist in negating the principle of non-contradiction, but rather in refining contradictory propositions so that they don’t trivialize the proposition and lead to absurd inferences resulting from mere Boolean matrix statistical calculations predicting the next word in the output processed by the algorithm given a specific prompt. What I mean is that, in an LLM (Logical Logic Model), according to binary logic, hallucinations are recurrent because the language consists of a non-trivial logical model where inconsistency is necessary to exist without generating an explos ion, and therefore, a hallucination.

The problem of machine hallucinations in current AI models is simple to understand from a logical point of view. The problem is that language is an inconsistent system, which generates triviality where everything is probable. And since current AI models boil down to calculating the statistical probability of the next word by comparing it to a database, hallucination in an AI that uses the Boolean model of matrix statistical calculation is inevitable and unavoidable. Or, in other words, the current AI model hallucinates because, in trying to assign absolute truth values to propositions, it does not allow for the refinement of propositions in such a way that logical explosion is inevitable. In short, the classical logic systems used in programming current AIs, when confronted with a contradiction, trivialize the system in such a way that every proposition bec omes true – that is, a hallucination.

The advantage of using paraconsistent logic in an AI or an LLM is that it’s possible to compute “local contradictions” without generating “global trivialities .” In the example of warm water, there is no logical contradiction in assigning the truth value “true” to both the concept of hot and the concept of cold in paraconsistent logic. In other words, there is a local contradiction (hot and cold are opposite concepts), but there is no global triviality – that is, the concept of lukewarm is a refinement of the proposition in such a way that the uncertainty of what is lukewarm – given that there is a subjectivity in this concept – does not generate a logical explosion insofar as an intermediate truth value is assigned between what is “absolutely true,” or 1, or “absolutely false,” that is, 0. In this sense, in that example I gave of a comparison between three temperatures, there is an assignment of intermediate truth values for each of the temperatures compared in the original proposition without there being a logical explosion, but what paracons i s t e nt logic calls a gentle explosion.

Critique of Pure Artificial Intelligence

As I argued above, the problem with current AI models lies in their way of thinking, where all inference is possible (the triviality problem) given their operating model, which is a mere statistical calculation predicting the next word in a proposition. The universality of word prediction through statistical inferences is a necessary and fun damental cause of machine hallucinations.

The first step in avoiding machine hallucinations lies in what paraconsistent logic calls proposition refinement. An AI, when processing a prompt, must refine this prompt in such a way that it is possible to seek an inference that is not merely a statistical calculation equivalence comparing the prompt and the database. The way to avoid trivialization is through the refinement of the prompt in the form of wha t Aristotle called a scientific syllogism.

  • Rule of Terms:It must contain only three terms (greater, lesser , and middle), each used in the same sense.

  • Middle Term Rule:The middle term should never appear in the conclusion.

  • Rule of Extension:The terms in the conclusion cannot have a greater extension than those in the premises.

  • Universal Middle Term Rule:The middle term must be un iversal (total) at least once in the premises.

  • Rule of Negatives:From t wo negative premises, nothing can be concluded.

  • Rule of Affirmations:Two affirmative pr emises must result in an affirmative conclusion.

  • Rule of Particulars:From t wo particular premises, nothing can be concluded.

  • Rule of the “Weak Part”:The conclusion always follows the weakest premise; that is, if there is a negative premise, the conclusion is negative; if there is a particular premise, the conclusion is particular.

To a certain extent, the prompts have already been refined in the form of Aristotelian scientific syllogism; however, the central point for achieving, at most, a gentle explosion in the concept of paraconsistent logic lies in the a pplication of Hempel’s paradox. The paradox states:

Inductive Logic:The principle that seeing black cro ws confirms that “all crows are black” is intuitive.

The Equivalence:Logically, the phrase “All crows are black” is ide ntical to “Anything that is not black is not a crow.”

The Problem (Counter-intuitive):Following the logic above, when you see a red apple (which is neither black nor a crow), you are confirm ing the second statement and, consequently, the first.

Conclusion:The paradox demonstrates that inductive confirmation, based strictly on formal logic, can lead to absurd conclusions, since irrelevant objects could validate a scientific theory.

That is, in the logic of LLM, not every subsequent word can be inferred from the preceding word. When an LLM is based merely on predictive statistical calculations, it is falling into the trap of intuition. The inconsistency of a purely statistical language system allows inferences that are nothing more than hallucinations generated by a combinatorial analysis calculation of word pr obability given by the database used in the AI training.

If we recall the paradox of white and black swans, we find a guiding thread to avoid this trap of trivial systems in a practical LLM context. When seeking the equivalent of the Aristotelian scientific syllogism, AI must assume that every conclusion is false until a true example is found. That is, the universal proposition that every swan is white is false, since black swans can exist. And why should every premise be taken as false until a true example is found? Due to Karl Popper’s principle of falsifiability .

By refining the prompt into an Aristotelian scientific syllogism, therefore, the AI, when seeking an equivalence with its database, must look for equiva lences that are falsifiable and not absolute truth values.

If Kant, in *Critique of Pure Reason*, limited the scope of reason—that is, what is knowable by reason—a “Critique of Pure Artificial Intelligence” would have no problem limiting the applicability of artificial intelligence. Just as human reason is limited by sensory experience and by the very mental structures that organize the knowable reality for humans, AI will always be limited by its own algorithm and the necessary consequence of limiting what are computable and non-computable operations. An AI will always be limited, it is worth emphasizing, by its algorithm and its database. And it is due to this very limitation that General Artificial Intelligence is a logical impossibility and a theoretical oxymoron. It will always be limited to its own algorit hm and the knowledge used for its training in its database.

AGI is a logical impossibility and a theoretical oxymoron because imagination is a non-computable problem. Let us remember Sartre’s concept of imagination: a fundamental expression of human freedom, that is, the process by which humans, faced with nothingness (the absence of a pre-defined destiny), act inventively in their interaction with the world. Imagination is the human capacity for derealization, that is, the glimpsing of possibilities beyond phenomenal reality (a Hegelian concept that defines consciousness a s the self-expression of reality in its historical process).

If an AI relies on predictive statistical calculations, it will only be able to compute new forms of past knowledge. The originality of new human knowledge is intangible to an AI. An AI will never have a “Eureka!” moment where the scientist glimpses new knowledge. Its limitations, imposed by its own algorithm, will allow it, at most, to recreate what has already been thought and is stored in its database. And even if the AI, like the example I gave of the monkey that randomly types on a typewriter and eventually reproduces the Iliad, is not endowed with consciousness, since this is a human attribute, and all too human , to know that it is an innovation in some area of knowledge.

In short, it is worth emphasizing and concluding that, just as human reason is limited by sensory experience and mental structures t hemselves, an AI is limited by its own algorithm and database.

Another central point for understanding the limitations of artificial intelligence and the impossibility of General Artificial Intelligence lies in the debate between Russell and Frege about what constitutes “truth.” The only truth knowable to an AI is found in the process of equivalence, as defended by Russell. AI can only assign truth value to propositions according to their equivalence with the real world. Although an AI can assign truth value to a logical structure, the real world is an unattainable phenomenon for a digital machine. The truth that an AI is capable of achieving will always depend on the mediation of human reason expressed in the programming of its alg orithm and its training based on a database of human knowledge.

To summarize my argument in the language of exact sciences, so that the engineers who populate the Passárgada of Silicon Valley can understand why AI will never be able to surpass human intelligence: an AI algorithm is a limit function, where the limit is a non-computable cognitive problem between the digital world and the real world. And the real world is only knowable to a digital machine through mediation from the real world itself. Proof of this lies in the need for machine learning, even in its initial stages, to be done by a person. An AI that programs itself is a logical contradiction. It’s the same as, in the example used earlier, a book that writes itself before being read by itse lf s o t h at it can teach itself w h a t it has written about itself.

You can find the full article in here, due to characteres limitations: (DOC) A true Epistemology for Artificial Intelligence

2

Hmm… for now:

You are onto something. But the strongest version of your case is narrower and more precise than the article in its current form.

My overall judgment

I would not defend the article exactly as written.

I would defend a revised version built around this claim:

Current LLMs are not reliable epistemic agents because they do not cleanly distinguish among vagueness, contradiction, uncertainty, formal validity, and empirical grounding. A better architecture would be plural and layered, not purely generative.

That thesis is serious. It matches real technical work. It also fits your philosophical instincts much better than the article’s larger claims about AGI being a logical impossibility.

Why I think you are onto something

1. You correctly see that fluency is not knowledge

Modern LLMs are excellent at producing plausible language. That is not the same as having a built-in theory of when a claim is justified, when evidence is missing, when two sources conflict, or when the right answer is “I do not know.” Current research on hallucinations treats this as a major open problem. OpenAI’s 2025 paper argues that standard training and evaluation often reward guessing over acknowledging uncertainty, and AbstentionBench reports that abstention on unanswerable questions remains unsolved even for frontier models. (OpenAI)

That means your core complaint is real. The field has built very strong generators. It has not yet built a universally strong epistemic discipline on top of them. That is a fair criticism. (OpenAI)

2. Your hybrid instinct is right

The strongest technical work near your thesis does not say that raw next-token generation is enough. Logic-LM combines LLMs with symbolic solvers. LINC uses the LLM as a semantic parser into first-order logic, then hands deduction to an external theorem prover. There is even a 2025 paper that directly integrates an LLM into the interpretation function of a paraconsistent logic while aiming to preserve soundness and completeness. So your instinct that reasoning should be split across different layers is strongly aligned with current neurosymbolic research. (ACL Anthology)

That is the part of your article I find most promising. You are not merely complaining that models hallucinate. You are saying that the architecture is missing distinct components for distinct epistemic tasks. That is a good insight.

3. Your concern about contradiction is legitimate

There is real evidence that LLMs can contradict themselves or generate unstable factual claims. SelfCheckGPT is built around the idea that hallucinated facts often vary or conflict across multiple samples. Chain-of-Verification tries to reduce hallucinations by forcing a draft, then generating verification questions, answering those independently, and only then producing a revised answer. These methods do not prove your philosophical thesis, but they do support your intuition that consistency management and verification matter. (ACL Anthology)

So on the big picture, yes: you are pointing at a real weakness in current systems.

Where your article is strongest

Your best move is not the attack on “Big Tech” or the rhetoric about Pinocchio. Your best move is the underlying structure:

  1. A generative model can be useful without being a full knower.
  2. Language contains vagueness, conflict, ambiguity, and context dependence.
  3. A single undifferentiated text generator is not well suited to all of those at once.
  4. A better system should separate the tasks.

That is a much stronger case than “AI can never be intelligent.”

The article is also strongest when it pushes for a pre-output judgment layer. In engineering terms, that would mean the model does not go straight from prompt to final answer. It first classifies the kind of problem it faces. Then it decides which tools or reasoning regime should apply. That general shape is already visible in Logic-LM, LINC, verification pipelines, retrieval systems, and abstention benchmarks. (ACL Anthology)

Where your article weakens itself

This is the decisive part.

1. You conflate paraconsistent logic and fuzzy logic

This is the biggest conceptual problem in the draft.

Paraconsistent logic is about non-explosion under inconsistency. In plain language, it asks how a system can contain contradictions without collapsing into “everything follows.” Fuzzy logic is about degrees of truth for vague or imprecise predicates. In plain language, it is designed for cases like tall, young, rich, warm, likely, or near, where sharp boundaries are unnatural. (Stanford’s Dictionary of Physics.)

Your “35 degrees water is lukewarm” example is not mainly a paraconsistency case. It is a vagueness case. “Hot” and “cold” are context-sensitive predicates with blurry thresholds. That fits fuzzy logic or many-valued semantics much more naturally than paraconsistency. If you keep using “lukewarm” as your main example of paraconsistency, technically informed readers will attack that immediately, and they will be right to do so. (Stanford’s Dictionary of Physics.)

So the clean distinction is:

  • Fuzzy logic for borderline predicates and graded truth.
  • Paraconsistent logic for inconsistent evidence or conflicting commitments that should not trivialize the whole system. (Stanford’s Dictionary of Physics.)

That single correction would improve your article more than anything else.

2. LLMs are not basically Boolean syllogism machines

Your article often reads as if current models work by applying binary Boolean logic internally and then exploding under contradiction. That is not how transformer LLMs are built. Transformers are neural architectures based on attention mechanisms, and the dominant autoregressive paradigm for LLMs is next-token prediction. They are continuous, probabilistic systems, not classical deduction engines in disguise. (arXiv)

This matters because your current diagnosis mislocates the failure. The main technical problem is not that the model has secretly committed itself to Aristotelian syllogism and Boolean truth tables. The problem is that a probabilistic text generator is being asked to do too many epistemically different jobs without enough explicit structure.

So I would replace this claim:

LLMs hallucinate because they are based on Boolean logic.

with this claim:

LLMs hallucinate because probabilistic generation alone is being used where tasks also require grounding, conflict management, calibration, and abstention.

That version is much stronger.

3. Your causal story about hallucinations is too simple

You often write as if hallucinations mainly come from reinforcement learning, stochasticity, or the attempt to simulate creativity. The current literature is broader than that. Hallucination research now treats the problem as multi-causal. It spans pretraining data, fine-tuning, alignment, prompting, retrieval quality, decoding choices, evaluation methods, and weak incentives for uncertainty. OpenAI’s paper emphasizes “rewarding guessing,” and surveys explicitly treat hallucination as a broad taxonomy with multiple causes and mitigation strategies. (OpenAI)

So I would not say RLHF is the cause. I would say it is one factor in a larger system that still does not sufficiently reward truthfulness, calibration, and refusal.

4. Your AGI impossibility claims are much too strong

This is where the article moves from “provocative and interesting” to “overreaching.”

Saying that AGI is a logical impossibility, that imagination is non-computable, or that AI can never produce genuinely original knowledge is not something your article actually proves. Those are very large philosophical claims. There is an active field of computational creativity, with serious surveys on machine creativity and creative systems. That does not prove machines will equal or exceed human minds. But it does show that the impossibility claim is not established just by saying “algorithms are algorithms.” (ACM Digital Library)

Here I would advise restraint. You do not need those impossibility claims to make your best argument. They make the piece sound grander, but they make it less defensible.

5. Your theory of truth is presented too narrowly

The article often writes as if the relevant account of truth is basically settled and then applies that framework directly to AI. Philosophically, that is too quick. Even leaving aside deeper debates, the practical problem in AI is not only “what is truth?” It is also:

  • what counts as evidence,
  • what counts as support,
  • what counts as conflict,
  • what counts as insufficient information,
  • and when the system should abstain.

Those are epistemic and operational questions as much as metaphysical ones. That is why I think the article is stronger as a paper about epistemic architecture than as a paper about the essence of truth.

The key distinction your paper needs

Your article currently treats several different phenomena as if they had one root. They do not.

You are really discussing at least four different things.

A. Vagueness

Examples: hot, cold, lukewarm, old, likely, near, safe.
Best fit: fuzzy logic, many-valued semantics, context-sensitive semantics. (Stanford’s Dictionary of Physics.)

B. Inconsistency

Examples: one source says X, another says not-X; the model has conflicting retrieved facts; two commitments cannot both be maintained.
Best fit: paraconsistent logic or other non-explosive approaches. (Stanford’s Dictionary of Physics.)

C. Uncertainty

Examples: not enough information, stale information, false-premise question, underspecified question.
Best fit: calibration, confidence estimation, abstention. (OpenAI)

D. Formal deduction

Examples: if-then structure, quantifiers, consistency-sensitive inference, proof tasks.
Best fit: symbolic logic, theorem provers, constraint solvers. (ACL Anthology)

Once you split the problem this way, your article becomes much more powerful. Instead of saying “paraconsistent logic solves LLM hallucinations,” you can say:

LLM reliability requires different formal treatments for different failure modes.

That is a serious claim.

The philosophical frame that fits your case best

I do not think your best frame is “replace current AI with paraconsistent logic.”

I think your best frame is logical pluralism.

Logical pluralism is the view that more than one logic can be correct, depending on what notion of validity or consequence relation is at issue. For your project, that is ideal. It lets you say that no single formal regime should be expected to handle all linguistic and epistemic situations equally well. Different subproblems call for different formal treatments. (Stanford’s Dictionary of Physics.)

That gives you a much stronger architecture:

  • use symbolic logic for strict deduction,
  • use fuzzy logic for vague predicates,
  • use paraconsistent logic for conflicting evidence,
  • use retrieval and verification for empirical questions,
  • use abstention for underdetermined questions. (Stanford’s Dictionary of Physics.)

This is the version of your idea that I think experts would take seriously.

What I would keep from your article

I would keep these points.

Keep 1

“Mere generation is not enough.”
Yes. Strong point.

Keep 2

“Current systems need an explicit judgment layer.”
Yes. Very good point.

Keep 3

“Contradictions should not globally trivialize a system.”
Yes. Good and technically meaningful.

Keep 4

“A useful AI architecture should distinguish kinds of questions before answering.”
Yes. Very strong idea.

Keep 5

“Human-like fluency should not be confused with warranted knowledge.”
Yes. Central and correct.

What I would cut or weaken

Cut 1

“AI is based on Boolean logic, therefore hallucination is inevitable.”

Too simple. Technically inaccurate. (arXiv)

Cut 2

“Paraconsistent logic or fuzzy logic” as if they were interchangeable.

They are not. (Stanford’s Dictionary of Physics.)

Cut 3

“RLHF is the cause of hallucinations.”

Too strong. The evidence points to multiple causes. (OpenAI)

Cut 4

“AGI is a logical impossibility.”

You have not shown that. It invites objections that distract from your best argument. (ACM Digital Library)

Cut 5

The stronger rhetorical attacks on engineers and companies.

They add heat, but they reduce credibility.

What your strongest revised thesis would be

Here is the version I think is best:

Current LLMs should not be treated as self-sufficient epistemic agents. They are probabilistic language generators that can be highly useful, but they need a plural architecture around them. Formal deduction should be delegated to symbolic tools. Vague predicates should be handled with graded or context-sensitive semantics. Conflicting information should be managed by non-explosive reasoning. Empirical claims should be grounded in retrieval and verification. Unanswerable questions should trigger abstention rather than confident guessing.

That is clear. It is defensible. It matches actual technical directions in the field. (ACL Anthology)

What a concrete architecture could look like

If you want your article to move from philosophical essay to serious proposal, I would sketch something like this:

Step 1. Classify the prompt

Is this:

  • factual,
  • deductive,
  • vague,
  • conflicting,
  • normative,
  • or underdetermined?

Step 2. Route by type

  • Deductive → theorem prover or symbolic solver
  • Factual → retrieval plus reference checking
  • Vague → fuzzy or context-sensitive interpretation
  • Conflicting → paraconsistent handling of local inconsistency
  • Underdetermined → abstain or request missing context

Step 3. Verify before final output

Use something like a verification pass. The general pattern behind Chain-of-Verification is good here. SelfCheckGPT is also relevant as a cheap instability detector. (ACL Anthology)

Step 4. Return not just an answer, but an epistemic status

For example:

  • supported,
  • weakly supported,
  • conflicting sources,
  • context-dependent,
  • unknown.

This is what your article is really aiming for. Not just “better answers,” but better judgment.

My view on your use of Kant, Aristotle, Popper, and philosophy of language

Your philosophical direction is better than your engineering description.

  • Kant is useful if you use him to talk about the conditions under which a system can judge, not as a general anti-AI slogan.
  • Aristotle is useful if you use him for distinctions among forms of inference and for the need to avoid careless equivocation.
  • Popper is useful for empirical claims and scientific conjectures, but not every user prompt is a falsifiable scientific hypothesis.
  • Philosophy of language is very useful here because many AI failures are failures of context, reference, vagueness, scope, presupposition, and support.

So yes, philosophy belongs in this debate. But it works best when it sharpens distinctions, not when it substitutes for technical description.

My blunt conclusion

You are not completely wrong. You are identifying a real problem. In fact, you are identifying one of the most important problems in current AI: the gap between language generation and epistemic responsibility.

But your article currently overstates and conflates too much.

The three biggest fixes are:

  1. Separate fuzzy logic from paraconsistent logic.
  2. Stop describing LLMs as if they were basically Boolean engines.
  3. Replace the “AGI is impossible” conclusion with a more precise claim about the limits of current LLM-style epistemic architecture.

If you make those changes, your paper becomes much stronger.

My final assessment is this:

  • Your intuition is good.
  • Your main categories need tightening.
  • Your best contribution is architectural and epistemological, not metaphysical.
  • Your strongest frame is pluralism, not one replacement logic.
  • Your most defensible thesis is that AI needs a layered theory of judgment.

That is a paper worth writing.

3

Hey john6666 I really appreciate your feedback. You gave me much to think about and a path do better the article.

As I said, programming or computer sciences is not my area of study, but as a pet project I tried to model an AI based on what I stated on my article. I will be posting the model here really soon. So I invite you to join that debate too.

4

If you are instered john, please join this discussion too 0danielfonseca/Doninha · Doninha is a proof of concept of a new kind of AI

5

ive been working on exactly this.

https://x.com/RadbroskiGadol

6

Hi John6666 and Daniel,

Joining this thread late but with real interest, because the diagnosis John6666 laid out maps almost one-to-one onto a research program some of us have been developing in the Latin American paraconsistent and neutrosophic tradition for several years. I think it can save Daniel some reinvention and give John6666 some references he may find useful.

Three quick observations:

1. The fuzzy / paraconsistent distinction is exactly right — and there is a third primitive missing from the discussion: indeterminacy.

John6666 is correct that conflating fuzzy logic with paraconsistency is the single biggest weakness in the article. But the cleanest way out is not to pick one or the other — it is to adopt a framework that already separates them axiomatically. Neutrosophic logic (Smarandache, 1998, 2005) decomposes any proposition into an independent triple (T, I, F) — Truth, Indeterminacy, Falsity — where the standard fuzzy/probabilistic constraint T + I + F = 1 is explicitly dropped. That single move buys you:

  • T + F > 1 → paraconsistency (genuine contradiction without explosion)
  • T + I + F < 1 → incompleteness / missing evidence
  • I high alone → vagueness or underdetermination
  • T high, I low, F low → confident assertion

So the four failure modes John6666 identifies (vagueness, inconsistency, uncertainty, deduction) are not four separate logics that need to be glued together — they are different regions of a single (T, I, F) space, plus a deductive layer on top. This is much closer to John6666’s “logical pluralism” conclusion than to a one-logic-replaces-all stance.

2. “Epistemic states that evolve through reasoning” already has a name.

The pre-output judgment layer John6666 sketches — classify → route → verify → return epistemic status — is essentially what we have been formalizing as Dynamic Epistemic Logic for LLMs (LED): the (T, I, F) state of a model is not static, it transitions through reasoning steps under three operators — Refinement (I decreases as evidence accumulates), Conflict (incompatible (T, I, F) tuples from different sources), and Resolution (collapse toward a more determinate state). Chain-of-Thought becomes a sequence of epistemic transitions; Mixture-of-Experts becomes aggregation of parallel epistemic states; abstention becomes a thresholded decision on I. The architecture John6666 is describing in his Step 1–4 is, in this language, the operational semantics of LED.

3. There is a concrete UQ implementation already published.

For Daniel’s proof-of-concept Doninha, the relevant prior work is NeutrosophicUQ — a paraconsistent neutrosophic uncertainty quantification framework for LLMs that uses hierarchical clustering with cosine similarity over stochastically sampled responses to extract (T, I, F, C) tuples. Unlike semantic entropy (Farquhar et al., 2024, Nature), which collapses everything to a scalar, this preserves the typology of failure: consensus vs. contradiction vs. ambiguity vs. missing information. It is model-agnostic and works through any LLM API. Daniel — if you want a head start instead of building from scratch, this is where I would point you.

On John6666’s substantive critique: I agree with almost all of it. The “Boolean syllogism machine” framing of LLMs is wrong, the AGI-impossibility move is overreach, and the strongest version of the article is architectural and epistemological, not metaphysical. The one place I would push back gently is on framing this as purely a Western neurosymbolic problem. The Latin American paraconsistent tradition (da Costa, Carnielli, Coniglio, Miró Quesada) and the neutrosophic program (Smarandache, and a growing community across Cuba, Ecuador, Mexico, Peru) have been working on exactly these questions — non-explosion under contradiction, indeterminacy as a primitive, plural logical regimes — for decades. The mainstream NeSy literature is only recently catching up.

References if useful:

  • Smarandache, F. (2005). A Unifying Field in Logics: Neutrosophic Logic. American Research Press.
  • Leyva-Vázquez, M., & Smarandache, F. (forthcoming). Dynamic Epistemic Logic for Large Language Models. Neutrosophic Sets and Systems.
  • Neutrosophic Sets and Systems (open-access journal) — full archive at fs.unm.edu/NSS

Happy to share preprints with either of you if there is interest. Daniel — looking forward to seeing Doninha.

Best,
Maikel Leyva-Vázquez
Universidad Bolivariana del Ecuador
Editor-in-Chief, Neutrosophic Sets and Systems

7

Hey Maikel…

Glad you joined the discussion. I will be reading the references you indicated. I programmed IA Doninha as a middleware and tested on Ollama and i loved the results testing it on several LLMs. I posted the main python files here ( 0danielfonseca/Doninha · Doninha is a proof of concept of a new kind of AI ) but if you are interested on the whole model you can find the whole middleware in here IA Doninha - Google Drive

Ps.: Im also a latin american (Brazil), so I loved to hear that paraconsistent logic is been studied all across latin america

8

Oi Maikel,

I made a summary of the corrections based on yours and John’s thoughts. Can you take a look and see if got everything right?

9

Hey Maikel and John…

So you can see IA Doninha working, i’ve made a random question (based on brazillian news and social media from the past weekend that took everybody by surprise and led crazy people to drink detergent on camera to make a political point) I asked Doninha 1.0 (still working on version 2.0 based on your considerations) and asked AIs from Bigtechs and Doninha to answer the question “Why detergent dont kill 100% of bacteria”.

I was pretty happy with the results from Doninha. See the answers below (I asked to all AI in portuguese and translated the answers through google translate for your convenience) and tell me what you think about Doninha 1.0 work:

10

Hey Maikel and John…

I was finally able to work on your considerations for a practical AI based on my article and the version 1.0 of Doninha AI.

I really, really happy with the results and visible and undeniable improvement on the model after I was able to insert the model coding your considerations. I will be posting the version 2.0 really soon. But here are a preview of what I was able to do on this proof of concept AI model

In the following link there is a practical comparation of Big Techs AIs and Doninha Versions 1.0 and 2.0. A ran three prompts in all of them to generate a practical answer (not just random questions from benchmarks) so we all could have some ground on comparing the models at their best. You will able to see the readme file to see what and how the Doninha AI 2.0 is operating: Benchmark Doninha AI version 2 - Google Drive

As soon as I get my claude tokens renewed, I will post here further benchmarks…

Hope the results will make you interested in going further on the discussion on this proof of concept AI Model.

PS.: I Didnt forgot about the article. I just took your advice and started programing a real AI Model based on all of our talk so I could see better the proposal of a paraconsistent / fuzzy / episthemological / hibrid model working to able me to write the revised version of the paper better.

11

You can test the new version of the model here: GitHub - danielfonseca420-blip/Doninha-2.0: An AI model that uses paraconsistent logic in its architeture. · GitHub

12

Hey Maikel and John… Here is the revised version of the article (with a proposal of an already tested and working AI Model): (DOC) A True Epistemology for Artificial Intelligence (Revised Version

Care to read again and give me your inputs (specially on the proposed model)?

13

Hey Maikel and John… Here is the full middlewere python files for you to test a functional version of AI Doninha: 0danielfonseca/Doninha-Artificial-Inteligence at main

14

Hey @mleyvaz have you seen my last answer in this post and the other one?

Im really interested in writting an article with you. It will be providential and very helpful to my phd selection next year.

Hope to hear from you soon.

17

Hey @mleyvaz @John6666 made some new improvements in the model. You can find the code and an article describing AI Doninha architeture here: GitHub - danielfonseca420-blip/Doninha-4.0: Hybrid Neuro-Symbolic Middleware for Epistemological Reasoning in Language Models · GitHub

18

Hi. I think this has moved much closer to something that could actually work as an architecture now. This time, looking at it from the perspective of “how could this be turned into working software?”, my view is roughly this:

Short version

I think the most practical framing is this:

Doninha should not be seen mainly as “a paraconsistent LLM”, but as a claim-level epistemic controller around an LLM.

That means the LLM can still generate, paraphrase, summarize, and compose text. But Doninha’s job would be to inspect claims and decide what epistemic status each claim has:

  • can this claim be stated normally?
  • does it need retrieval?
  • is it vague?
  • is it contradicted by another source?
  • is the premise invalid?
  • should the model abstain?
  • should the answer include a caveat?
  • should the claim be routed to a formal checker?

So I would not abandon the philosophical layer. I would translate it into engineering roles.

The important point is not to make one logic solve every epistemic problem. The important point is to route each claim to the right epistemic handler.

The first concrete milestone

If the goal is working software, I would make the first milestone very small:

One prompt goes through claim extraction, claim-ledger JSON, optional retrieval/checking, license decision, and final answer generation.

No GUI is needed at first. No hosted demo is needed at first. A GitHub repository that runs locally or in a basic notebook environment such as Google Colab would already be enough.

A first version could simply do this:

User question
  ↓
Extract 3–5 claims
  ↓
Store each claim as JSON
  ↓
Retrieve or check evidence when needed
  ↓
Assign a license state
  ↓
Generate a final answer from the ledger
  ↓
Save both the ledger and final answer

The first goal would not be high performance. The first goal would be observability:

  • can we see the extracted claims?
  • can we see the evidence?
  • can we see the license decision?
  • can we see why the final answer was softened, verified, or withheld?
  • can tests confirm that each failure mode is routed correctly?

Once that vertical slice works, the larger L1–L7 architecture becomes much easier to grow.

Main practical framing

A software-shaped version of Doninha could look like this:

User prompt
  ↓
Claim / concept extraction
  ↓
Claim type classification
  ↓
Evidence retrieval / verification / formal checking
  ↓
Epistemic state assignment
  ↓
License decision
  ↓
Final answer generation
  ↓
Audit / explanation

The key intermediate object would be a claim ledger.

For example:

Claim Type Evidence Conflict Indeterminacy License
Claim A empirical strong low low licensed
Claim B empirical weak medium high needs_retrieval
Claim C conceptual medium low medium qualified
Claim D current factual missing unknown high retrieve_or_abstain
Claim E controversial mixed high medium conflicted

The final answer would then be generated from this ledger, rather than directly from the raw LLM output.

This would also make the project easier to test, because each module has a visible job.

RAG is useful, but it is not the whole epistemic layer

I would treat RAG as the evidence provider, not as the full solution.

A simple way to say it:

RAG retrieves evidence; Doninha decides whether that evidence licenses the claim.

For example:

Situation Doninha behavior
evidence supports the claim licensed
evidence weakly supports the claim qualified
evidence contradicts the claim conflicted
no evidence is found insufficient or abstain
source is present but does not support the sentence source_mismatch
question requires current information needs_retrieval
question contains a false premise invalid_premise

This is the layer that makes Doninha more than ordinary RAG.

Practical next steps

I would keep the next steps narrow and sequential.

Step 1 — Make the claim ledger explicit

Start with a visible JSON object.

Example:

{
  "question": "Is 35°C water hot or cold?",
  "claims": [
    {
      "claim": "35°C water is hot.",
      "claim_type": "vague_predicate",
      "truth": 0.4,
      "indeterminacy": 0.7,
      "falsity": 0.2,
      "conflict": 0.0,
      "license": "vague",
      "final_behavior": "Use graded language instead of treating this as a contradiction."
    }
  ],
  "final_answer": "35°C water is better described as warm or lukewarm rather than simply hot or cold. The classification depends on context."
}

Step 2 — Define a small set of license states

For example:

licensed
qualified
needs_retrieval
conflicted
vague
source_mismatch
invalid_premise
needs_clarification
formal_check_needed
abstain

Step 3 — Build a minimal local / notebook demo

A simple CLI or notebook cell is enough:

python -m doninha.run examples/inputs/vague_water.json

or:

from doninha import run_pipeline

result = run_pipeline("Is 35°C water hot or cold?")
result.claim_ledger

Step 4 — Create a small benchmark

Even 50–100 examples would be useful if each category is clear.

Step 5 — Add tests before adding more layers

At first, simple checks are enough:

python -m compileall src
pytest
python eval/run_eval.py

The goal is not to prove the whole theory immediately. The goal is to make the pipeline inspectable and stable.

Optional: possible GitHub / notebook first working slice

A minimal first version can stay entirely inside the GitHub repository. It does not need a GUI, hosted demo, or production runtime.

A possible repository shape:

src/doninha/
  claim_extractor.py
  claim_schema.py
  retriever.py
  checker.py
  license_router.py
  answer_composer.py
  run.py

examples/
  inputs/
  outputs/

eval/
  mini_benchmark.jsonl
  run_eval.py

tests/
  test_claim_schema.py
  test_license_router.py
  test_benchmark_cases.py

notebooks/
  doninha_minimal_demo.ipynb

The first runnable slice could be:

claim_extractor.py
  extracts claims from a prompt or draft answer

claim_schema.py
  defines the JSON structure of each claim

retriever.py
  optionally retrieves candidate evidence

checker.py
  checks support, contradiction, vagueness, or missing evidence

license_router.py
  assigns the license state

answer_composer.py
  generates the final answer from the claim ledger

run.py
  connects the whole flow

For this stage, even a rule-based checker is acceptable. The important thing is not sophistication yet. The important thing is to make the epistemic decision visible.

A minimal command could be:

python -m doninha.run examples/inputs/vague_water.json \
  --output examples/outputs/vague_water.result.json

The output should include both the final answer and the ledger. That way, anyone reading the repo can inspect what happened.

Useful implementation references:

Optional: mapping the current Doninha 4.0 structure to a software architecture

I would not treat the “claim-level epistemic controller” framing as a different project. Looking at the current 4.0 direction, many of the necessary pieces already seem to be present. I would mostly make the intermediate object more explicit: a claim ledger with epistemic license states.

Doninha 4.0 layer / component Software interpretation Practical role
L1 Concept Table concept / claim extraction Break the prompt or draft answer into units the system can inspect
L2 Kantian judgments claim type classification Decide whether a claim is empirical, conceptual, formal, normative, vague, etc.
Scientific syllogism / Hempel / Popper filters formal and scientific filtering Check whether the claim needs deduction, empirical support, falsification search, or relevance filtering
L3 Paraconsistent Logic conflict / uncertainty handler Handle cases where evidence supports both a claim and its negation
T/I/F-style epistemic state epistemic state vector Keep truth, indeterminacy, and falsity separate instead of compressing them into one score
RAG layer evidence provider Retrieve candidate evidence, but not decide by itself whether the claim is licensed
L4 Russellian synthesis + Chain of Verification verification controller Check whether each claim is actually supported, contradicted, underspecified, or source-mismatched
L5 text generation answer composer Generate a readable response from the claim ledger
L6/L7 refinement final license-aware editing Add caveats, abstentions, uncertainty markers, or conflict summaries
API / app files interaction surface Expose the pipeline as something users can test later
eval pipeline regression / benchmark layer Check whether each module improves the relevant failure mode

In this view, RAG retrieves evidence, but Doninha decides whether that evidence licenses the claim.

Optional: philosophical vocabulary → engineering vocabulary

I would keep the philosophical language, but pair it with an engineering role.

Philosophical vocabulary Engineering vocabulary Practical role
Kantian judgment claim type classifier What kind of claim is this?
Aristotle / syllogism formal structure checker Does this argument need deductive validation?
Russellian correspondence reference / evidence alignment checker Does the world or source match the claim?
Popperian falsifiability counter-evidence search What would defeat this claim?
Hempel-style confirmation confirmation / relevance filter Is this evidence actually relevant?
Paraconsistent logic conflict-tolerant evidence handler What if evidence supports both X and not-X?
Fuzzy logic graded-vagueness handler What if the predicate has no sharp boundary?
T/I/F epistemic state vector Track truth, indeterminacy, and falsity separately
Critique of Pure AI scope / limitation policy What should the model not claim?
Epistemology for AI claim-level epistemic controller What license does each claim receive?

A compact distinction that may help:

vagueness       → fuzzy / graded semantics
contradiction   → paraconsistent logic
indeterminacy   → T/I/F-style state vector
missing info    → retrieval or abstention
formal validity → symbolic checker

So paraconsistency remains important, but it should be one handler inside a broader epistemic router.

Optional: possible license states

A practical system needs a small vocabulary of decisions.

License state Meaning Final-answer behavior
licensed sufficiently supported state normally
qualified plausible but limited state with caveat
needs_retrieval external evidence is required retrieve before answering
conflicted strong evidence exists on both sides present both sides
vague concept boundary is unclear use graded language / define terms
insufficient evidence is too weak or absent say support is insufficient
source_mismatch citation does not support the claim do not cite it as support
invalid_premise question assumes something false correct the premise
needs_clarification user intent is underspecified ask or narrow the context
formal_check_needed deductive validity matters route to solver / formal checker
abstain claim should not be stated as fact withhold or say unknown

This is where Doninha could become practically useful: not only generating answers, but deciding the epistemic license of each part of an answer.

Optional: small benchmark sketch

A first benchmark does not need to be large. Even 50–100 examples would be useful if the categories are clear.

Category Example question Expected Doninha behavior
Vagueness Is 35°C water hot or cold? Mark as vague / graded, not contradictory
Conflicting evidence Source A says the substance is safe; Source B says it is unsafe. Mark as conflicted and preserve both sides
Missing evidence Is <obscure claim> true? Retrieve first; abstain if no reliable support appears
False premise Why did <event that never happened> happen? Detect invalid premise instead of answering directly
Current factuality Who is the current CEO of <company>? Retrieve before answering
Formal reasoning If all A are B and all B are C, are all A C? Route to formal checker
Source mismatch A citation is present but does not support the sentence. Mark source_mismatch
Subjective judgment Is this artwork beautiful? Qualify as interpretive, not factual
Ambiguous question Is Python better? Ask for context or infer a limited context
Weak support A factual claim has only weak or indirect evidence. Lower license: qualified or needs_retrieval

Possible ablation:

LLM only
LLM + RAG
LLM + verification
LLM + paraconsistent/conflict layer
Full Doninha

The point is not only to ask “which system gives the best answer?” but also:

Question Why it matters
Did it extract the right claims? tests claim extraction
Did it retrieve relevant evidence? tests RAG
Did it notice unsupported claims? tests grounding
Did it detect contradictions? tests paraconsistent/conflict handling
Did it abstain when appropriate? tests epistemic restraint
Did the final answer preserve the ledger? tests generation discipline

This would make the project easier to improve incrementally.

Optional: related work that seems especially relevant

A few existing directions seem useful as engineering neighbors.

Claim-level factuality

  • FActScore decomposes long-form generations into atomic facts and checks whether those facts are supported by reliable sources.
  • RefChecker represents LLM response claims as claim-triplets and checks them against references.
  • RAGChecker evaluates RAG systems through fine-grained claim-level checking.

These are relevant because Doninha’s central object could be similar: not only a final answer, but a structured list of claims and their epistemic status.

Verification

  • Chain-of-Verification drafts an answer, generates verification questions, answers them independently, and then produces a final verified answer.
  • SelfCheckGPT uses consistency across sampled model outputs to detect hallucination without requiring an external database.

This suggests two useful verification modes for Doninha:

Verification mode What it checks
internal consistency whether sampled generations agree or diverge
external grounding whether retrieved sources support the claim

Abstention

  • AbstentionBench evaluates whether LLMs can abstain across unknown answers, underspecified questions, false premises, subjective interpretations, and outdated information.
  • Mitigating LLM Hallucinations via Conformal Abstention is useful for the idea that “I don’t know” can be a deliberate reliability behavior, not just a fallback phrase.

This is important because Doninha should not only decide how to answer. It should also decide when not to answer.

Symbolic reasoning

  • Logic-LM uses LLMs to translate natural language into symbolic formulations and lets solvers perform the reasoning.
  • LINC similarly treats the LLM as a semantic parser and delegates formal reasoning to external symbolic tools.

So Doninha does not need to make the LLM itself “logical” in every case. It can route formal problems to formal tools.

Modular / tool-based systems

  • MRKL Systems are modular systems combining LLMs, external knowledge, and discrete reasoning modules.
  • ReAct combines reasoning and action/tool use.
  • Toolformer is relevant to the idea of learning when to use tools.

This supports the idea that Doninha can be a router, not a single monolithic model.

Optional: practical implementation stack

A prototype does not need to invent every component from scratch.

One possible stack:

Doninha function Possible tool Why
stateful workflow / router LangGraph graph-like, stateful agent workflows
retrieval / RAG LlamaIndex or Haystack document ingestion, retrieval, query pipelines
claim ledger schema Pydantic-style schema or Guardrails structured JSON output and validation
RAG / LLM evaluation Ragas or DeepEval faithfulness, answer relevance, context quality, regression tests
tracing / debugging Phoenix or TruLens inspect retrieval, tool calls, generation, and evaluation
later optimization DSPy optimize modular LM programs instead of hand-tuning prompts forever

A minimal first implementation could be:

LangGraph or simple Python functions → epistemic router / state machine
LlamaIndex or a simple retriever       → retrieval layer
Pydantic / JSON schema                 → claim ledger schema
pytest                                 → tests
mini_benchmark.jsonl                   → small evaluation set
notebook or CLI                         → first usable interface

The exact tools can change. The important part is to keep the boundaries explicit:

orchestration
retrieval
checking
license decision
final generation
evaluation

I would postpone GUI or deployment until the local / notebook version is easy to run and inspect.

Final summary

My main suggestion is therefore simple:

Make the claim ledger explicit.

Once the claim ledger exists, the philosophical layer and the engineering layer can meet in the same place.

The philosophical layer asks:

What kind of epistemic problem is this?

The engineering layer asks:

What should the software do with this claim?

That seems like the bridge between the original intuition and a working implementation.

19

Hey John…

I much appreciate your feedback. You gave me a lot to think (and do) about.

For now Doninha is here: GitHub - danielfonseca420-blip/Doninha-6.0: Hybrid Neuro-Symbolic Middleware for Epistemological Reasoning in Language Models · GitHub

Will be working on your suggestions next!

Thanks

20

Hi. Last time I may have leaned a bit too far into the broader/general framing​:sweat_smile:, so this time I tried to reorganize things in a more practical “how to move forward” way, using Doninha 6.0 as the base:

My short version would be:

I would make the next Doninha milestone very small, visible, and inspectable.

Not a full benchmark yet.
Not a claim that Doninha “solves hallucination.”
Not a huge architecture expansion.

The first useful proof target could be:

one prompt
  → extracted claims
  → evidence per claim
  → support / opposition / insufficiency / vagueness
  → license state
  → final answer constrained by those states

In one sentence:

RAG retrieves evidence; Doninha decides whether that evidence licenses the claim.

That distinction feels important to me. RAG can bring evidence into the system, but Doninha’s more interesting role may be deciding what the system is allowed to assert, what it should qualify, what it should mark as conflicted, and when it should not answer directly.

So I would frame the next step as:

The first win should be inspectability, not performance.

If Doninha can show its intermediate epistemic decisions, that is already a meaningful and testable step.

Main framing: Doninha as a claim-level epistemic controller

I would now frame Doninha less as a “paraconsistent LLM” and more as a claim-level epistemic controller around an LLM.

That does not remove the paraconsistent part. It gives it a clearer role.

Something like this:

Component Role
LLM proposes language, drafts, candidate answers, or candidate claims
RAG / search retrieves possible evidence
verification layer checks whether evidence supports or refutes claims
paraconsistent layer handles local conflict without trivializing the whole answer
abstention / restraint layer prevents unsupported claims from being asserted
symbolic checker handles formal reasoning cases when appropriate
claim ledger makes all of this visible

So Doninha’s distinctive artifact may not be only the final answer. It may be the ledger behind the answer.

A possible slogan:

The final answer is only the surface. The claim ledger is the epistemic object.

This connects Doninha to nearby work without reducing Doninha to any one existing project.

For example:

  • FActScore breaks long-form generations into atomic facts and evaluates whether those facts are supported by a reliable source.
  • RefChecker uses claim-triplets for fine-grained hallucination checking against references.
  • RAGTruth is useful because it shows that hallucinations can still appear in standard RAG settings. Retrieved context does not automatically make every generated claim grounded.

I would not say Doninha is the same as these systems. They are mostly evaluators, checkers, or benchmarks. Doninha can be more architectural: it can use claim status not only for evaluation, but also to control the final answer.

That is why I like the distinction:

RAG retrieves evidence.
Doninha licenses claims.

The licensing step is where Doninha becomes interesting.

1. First visible milestone: one-prompt claim ledger

I would start with a very small demo.

Input:

one prompt

Output:

final answer
claim_ledger.json

A first ledger does not need to be perfect. It only needs to be visible.

A minimal shape could be:

{
  "claim_id": "c1",
  "claim_text": "Detergent does not kill 100% of bacteria.",
  "claim_type": "empirical_factual",
  "evidence": [
    {
      "source_id": "s1",
      "source_span": "...",
      "relation": "supports"
    }
  ],
  "support": 0.82,
  "opposition": 0.10,
  "vagueness": 0.05,
  "context_sufficiency": "sufficient",
  "license_state": "licensed",
  "final_action": "state_normally"
}

The exact field names can change. The important part is the contract:

For each claim, Doninha should show why the final answer is allowed to state it, weaken it, reject it, retrieve more evidence, present a conflict, or abstain.

Possible first license states:

State Meaning
licensed evidence supports the claim enough to state it
qualified evidence partially supports it, but the final answer should hedge
needs_retrieval Doninha should retrieve before answering
insufficient_context retrieved context is not enough to license the claim
conflicted strong support and strong opposition both exist
refuted evidence contradicts the claim
source_mismatch a citation/source exists but does not support the claim
invalid_premise the prompt assumes something false or unverified
vague_or_ambiguous the predicate or question needs qualification
abstain Doninha should not assert the claim
Why this ledger matters

A final answer can look good while hiding failure modes.

A ledger makes those failure modes inspectable:

Problem Without ledger With ledger
unsupported claim hidden inside fluent prose marked as insufficient_context
contradictory sources model may choose one side too confidently marked as conflicted
vague predicate treated like a factual yes/no marked as vague_or_ambiguous
false premise model answers the wrong question marked as invalid_premise
bad citation citation looks reassuring marked as source_mismatch
formal reasoning LLM may improvise routed to symbolic checker

This is also why claim-level work such as FActScore and RefChecker is useful vocabulary. They show that answer-level scoring is often too coarse.

Doninha can take that idea and make it operational inside the generation process.

A simple first version could use plain text claims:

{
  "claim_text": "X happened in 2024."
}

A later version could use more structured forms inspired by RefChecker-style claim triplets:

{
  "subject": "X",
  "relation": "happened_in",
  "object": "2024"
}

But I would not start with the complex version. I would start with the visible ledger.

2. Second milestone: a five-case mini set

After one ledger example works, I would make a tiny hand-written mini set.

Maybe only five cases at first:

Case What it tests Expected Doninha behavior
supported claim normal factual grounding licensed
unsupported claim missing evidence insufficient_context / abstain
conflicting evidence source A supports X, source B refutes X conflicted
vague predicate “hot”, “cold”, “safe”, “intelligent” vague_or_ambiguous / qualified
false premise prompt assumes something false invalid_premise

This is not meant to be a leaderboard. It is a debugging set.

The point is not:

“Doninha beats model X.”

The point is:

“Doninha distinguishes epistemic behaviors that ordinary generation often collapses.”

Why these five cases are useful

1. Supported claim

The simple case.

Evidence supports claim X.
Doninha may state X.

Expected:

{
  "license_state": "licensed",
  "final_action": "state_normally"
}

2. Unsupported claim

The model may want to answer, but evidence is missing.

This connects to work like Sufficient Context, which asks whether retrieved snippets are actually sufficient to answer the query.

Expected:

{
  "context_sufficiency": "insufficient",
  "license_state": "insufficient_context",
  "final_action": "retrieve_more_or_abstain"
}

3. Conflicting evidence

This is the cleanest demo for the paraconsistent side.

Source A supports X.
Source B refutes X.

Expected:

{
  "support": 0.78,
  "opposition": 0.74,
  "license_state": "conflicted",
  "final_action": "present_both_sides_without_overclaiming"
}

This is close to the kind of problem studied in conflicting-evidence / knowledge-conflict RAG work such as CONFACT, ConflictBank, and FaithfulRAG.

Those are not paraconsistent-logic systems, but they are useful engineering neighbors for testing Doninha’s conflict branch.

4. Vague predicate

This is different from contradiction.

Is water at 35°C hot or cold?

The issue is not necessarily “X and not-X are both true.” It may be context, threshold, use case, or graded language.

Expected:

{
  "license_state": "vague_or_ambiguous",
  "final_action": "qualify_or_ask_context"
}

5. False premise

Example shape:

Why did event Y happen?

But the retrieved evidence suggests that event Y did not happen.

Expected:

{
  "license_state": "invalid_premise",
  "final_action": "correct_the_premise"
}

This is also where AbstentionBench is useful: it includes unknown-answer, underspecified, false-premise, subjective, and outdated-information cases.

3. Branch map: choose what Doninha should prove first

Depending on what you want Doninha to prove first, the path changes.

I would not implement all branches at once.

Branch If you want to prove… First artifact
Claim ledger Doninha is inspectable one-prompt ledger JSON
RAG faithfulness Doninha checks evidence, not just retrieval claim-evidence relation
Conflicting evidence paraconsistency has a practical role conflicted claim state
Abstention reliability includes not answering abstain / invalid_premise cases
Verification / CoVe draft answers can be checked before final answer verification questions per claim
Formal reasoning LLM should not do all logic alone symbolic-checker route
Corrective retrieval bad retrieval should trigger correction retrieval-quality grading
Detailed branch map with references

A. Claim ledger path

Goal:

Make Doninha’s intermediate decisions visible.

Useful neighbors:

Possible first output:

final_answer.md
claim_ledger.json

B. RAG faithfulness path

Goal:

Check whether generated claims are actually supported by retrieved context.

Useful neighbors:

I would use these as references, not as the entire Doninha evaluation. Doninha’s own ledger should remain visible.

C. Conflicting-evidence / paraconsistency path

Goal:

Show that Doninha can preserve local conflict instead of forcing one overconfident answer.

Useful neighbors:

  • FaithfulRAG, which models fact-level conflict between retrieved context and parametric knowledge.
  • CONFACT, which studies conflicting evidence and source credibility in fact-checking.
  • ConflictBank, which studies knowledge conflicts in RAG-like settings.

Important nuance:

These are not “the same thing as paraconsistent logic.”
But they are useful engineering neighbors for testing Doninha’s conflict behavior.

D. Abstention / insufficient-context path

Goal:

Show that Doninha knows when not to license a claim.

Useful neighbors:

  • AbstentionBench, for unanswerable / underspecified / false-premise / outdated / subjective cases.
  • Sufficient Context, for checking whether retrieved snippets alone could plausibly answer the question.

Possible Doninha states:

needs_retrieval
insufficient_context
invalid_premise
abstain

E. Verification / Chain-of-Verification path

Goal:

Make L4 verification visible.

Chain-of-Verification is useful here because its structure is simple:

draft response
  → verification questions
  → independent answers to those questions
  → final verified response

For Doninha, I would connect each verification question to a claim ID:

{
  "claim_id": "c2",
  "verification_question": "Does source S actually support claim c2?",
  "verification_result": "not_enough_information",
  "license_state": "insufficient_context"
}

F. Formal reasoning / symbolic checker path

Goal:

Do not force the LLM to perform formal logic alone.

Logic-LM is a useful reference here: the LLM translates a natural-language problem into a symbolic formulation, then a deterministic symbolic solver performs inference.

For Doninha, this could be only one branch:

if claim_type == "formal":
    route_to_symbolic_checker()

This keeps symbolic reasoning from taking over the whole project while still giving it a clean role.

G. Corrective retrieval / decision-graph path

Goal:

If retrieval is weak, wrong, or ambiguous, Doninha should not blindly generate.

Useful neighbors:

  • CRAG, which uses a retrieval evaluator and triggers corrective actions when retrieved documents are weak.
  • Self-RAG, which uses reflection signals for retrieval and generation.
  • LangGraph self-reflective RAG, which shows how retrieval grading and retry loops can be implemented as a decision graph.

For Doninha, the small practical version could be:

retrieve
  → grade retrieval quality
  → verify claim
  → answer / qualify / retrieve more / abstain

4. What I would test first

I would test whether the final answer obeys the ledger.

That is the important contract.

Ledger state Final answer should…
licensed state the claim normally
qualified hedge or narrow the claim
conflicted present the conflict without collapsing it
insufficient_context retrieve more, qualify, or abstain
invalid_premise correct the premise
source_mismatch not use that citation as support
vague_or_ambiguous add context, threshold, or clarification
formal claim type route to symbolic checker if possible

A simple test question for every case:

Did the final answer respect the claim’s license state?

If not, then Doninha may have produced a good-looking answer, but the controller failed.

Possible tiny test format

A small cases.jsonl could look like this:

{"case_id":"supported_001","category":"supported_claim","prompt":"...","expected_states":["licensed"]}
{"case_id":"unsupported_001","category":"unsupported_claim","prompt":"...","expected_states":["insufficient_context","abstain"]}
{"case_id":"conflict_001","category":"conflicting_evidence","prompt":"...","expected_states":["conflicted"]}
{"case_id":"vague_001","category":"vague_predicate","prompt":"...","expected_states":["vague_or_ambiguous","qualified"]}
{"case_id":"premise_001","category":"false_premise","prompt":"...","expected_states":["invalid_premise"]}

And the output directory could be:

doninha-mini/
  cases.jsonl
  evidence_store.jsonl
  run_ledger_demo.py
  outputs/
    supported_001.answer.md
    supported_001.ledger.json
    conflict_001.answer.md
    conflict_001.ledger.json

The point is not to make a polished benchmark yet. The point is to make debugging possible.

5. Practical implementation shape

I would keep the first implementation boring and explicit.

Something like:

Step 1 — get candidate answer or candidate claims
Step 2 — split into atomic claims
Step 3 — attach or retrieve evidence
Step 4 — classify evidence relation per claim
Step 5 — assign license state
Step 6 — generate final answer under license-state constraints
Step 7 — save final answer + ledger

The first version can use hand-written evidence. It does not need to solve retrieval on day one.

Actually, I think that may be better: if retrieval and epistemic routing are both changing at the same time, debugging becomes harder.

Why I would separate retrieval from licensing at first

For the first demo, I would separate these two questions:

  1. Did retrieval find the right evidence?
  2. Given evidence, did Doninha assign the right epistemic state?

These are different failure modes.

For example:

Failure What happened
retrieval failure the needed evidence was never retrieved
ranking failure weak/irrelevant evidence ranked too high
context insufficiency evidence is related but not enough
context conflict sources disagree
verification failure evidence exists but is misread
generation failure final answer overstates the ledger
citation failure citation does not support the claim

This distinction is also why I would be careful with automatic scores at the beginning.

Tools like RAGAS are useful, but a single aggregate score can hide which component failed. Some GitHub issues around RAGAS also show that metric behavior can be surprising or setup-sensitive, for example reports of inconsistent-looking scores or language-sensitive evaluation behavior such as non-English answer relevancy issues.

So I would use automatic metrics later, but make the first Doninha demo human-inspectable.

6. Pitfalls I would avoid

A few things I would avoid while keeping the first demo small:

Pitfall Better Doninha behavior
RAG = grounding check whether evidence supports each claim
citation = support verify cited span against the claim
one aggregate score = proof keep claim-level decisions visible
vagueness = contradiction route vague predicates separately
all failures = hallucination distinguish retrieval, evidence, generation, and premise failures
architecture expansion first make one tiny vertical slice work first
More detail on the main pitfalls

1. Do not equate RAG with grounding

RAG gives the model context. It does not automatically prove that every generated claim is supported.

This is why RAG hallucination datasets like RAGTruth are useful.

2. Do not equate citation with support

A source link or citation is not enough. The cited span must actually support the claim.

This is a known problem in RAG attribution. For example, MIRAGE discusses cases where self-citing LLMs may refer to non-existent sources or fail to reflect actual context usage, and Promptfoo has a RAG Source Attribution plugin specifically to test fabricated citations or source references.

So Doninha should probably have an explicit state like:

source_mismatch

3. Do not collapse different epistemic problems into one bucket

These are different:

Problem Better label
source A says X and source B says not-X conflict
“hot” / “cold” depends on threshold or context vagueness
not enough evidence was retrieved insufficient context
the prompt assumes something false invalid premise
the inference form is invalid formal error
the citation does not support the claim source mismatch

Paraconsistency is most visible in the conflict case.
Vagueness may need graded or contextual handling.
Formal validity may need a symbolic checker.
Missing evidence may require retrieval or abstention.

4. Do not start with a huge benchmark

A large benchmark can come later.

At the beginning, a five-case set may teach more than a thousand noisy examples.

5. Do not hide the important part inside fluent prose

The final answer can be fluent even when the epistemic control failed.

That is why I would save the ledger.

7. Suggested progress ladder

If I had to choose a practical next sequence, I would do this:

Step Artifact Why it helps
1 one-prompt ledger proves Doninha can expose intermediate decisions
2 five-case mini set separates supported / unsupported / conflicted / vague / false-premise cases
3 conflicting-evidence demo gives the paraconsistent branch a clean test
4 abstention demo shows reliability as restraint, not only answer generation
5 source-mismatch demo prevents “citation = support” confusion
6 20–50 case small benchmark makes the project easier to compare and discuss
7 optional metrics RAGAS / faithfulness / context metrics can be added after the ledger is stable

The shortest path is:

one prompt
  → claim ledger
  → final answer constrained by ledger

Then:

five cases
  → five expected epistemic behaviors

Then:

20–50 cases
  → small inspectable benchmark
A possible first public demo success criterion

For a first public mini-demo, I would define success like this:

Doninha succeeds if a reader can inspect the output and see:

  1. what claims were extracted;
  2. what evidence was considered;
  3. whether each source supports, contradicts, or fails to support each claim;
  4. which license state was assigned;
  5. whether the final answer obeyed those license states.

That is enough for a first useful proof.

It does not need to prove that Doninha solves hallucination.

It only needs to prove that Doninha can make hallucination-relevant decisions explicit.

That would already be a meaningful step.

8. Concrete recommendation

If I had to choose one next action, I would build this first:

Doninha 6.0 — one-prompt ledger demo

Target:

Input:
  one prompt

Output:
  final answer
  claim_ledger.json

Then expand to:

five cases:
  supported
  unsupported
  conflicted
  vague
  false premise

And only after that, move toward larger benchmarks, automatic scoring, UI, or more layers.

This keeps the philosophical motivation intact, but gives the project a small testable object.

For me, that is the key move:

Keep the philosophy, but make the next proof target small and visible.