AI/LLM delivery — from requirements to acceptance

The problem

A working AI/LLM PoC is not the same as a system users can evaluate in their workflow. Ambiguous needs, authentication and operational constraints, answer provenance, and approval state must be resolved before a demo can become a deliverable system.

Scope

• Translate interview findings and environment constraints into technical requirements and acceptance criteria
• Own the application layer across frontend, API, RAG, data, infrastructure as code, and deployment
• Coordinate authentication, operations, and incident boundaries across customer, product, and infrastructure stakeholders
• Treat product integration and delivery to a customer verification environment as separate outcomes with separate acceptance criteria

Design and delivery practice

• Define user-visible answer provenance as a requirement before implementation
• Separate human input, AI drafts, retrieval results, and human approval so provisional information cannot cross into accepted knowledge
• Diagnose failures through controlled comparisons across UI, API, data, retrieval, generation, and cloud layers instead of relying on test status alone
• When using AI coding agents, separate implementation from review and retain acceptance criteria, test results, and visual evidence
• State unknowns and external dependencies explicitly rather than claiming outcomes outside the owned scope

What I actually did

• Interviewing and approval: AI interviews veteran staff and drafts findings; only findings approved by the site lead are written back to internal search, with version and approval state. Unapproved items stay out of search, and rejection reasons are recorded. In production, the AI’s first-pass classification (tacit vs. explicit knowledge) and the lead’s decision diverged for more than half of the approved items — evidence from my own data that final decisions had to go through human approval
• Fast feedback loops: Feedback from the site lead on the first day of real use was traced to root causes that night, and most of it was confirmed fixed in staging by the early morning. I also once shipped a behavior change outside the requested fixes just before a trial and caused confusion. Since then: fix wording and display immediately, change behavior only after looking at real data, and freeze behavior before customer trials
• Questioning the evaluation premise: Asked to tune answer quality, I compared, through the API, the data used for evaluation with the data retrieval actually referenced, and found they did not match. Prompt changes could not help in that state, so I stopped tuning and started by aligning the evaluation premise

Approach

• Break interview findings and environment constraints into technical requirements, acceptance criteria, and explicit unknowns before implementation
• Verify frontend, API, retrieval and generation, data, and cloud as separate layers to locate ownership boundaries and root causes
• Model answer provenance and human approval state so unapproved content cannot silently become accepted knowledge
• Separate AI-assisted research, implementation, review, and visual QA, using tests and change evidence as delivery gates
• Never edit production settings or prompts directly; confirm the effect in a separate environment first. For external storage connectors, keep scheduled runs in production disabled until credentials are handed over, then enable them in stages