Begin with the decision, not the model.
A useful brief starts with the work: finding an approved procedure, comparing documents, or drafting an answer for review. Define the users, the source material, and the action that follows an answer. A narrower first use case makes it easier to evaluate whether the system is useful.
Retrieval and training solve different problems.
An assistant may retrieve information from approved documents without changing the underlying model. Fine-tuning is a separate decision. The architecture should follow the required behaviour, evaluation results, hosting constraints, and operating cost rather than assuming that every business needs its own trained model.
Design the permission boundary first.
Identify who may read each source. The retrieval layer should respect that boundary, including when documents change or access is revoked. Source references help a reviewer inspect an answer; they do not by themselves establish that the answer is correct.
Make uncertainty part of the experience.
Include unanswered questions, conflicting sources, and out-of-scope requests in evaluation. Define when the assistant should ask for clarification, decline to answer, or route a question to a person. Test the entire workflow, including the action after the answer.
What a first scoping session should produce.
An agreed use case, an inventory of approved sources, an access model, an evaluation set, and a proposed deployment boundary. Hosting and provider terms should be checked for the particular configuration before implementation.
Bring your workflow, your constraints, and the outcome you want to achieve.