FDE, Part 2: Discover AI Requirements and Define Pilot Acceptance

“We need an AI assistant” isn’t enough to start development. It could mean document lookup, ticket organization or report generation, each with different data, quality and integration requirements. An FDE first identifies the actual work, then chooses an implementation.

Observe how one task is completed

Choose a recent real task and ask its user to explain the input, steps, decision criteria and result. Record time spent searching, waiting for replies, entering duplicate information and reworking output. Policy documents help, but check how work actually happens.

Frequent switching between support systems may signal scattered information; repeatedly asking colleagues may indicate missing applicability conditions. These need different remedies. Unified search may help the first; the second requires organizing documentation and business rules first.

Include the owner, users and maintainers. Owners know goals, staff know operational difficulties, data owners know sources and permissions, and maintainers know API constraints. Together, these form a workable scope.

Confirm that data supports the request

Having many documents doesn’t make them ready to use. Check source, format, version, update frequency and access scope. Sample scanned pages and tables to verify parsing.

In electric-vehicle work, a technical detail may apply only to a specific model, configuration or software version. A historical ticket’s recommendation isn’t necessarily a general rule. Appropriate specialists should identify authoritative sources and conclusions requiring review.

These issues define what the system can handle. If essential data is missing, narrow the pilot or prepare the data. Don’t promise results first and expect development to fill every gap.

Choose a pilot that is easy to verify

Compare task frequency, business cost, data readiness, verifiability and the impact of errors. Internal summaries and assisted lookup are often easy to compare with sources. Important professional conclusions need stricter review.

Once selected, establish the old workflow’s baseline: full processing time, corrections and rework. Compare the new system using the same measures, rather than counting generation speed while ignoring verification effort.

Turn goals into observable behavior

“Accurate answers” needs detail. A knowledge assistant might have these acceptance conditions:

1. Ask for required information when key conditions are missing.
2. Retrieve material within the user’s permissions and the source’s applicability.
3. Cite sources that support the conclusion.
4. Explain missing evidence or API failures and hand over to a human.

Use samples for every condition, covering routine tasks, difficult cases and questions the system shouldn’t answer. Pass necessary access and quality checks before discussing efficiency gains.

Finally, document scope, sources, acceptance methods and owners in a short pilot brief. Assign who supplies documents, confirms criteria and approves API access. Discovery should leave the team knowing what to do next and how to recognize completion.