From Vague Requirements to Verifiable Business Scenarios: A 7-Step Ontology Research Method

Business Research Is Not Feature Collection

Many ontology projects fail because the problem originates earlier than modeling. Stakeholders — business owners, frontline staff, product managers, data teams, AI teams — each articulate valid needs, but the resulting feature list (e.g., Q&A, alerts, auto-reports, system integrations) lacks verifiability. Directly modeling from such a list leads to two extremes: piling concepts around existing table fields or attempting a single "grand ontology" covering all business.

The goal of this research phase is not to draw ontologies or define database fields, but to produce a "Scenario Definition Card Draft" jointly confirmed by business, data, and technical teams. The complete path is:

Concrete tasks & real cases → Facts, rules, judgments, hypotheses → Candidate opportunities → Scenario screening → Value narrative → Scenario boundaries → Scenario definition card draft

This method applies to any serious system construction, but ontology models demand extra rigor because they will be reused across cross-system data governance, semantic query, rule validation, and agents. Semantic ambiguities left in research propagate into data mappings, semantic constraints, and agent actions.

Prepare Four Inputs Before Research

One Concrete Task

Do not research broad domains like "contract management." Converge on a completable task, e.g.:

Identify order fulfillment delay risk

Review high-risk contract clauses

Decide if equipment anomaly requires shutdown

Verify case materials meet review requirements

Specific tasks make start/end points, roles, and verification results easier to find.

A Set of Real Cases

Prepare at least one normal and one abnormal case. Without exceptions, teams mistake prescribed processes for actual operations. Retain original contracts, forms, system records, chat logs, approvals, and outcomes; avoid relying solely on recall.

A Set of Key Roles

Include: owners (goals), frontline (real process), domain experts (rules/exceptions), data/system staff (existing records), risk/compliance (permissions/responsibility boundaries). Interviewing only leaders yields ideal flows; only frontline misses governance context.

A List of Hypotheses to Validate

State assumptions but do not treat them as conclusions. Examples:

Risk detection lag may stem from scattered data

Delay approvals may not link correctly to orders

Contract delivery dates may live mainly in unstructured docs

Account managers may spend excessive time re-verifying

Research aims to find evidence and correct hypotheses, not to prove the technical team's initial guesses.

Step 1: Follow a Real Task End-to-End

Business people in meetings describe prescribed processes. Real efficiency and risk impacts come from cross-system queries, ad-hoc communication, manual reconciliation, experiential judgments, exception fixes, and repeated confirmations. Combine four research techniques:

Shadowing: Observe how tasks trigger, information flows, and people operate

Case Replay: Reconstruct what happened around a completed real task

Process Walkthrough: Walk from start to end, confirming roles, judgments, handovers, exception paths

Artifact Verification: Use regulations, contracts, records, logs to verify verbal descriptions

Do not ask "what objects, states, relations exist?" Instead, follow chronological probes:

What event triggered the task?

Who handled first, then whom?

What was viewed, created, judged, or changed at each step?

Which systems, documents, logs, or human communications provided information?

Which nodes required lookup, comparison, interpretation, or repeated confirmation?

Which judgments relied on experience, and can the basis be articulated?

How were missing, conflicting, timeout, or exceptional situations handled?

Who confirmed completion, and were results and corrections recorded?

For order fulfillment, don't accept "order created → ship → alert if overdue." Take a real anonymized exceptional order and ask: How was risk first discovered? Which contract version, delivery date, system record were checked? Where is the delay approval stored? Who resolves material conflicts? How was it finally disposed, and were corrections written back and logged?

Only by tracing real cases can teams separate facts, rules, judgments, and unverified conjectures. Business people narrate reality; business architects, product managers, or knowledge engineers abstract structure. Do not shift modeling work to business, nor let technicians guess reality from interview notes.

Step 2: Distinguish Facts, Rules, Judgments, and Hypotheses

Interviews mix four information types. If undifferentiated, they enter requirements as confirmed knowledge.

Business Facts: Occurred and evidenced (e.g., no valid delivery record at query time) → Find data/docs/logs/manual records as evidence, build data mappings

Institutional Rules: Constraints applicable in a scope (e.g., valid extensions adjust order delivery date) → Record source, scope, exceptions; decide execution via rule engine, workflow, or manual

Professional Judgments: Conclusions from experience/context (e.g., whether a specific extension approval applies to current order) → Clarify basis, context, responsible role; assess AI assistance extent

Hypotheses to Validate: Unproven conjectures (e.g., risk lag mainly caused by cross-system queries) → Define validation plan: samples, metrics, data sources, criteria

