Paraconsistent Logic and AI models

Hi. Last time I may have leaned a bit too far into the broader/general framing​, 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 (click for more details)

---

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 (click for more details)

---

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 (click for more details)

---

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 (click for more details)

---

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 (click for more details)

---

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 (click for more details)

---

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 (click for more details)

---

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 (click for more details)

---

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.