PrismShine is a self-hosted anti-hallucination verdict engine. It runs cause-side forensics on runtime evidence, then grounds the answer against your preload — one auditable ShineVerdict with a named resolution_gate. Apache-2.0. pip install prismshine.
No reviews yetBe the first to leave a review for PrismShine
Maker
📌
Hey Product Hunt — maker here.
I got tired of “sounds right” answers slipping past score-only checkers. Most detectors only see the final text. A lot of failures start earlier — empty retrieval, a swallowed tool error, a stale cache — then the model fills the gap fluently.
PrismShine is a self-hosted anti-hallucination verdict engine: cause-side forensics on runtime evidence + grounding against your preload → one auditable ShineVerdict (decision + named resolution_gate + evidence_hash).
Not a prompt-injection firewall. Not an agent runtime. It verifies answers against evidence.
Public receipt vs HHEM-2.1-Open on HaluEval (2026-07-20_run4_onnx): B1 F1 0.831 vs 0.746 · fabricated numbers B2 1.0 / 0 FP · ~90 ms · 0 LLM on the fast path.
Try it:
pip install "prismshine==0.2.2"
prismshine verify --demo
Landing: https://www.insightits.com/produ...
Interactive demo (no API key): https://insightitsgit.github.io/...
GitHub: https://github.com/insightitsGit...
Honest limit: PASS ≠ world-true — grounded in the preload you provided, not the whole world.
Question for the community: where would you wire this first — after the LLM node, before generation (halt empty retrieval), or both? And what’s the worst false positive you’ve hit with other checkers?
Report
The resolution_gate concept is genuinely useful for tracing back why an answer got flagged. One thing I'd love to see is a way to export the verdict history as a structured log so I can plug it into my existing observability stack and correlate spikes in hallucinations with specific deploys or prompt changes.
Report
Maker
@rhastekkes51150 Thanks Rabia — that’s exactly the use case we designed resolution_gate for.
Today every ShineVerdict is already a structured record (decision + named resolution_gate + evidence_hash + signatures/spans). Pattern most people use: log the verdict JSON next to your request metadata (deploy SHA, prompt version, model), then spike on decision!=pass or on specific gates in whatever you already run (Datadog / Loki / BigQuery / etc.).
What we don’t ship yet is a built-in “verdict history → observability sink” exporter — your note is on the short list. If you drop which stack you use (OTel? Datadog? something else), that helps us prioritize the shape.
tried it on a flaky agent log and honestly the resolution_gate label made debugging way less painful than usual. basically exactly what i needed
Report
Maker
@berkecakal35596 Appreciate that, Berke — glad resolution_gate earned its keep on a real flaky log. That’s the whole point: name the gate, don’t leave you with a mystery score.
If anything felt confusing in the verdict fields, shout — happy to clarify.
The resolution_gate concept is genuinely useful for tracing back why an answer got flagged. One thing I'd love to see is a way to export the verdict history as a structured log so I can plug it into my existing observability stack and correlate spikes in hallucinations with specific deploys or prompt changes.
@rhastekkes51150 Thanks Rabia — that’s exactly the use case we designed resolution_gate for.
Today every ShineVerdict is already a structured record (decision + named resolution_gate + evidence_hash + signatures/spans). Pattern most people use: log the verdict JSON next to your request metadata (deploy SHA, prompt version, model), then spike on decision!=pass or on specific gates in whatever you already run (Datadog / Loki / BigQuery / etc.).
What we don’t ship yet is a built-in “verdict history → observability sink” exporter — your note is on the short list. If you drop which stack you use (OTel? Datadog? something else), that helps us prioritize the shape.
Demo if useful: https://insightitsgit.github.io/PrismShine/demo.html
tried it on a flaky agent log and honestly the resolution_gate label made debugging way less painful than usual. basically exactly what i needed
@berkecakal35596 Appreciate that, Berke — glad resolution_gate earned its keep on a real flaky log. That’s the whole point: name the gate, don’t leave you with a mystery score.
If anything felt confusing in the verdict fields, shout — happy to clarify.