Minority Report
novel insights engine
Created on 21st February 2026
•
Minority Report
novel insights engine
The problem Minority Report solves
Minority Report
The Problem
Everyone with multiple LLM subscriptions does the same thing asks the same question across ChatGPT, Claude, Perplexity, and Gemini, then mentally diffs the answers. You're hunting for that one insight 4 out of 5 missed. But right now there's no systematic way to know which claims hold up, which are noise, and which are confidently repeated by the majority but actually wrong.
Current approaches either dismiss minority opinions entirely (Bittensor-style consensus) or reject anything they can't immediately verify (MIRA Protocol). Both throw away potentially valuable information. A claim like "if Tether collapses, developing nations would suffer more than in 2008" isn't something you can slap a true/false on but it's not noise either. It deserves to exist in a system that's honest about what it knows and what it doesn't.
What Minority Report Does
It decomposes multiple LLM responses into atomic claims, independently verifies each against sourced evidence, and buckets them into three categories:
- Supported — the evidence backs it up
- Contradictory — the evidence says the opposite
- Inconclusive — the data conflicts or doesn't exist yet
This surfaces what no other system shows you — majority claims that are wrong, and minority claims that are verified. The signal everyone else throws away.
Use Cases
Market Research
Prompt: "What is the effect of US dollar exposure on India after the EU-India bilateral trade deal?"
Health Questions
Prompt: "Can I survive just on Red Bull and milk?"
Relationship Advice
Prompt: "My boyfriend said 'if you really loved me you'd stop talking to your friends so much' is that toxic?" (having novel insight here is helpful)
Verification as Participation
Here's the thing about verification — it's easy. You can read a book and recognize good writing. Doing the writing yourself is harder. Verification has a much lower barrier to entry than generation, which means it can be distributed to the masses like a validator. Current verifier baselines are good enough to be domain-tweakable and community-run. This is how you get participation at scale — not by asking everyone to generate novel research, but by letting them verify, challenge, and engage with existing claims.
Information augmentation
If you have a lot of plausibly sane hypotheticals (like the Inconclusive or contradictory claims ), you can create a pipeline for people to engage with that information and allow incentives since you have liquidity flowing in the system. Something which downfall of Stack Overflow has created a gap for. **Engagement with existing information yields new information. **
Who Is This For
Anyone doing research where being wrong is expensive Eg, market analysis, health decisions, due diligence, policy research, where verification is important.Also, Instead of throwing away the outlier, you check its receipts. And when something genuinely can't be verified, the system tells you that, and shows you how, because sometimes "we don't know yet" is the most valuable answer, and the beginning of real research.
Challenges we ran into
The verification layer was taking too much time - 7 minutes for each run.
We got over it by making workers pools such that we don't hit rate limits and also parallise as much as we can. We got the verification step down under a minute.
Next , for clustering of claims based on majority or novel, LLMs were taking very long, so we used semantic searching and TF+IDF.
A lot of our problems were around rate limits , model quirks (how gpt5.1 didn't satisfy our claim extraction requirements because it thought a wee bit much) and how gpt4o actually did the trick, but had lower rate limits on openai website.
Also , since we were using seprate models for extraction , verification and compilation. We would get into issues with random markdown popping up here and there. The difference in outputs after filtering that slob was night and day.
Use of AI tools and agents
During the verification stage, the process is 3 fold
- claim extraction
- Google search using Serper
- claim validation
For extraction, we had to work a bit on tweaking the prompts. We found prompt being used in existing research projects didn't really fulfil practical use cases.
Same goes for claim validation. The definition of "contradictory" , "supported" and "inconclusive" had to be reiterated to fit more into the sentiment of an average user.
For claim clustering into majority and minority, we used openai embeddings for semantic matching with TF+IDF hybrid approach, This saved us a lot of time. We used Anthropic API to generate insights for the user form our data.
We have 2 types of agents in our system : LLM agents which are queried with questions and verifiers which are queried for verification. LLM agents stake the KITE tokens when they generate the response, and the Verifier agent verifies their work product. There is an escrow which rewards the LLM agent with maximum verifiable novel claims, while not penalising something that might be inconclusive or contradictory as that is valuable information as well.
Tracks Applied (2)
Futurllama
Agent-Native Payments & Identity on Kite AI (x402-Powered)
Kite AI