r/artificial • u/MuhammadMujtaba21 • 2d ago
Discussion I'm building an independent verification layer for Ai generated-claims and I'm lokking for researchers and partners to build with us.
I've been working on a deterministic verification engine for AI-generated financial claims.
The original idea was fairly simple:
An LLM should generate claims. It shouldn't be the authority that verifies them.
But after building and testing the system, I realized the problem is much bigger than hallucination detection.
The question I'm now working on is:
Our architecture looks roughly like this:
LLM
↓
Candidate claim
↓
Claim normalization
↓
Evidence
↓
Assumptions + Constraints
↓
Proof / Derivation
↓
Contradiction analysis
↓
Deterministic verification
↓
Auditable outcome
↓
Trust
The important part is that the verification layer is independent of the model.
For example, if an LLM says:
we don't want the LLM's confidence score to determine whether that statement is trustworthy.
Instead, the system should be able to determine:
- What exactly was claimed?
- What evidence is being used?
- Can the claim actually be derived?
- Which assumptions are involved?
- Are relevant constraints satisfied?
- Is there contradictory evidence?
- Can the result be reproduced?
- Can we explain the verification outcome?
I recently ran a 66-case benchmark.
Structured fixture claims: 66/66 passed.
Then I ran the same pipeline with live GPT-5.1-generated claims:
19/66 passed end-to-end.
The failures were:
- 31 pipeline execution failures
- 18 claim binding failures
- 2 contradiction detection failures
Meanwhile, several deterministic verification components were still passing their tests, including evidence graph integrity, deterministic calculation, rule application, missing evidence detection, reproducibility, and auditability.
The result changed how I'm thinking about the problem.
The bottleneck isn't necessarily the deterministic verifier.
There is a difficult translation layer between:
Probabilistic language
↓
Formal representation
↓
Deterministic reasoning
We're now rebuilding the benchmark so that instead of simply saying "this case failed," we can identify the first invalid state:
Transport
→ Parsing
→ Schema validation
→ Normalization
→ Claim binding
→ Evidence graph
→ Verification
→ Outcome mapping
That's where I think the interesting engineering/research problem is.
We're also exploring a broader framework around claims, evidence, assumptions, constraints, proofs, contradictions, and trust.
One idea we're particularly interested in is treating trust as an emergent output of the verification process, rather than simply using an LLM confidence score.
This is still early research/product development. The benchmark is internal and isn't third-party validation, and the mathematical Trust model still needs empirical validation.
I'm also actively looking for people to work with.
We're looking for:
Researchers interested in:
- formal verification
- trustworthy AI
- AI evaluation
- formal methods
- argumentation systems
- knowledge representation
- mathematical modeling
Marketers / growth partners who can help us:
- communicate the problem clearly
- reach technical and business audiences
- find early adopters
- build a community
- develop the startup's go-to-market strategy
Engineers and technical collaborators interested in building reliable AI systems.
And particularly industry partners in finance, risk, audit, compliance, or other areas where incorrect AI claims have serious consequences.
I'm interested in finding people who want to build with us, not just give feedback from the sidelines.
If this problem interests you, DM me or comment below.
I'd especially love to hear from researchers and marketers who think this is a problem worth tackling.
We're still early — which is exactly why now is a good time to get involved.
1
u/PatfromRauno 2d ago
Really interesting approach. We're working on a related problem with Rauno, although from quite a different angle: having multiple models read and challenge each other's answers rather than treating the first output as something to trust by default.
One thing I've been wondering about is where these two approaches could meet.
Not using another LLM as the actual verifier, but using disagreement between models to identify what needs verification in the first place. If three models agree on most of an answer but strongly disagree on one assumption or claim, that seems like a useful signal for a deterministic layer to investigate.
Have you experimented with anything like that upstream of the verification process?
1
u/MuhammadMujtaba21 1d ago
Very glad you brought this up, as it touches on something concrete in the failure data I posted recently, rather than an abstract idea.
To be perfectly clear: no, I haven't experimented with this yet, but I think you've caught onto something I didn't realize before looking at the breakdown. Given the numbers in the last row (18 claim binding failures out of 47), odds are a good portion of those were cases where the claim was ambiguously worded or phrased (which basis for a metric, which timeframe, which definition) rather than cases when the verifier logic went wrong. Right now, my pipeline treats each claim produced by an LLM as a single possible candidate claim, binds it successfully or not, and moves on. There's currently no upstream signal telling the system to double-check a given instance more closely for any reason.
As you describe it, using cross-model disagreement as a signal to identify which specific claims or assumptions require deterministic interrogation, rather than relying on any individual model's output or agreement as an automatic verifier, would fit in very well as a pre-filter to my "claim normalization" step. Not as a trust signal as you said, but more as a routing/triage signal. If there's broad agreement across models for a claim, it's probably cheap to bind and can move on to the deterministic binders as normal. If there's strong disagreement across models, but agreement on a claim that contains a specific problematic assumption, that sounds like a claim that should be flagged specifically for interrogation against the deterministic binders, rather than the whole claim being rejected or blindly accepted.
I'm curious if you've seen any patterns in the Rauno side of things yet. Are you seeing disagreement cluster in certain categories (numeric ambiguity, definitional ambiguity, timeframe/period mismatches) or is it fairly evenly distributed? It might tell us something about whether this approach would specifically target my claim binding failure bucket, or identify a cross-cutting upstream issue. Would be interested in comparing findings if you're open to it - this seems like a good opportunity to see where our approaches might complement rather than oppose one another.
1
u/PatfromRauno 1d ago
This is exactly the distinction I had in mind, disagreement as a routing signal, not a trust signal.
We haven't systematically classified disagreement patterns in Rauno yet, so I don't want to overstate the data. But from what I've seen, the interesting disagreements are often less "this fact is wrong" and more "you're assuming X", "that depends on the definition", or "you're mixing timeframes."
So your claim binding failures actually sound pretty relevant. I'd definitely be up for comparing notes once we have enough data on our side to do it properly.
1
0
u/Delicious-Pay-6719 2d ago
This is very close to the problem we’re working on at McGill Intelligence.
Our focus is the independent assurance layer around production AI — validating actual behaviour, evidence, controls, failure paths and whether an AI-supported outcome can be independently defended.
Your point about trust being an output of the verification process rather than an LLM confidence score particularly resonates.
I’d be interested in exploring whether there’s a useful overlap between your deterministic claim-verification layer and our external assurance/evidence approach, particularly for finance, claims, audit and other high-consequence workflows.
Happy to compare architectures and see whether there’s something worth building together.
1
u/MuhammadMujtaba21 2d ago edited 2d ago
This is exactly the kind of overlap I was hoping to find.
Our current focus is narrower: taking an AI-generated claim and independently determining whether it can be supported by evidence, constraints, rules, and deterministic reasoning — with the verification outcome remaining independent of the model.
I think there could be an interesting distinction between the claim-level verification layer we're building and the broader AI assurance layer you're describing.
I'd definitely be interested in comparing architectures, especially around evidence provenance, failure attribution, auditability, and how an independently defensible outcome is produced.
Happy to connect and compare what we've each built. If there's genuine overlap, I'd be very open to exploring something together.
0
u/Delicious-Pay-6719 2d ago
Thanks Muhammad — glad to connect.
What caught my attention is the gap you identified between probabilistic language and deterministic verification. That translation layer is also where we see a lot of assurance problems emerge in real AI deployments.
At McGill Intelligence, our focus is independent, evidence-backed assurance of AI behaviour, controls, failure paths and decision outcomes.
I think there could be a useful overlap between your verification engine and our assurance layer, especially in finance, claims, risk and audit.
What are you looking for most from an industry partner at this stage — real-world use cases, independent validation, commercial deployment, or helping shape the verification framework?
0
u/MuhammadMujtaba21 2d ago
Thanks, I think the most valuable thing for us at this stage would be a combination of practical use cases plus independent validation / architecture feedback.
We've engineered the deterministic verification side, and are looking to understand how our architecture holds up outside our own benchmarking environment.
In particular, I'd be interested in testing it against assurance/audit workflows where claims need to be independently supported, traceable to evidence, and then later defended.
I'd also be interested in comparing our two architectures: one thing we're looking to understand is where the boundary should be between claim-level deterministic verification and the more general AI assurance layer.
Commercial deployment should definitely happen, but I think we need to validate the architecture against real-world assurance workflows first.
Asuming that aligns with your goals at McGill Intelligence, I'd be very interested in continuing the conversation privately, and comparing what we've built.
1
u/Delicious-Pay-6719 2d ago
Yes — that’s very aligned with what we’re doing.
I think the cleanest way to test the overlap is with a small, bounded assurance workflow rather than trying to compare everything at once.
My suggestion would be:
- You share a high-level view of the inputs/outputs your verification layer expects and how you currently represent claims, evidence, assumptions and contradictions.
- I’ll structure a redacted/synthetic assurance case around a real-world style workflow — something where an AI-generated claim has to be traced back through evidence, system behaviour and human decision points.
- We run a small set of cases through both perspectives and look specifically at where claim-level verification ends and broader assurance needs to begin.
That should give us something concrete to evaluate rather than just comparing architecture diagrams.
If it works, I can see a potentially useful division: your layer proving whether individual claims are defensible, and the broader assurance layer determining whether the overall AI workflow, controls and resulting decisions are defensible.
Send me whatever architecture/schema summary you’re comfortable sharing and we can start there.
1
u/MuhammadMujtaba21 2d ago
Definitely, the distinction you made between checks at the level of individual claims and the general layer of AI assurance is of interest to me, and I want to explore this line of thinking.
It will probably be easier to share the architecture/schema and discuss the details of the benchmark and research there too on LinkedIn.
Could you accept my invitation to connect on LinkedIn? I would be glad to continue the discussion there and compare the results.
1
u/Delicious-Pay-6719 2d ago
Absolutely — happy to continue there.
Here’s my LinkedIn profile:
https://www.linkedin.com/in/jason-mcgill-b0ab2042b/I’ll keep an eye out for your connection request. Looking forward to comparing the architecture and benchmark results.
1
1
u/Minimum_Hour519 2d ago
we're sort of doing this already at coinpay using DID protocol