{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreig5dlgxtvrbtwnhqaovxqhevjoviuyinfns4qjeh4jb7haglsvka4",
    "uri": "at://did:plc:pgryn3ephfd2xgft23qokfzt/app.bsky.feed.post/3mosemkqv7ad2"
  },
  "path": "/t/paraconsistent-logic-and-ai-models/174262#post_18",
  "publishedAt": "2026-06-21T11:33:18.000Z",
  "site": "https://discuss.huggingface.co",
  "tags": [
    "Google Colab",
    "(click for more details)"
  ],
  "textContent": "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:\n\n* * *\n\n## Short version\n\nI think the most practical framing is this:\n\n> Doninha should not be seen mainly as “a paraconsistent LLM”, but as a **claim-level epistemic controller** around an LLM.\n\nThat 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:\n\n  * can this claim be stated normally?\n  * does it need retrieval?\n  * is it vague?\n  * is it contradicted by another source?\n  * is the premise invalid?\n  * should the model abstain?\n  * should the answer include a caveat?\n  * should the claim be routed to a formal checker?\n\n\n\nSo I would not abandon the philosophical layer. I would translate it into engineering roles.\n\nThe 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.\n\n* * *\n\n## The first concrete milestone\n\nIf the goal is working software, I would make the first milestone very small:\n\n> One prompt goes through claim extraction, claim-ledger JSON, optional retrieval/checking, license decision, and final answer generation.\n\nNo 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.\n\nA first version could simply do this:\n\n\n    User question\n      ↓\n    Extract 3–5 claims\n      ↓\n    Store each claim as JSON\n      ↓\n    Retrieve or check evidence when needed\n      ↓\n    Assign a license state\n      ↓\n    Generate a final answer from the ledger\n      ↓\n    Save both the ledger and final answer\n\n\nThe first goal would not be high performance. The first goal would be **observability** :\n\n  * can we see the extracted claims?\n  * can we see the evidence?\n  * can we see the license decision?\n  * can we see why the final answer was softened, verified, or withheld?\n  * can tests confirm that each failure mode is routed correctly?\n\n\n\nOnce that vertical slice works, the larger L1–L7 architecture becomes much easier to grow.\n\n* * *\n\n## Main practical framing\n\nA software-shaped version of Doninha could look like this:\n\n\n    User prompt\n      ↓\n    Claim / concept extraction\n      ↓\n    Claim type classification\n      ↓\n    Evidence retrieval / verification / formal checking\n      ↓\n    Epistemic state assignment\n      ↓\n    License decision\n      ↓\n    Final answer generation\n      ↓\n    Audit / explanation\n\n\nThe key intermediate object would be a **claim ledger**.\n\nFor example:\n\nClaim | Type | Evidence | Conflict | Indeterminacy | License\n---|---|---|---|---|---\nClaim A | empirical | strong | low | low | `licensed`\nClaim B | empirical | weak | medium | high | `needs_retrieval`\nClaim C | conceptual | medium | low | medium | `qualified`\nClaim D | current factual | missing | unknown | high | `retrieve_or_abstain`\nClaim E | controversial | mixed | high | medium | `conflicted`\n\nThe final answer would then be generated from this ledger, rather than directly from the raw LLM output.\n\nThis would also make the project easier to test, because each module has a visible job.\n\n* * *\n\n## RAG is useful, but it is not the whole epistemic layer\n\nI would treat RAG as the **evidence provider** , not as the full solution.\n\nA simple way to say it:\n\n> RAG retrieves evidence; Doninha decides whether that evidence licenses the claim.\n\nFor example:\n\nSituation | Doninha behavior\n---|---\nevidence supports the claim | `licensed`\nevidence weakly supports the claim | `qualified`\nevidence contradicts the claim | `conflicted`\nno evidence is found | `insufficient` or `abstain`\nsource is present but does not support the sentence | `source_mismatch`\nquestion requires current information | `needs_retrieval`\nquestion contains a false premise | `invalid_premise`\n\nThis is the layer that makes Doninha more than ordinary RAG.\n\n* * *\n\n## Practical next steps\n\nI would keep the next steps narrow and sequential.\n\n### Step 1 — Make the claim ledger explicit\n\nStart with a visible JSON object.\n\nExample:\n\n\n    {\n      \"question\": \"Is 35°C water hot or cold?\",\n      \"claims\": [\n        {\n          \"claim\": \"35°C water is hot.\",\n          \"claim_type\": \"vague_predicate\",\n          \"truth\": 0.4,\n          \"indeterminacy\": 0.7,\n          \"falsity\": 0.2,\n          \"conflict\": 0.0,\n          \"license\": \"vague\",\n          \"final_behavior\": \"Use graded language instead of treating this as a contradiction.\"\n        }\n      ],\n      \"final_answer\": \"35°C water is better described as warm or lukewarm rather than simply hot or cold. The classification depends on context.\"\n    }\n\n\n### Step 2 — Define a small set of license states\n\nFor example:\n\n\n    licensed\n    qualified\n    needs_retrieval\n    conflicted\n    vague\n    source_mismatch\n    invalid_premise\n    needs_clarification\n    formal_check_needed\n    abstain\n\n\n### Step 3 — Build a minimal local / notebook demo\n\nA simple CLI or notebook cell is enough:\n\n\n    python -m doninha.run examples/inputs/vague_water.json\n\n\nor:\n\n\n    from doninha import run_pipeline\n\n    result = run_pipeline(\"Is 35°C water hot or cold?\")\n    result.claim_ledger\n\n\n### Step 4 — Create a small benchmark\n\nEven 50–100 examples would be useful if each category is clear.\n\n### Step 5 — Add tests before adding more layers\n\nAt first, simple checks are enough:\n\n\n    python -m compileall src\n    pytest\n    python eval/run_eval.py\n\n\nThe goal is not to prove the whole theory immediately. The goal is to make the pipeline inspectable and stable.\n\n* * *\n\nOptional: 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)\n\n## Final summary\n\nMy main suggestion is therefore simple:\n\n> Make the claim ledger explicit.\n\nOnce the claim ledger exists, the philosophical layer and the engineering layer can meet in the same place.\n\nThe philosophical layer asks:\n\n> What kind of epistemic problem is this?\n\nThe engineering layer asks:\n\n> What should the software do with this claim?\n\nThat seems like the bridge between the original intuition and a working implementation.",
  "title": "Paraconsistent Logic and AI models"
}