HANAI

Making The Web Make Sense

Comment

HANAI - Hybrid Artificially Natured Algorithmic Intelligence

The Web, Structured.

Note: HANAI is a concept-stage project. The core engine and API are functional - but full-scale deployment, a production entity graph, real-time trust learning, and own indexing are still ahead. Funding and infrastructure are the current bottlenecks. What exists today is a working proof of concept for an idea worth building.

Inspiration

Every time you search the web, you get a wall of blue links. No structure. No hierarchy. No indication of whether what you are looking at is a verified institution or a scam sitting one typo away from a real website.

I kept asking: why does the internet feel like a dump of unorganised files? Every computer has a folder system. File managers give structure to chaos. Why can the web not work the same way?

The deeper problem is that trust is invisible on the web. Search engines rank by relevance - not by safety, not by structure. You cannot tell at a glance whether a result is established, unknown, or actively trying to deceive you. You just guess and click.

That gap is what HANAI is built to close. Instead of returning raw URLs, every search result gets an identity (@entity), a location in a structured folder (@amazon/india/fashion), and a trust score (Verified - 0.93). The web, treated like a navigable file system.

How I Built It

The Pipeline

HANAI is not a search engine - it has no index of its own yet. It sits on top of existing search APIs (Serper for Google results, Tavily for AI-powered search) and transforms what they return. A query like buy running shoes does not return a wall of links. It returns:

@amazon    / india / fashion   - Verified   (0.93)
@flipkart  / india / fashion   - Verified   (0.88)
@myntra    / india / fashion   - Safe       (0.76)
@unknown   / global / shopping - Unverified (0.51)

Every result goes through eight steps.

Step 1 - Intent Classification

Before anything is fetched, HANAI classifies the query. The classifier scores the input against four intent types using keyword matching and regex patterns:

$$\text{score}(\text{intent}) = \sum_{k \in \text{keywords}} 0.3 \cdot \mathbf{1}[k \in q] + \sum_{p \in \text{patterns}} (0.5 + \delta) \cdot \mathbf{1}[p \text{ matches } q]$$

where $\delta$ is a per-intent confidence boost. The winner from transactional, navigational, informational, and local shapes everything that follows - folder paths, ranking weights, result ordering.

Step 2 - Parallel Fetch

The query goes to Serper and Tavily simultaneously using Promise.all(). Results from both are merged and deduplicated by URL. This gives up to 50+ raw results to process.

Step 3 - Entity Resolution

Each URL is mapped to an @entity. Known entities (Amazon, Wikipedia, YouTube, etc.) are matched against a registry with a trust baseline. Multiple results pointing to the same domain are grouped together - this consensus becomes a trust signal. Confidence increases with each agreeing source:

confidence_n = min(confidence_{n-1} + 0.02, 1.0)

Step 4 - Folder Path Building

Each resolved entity gets a path with up to four levels:

@entity / region / service / category

Region is detected from the domain TLD and known regional patterns. Service comes from the entity registry (shopping, video, docs). Category is inferred from the URL path and query context.

Step 5 - Trust Calculation

Trust is the core of HANAI. Six signals are collected per entity and combined with a weighted sum:

$$T = \sum_{i} w_i \cdot s_i$$

Signal Weight Description
Entity reputation 0.30 Is this a known, registered entity?
Consensus 0.25 How many sources agree on this entity?
Security 0.20 Is the connection HTTPS?
TLD risk 0.10 Is the domain extension trustworthy?
Suspicious pattern 0.10 Does the domain look like typosquatting?
Position 0.05 What is the average search result position?

The score T∈[0,1] maps to a label:

$$\text{label}(T) = \begin{cases} \text{Verified} & T \geq 0.88 \ \text{Safe} & T \geq 0.70 \ \text{Unverified} & T \geq 0.50 \ \text{Suspicious} & T \geq 0.30 \ \text{Dangerous} & T < 0.30 \end{cases}$$ }

When confidence in the score is low, HANAI shows an uncertainty range instead of a fixed label - for example Safe ↔ Verified - to avoid false precision. Confidence is calculated from how much the signals agree with each other:

$$C = C_{\text{source}} \cdot \left(1 - \frac{\sqrt{\text{Var}(\mathbf{s})}}{2}\right), \quad C_{\text{source}} = \min(0.5 + 0.1 \cdot n_{\text{sources}},\ 0.95)$$

More sources agreeing plus lower signal variance equals higher confidence.

Step 6 - Ranking

Results are ranked by a composite score:

$$R = 0.40 \cdot T + 0.25 \cdot M_{\text{intent}} + 0.20 \cdot E_{\text{relevance}} + 0.10 \cdot N_{\text{sources}} + 0.05 \cdot P_{\text{position}}$$

Trust is the strongest signal at 40% by design. A highly relevant but untrustworthy result should not outrank a verified source. Hard rules are applied after scoring: Dangerous results are pushed to the bottom regardless of score.

Step 7 - Behavioural Personalisation

Each user builds a local profile. Click patterns are tracked per entity. Frequently clicked entities receive a small ranking boost of up to 12%:

$$R_{\text{final}} = \min!\left(1,\ R + \frac{\text{clicks}_e}{\max_e(\text{clicks})} \cdot 0.12\right)$$

No user accounts needed - the profile is stored locally as a JSON file. When Groq is configured, the behaviour engine generates a natural language summary of the user's interest areas, search style, and a risk alert if they frequently click suspicious sites.

Step 8 - AI Enrichment

If a Groq API key is present, results are passed through Llama 3.3 70B. The model scores each result for relevance to the query, generates a short summary, flags red flags, and can override the algorithmic trust label when it detects something the signals missed. This runs asynchronously and adds AI-sourced metadata on top of the computed scores.

The API

The API is a standard Express REST server on Node.js. The main endpoint is POST /search which runs the full pipeline. Secondary endpoints cover entity lookup (GET /entity/:id), trust score retrieval by domain (GET /trust/:entity), and key management via Firebase authentication.

Rate limiting is applied at the IP level before API key validation. The key system supports configurable daily query limits, which allows the API to be shared externally with controlled usage.

JavaScript SDK:

const HANAI = require('./sdk/hanai');
const client = new HANAI({ baseURL: 'https://hanai-api.onrender.com' });
const results = await client.search('buy shoes', 'india');

Python SDK:

from sdk.hanai import HANAI
client = HANAI(base_url='https://hanai-api.onrender.com')
results = client.search('buy shoes', region='india')

What I Learned

  • Representing uncertainty honestly is harder than picking a label. False precision is worse than showing a range.
  • Intent classification changes everything downstream. “Python” navigational vs. informational produces very different results.
  • Every weight in the trust formula is a design statement. Entity reputation 30%, search position 5% – reflects reasoning, not arbitrary tuning.
  • Parallel API deduplication needs careful merging. Different sources return overlapping results in different formats.
  • Groq as a free AI layer is underrated. Llama 3.3 70B adds a second trust layer that catches subtle signals.

Challenges

  • Manual entity registry. Works for demo but needs live graph automation for scale.
  • Trust scoring without ground truth. Signals are reasoned but lack labeled datasets.
  • Funding and scale. Free-tier APIs limit query volume; full indexing and real-time trust require resources.

Demo

Demo Video of a Browser Built On HANAI: https://youtu.be/l-zZN6SgMQ0

Built With

Share this project:

Updates

Submission history