Problem-Definition Method

Purpose

A repeatable method for defining a problem before an AI or machine learning system is designed. It confirms the problem is understood, that machine learning is the right solution, and that risks and costs have been screened. Its outputs are the Phase 1 inputs AI-013 requires.

Scope

Applies to any proposed AI or machine learning system governed by the AI Management System. Use it for new systems and for systems where a solution has already been selected and must be validated.

Lifecycle Position

This procedure describes how to carry out AI-013 Phase 1. It produces the AI Problem Definition document and inputs to the impact assessment (AI-009), the risk assessment (AI-008), the feasibility study, and the System Design Specification. Three rules govern how it fits the lifecycle:

• Altitude. Problem-definition outputs are high level and provisional. They bound scope and confirm feasibility. Binding functional detail (field-level requirements, accuracy units and thresholds, edge-case handling) belongs in the System Design Specification.
• Handoff. Steps 5 and 6 are preliminary screening. They produce inputs to the formal risk assessment (AI-008) and impact assessment (AI-009). The problem definition links to those documents and does not repeat their content. The risk register is the single source of truth for risks.
• Definition of done. Phase 1 is complete when the AIMS objective mapping is recorded, the impact and risk assessments are linked, the compliance checklist passes, and management approval is recorded (Step 7).

Principle

Define the problem before selecting a solution. Work the steps in order, because each answer informs the next. Do the cheap, low-risk checks first; above all, check whether machine learning is needed at all before making expensive commitments. A finding at any step may send you back to an earlier one.

Step Summary

Procedure

Step 0: Determine the starting point

Purpose: Establish whether the solution is already decided or still open.

Actions:

1. Determine whether a platform, tool, or supplier has already been selected. If it has, the task is to confirm it fits the problem and record the reasoning. If it has not, derive the solution from the problem.
2. List every constraint already fixed. Mark each as inherited (decided elsewhere) or derived (concluded here).

Output: A statement of whether the solution is predetermined, and the list of inherited decisions.

Done when: Inherited decisions are separated from conclusions reached here.

Caution: If the solution is already decided, stay prepared to reach a different conclusion at Step 3. Otherwise the analysis is not genuine.

Step 1: Define the problem, its value, and its AIMS alignment

Purpose: Establish why the problem exists, why it is worth solving, and which AIMS objectives it serves.

Actions:

1. Ask why the problem exists, repeatedly, until you reach a cause you can act on. The cause is often a past decision that may be reversible without machine learning. A problem usually has several causes; examine each.
2. State why the problem is worth solving, and why now, in the sponsor’s own terms: a growth target, a cost reduction, reduced staffing, a service-level commitment. This defines success.
3. Map the initiative to the AIMS objectives (AI-002) it supports and state how it advances each.
4. Remove every technology term from the problem statement. What remains should still describe the problem to a non-specialist. If nothing remains, the statement describes a solution.

Output: A plain-language problem statement; the underlying causes; the business value in the sponsor’s terms; the AIMS objective mapping.

Done when: The statement contains no technology terms, the causes are actionable, and the AIMS mapping is recorded.

Caution: Do not steer the questioning toward a conclusion already chosen.

Step 2: Describe the current situation and identify stakeholders

Purpose: Establish what happens today and who is affected.

Actions:

1. Write a summary senior leadership would understand without technical terms, then add detail. Examine each significant word in the problem statement.
2. Consult every type of stakeholder. Senior staff give the strategic reason; the people who do the work daily describe how it actually happens, including informal methods. These two groups are the most often overlooked.
3. Where two parts of the problem differ in difficulty, risk, or measure of success, decide deliberately whether they are one problem or several.

Output: A current-situation description; stakeholders consulted and not yet consulted; open questions and who can answer them. Problem-level and boundary-level questions are resolved within the problem definition; rule-level and scenario-level questions move to the scenario inventory (see Relationship to Requirements Engineering).

Done when: Every stakeholder type has been consulted, or any gap is recorded as a known risk.

Step 3: Identify the simplest viable solution

Purpose: Confirm whether machine learning is required, and for which parts.

Actions:

1. Divide the problem into its separate capabilities.
2. For each capability, select the simplest option that will work, in order of preference: remove the cause; use fixed rules; use or improve an existing tool or third-party product; build a machine learning system.
3. Machine learning is the most expensive option to build, the hardest to inspect, and the least predictable. Assign it only to capabilities the simpler options cannot address.

Output: A table of capabilities and selected solutions; the machine-learning scope; each rejected option with the reason.

Done when: Machine learning is assigned only where simpler options fail, and rejected options are documented.

