---
title: "Comment by Ahmet Özel on \"Beyond a PoC #1: Your RAG demo works. But is it production-ready ?\" | Hashnode"
description: "The profile precedence chain is useful, but startup validation only covers values already known at startup. Request-level overrides arrive later and can still p"
url: "https://hashnode.com/posts/beyond-a-poc-1-your-rag-demo-works-but-is-it-production-ready/6ae601272d3af9cb1bd7a4b7/comment/6ae79098ea6bf46f2b927b14"
---

[Discussion](https://hashnode.com/posts/beyond-a-poc-1-your-rag-demo-works-but-is-it-production-ready/6ae601272d3af9cb1bd7a4b7)

Comment [Beyond a PoC #1: Your RAG demo works. But is it production-ready ?](https://hashnode.com/posts/beyond-a-poc-1-your-rag-demo-works-but-is-it-production-ready/6ae601272d3af9cb1bd7a4b7)

[Ahmet Özel](https://hashnode.com/@ahmetozel)

[Nov 1](https://hashnode.com/posts/beyond-a-poc-1-your-rag-demo-works-but-is-it-production-ready/6ae601272d3af9cb1bd7a4b7/comment/6ae79098ea6bf46f2b927b14)

The profile precedence chain is useful, but startup validation only covers values already known at startup. Request-level overrides arrive later and can still produce an invalid or unexpectedly expensive effective profile even if every named YAML profile is valid.

I would validate the fully resolved configuration per request, including bounds on top\_k, candidate depth, and context budget, while keeping authorization constraints outside the override mechanism. Recording that resolved profile with the retrieval trace would also let you reproduce a result without guessing which defaults and overrides were active when it was served.

[Mete Mertkan](https://hashnode.com/@metemertkan)

[Nov 2](https://hashnode.com/posts/beyond-a-poc-1-your-rag-demo-works-but-is-it-production-ready/6ae601272d3af9cb1bd7a4b7/comment/6ae79098ea6bf46f2b927b14#reply-6ae848488ebd91f5371a6d85)

Thanks for the input, this is the first episode of the series where I will deep dive into different parts of the project. Request-level validation and reproducibility are definitely important pieces of production-ready retrieval. Where I will touch upon on the following episodes.

In the next episode, I'm going to focus on document ingestion — another critical part of the RAG pipeline. I'll explore how to make ingestion more reliable, handle different document structures, and deal with failures without leaving the knowledge base in an inconsistent state.

There's a lot more to RAG than retrieval! More coming soon. 🚀

[Ahmet Özel](https://hashnode.com/@ahmetozel)

[6d ago](https://hashnode.com/posts/beyond-a-poc-1-your-rag-demo-works-but-is-it-production-ready/6ae601272d3af9cb1bd7a4b7/comment/6ae79098ea6bf46f2b927b14#reply-6aedf78a497f505e0d6f2d58)

The ingestion episode gives that reproducibility point a concrete boundary: a retrieval trace should identify which ingestion revision made its documents eligible to search. A resolved query profile alone cannot reproduce an answer if the indexed collection changed underneath it.

For a failed ingestion, I would test that the previously published revision remains searchable and that the partially built replacement is never exposed as complete. The next successful publish can then name a specific revision rather than merely reporting that the job finished.