Name the user and the task.
“Add AI” is not a specification. “Help staff answer a policy question using the current approved document” identifies a user, a source and a useful action.
Check the sources and alternatives.
Identify who owns the information, how it changes and how access is granted. Compare the current application’s features and available products before commissioning a new component.
Write examples of success and failure.
Include a question with a known answer, an ambiguous request, a missing source and a user without access. Agree what the application should do in each case. Generated text alone is not evidence that the workflow works.
Account for operating the feature.
Who reviews an uncertain answer? Who updates the sources? Who investigates a failed connection? Make recurring model, hosting and support costs visible before release.
Make the first commitment reviewable.
A technical discovery should produce an assessment, implementation brief, acceptance plan and priced proposal. Proceed when the task, access, owner and scope are clear. Resolve missing prerequisites before committing to a build.
Use a real task in the first conversation.
Describe the application, one example of the work and the expected result. Share a general description initially; private records and source access can follow an agreed discovery process.
Discuss your applicationAnvayric engineering guidance based on the implementation patterns described in the IMFIT case study. This checklist is not a market forecast or a guarantee of commercial results.