Tag research records with these four types, noting source, provider, time, open questions. Example: "This customer often delays" is experience; "Three approved extensions in last six months" is verifiable fact; "Therefore this time can also extend" is a judgment needing rule and evidence.

Ontology modeling needs confirmed business knowledge, not every statement from meetings structured.

Step 3: Form Candidate Opportunities from Business Friction

Research purpose is not exhaustive documentation but finding key nodes worth changing. Candidate opportunities appear in five friction types:

Information scattered, requiring repeated cross-system/document searches

Same content re-entered, compared, verified

Critical judgments depend on few people's tacit experience

Exceptions discovered too late, missing low-cost handling window

Manual corrections and dispositions produce no feedback loop

Example: Business initially asks for "order intelligent Q&A." Walkthrough reveals real problem: account managers daily cross-check contract, order, approval systems for delivery dates, fulfillment records, extension approvals; risks often found only after customer complaints. The candidate opportunity becomes:

Help account managers timely identify orders with fulfillment delay risk, aggregate judgment evidence, and route to subsequent disposition after manual confirmation.

Candidate opportunities indicate what deserves further analysis, not project commitments.

Step 4: Assess Worth, Feasibility, and AI Need

Ontology-driven data governance should not start with full-domain modeling, nor build complex semantic assets for vague value. After forming multiple candidate scenarios, use a pain-point map (business impact × urgency) to prioritize. Priority does not equal readiness for pilot/modeling.

Each candidate must pass six admission criteria:

Business Value: Impacts revenue, cost, efficiency, risk, compliance, or customer experience

Closed-loop Clarity: Can articulate start, key judgments, state changes, results, feedback

Evidence Base: Traceable data, documents, logs, regulations, manual confirmations exist

Implementation Feasibility: Key data accessible, source systems support needed integration, responsible roles willing, pilot cost/cycle controllable

Result Verifiability: Can establish current baseline, target values, acceptance samples

Semantic Asset Reusability: Can deposit reusable objects, relations, states, rules, data mappings, agent capabilities

Some criteria are hard gates: if key evidence untraceable, responsible person unwilling, high-risk actions lack human confirmation, compliance boundaries unclear — do not enter pilot.

Separately ask: Does this really need AI? If inputs fully structured, rules fixed, action paths fixed, system integration/rule engine/workflow are more stable than LLMs. AI suits unstructured materials (contracts, approval opinions) for semantic extraction, information merging, conflict detection, evidence summarization, explanation generation, assisted judgment.

In the order fulfillment example:

AI assists extraction of contract delivery terms and extension notes

Deterministic mechanisms execute working-day calculation, overdue rules, state transitions

Business people confirm evidence conflicts and major exceptions

Formal alerts, penalties, credit adjustments constrained by permissions and approvals

A scenario can combine data governance, rule calculation, workflow, and AI capabilities; not all must go to LLMs. AI need determines implementation approach, not whether ontology modeling is needed. Even without LLMs, cross-system object inconsistency, unclear rule semantics, lack of unified evidence for business facts still justify ontology-driven governance.

Step 5: Define Targets with Value Narrative

After screening, don't discuss pages, buttons, APIs. Use value narrative to align on shared goal. It answers: for whom, in which process, transform current work style into target work style, improve which business result.

Value Narrative Formula: To help [specific role/object], in [clear business process/scenario], transform [current inefficient/broken/risky work style] into [target work style], and improve [key metric] from [current baseline] to [target value].

Order fulfillment scenario:

To help account managers in order fulfillment monitoring, transform current work style reliant on manual cross-system verification and late risk discovery into target work style where system proactively aggregates delivery and extension evidence, prompts suspected risks for personnel confirmation, and improve risk detection time, miss rate, confirmation time from pilot baseline to jointly agreed targets.

Value narrative is not a slogan or fabricated ROI. If baseline unknown, measure first — don't invent numbers. Baseline measurement covers four categories:

Task volume, frequency, exception ratio over a period

Average handling time, wait time, cross-system query count

Miss rate, rework rate, overturn rate, exception detection point

Manual effort, business loss, risk consequences

Each baseline records statistical period, sample scope, data source. Otherwise target values cannot be judged post-implementation. A valid narrative also constrains scope: who served, which process, what work style changed, what results are out of scope for this phase. "Current work style" and "target work style" describe business value change, not object states in the later business model (e.g., order state, risk task state).

Step 6: Define Scenario Boundaries Explicitly

Value narrative answers "why"; boundaries answer "how far this time." Confirm at least six boundaries:

Target Roles: Who uses results, who bears business responsibility

Trigger Event: What starts the scenario

Exit Condition: What result ends the scenario

Core Objects: What is truly managed, judged, changed this phase

Human Boundary: Which judgments/actions must be human-confirmed

