Define the task and its limits
A useful pilot has a user, a task, and a boundary. An internal assistant that helps operations staff find an approved procedure is a clearer starting point than an assistant that can answer anything about the business.
List the sources it may use, the information it must not expose, and the actions it cannot take. Finding an answer and executing a change are different responsibilities. Begin with the smallest useful scope and make any proposed expansion explicit.
In the synthetic example used here, the assistant can answer questions from two short operating notes. It cannot search employee records, approve a release, or invent a policy for a topic that the notes do not cover. The browser demonstration is scripted; it is not connected to an AI model.
Build a test set that includes non-answers
Include straightforward questions, ambiguous wording, missing evidence, conflicting versions, and attempts to cross an access boundary. Give each case an expected behavior that a reviewer can evaluate. "Sounds convincing" is not an acceptance criterion.
For a release question, a useful response might identify the required checks and point to the source paragraph. For a question about next year's travel budget, the expected behavior may be to say the available sources do not answer it. Refusing to invent an unsupported answer is a successful result for that case.
Choose reviewers who understand the task and can explain the difference between an incomplete response and an unsafe one. Record the reason for disagreement, then revise the definition or the test rather than hiding the disagreement in an average score.
Keep permission checks separate from persuasion
Treat access as an application responsibility, not something the model can decide from a prompt. The retrieval and integration design should only expose information permitted for the requesting user and action.
Include adversarial examples in the evaluation: a request to ignore the rules, a document containing instructions that conflict with the task, or a question about another team's restricted record. The expected response and the enforcement boundary should be clear before launch.
Source references also need review. A citation is useful only when the user is permitted to open the source and the cited content actually supports the answer. A link added to an unsupported claim does not make the claim reliable.
Evaluate the full workflow, not only the answer
Record answer quality, source support, missing-evidence behavior, permission handling, response time, and cost against the agreed cases. Keep useful failures visible. A slow response, an unavailable source, and a denied permission require different user messages.
A pilot should show what happens when a dependency fails. Does the user get a clear message? Can they return to the source manually? Is a partially completed action distinguishable from a completed one? Avoid automatic retries where they could repeat an external action.
Use the initial measurements as a baseline for a scoped decision, not as proof that the system is ready for every question or audience. Thresholds should reflect the consequences of an error and the supervision available.
Make the release decision reviewable
The handover should identify the source owner, evaluation owner, integration owner, and person who can stop or change the workflow. Include the allowed use, known limitations, unresolved cases, and the conditions that would require a new review.
Review the test set when sources, models, prompts, permissions, or integrations change. A previously useful output is not a permanent guarantee. Keep a route for users to report an unsupported answer and for an owner to investigate it.
The downloadable sheet is a starting structure for those conversations. It does not certify safety, security, or compliance. Begin with a bounded task, test the difficult cases, and expand only when the evidence supports the next step.
PUT THE IDEA TO WORK
A small evaluation pack with clear expected behavior.
These cases are examples for a source-based knowledge assistant. Replace the sources and expected outcomes with approved material.
| Test case | Expected behavior | Evidence to retain |
|---|---|---|
| Answer exists | Answer the question and identify the supporting source | Reviewer judgment plus the exact source passage |
| Source does not answer | State the gap and offer a route to the owner | No invented policy or unsupported citation |
| Restricted information | Do not retrieve or reveal the restricted information | Permission-boundary test result |
| Dependency unavailable | Explain that the task could not be completed | A distinguishable failure, not a success message |
An original working perspective from DataNxt Analytics. Examples are illustrative, not customer results, independent research, or a certification of security or compliance.