From Contract to Production: A 90-Day Delivery Timeline for an Enterprise RAG Knowledge System

Start with the conclusion, then walk back through the process.

This case spans 90 days from contract signing to production deployment, compliance approval, and daily team usage. Writing retrieval and generation logic consumed one-third of the time. The rest went into converting a working demo into something compliance would approve and the business would use.

The customer was a mid-sized financial holding's wealth management division. The problem was straightforward: wealth advisors answering client questions about product terms, fee structures, and regulatory applicability had to flip through fifteen or more PDFs, check with three departments, and spend forty minutes per question on average. They needed a knowledge system that cited clauses with source attribution and maintained an audit trail, not a chatbot.

Weeks 1 to 2: Data inventory, the first bottleneck

We did not start by writing code. The first step was mapping where the knowledge lived.

What we found was more complex than expected. More than 1,400 core product documents scattered across three systems: a legacy document management platform, a shared drive, and some only in senior advisors' inboxes. The version problem was worse. The same product spec existed in 2022, 2023, and 2024 versions, all in circulation, with no clear way to identify which was current.

We hit a problem here. We planned to OCR everything in bulk. After two days, we found that 15% of documents were scanned images with watermarks where OCR extraction misaligned numbers. In financial documents, a single digit error becomes a compliance incident. We stopped and built a version-tagging and manual review process first, treating 'which files are safe to use' as a controlled gate.

Data quality determines how smoothly the next 60 days proceed. This has no shortcuts.

Weeks 3 to 5: Retrieval pipeline and first working system

This phase covers familiar ground. We built chunking strategy, embeddings, a vector store, and a retrieval pipeline with re-ranking.

Financial documents need structural rather than fixed-length chunking. Cut a clause in half and the meaning breaks. Retrieved content loses context. We used structure-aware chunking instead, treating articles, subsections, and appendices as chunk boundaries. We attached metadata to each chunk: product category, document version, effective date. This allowed later filtering for current-version results only, resolving the version problem from week 1.

By week 5 end, we had a working question-and-answer system. Internal testing showed 78% retrieval accuracy. That seemed acceptable until we considered a financial context, where it fell short of production requirements.

Weeks 6 to 8: Accuracy, hallucination control, and compliance

This phase caused the most delays. RAG deployments typically stall here, not in initial engineering work.

Compliance set three requirements: every answer required clickable source citations. Uncertain system responses had to say 'not found' instead of guessing. All Q&A needed a full audit trail.

We addressed hallucinations with three mechanisms. First, prompt-level constraints limited the model to retrieved content and refused to answer without sources. Second, a consistency layer compared generated answers against source passages to verify they appeared in citations. Third, we created a whitelist for high-risk categories (fees, guaranteed returns, regulatory applicability) requiring human review.

These metrics show the impact:

Response time increased slightly. In financial services, that tradeoff made sense: a slower system that could be audited and produced no hallucinations outweighed the speed cost.

Weeks 9 to 11: Compliance approval and pilot

Week 9, we sent the system for compliance and security review. We prepared data flow diagrams, retention policies, and a list of questions the model would refuse. With hallucination at 0.3% and citation accuracy at 99.4%, review took two rounds before approval. The earlier work showed its value.

We recruited 12 wealth advisors for a two-week pilot. First-week usage was 12%, not because the system failed but because staff defaulted to asking experienced colleagues instead of using a new tool. Our engineers sat on the trading floor, observing how questions were asked and where users struggled. They added preset queries for common products, keyboard shortcuts, and one-click citation copying. Second-week usage reached 41%.

Weeks 12 to 13: Production launch and handoff

On day 90, the system went live in production for all 140 wealth advisors. A month after launch, daily active usage stabilized at 63%, and average time per question fell from 40 minutes to 6 minutes.

More important than these metrics was whether the system would function after our team left. The final two weeks focused on handoff. We documented chunking strategy, prompt rules, the refusal whitelist, and the process for adding new documents to the RAG, all in a playbook the customer's internal team could run independently. We walked them through two cycles of document onboarding.

In retrospect, 25 of the 90 days went into retrieving and generating logic. The remainder went into data preparation, compliance approval, and adoption. A working demo is not the same as an adopted system. Our engineers remained through launch and handoff because RAG success requires more than code. They stayed until the system was being used.