Building a RAG assistant that answers only from its sources: the Hikam Shughro case study

Hikam Shughro is the organisation app we built for the Al-Manshur Shughro family association: finances, dues, study programmes, procurement, meetings, and live streaming for members of every age, on Android and iOS. One module gets asked about more than any other — Maktabah AI, an assistant that answers questions about the association’s reference texts.

This article explains how it works, why we chose each part, and what the same pattern can do for a business that runs on documents.

Why a normal chatbot was not an option

A general-purpose language model will always produce an answer. When it does not know, it produces a plausible one. For reference material, a confident answer attributed to a text that never said it is worse than no answer at all — it damages trust in both the app and the source.

So the requirements were strict from day one:

• Answer only from the reference texts the association provides — never from the model’s general knowledge.
• Show where every answer comes from, so a reader can open the source and check it.
• Say plainly when the texts do not cover a question, instead of guessing.

The architecture in four steps

1. Ingestion. Each text is split into passages along its natural structure (book, chapter, section). Every passage is turned into an embedding — a vector that captures its meaning — and stored in PostgreSQL with pgvector, together with its source reference.
2. Retrieval. When a member asks a question, the question is embedded the same way, and a cosine-similarity search returns the passages closest in meaning. Because it matches meaning rather than keywords, a question phrased differently from the text still finds the right passage.
3. Grounded answer. The language model receives only the retrieved passages, with instructions to answer from them alone and to cite them. It is not allowed to fill gaps from what it “knows”.
4. Decline when unsure. If no passage is relevant enough, the assistant says the references do not cover the question. A clear “not found” is a feature, not a failure.

Why pgvector instead of a separate vector database

The app already runs on PostgreSQL. Keeping embeddings in the same database means one system to back up, secure, and monitor; passages and their metadata live in the same transaction; and filters such as “only this book” are plain SQL. For a library of this size, a dedicated vector database would have added cost and moving parts without adding quality.

Citations are what make the answers trustworthy

Every passage carries its source reference from the moment it is ingested, so a citation always points to a real location in a real text. The answer is shown with its source underneath. Readers do not have to trust the model — they can verify it. In practice, this is what turns an AI feature from a novelty into something people rely on.

Testing before release

Before launch, the assistant was tested against an agreed list of questions. For each answer we checked two things: is the cited passage really the source, and does the answer stay within what the passage says? The same test set was used to tune the point at which the assistant declines instead of answering. This is the step most AI projects skip, and the one that matters most for trust.

Part of a larger app, not a bolted-on chatbot

Maktabah AI sits inside a Flutter app with ten modules. The same app transcribes meeting recordings with Whisper large-v3 and turns them into structured minutes, signs members in with a WhatsApp OTP instead of a password, and restricts each module by role. The AI is useful because it lives where members already are, next to the rest of their work.

Where this pattern fits in a business

Any organisation with answers buried in documents can use the same design:

• Customer support that answers from your policies and product manuals, with the source attached.
• Internal assistants over SOPs, HR handbooks, or compliance documents.
• Sales teams that need accurate answers from catalogues, price lists, and contracts.
• Any case where a wrong answer is expensive and “I could not find that” is acceptable.

What we took away

• Start from sources you trust. Retrieval quality is capped by the quality of the documents.
• Citations build trust faster than any accuracy claim.
• Declining beats guessing — design for it on purpose.
• Use the database you already run until you have a measured reason not to.

You can see the app on its website and in the portfolio. If you have documents your team or customers keep asking about, tell us about them — we will tell you honestly whether RAG, simple search, or plain automation is the better fit.