KHAAN
How KHAAN works

The System

KHAAN is not a chatbot wrapped around a search box. It is a checked agent pipeline: retrieve first, draft in parallel, synthesize once, verify the claims against their sources, and stop at a human gate when an action cannot be undone.

This page describes the production workflow — not a roadmap.
The graph

Five nodes. One accountable answer.

Parallel work is useful only when its outputs converge through checks. KHAAN separates generation from verification so that fluency is never mistaken for evidence.

01

Retrieve

SI Search expands a question into several targeted searches. Results are merged, deduplicated, and passed through a relevance gate.

02

Draft

For SI Search, two available models draft independently from the same source set instead of editing one another.

03

Synthesize

One synthesizer resolves overlap and conflict, states uncertainty, and attaches citations to factual claims.

04

Verify

Key cited claim segments are aligned with the text of their own sources and graded strong, medium, or weak.

05

Publish or gate

Checked information can flow. Irreversible action cannot pass on model confidence alone.

In production

What runs every day

Daily Brief

Signals before noise

The morning brief collects English, Chinese, Russian, and Mongolian RSS/Atom feeds, removes duplicates, rejects stale items, and keeps only material relevant to the advance of superintelligence.

  • An editor model selects up to five consequential items and writes one short take on each.
  • If model selection is unavailable, the system falls back to the latest qualifying stories instead of inventing a ranking.
  • The result is cached for the site and sent to subscribers through the newsletter pipeline.
SI Search

Multi-model research, then source alignment

SI Search expands the query, retrieves a broader source set, reads the leading pages, and uses independent drafts before a single synthesis.

  • Out-of-range citation numbers are stripped mechanically before publication.
  • A separate verification pass compares the key cited claims with their source text; weakly supported claims are visibly marked.
  • If verification times out, the answer is labelled unverified rather than given invented grades.
  • Verified accounts receive a metered daily allowance; exhaustion falls back explicitly to standard search.
Standard Search

Fast answers with visible sources

The standard tier is optimized for speed: live retrieval, a relevance check, and a source-linked answer when relevant pages are found, without the heavier multi-model and claim-alignment passes reserved for SI Search.

Newsletter

A scheduled, bounded job

The daily email is not an agent improvising at send time. It uses the same brief builder, a stored subscriber list, and unsubscribe links. Standing jobs run only inside their pre-approved scope.

Evidence ladder

Confidence is not evidence.

The same ladder governs a search answer and an operational decision. Lower-grade evidence can inform a draft; it cannot silently authorize a conclusion or an irreversible step.

STRONG

A reproducible test, a machine-checkable result, a receipt, or source text that directly supports the exact claim.

MEDIUM

An independent route reaches the same answer, or the source supports the core claim while leaving a material detail indirect.

WEAK

Another model agrees, or the source is related to the topic but does not carry the specific claim. Weak support is labelled, not hidden.

NOISE

“Looks good,” unexplained confidence, or the absence of an error. Noise never counts as verification.

Human gates

Autonomy scales with reversibility.

The gate is determined by how hard a mistake would be to undo — not by how confident a model sounds.

Runs automatically

Read-only research, retrieval, drafting, classification, and scheduled jobs operating inside written scope and limits.

Runs, then reports

Reversible content and configuration work that can be inspected, compared with the previous state, and rolled back.

Stops for a human

New external commitments and actions that send, pay, delete, change production irreversibly, or create a legal obligation.

Failure handling

A failure is not finished when it is retried.

It is finished when the system has learned the condition that allowed it — and a later run is checked against that lesson.

ObserveKeep the failing output, request, or state. A summary is not a substitute for evidence.
ReproduceRun the failure again on the smallest case that still breaks.
ExplainName the mechanism, not just the symptom.
Write the ruleConvert the lesson into a standing instruction, parser rule, gate, or automated check.
Re-verifyTest the repaired path and inspect the live result. “Deployed” is not the same as “working.”

That is why a citation that merely exists is no longer enough on this site. The failure mode — a correct-looking reference attached to an unsupported sentence — became a product rule: align the claim with the source, grade the support, and expose the trace.

Operating limits

What the system will not do

No invented proof. Metrics, customers, cases, and citations are not created to make a page look complete.
No silent weak evidence. Unsupported or partly supported claims are marked, downgraded, or left unverified.
No shared-context theatre. When independent review matters, reviewers do not simply ratify the same draft in the same context.
No confidence-based gates. A fluent answer cannot approve its own irreversible action.