Defining the Need in AI

An AI application starts with a clear account of the job it is expected to do. Before choosing a model, the need, existing workflow and expected output are defined. This provides a basis for setting the application’s scope and evaluating technical options against the same goal.

Setting the scope

Defining the need involves understanding the conditions in which a task takes place. The user’s goal, existing tools and practical difficulties are considered together.

For example, summarising a document and classifying a record call for different outputs. Describing those outputs clearly also makes the basis for evaluating the application more concrete.

Understanding the data

The source and content of the available data are identified. How closely the examples represent real usage conditions is one of the questions to examine during development.

Missing, inconsistent or outdated records can make evaluation more difficult. Data preparation includes examining the quality of these records and their suitability for the intended use.

Access, storage and usage boundaries also form part of the plan. The information passed to the application and the people allowed to use it are clearly defined.

Defining its place in the system

An AI component often works within a larger application. Its inputs, the point at which its output is used and the way information reaches other systems are planned together.

Decisions can be shared across fixed rules, user approval and existing software functions. Defining this workflow makes the role and responsibility of each part easier to understand.

Evaluating the result

Output is assessed against the task the application is meant to perform. Format, accuracy, consistency, response time and resource use may carry different weight in that assessment.

One successful example does not cover every usage condition. Alongside typical inputs, evaluation considers missing information, ambiguous requests and unexpected content.

Keeping a record of evaluation examples and acceptance criteria makes changes easier to compare. The same examples can be checked again after changes to the model, instructions or data flow.

Planning the user’s role

Where users review an output, how they correct it and when they approve it are part of the design. These steps should have a clear place in the application.

Passing an output directly into another operation carries different responsibilities from reviewing it first. The workflow is planned with this distinction in mind.

Starting with a focused trial

A trial built around a limited use case makes technical assumptions easier to examine. A basic workflow is established, and the application is observed through its inputs, outputs and review points.

The findings help define the next development steps. The scope can be expanded as the behaviour of the existing workflow becomes clearer and further needs are understood.

Considering operating conditions

How the application will be monitored in use also needs attention. Expected behaviour is defined for connection problems, empty responses, changing inputs and resource limits.

Recording the following points in a short, shared document can help the people developing different parts of the application work from the same understanding.

Input source
Expected output
Review point
Response to errors

Keeping decisions visible

Documenting the reasoning behind technical choices supports continuity in development. The record explains which option was chosen for which need and which questions remain open.

These records provide a reference when someone joins the project or an existing approach is reconsidered. Information about how the application works is also part of maintaining it.

New questions may emerge during development. The original scope and recorded decisions help show what needs to be revisited as the application changes.