Skip to content
Back to home
In proposal2026· Institutional client · GovTech

Tuki

A civic assistant that only answers what the city actually publishes

The problem

Information about municipal procedures exists, but it's scattered across pages, PDFs and departments. Citizens don't know what they need, where to file it or what it costs, and end up going in person to ask.

A generic chatbot makes it worse: it confidently answers with information that may be wrong. In a public service, an invented answer about a requirement is not a minor error.

The decision that defines the system

Anchor every answer to an official document.

Tuki doesn't answer from the model's general knowledge. It retrieves the relevant fragments from the corpus the city loads and controls, and limits itself to restating that information in plain language.

The consequence is twofold: what Tuki says is what the city publishes, and every answer can be traced back to its source document. If a procedure isn't in the corpus, it says so and refers you to the right channel instead of improvising.

How it works

Questionfrom the citizenEmbedding768 dimensionsSearchpgvector · cosineFragment found?in the corpusyesnoGemini restatesciting the sourcedocumentRefers onwardright channelno improvisingQuestionfrom the citizenEmbedding768 dimensionsSearchpgvector · cosineFragment found?in the corpusyesnoGemini restatesciting the sourcedocumentRefers onwardright channelno improvising
The accent marks the only point where the model steps in. Both exits are the same size on purpose: knowing when not to answer is a design decision, not an edge case.

A corpus of 133 procedures —every one the city publishes— scraped from the official site, chunked and embedded with gemini-embedding-001 at 768 dimensions into Supabase with pgvector.

Retrieval uses cosine distance over an ivfflat index rebuilt after load. If relevant fragments exist, Gemini restates that information citing the source document. If they don't, the system says so and refers the query to the right channel.

Open any screenshot to view it full size

Home screen of the Tuki web prototype: the assistant introduces itself as an advisor for municipal procedures, with the query field and three promises alongside: 100% online, instant answers and official information.
Frequent queries in the prototype: six sample questions, from opening a food truck to getting a first driver's licence, and a footer note that Tuki only answers with the official information loaded.
The official-sources block at the foot of an answer: four corpus documents with their category and the date they were verified. That is what every answer resolves to.

What's built

It started at a public-sector innovation hackathon in August 2026. Today it's at the formal proposal stage with the client, and all three pieces run.

  1. 01The hackathon web prototype, deployed and public.
  2. 02The MVP demo presented to the client, deployed with the web integration.
  3. 03A React Native (Expo) mobile app with the assistant integrated, running on device and used in institutional presentations.

How the work was organized

Technical lead of a five-person team organized in two departments: engineering and product/communications. I defined the architecture, the role assignment and the delivery structure over a five-phase, three-month plan.

I'm the single point of technical contact with the client: scope, effort estimation, data-access requirements and security commitments.

Status

Formal proposal under evaluation by the client. What's built and deployed is what's described here: the web prototype, the MVP demo and the mobile app running on device.

StackNext.js · TypeScript · React Native (Expo) · Supabase (PostgreSQL + pgvector) · Google Gemini API · Vercel