-
-
Contrarian Architecture
-
-
Inspiration
People rarely make expensive decisions with no evidence. The more common problem is that they collect evidence in a way that protects the answer they already want.
A founder proposes a new market. A company proposes an infrastructure investment. A strategy team proposes a product expansion. Then the research begins—and the search process gradually becomes an exercise in justification.
Ordinary research agents can amplify this problem. They search before defining what failure means, summarize instead of testing assumptions, count repeated reporting as independent confirmation, and produce recommendations without explaining what evidence would change them.
We built Contrarian around a different question:
What if the research agent’s job were to kill the proposal?
Contrarian is an adversarial decision-research system. It converts a proposal into falsifiable assumptions, locks the failure conditions before searching, and uses live structured SerpApi results to test whether those assumptions survive.
Live link: https://contrarian.streamlit.app/
What it does
A user begins with a proposed decision, including its geography, timeline, constraints, desired outcome and the evidence that would change their mind.
Contrarian then:
- Converts the proposal into four to six falsifiable assumptions.
- Creates an explicit kill condition for every assumption.
- assigns importance weights that must total 100%.
- Locks this versioned Decision Contract before any search runs.
- Routes targeted prosecutor and defender queries through multiple SerpApi engines.
- Deduplicates repeated reporting into source families.
- Calculates inspectable evidence pressure.
- Displays an Assumption Survival Board.
- Identifies the most fragile parts of the proposal.
- Suggests constrained repairs and researches them with new queries.
The result is not another AI-generated research summary. It is a visible record of what the decision assumes, what could kill it, what evidence was found and what must change for the proposal to become less fragile.
Our demonstration
Our demo evaluates the following proposal:
Should a startup build a 20 MW AI-inference data centre in Johor by 2028 to serve Singapore-based customers?
Contrarian decomposes this proposal into six assumptions:
- Grid capacity can be contracted
- Water and cooling remain manageable
- Singapore demand will spill into Johor
- Cross-border latency is acceptable
- Residency rules permit the workloads
- The facility can differentiate
Each assumption has a precommitted kill condition. For example, the grid assumption fails if an official source establishes that a new 20 MW connection cannot be contracted for delivery by 2028.
Only after these conditions and their weights are locked does research begin.
How we used SerpApi
SerpApi is the evidence infrastructure of Contrarian, not a decorative search box.
Contrarian routes different questions to different SerpApi engines:
| Research need | SerpApi engine |
|---|---|
| Official sources, regulation and general evidence | Google Search |
| Recent failures, announcements and policy changes | Google News |
| Scientific and engineering assumptions | Google Scholar |
| Relative demand direction | Google Trends |
| Physical competitive visibility | Google Maps |
Each investigation targets approximately 18 SerpApi calls with a hard limit of 22.
Every search activity record preserves:
- Engine
- Query
- Prosecutor or defender role
- Geographic parameter pack
- Engine-selection reason
- Result count
- Duration
- Cache state
- Completion status
Contrarian also uses SerpApi’s localization parameters to test the same core query from two evidence environments.
For the demo, Johor searches use:
location = Johor Bahru, Johor, Malaysia
gl = my
hl = en
Singapore searches use:
location = Singapore
gl = sg
hl = en
The resulting Evidence Geography Gap compares URL and domain overlap. It does not claim to measure public sentiment. It shows how the visible evidence environment changes when the location parameters change.
Without SerpApi, Contrarian would lose its live evidence, freshness signals, engine specialization, localization analysis, market visibility and counterfactual validation.
How the evidence engine works
For evidence item (j) applied to assumption (i), Contrarian calculates:
$$
E_{ij}
d \times r \times s \times q \times f \times n $$
Where:
- (d) = direction: contradicts, contextual or supports
- (r) = relevance
- (s) = evidence strength
- (q) = source reliability
- (f) = freshness
- (n) = independence
Contrarian deliberately calls this evidence pressure. It is not a truth score or a probability that the proposal will succeed.
An assumption may:
- Survive
- Be under pressure
- Fail
- Have insufficient evidence
The overall Fragility Index is a weighted summary of these statuses, not a success probability.
Preventing ten copies from becoming ten facts
One of the hardest problems was evidence duplication.
A single announcement may be republished by many news sites. A naive system could treat ten versions of the same press release as ten independent confirmations.
Contrarian uses embeddings or TF-IDF cosine similarity to cluster near-duplicate results and related sources into evidence families.
The first item in a source family receives full independence weight. Repeated members are discounted using:
$$ \text{independence} = \frac{1}{\sqrt{n}} $$
This allows the system to preserve corroboration without allowing repeated reporting to overwhelm genuinely independent evidence.
The Evidence Flow Sankey makes the reduction visible:
Raw SerpApi results → Source families → Evidence cards → Assumptions
Counterfactual repair
Breaking a proposal is useful. Showing how to repair it is more useful.
When assumptions fail or come under pressure, Contrarian creates constrained counterfactuals that modify no more than two major variables.
In the demo, the original 20 MW regional data-centre proposal can be reframed as a 2 MW liquid-cooled edge facility in Kulai serving local manufacturers.
Contrarian does not automatically declare the revised idea viable. Selecting Research this repair creates new SerpApi micro-queries and recomputes its evidence pressure.
A reduction in fragility is presented only as a reduction in fragility—not proof of success.
How we built it
The judges’ application is a single Streamlit process with a Python research engine.
Decision input
↓
AI-generated falsifiable assumptions
↓
Locked Decision Contract
↓
SerpApi engine router
↓
Normalization and source-family clustering
↓
Deterministic evidence-pressure scoring
↓
Survival Board and Counterfactual Lab
The project uses:
- Streamlit for the interactive application
- SerpApi for structured multi-engine search
- Gemini for structured assumption, stance and summary generation
- SQLAlchemy and SQLite for investigation state
- Pydantic for validated contracts
- scikit-learn for TF-IDF clustering
- Plotly for evidence-flow visualization
- HTTPX for asynchronous API requests
- Pytest for the test suite
API keys remain server-side and never reach the browser.
Challenges we faced
Fighting confirmation bias structurally
Telling an AI to “be critical” is not enough. We needed to change the sequence of the workflow. Kill conditions are therefore created, weighted and locked before retrieval begins.
Choosing the correct search engine
A trend line cannot prove market size. A Maps result is not a complete business registry. A news article should not establish an engineering constraint by itself.
We built explicit routing rules so each engine handles an appropriate evidence type and the interface states those limitations.
Separating repeated reporting from independent evidence
Deduplicating exact URLs was insufficient. We needed source-family clustering and an independence penalty to prevent syndicated coverage from dominating the result.
Comparing different evidence environments
The same query may produce different sources depending on location. We kept the query constant while changing only the SerpApi localization pack, allowing the application to expose that gap without mislabelling it as sentiment.
Building a reliable live demonstration
Live multi-engine research can encounter latency, missing fields or temporary failures. We implemented normalization, caching, call budgets and a labelled recorded-results fallback. Recorded data is never presented as live.
What we learned
We learned that more search results do not necessarily mean more evidence. Independence matters as much as volume.
We also learned that localization is not simply a presentation setting. It can materially change which evidence becomes visible to a decision-maker.
Most importantly, we learned that a recommendation is only useful when a user can inspect what produced it and state what evidence would reverse it.
Who it is for
Contrarian could support:
- Corporate strategy teams
- Venture and investment committees
- Founders testing expansion plans
- Infrastructure and site-selection teams
- Product leaders evaluating new markets
- Consulting and innovation teams
A production version could offer collaborative Decision Contracts, scheduled re-investigation when evidence changes, organization-specific source policies and auditable decision reports.
The commercial model could combine team subscriptions with usage-based pricing for live multi-engine investigations.
Responsible use and limitations
Search snippets are evidence leads, not substitutes for full documents or professional review.
Google Trends represents relative interest, not absolute demand. Google Maps shows maps-visible businesses, not a complete registry. Unknown dates receive reduced freshness weight.
Contrarian is not legal, financial, medical or regulatory advice. It must not be used to rank employees, applicants or borrowers, or to infer protected characteristics.
Its purpose is not to make the decision for the user.
Its purpose is to reveal what the decision is quietly assuming.
Most AI helps defend the idea. Contrarian prosecutes it.
Try to break the decision before the decision breaks you.
Built With
- explainable
- explainable-ai
- fastapi
- gemini
- generative
- google-maps
- google-news
- google-scholar
- google-trends
- natural-language-processing
- plotly
- pydantic
- python
- serpapi
- sqlalchemy
- streamlit
Log in or sign up for Devpost to join the conversation.