Velicham, in the open.
Most assistants are a black box. Velicham is the opposite: every retrieval source, every model, every grounding step is documented here so the system can be audited, not just trusted. This page is the architectural reference of record.
Six stages, all server-side
Provider keys never reach the browser. Every call is made from a TanStack server function.
- 01 · Retrieval
The user's question is embedded against the local docs corpus (src/content/vinmin-docs). Top passages are returned with their canonical paths.
- 02 · Web grounding
If the question reaches outside the corpus, a Tavily search is performed and Firecrawl pulls the cleanest extractable passages from the result URLs.
- 03 · Model routing
A Gemini 2.5 Flash router decides whether to answer locally, escalate to a higher tier, or call GPT-5 for synthesis. Tamil-first questions stay on Tamil-strong models.
- 04 · Synthesis with citations
The answering model is given the corpus passages and web extracts as context. Every load-bearing claim is required to surface its source path or URL.
- 05 · Logging and continuity
The question, language, and era day are logged. High-value questions can be promoted by a Keeper into a permanent /velicham/$slug thread with the reviewed answer.
- 06 · Human review for publication
Nothing is published from the assistant alone. A Keeper reviews answers before they become part of the public Velicham archive.
What Velicham reads from
- Local corpussrc/content/vinmin-docs · primary truth
- Citation layertlte-cite:NNNN · stable IDs for every load-bearing claim
- Web groundingTavily search + Firecrawl extraction · only when the corpus is silent
- Model gatewayManaged AI Gateway · Gemini 2.5 Flash router, GPT-5 synthesiser, fallback Gemini Pro
- Witness archivewitness_submissions · community evidence, Keeper-reviewed
- Velicham threadsvelicham_questions_log · public Q&A, era-stamped
What Velicham will and will not do
Answers respect the language of the question. Tamil questions get Tamil answers — not translations of an English answer.
Provider keys, prompts, and model routing live on the server. The client never sees them.
Claims that cannot be sourced are softened or refused. Refusal is preferred to confident nonsense.
Public threads carry a review delay. Speed is not the moat — accuracy and provenance are.
Velicham informs and assists. It does not act on the archive. Every published change passes through a Keeper.
Session memory is local-only (sessionStorage). Nothing about a visitor is persisted server-side without an explicit Witness submission.
The archive is the citation. The architecture is the proof.
When a journalist or researcher cites a TLTE position, they should be able to follow the claim back to its passage in the corpus, the Witness record that corroborates it, and the model pipeline that surfaced it. This page makes that chain inspectable.
Other platforms ask the public to trust their AI. We ask the public to read it.
Operated by TLTE C.I.C. · United Kingdom
This document is the canonical reference for the Velicham assistant architecture as of the current era. Material changes are logged in archive_canon_updates.