Paraconsistent Logic and AI models

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 (click for more details) Optional: mapping the current Doninha 4.0 structure to a software architecture (click for more details) Optional: philosophical vocabulary → engineering vocabulary (click for more details) Optional: possible license states (click for more details) Optional: small benchmark sketch (click for more details) Optional: related work that seems especially relevant (click for more details) Optional: practical implementation stack (click for more details)

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.