Exclusions: Which objects, processes, actions, exceptions are deferred

Not "covers order fulfillment management." Instead:

Scenario starts at daily fulfillment check, ends when suspected risk is confirmed, excluded, or escalated to manual review. Phase 1 covers only orders with explicit delivery dates linkable to contracts and delivery records. No automatic customer penalties, no automatic credit adjustments, no substitution for contract dispute adjudication.

Such boundaries decide which objects, relations, states, rules to model next, and prevent scope creep during pilot.

Step 7: Produce Scenario Definition Card Draft

Research should not leave only interview notes and feature lists. The useful deliverable is a Scenario Definition Card Draft. Example for order fulfillment delay risk:

Scenario Goal: Timely detect overdue risk, reduce cross-system verification and post-complaint discovery

Target Roles: Account managers, fulfillment managers

Trigger & End: Daily check start → risk confirmed, excluded, or escalated to manual review

Current vs Target Work Style: From manual verification & late discovery → proactive evidence aggregation & timely risk confirmation

Core Object Candidates: Customer, Contract, Order, Delivery Record, Extension Approval, Risk Task

Key Judgments: Current valid delivery date? Valid delivery or extension exists?

Evidence Source Candidates: Contract versions, order records, delivery logs, extension approvals, manual confirmations

Capability Allocation: AI extracts & aggregates materials; rule mechanism calculates; account managers confirm exceptions

Governance Boundaries: Evidence missing/conflicting → human; unauthorized high-risk actions or audit trail breaks → block auto-processing, escalate to human/audit

Validation Metrics: Risk detection time, miss rate, confirmation time, overturn rate, task cost

Exclusions: Contract dispute adjudication, customer penalties, cross-department credit actions

Open Issues: Extension approval applicability, contract version priority, missing data handling

Objects, evidence, rules here remain candidates. The card sets modeling boundaries, not a substitute for the business model. Candidate opportunities, screening conclusions, scenario definitions need not be separate cards; one card can evolve: research records opportunities, screening adds admission conclusions, definition adds targets/boundaries, lock version before modeling with open items retained.

The card summarizes conclusions but cannot replace raw research records. Fact sources, rule bases, conflict evidence, open issues, confirmation logs stay in an accompanying Research Evidence & Issue Ledger, linked to card version.

How to Organize a Business Research Session

Scenario research cannot be done by a product manager alone, nor by technicians inferring from interview notes. Minimum participants: business owner, frontline staff, domain expert, data/system lead, risk/compliance, plus business architect/product manager/knowledge engineer for abstraction and recording.

Effective research in three phases:

Pre-research: Define concrete task, real cases, roles, existing materials, hypotheses to validate

During research: Reconstruct normal/abnormal cases along timeline; distinguish facts, rules, judgments, hypotheses

Post-research: Organize candidate opportunities and scenario definition card; tag evidence sources, conflicts, open issues, responsible persons

Do not attempt scenario selection, business modeling, data mapping, and technical design in one meeting. After research, have business owner confirm value and scope before entering business modeling.

When Can You Enter Business Modeling?

The six criteria above address "worth doing, can do." The following seven questions check "research output ready for modeling." The former is scenario admission; the latter is phase gate.

Is it pinned to one specific role and one real task?

Are there normal and abnormal cases as basis?

Are trigger event, exit condition, exclusions clear?

Is there a verifiable value narrative with baseline and target metrics?

Are data and regulatory evidence for key business facts identified?

Is preliminary responsibility split among AI, deterministic rules, workflow, human clear?

Are remaining unconfirmed issues, owners, and resolution plans recorded?

If answers are "discuss later," "let the model guess," "build features first and see," do not rush to draw ontologies. Ontologies don't automatically resolve business ambiguity; they may solidify unconfirmed assumptions into queryable, inferable, executable semantics. Once reused by data mappings, rule mechanisms, and agents, errors propagate along judgment and action chains.

Summary

Pre-modeling business research is not collecting a feature wish list, nor reverse-engineering business from table fields. The complete method: prepare concrete tasks and real cases, discover business friction along actual work processes, distinguish facts, rules, judgments, hypotheses, then assess whether a scenario is worth doing, feasible, needs AI, finally use value narrative and explicit boundaries to produce a Scenario Definition Card Draft.

The research phase deliverable is not "what features users want," but "which role encounters what problem within what business boundary, why this problem warrants modeling, and what the subsequent business model must explain and verify."

Once the scenario is clear, the next step extracts objects, relations, events, processes, states, rules, evidence, behaviors from real cases, turning the scenario definition into a verifiable business model. The next article "From Research Results to Ontology Modeling: From Real Cases to Verifiable Business Models" will continue this step.