Readiness is not a generic maturity score or a certificate. It describes whether a bounded use case can be tested under its real conditions. A sound result may be to start smaller, resolve a dependency first, or not build at all.
Put the workflow before the model
Describe the work as it happens now: who provides which information, who makes the decision, and what follows. Mark waiting, repeated review and the points where an error has consequences. Only then is it possible to judge whether a model could make a useful contribution.
A defensible question names the desired change without prescribing the solution. “Support research for process X with traceable sources” is more testable than “introduce an assistant”.
Review data and access together
A source that is technically reachable is not automatically permitted or useful. Ownership, currency, structure, language, retention and the current user’s permissions all matter.
For knowledge systems, the response to missing or conflicting sources also needs to be explicit. A system that answers confidently on an uncertain basis does not solve a knowledge problem. It relocates it.
Keep accountability visible
Who may use the output? Who reviews edge cases? Which action may the system trigger itself? Who makes the decision during an incident?
These questions belong inside the system boundary, not only in a later policy. Tools that can write, personal data and consequential decisions require an explicit identity and an appropriate approval point for each action.
Define acceptance before the prototype
A small evaluation set should cover ordinary, critical, ambiguous and deliberately difficult cases. Criteria are agreed before results are compared. Depending on the task, they may include source support, completeness, numerical consistency, permissions, format or a correct refusal to answer.
Not every quality can be scored automatically. Where professional judgement is required, identify the reviewer and decide how disagreement will be handled. A persuasive demonstration does not replace that decision.
Include operations and fallback
Readiness also covers the period after a successful first test. Model and prompt versions, relevant sources, validation results, cost and failure need an appropriate level of traceability. There must be a safe fallback and a person responsible for changes.
The smallest useful next step is therefore not an isolated chat. It is a small, complete slice of the real workflow: a real source, real permissions, a testable output and a way back.
Record the decision
The result should capture four things: the bounded task, the main assumptions, open dependencies and explicit acceptance criteria. That supports a reasoned choice: build, narrow, resolve a prerequisite first, or stop.
The services show how that decision can become a useful system slice and a clean handover.
Want to assess a specific workflow?
Get in touch