When to use
- The solution may generate, interpret, predict, rank, recommend, classify, or detect patterns.
- Data, knowledge sources, labels, feedback loops, or human review need validation.
Treat AI and ML as product and operating decisions, not model-selection exercises.
Use this framework when the expected value depends on uncertain model output rather than deterministic logic. It helps teams compare AI, ML, and non-model routes before they commit to build, rollout, or automation.
Managed AI API
Use an external or managed foundation-model provider when the team needs speed and can govern data sharing, output quality, cost, latency, and vendor dependency.
Managed AI API
Focus on the product problem, sensitive-data boundaries, prompts, retrieval, tools, user review, evaluation against real tasks, and the cost and fallback model.
AI/ML.1 Problem, Decision, and Non-AI BaselineAI/ML.2 Automation Boundary and Failure CostAI/ML.5 Input, Knowledge, Feature, and Scope DesignAI/ML.7 Evaluation, Safety, and Error AcceptanceAI/ML.9 Pilot, Monitoring, and Model Operations
When not to use
- A deterministic workflow, rules engine, search experience, report, or dashboard is enough.
- The team lacks usable data, knowledge, labels, or feedback signals.
Start with
- Define the non-model baseline and the task a model must outperform.
- Audit data, knowledge, permissions, labels, feedback, and privacy constraints.
- Set evaluation, human-review, safety, escalation, monitoring, and rollback standards.
Activities
Phase 1 - Is a model justified?
Clarify the real problem, the current baseline, and the cost of model mistakes before anyone chooses tools, vendors, or architectures.
Activity 1CoreAI/ML.1 Problem, Decision, and Non-AI Baseline
Clarify the real problem, the current workflow, the decision or job to improve, and the simplest credible non-AI alternative.
Typical output: AI/ML Opportunity Brief
AI/ML.1 Problem, Decision, and Non-AI Baseline
Clarify the real problem, the current workflow, the decision or job to improve, and the simplest credible non-AI alternative.
Typical output: AI/ML Opportunity Brief
Activity 2CoreAI/ML.2 Automation Boundary and Failure Cost
Define what the model may do, what remains human-owned, what errors are possible, how serious they are, and how uncertainty or escalation should work.
Typical output: Authority and Failure Boundary
AI/ML.2 Automation Boundary and Failure Cost
Define what the model may do, what remains human-owned, what errors are possible, how serious they are, and how uncertainty or escalation should work.
Typical output: Authority and Failure Boundary
Phase 2 - What evidence and route do we need?
Assess readiness evidence, then choose between managed AI, self-hosted AI, predictive ML, anomaly ML, ranking ML, or a non-model alternative.
Activity 3CoreAI/ML.3 Data, Knowledge, and Feedback Readiness
Assess whether the initiative has enough accessible, lawful, relevant, and trustworthy material to support the chosen route.
Typical output: Data, Knowledge, and Feedback Readiness Note
AI/ML.3 Data, Knowledge, and Feedback Readiness
Assess whether the initiative has enough accessible, lawful, relevant, and trustworthy material to support the chosen route.
Typical output: Data, Knowledge, and Feedback Readiness Note
Activity 4CoreAI/ML.4 Capability and Deployment Route Decision
Choose between managed AI API, self-hosted open-source AI, predictive ML, anomaly or segmentation ML, ranking or recommendation ML, or a non-model alternative.
Typical output: Capability and Route Decision Note
AI/ML.4 Capability and Deployment Route Decision
Choose between managed AI API, self-hosted open-source AI, predictive ML, anomaly or segmentation ML, ranking or recommendation ML, or a non-model alternative.
Typical output: Capability and Route Decision Note
Phase 3 - How will the system work safely?
Define the inputs, boundaries, permissions, evaluation rules, and human experience before rollout is discussed as a delivery step.
Activity 5CoreAI/ML.5 Input, Knowledge, Feature, and Scope Design
Define the information the model may use, what it must ignore, what context it needs, and the boundaries of the first version.
Typical output: Model Input and Scope Design
AI/ML.5 Input, Knowledge, Feature, and Scope Design
Define the information the model may use, what it must ignore, what context it needs, and the boundaries of the first version.
Typical output: Model Input and Scope Design
Activity 6CoreAI/ML.6 Integration, Tools, Permissions, and Action Boundaries
Define how the capability connects to systems, retrieves data, accesses tools, writes back information, and safely handles permissions.
Typical output: Integration and Permission Boundary
AI/ML.6 Integration, Tools, Permissions, and Action Boundaries
Define how the capability connects to systems, retrieves data, accesses tools, writes back information, and safely handles permissions.
Typical output: Integration and Permission Boundary
Activity 7CoreAI/ML.7 Evaluation, Safety, and Error Acceptance
Define how the team will test model behavior before real rollout using realistic use cases, failure cases, thresholds, cost, latency, reliability, and escalation behavior.
Typical output: Evaluation and Acceptance Plan
AI/ML.7 Evaluation, Safety, and Error Acceptance
Define how the team will test model behavior before real rollout using realistic use cases, failure cases, thresholds, cost, latency, reliability, and escalation behavior.
Typical output: Evaluation and Acceptance Plan
Activity 8CoreAI/ML.8 Human Experience, Review, and Escalation Design
Design how users understand, trust, challenge, correct, approve, reject, or escalate model output.
Typical output: Human Review and Escalation Design
AI/ML.8 Human Experience, Review, and Escalation Design
Design how users understand, trust, challenge, correct, approve, reject, or escalate model output.
Typical output: Human Review and Escalation Design
Phase 4 - Can we operate this responsibly?
Use pilot, monitoring, and recommendation evidence to decide whether to pilot, scale, pause, or choose a simpler alternative.
Activity 9CoreAI/ML.9 Pilot, Monitoring, and Model Operations
Design a controlled pilot and define how the team will operate the capability after launch, including quality monitoring, versioning, logging, support, drift, rollback, and ownership.
Typical output: Pilot and Monitoring Plan
AI/ML.9 Pilot, Monitoring, and Model Operations
Design a controlled pilot and define how the team will operate the capability after launch, including quality monitoring, versioning, logging, support, drift, rollback, and ownership.
Typical output: Pilot and Monitoring Plan
Activity 10UsefulAI/ML.10 Final Recommendation
Use the evidence from the full framework to decide the next move without forcing a simplistic go / no-go answer.
Typical output: Final AI & ML Recommendation
AI/ML.10 Final Recommendation
Use the evidence from the full framework to decide the next move without forcing a simplistic go / no-go answer.
Typical output: Final AI & ML Recommendation
Move from model justification to responsible operation.
Phase 1 - Is a model justified?
Clarify the real problem, the current baseline, and the cost of model mistakes before anyone chooses tools, vendors, or architectures.
Phase 2 - What evidence and route do we need?
Assess readiness evidence, then choose between managed AI, self-hosted AI, predictive ML, anomaly ML, ranking ML, or a non-model alternative.
Phase 3 - How will the system work safely?
Define the inputs, boundaries, permissions, evaluation rules, and human experience before rollout is discussed as a delivery step.
Phase 4 - Can we operate this responsibly?
Use pilot, monitoring, and recommendation evidence to decide whether to pilot, scale, pause, or choose a simpler alternative.
Who uses it, when to use it, what it produces, and how to use it.
Who uses it
Product Managers, Business Analysts, AI Engineers, ML Engineers, Tech Leads, Data Engineers, domain SMEs, security or compliance stakeholders, operations owners, and teams responsible for the experience after launch.
When to use it
Use it when the expected value depends on uncertain model output rather than deterministic logic, and the team must validate route fit, safety, inputs, evaluation, and operating responsibility.
What it produces
An opportunity brief, route decision, readiness assessment, safe automation boundary, evaluation plan, pilot plan, monitoring model, and final recommendation.
How to use it
Start with the business problem and non-AI baseline, choose the right route, test it with realistic examples, define safe human and automation boundaries, and use a controlled pilot before scaling.
Capture this project context before discovery begins.
- Initiative name
- Business owner
- PM / BA owner
- Technical owner
- AI / ML owner
- Domain SME
- Target users or operational team
- Decision, job, or workflow to improve
- Current process or non-AI baseline
- Desired outcome
- Data, knowledge, or content sources
- Sensitive-data classification
- Regulatory, legal, or policy constraints
- Target date
- Expected scale: users, transactions, documents, requests, or predictions
- Brief description of what the model may assist with or automate
Keep the framework disciplined, not fashionable.
Solve the job, not the AI trend
Do not begin with 'Where can we use AI?'. Begin with a real user or business problem, the current workflow, and the measurable improvement required.
Prove the baseline first
Document how the problem is solved today through people, rules, search, reports, workflows, or existing systems. AI or ML must improve something meaningful.
Keep authority explicit
Assisting, recommending, drafting, classifying, and acting are different levels of authority. Make the human review, escalation, and uncertainty rules visible early.
Measure behavior in real context
A good demo is not enough. Evaluation must use realistic examples, expected failure cases, real user tasks, and the cost of wrong outputs.
Do not automate high-impact decisions by default
Where outputs affect money, eligibility, safety, compliance, or reputation, begin with decision support and human review unless governance and evidence justify more autonomy.
Different capability routes, not a maturity ladder.
The best option depends on the user problem, readiness evidence, privacy constraints, autonomy required, expected scale, and the team's ability to support the system over time.
Rules / workflow / searchManaged AI APISelf-hosted open-source AIPredictive / forecasting MLPattern / anomaly MLRanking / recommendation ML
AI & ML are often a secondary lens alongside another discovery type.
Choose a lead lens based on the dominant uncertainty. Add AI & ML Discovery when model behavior, model governance, data readiness, or safe automation is a material risk.
| Primary situation | Lead lens | Common secondary lens |
|---|---|---|
| Internal assistant using company documents | AI & Machine Learning Discovery | Data + Integration |
| AI feature for a public-facing app | AI & Machine Learning Discovery | Mass Product |
| AI capability across multiple enterprise clients | AI & Machine Learning Discovery | Scaled Solution |
| Predictive score using fragmented historical records | AI & Machine Learning Discovery | Data |
| AI assistant that performs system actions | AI & Machine Learning Discovery | Integration |
| Small feature using an existing approved AI service | Tactical Discovery | AI & Machine Learning Discovery |
| Internal workflow transformation with AI assistance | Operational Discovery | AI & Machine Learning Discovery |
Rows with values show source examples; empty cells are working fields.
Scale participation with risk, sensitivity, and automation level.
Not every role is mandatory for every initiative, but the table keeps authority clear when AI or ML changes user, operational, or governance risk.
| Area | PM / BA owns | AI / ML Engineer owns | Tech Lead / Architect owns | Domain SME owns | Security / Compliance owns |
|---|---|---|---|---|---|
| Problem and baseline | Define the problem, user, workflow, and success measure | Advise on technical feasibility | Identify system constraints | Validate the real-world need | Flag policy constraints |
| Automation boundary | Define decision rights, workflow, and escalation | Explain model limitations | Design enforcement points | Validate acceptable risk | Approve high-risk boundaries |
| Data and knowledge readiness | Define business meaning and access need | Assess suitability for model use | Confirm systems and data access | Validate source relevance | Review data classification and use |
| Route decision | Own product trade-offs and business value | Recommend the model approach | Assess integration and operations | Validate fit in practice | Assess vendor, hosting, and governance risk |
| Evaluation | Define business acceptance criteria | Build the model evaluation approach | Test reliability and performance | Validate outputs against reality | Review safety and control requirements |
| Pilot and monitoring | Own pilot decision and success metrics | Monitor model quality and drift | Operate service and incident response | Review pilot usefulness | Monitor control compliance |
Rows with values show source examples; empty cells are working fields.
Discovery is complete when all are true.
- The user or business problem is clear and measurable.
- The current non-AI baseline is documented.
- The team can explain why AI or ML is better than a rule, workflow, search, report, or manual process.
- The primary route is chosen and justified.
- Data, documents, knowledge sources, labels, or feedback signals are assessed for readiness.
- Sensitive-data, privacy, security, and access constraints are documented.
- Model authority and human-review boundaries are explicit.
- Realistic evaluation cases and acceptance thresholds are defined.
- High-impact errors, unsafe behaviors, and escalation paths are documented.
- Cost, latency, reliability, and operating responsibilities are understood.
- The pilot scope, success metrics, monitoring approach, and rollback process are defined.
- Stakeholders agree on the final recommendation and what should happen next.
Final AI & Machine Learning Discovery Output
A decision-ready package that explains the problem, baseline, AI or ML route, data or knowledge readiness, automation boundary, evaluation criteria, safety controls, pilot model, operating ownership, and recommendation.
People, artifacts, escalation
Minimum participants
Product or BA ownerDomain SMEAI or ML engineerTech leadSecurity or complianceOperations owner
Minimum artifacts
- Problem and baseline brief
- Data or knowledge readiness audit
- Evaluation plan
- Human-review and escalation model
- Monitoring and rollback plan
Escalate if
- Model output can affect eligibility, access, money, safety, legal status, or vulnerable users.
- The team cannot explain failure handling or human review.
- Evaluation data is unavailable or not representative.
Check the evidence before moving forward.
What decision will this discovery evidence support?
What user, process, data, system, or model evidence would change the decision?
Which risk remains unresolved, and who accepts it if the team proceeds?
What artifact proves the team is ready for build, pilot, rollout, or scale?
Continuous Discovery
Cadence
- Weekly or biweekly signal review for live behavior, support issues, and adoption friction.
- Monthly user or stakeholder touchpoints for deeper problem discovery.
- Quarterly roadmap and outcome review using evidence, not only delivery volume.
Activities
- Track behavior, funnel, support, operational, and trust signals after launch.
- Keep a discovery backlog of assumptions, unresolved risks, and improvement hypotheses.
- Run lightweight interviews, usability checks, experiment reviews, or data validation as new evidence appears.
- Feed validated learning into roadmap, backlog, support readiness, and deprecation decisions.
Outputs
Discovery backlogLearning logExperiment or validation planOutcome dashboardRoadmap recommendation