Caution: This output is a scope boundary. Solution creep most often starts here; keep it at outcome level.

Step 4: Frame the system’s task

Purpose: Frame what the machine learning system must do, only enough to confirm it is solvable and to bound the design specification.

Actions:

1. For each capability assigned to machine learning, state the general input and the required output, at outcome level.
2. Describe how a skilled person performs the same task. This sets a baseline and shows whether the task is solvable.
3. Establish the basis on which accuracy will be measured: comparison of the system’s output to the output a person approves.

Output: A provisional task framing; the human baseline; the basis of the accuracy measure.

Done when: The task is solvable in principle and the success criteria have a meaningful basis.

Caution: The precise input-output contract, the accuracy unit (per field, document, or order), and the thresholds belong in the System Design Specification. Stating them here creates two competing specifications.

Step 5: Screen constraints and risks

Purpose: Surface the limits the system must operate within and the harm it could cause, as inputs to the formal assessments.

Actions:

1. State what the system must protect against in concrete terms: financial loss, operational error, customer impact, legal or regulatory exposure, mishandling of personal data. Note where exposure is low.
2. Identify firm limits early. The most common is data: whether enough labeled historical examples exist to test the system, and how varied they are. Also check connected-system limits (rate limits, posting frequency) and any speed or volume requirements.
3. For each safeguard, confirm it works in practice and state what makes it effective.

Output: Screening inputs recorded in the impact assessment (AI-009) and the risk assessment (AI-008), with links from the problem definition. Keep one risk list, in the assessment of record.

Done when: Risks are stated as specific harms, the data and connected-system limits are known, and the impact and risk assessments are opened or linked.

Step 6: Screen the cost of errors

Purpose: Establish how serious errors are and how reliable the system must be.

Actions:

1. Decide whether the system must never produce an incorrect result, or whether occasional errors are acceptable because they are caught (for example, a person reviews every result). State which applies; this justifies a high accuracy target rather than perfection.
2. Weigh frequent small benefits against rare serious losses, using the human baseline from Step 4.
3. Consider longer-term and indirect effects: corruption of data later used to improve the system, reputational damage, and any beneficial effect worth building in deliberately, such as recording the corrections people make.

Output: A reliability stance consistent with the Step 1 value; cost screening captured in the risk assessment (AI-008) and reflected in the success criteria.

Done when: The reliability stance is stated and the cost screening is in the risk assessment.

Step 7: Record the decision (Go/No-Go)

Purpose: Complete the AI-013 definition of done.

Actions:

1. Confirm the AIMS objective mapping is recorded (Step 1), the impact and risk assessments are linked (Steps 5 and 6), and the compliance checklist passes.
2. Obtain and record management approval to proceed, with date and approver.

Output: A Go/No-Go decision record.

Done when: Management approval is recorded and the compliance checklist passes.

Assembling the Document

The step outputs populate the sections of the AI Problem Definition template:

Two step outputs are not template sections. Step 0’s inherited decisions are recorded within 1.2 Business Context and 4.2 Constraints, not as a separate section. Step 7’s Go/No-Go is recorded outside the document — in the Jira decision record and the GitLab approval — per the docs-as-code workflow.

A template section with no supporting step output means Phase 1 is incomplete.

Relationship to Requirements Engineering

This method frames the problem and sets the machine-learning boundary. Example Mapping then elicits the rules, examples, and scenarios within that boundary. Run them in sequence: problem definition first, Example Mapping second.

Route open questions by level so there is one question list per level. Problem-level and boundary-level questions (is the solution predetermined; what does the sponsor value; what is in scope) are resolved within the problem definition. Rule-level and scenario-level questions move to the scenario inventory question list, which is the single source of truth for that class. The problem definition links to that list.

Using an AI Assistant

An assistant can carry out routine drafting and review. Judgment, stakeholder contact, and governance decisions stay with the responsible person.

Suitable tasks for an assistant: drafting the list of causes; checking the problem statement for technology terms; proposing the capability division and solution options for review; drafting the provisional task framing and the accuracy basis; listing missing stakeholder types; reviewing whether each safeguard is effective.

Instruct the assistant to question its own conclusions, to accept that machine learning may not be required, to flag technology terms in the problem statement, and to keep its output at problem-definition altitude. It must never invent assessment content or approval decisions.

Summary

Define the problem before the solution: why it exists, what the system must do, and what an error would cost. Do the cheap checks first. Hand off to the AIMS objective mapping, the impact and risk assessments, and a recorded Go/No-Go decision.

Revision History