From Business Research to Ontology Modeling: 7-Step Framework for Verifiable Business Models

Why Scenario Definition Cards Are Not Business Models

A scenario definition card captures value and boundaries (who benefits, start/end points, scope, data dependencies, AI/human split). A business model captures how the business actually runs: which objects participate and change, what events trigger processes, which states/rules/exceptions apply, what evidence proves facts, and who executes which behaviors with what responsibility. Skipping this layer leads technical teams to mistake database tables for business objects, process nodes for object states, model outputs for certain facts, or API calls for complete business behaviors.

Step 1: Extract Nine Business Elements from Real Cases

The author expands the previous six-element framework into nine concrete elements, each with verification questions and an order-fulfillment example:

Business Objects — Verification: Who/what is managed, judged, changed? Example: Customer, Contract, Order, Delivery Record, Extension Approval, Risk Task

Object Relationships — Verification: Why linked? Time/scope bounds? Example: Contract constrains order fulfillment; extension approval may alter delivery deadline

Business Events — Verification: What change triggers processing/re-judgment? Example: Daily check time reached, delivery deadline passed, extension approval takes effect/expires

Business Processes — Verification: Which activities drive the task forward? Example: Aggregate evidence, verify overdue, confirm exception, raise alert

Object States — Verification: Current state? Allowed transitions? Example: Order: Awaiting Fulfillment; Risk Task: Pending Generation → Pending Confirmation → Alerted / Excluded / Pending Manual Review

Business Rules — Verification: Conditions for judgment? Exceptions? Example: Past valid delivery date + no delivery record; conflicting evidence → manual

Roles & Permissions — Verification: Who executes, confirms, approves, owns? Example: Risk service generates prompt, account manager confirms, high-risk actions need separate approval

Evidence & Basis — Verification: What data proves facts? What policies support rules? Example: Contract clauses, order records, delivery logs, approval records, policy docs, manual confirmations

Business Behaviors — Verification: Who does what to which object when? Example: Extract clauses, aggregate evidence, verify rules, submit confirmation, raise alert

The nine elements are an operational framework, not a new universal ontology standard. Projects may merge/extend but must not omit object identity, state ownership, rule scope, evidence source, or responsibility boundaries. The author distinguishes business process (multi-activity outcome), business behavior (assignable execution unit with input/output/effect), and engineering action (API/MCP tool/action contract) — they are not equivalent.

Step 2: Identify Business Objects, Then Confirm Relationships

Business objects are not database tables or every noun in documents. Five sequential questions test candidacy:

Does it have an identifiable business identity?

Does it persist over time?

Does it own attributes, states, or a lifecycle?

Does the business judge or act around it?

Must it be individually tracked, authorized, or audited?

Example: "Risk" may be a judgment result, but "Risk Task" has creation time, state, owner, evidence list, and handling result — making it a manageable object. Relationships need business semantics: which contract version constrains which order, when the relation becomes effective, whether extension approval alters the original delivery commitment, what system/document/manual confirmation supports it, and how to handle expiry/conflict. Relations exist to support judgment, query, and constraint in the current scenario — not to draw a graph.

Step 3: Separate Events, Processes, and States

Requirements often conflate them. Definitions:

Event : Something happens at a point in time (e.g., daily check time reached, extension approval takes effect).

Process : Activities executed by system/people to produce change (e.g., verify fulfillment risk, confirm extension exception).

State : Situation an object is in over a period (e.g., Order: Awaiting Fulfillment; Risk Task: Pending Confirmation).

Core relationship: Event triggers process; process reads/changes object; object enters new state.

The order-fulfillment scenario decomposes into a trigger-event → execution-process → main-object → possible-state-change mapping (five rows):

Daily check time reached → Aggregate evidence → Order, Contract, Delivery Record → Order state not necessarily changed

Valid delivery date passed → Verify overdue rule → Order, Risk Task → Risk Task: Pending Generation → Pending Confirmation

Account manager confirms risk → Raise formal alert → Risk Task → Pending Confirmation → Alerted

Valid extension confirmed → Exclude current risk → Risk Task → Pending Confirmation → Excluded

Evidence missing or conflicting → Initiate manual review → Risk Task → Pending Confirmation → Pending Manual Review

States must belong to explicit objects; mixing multiple objects' states into one flow line causes ambiguity. Correctly: Order state (Awaiting Fulfillment → Delivered/Cancelled) and Risk Task state (Pending Generation → Pending Confirmation → Alerted/Excluded/Pending Manual Review) are independent. An order can still be Awaiting Fulfillment while its risk task is already Pending Confirmation.

Step 4: Define Value, Rules, and Behaviors Separately

Three definitions answer different questions:

Value Narrative — Primary Question: Why do this, for whom, improve what outcome? Typical Problem If Missing: Feature delivered but business value unproven

Business Rule — Primary Question: Under what scope/conditions how to judge? Typical Problem If Missing: Output looks reasonable but lacks stable basis and exception handling

Business Behavior — Primary Question: Who does what at what trigger? Typical Problem If Missing: Only generates information, no closed-loop business disposition

Business Rule Formula

When [Applicable Object] is in [Business State] and [Trigger Condition] holds, make [Business Judgment] or impose [Business Constraint]; if [Exception Condition] exists, route to [Exception Handling] by [Responsible Role] for [Confirmation/Approval/Disposition].

A complete rule includes: Applicable Scope → Pre-condition State → Trigger Condition → Judgment/Constraint → Exception Handling → Responsible Party → Basis & Audit Trail. Example rule for overdue risk: When Order is Awaiting Fulfillment, current date ≥ valid delivery date + 3 working days, and no valid delivery record exists → identify as fulfillment overdue risk. Valid delivery date prefers approved extension applicable to that order; if original contract conflicts with extension material or extension applicability uncertain, do not auto-alert; route to account manager for review with recorded rationale.

Business Behavior Formula

By [Executing Role/System] against [Business Object] at [Trigger Moment] using [Required Data & Rules] execute [Concrete Action] producing [Output Result] and optionally creating [Result Object] or moving [Business Object] from [Current State] to [Target State]; if [Risk/Permission Boundary] involved, must pass [Manual Confirmation/Approval] and record [Execution Result & Evidence].

Complete behavior: Executor → Target Object → Trigger Moment → Input Data/Rules → Action → Output → Object Creation/State Change → Permission/Manual Confirmation → Audit Trail. Some behaviors only read/generate results without changing original object state — must clarify what they create/output, not invent state changes. Order-fulfillment behavior example: Risk identification service against Awaiting Fulfillment orders at daily check reads order/delivery logs, references AI-extracted & verified delivery terms from valid contract/extension, executes deterministic overdue rule, generates risk prompt + evidence list, marks risk task Pending Confirmation; account manager confirms → task becomes Alerted or Excluded; insufficient/conflicting evidence → Pending Manual Review; full lineage of data sources, rule versions, confirmations retained.

For quick alignment, combine into a scenario master definition (template provided) but this cannot replace detailed object model, rule exceptions, evidence lists, and verification samples.

Step 5: Make Data Sources into Business Evidence

"Data from order system" only says where to fetch; it doesn't say what the data proves. The business model must link business facts to primary evidence and required metadata:

Business Fact: Which delivery date currently applies — Primary Evidence: Valid contract version, extension approval — Also Record: Effective time, applicable order, version priority

Business Fact: Whether order has been delivered — Primary Evidence: Delivery record, sign-off record, status log — Also Record: Record time, source system, reversal/correction status

Business Fact: Whether extension is valid — Primary Evidence: Approval result, approval scope, validity period — Also Record: Approver, authority, linked order, expiry conditions

Business Fact: Whether risk has been confirmed — Primary Evidence: Risk task, manual confirmation record — Also Record: Confirmer, time, basis, rule version

Evidence layers: authoritative source vs. derived data; directly observable source facts, rule-derived conclusions, authorized human judgments, model-generated candidate conclusions; current valid evidence vs. expired history; primary evidence that directly proves fact vs. secondary reference evidence. AI extraction results are candidate facts/assertions/evidence leads — not original evidence. Model must retain source references (contract paragraph, doc version, log position) and explicitly state whether rule verification or human confirmation is required.

Step 6: Convert Natural Language to Confirmable Symbolic Models

Natural language hides ambiguity (e.g., "after approval completes, enter processing" — which approval object, what result counts as complete, which object enters what state). Better: visualize/symbolize the nine elements into at least four views:

Scenario Boundary View : roles, trigger events, start/end, exclusions.

Object Relationship View : core objects, relationships, applicability.

Process-State View : how events trigger processes, how processes change different objects' states.

Rule-Behavior View : rules, exceptions, evidence, execution actions, human confirmation points.

Tools: OPM (unifies object/process/state, good for ontology handoff), BPMN (process/role/branch), Domain Model (object/relation clarity). Tool choice matters less than whether business experts can read, spot errors, and confirm. Business experts should not need RDF/OWL; division of labor: experts provide real cases, rule bases, exception experience; modelers translate to symbolic models; experts reconfirm/correct.

Output is a business model, not the final ontology. Pipeline: Real Cases → Scenario Card → Symbolic Business Model ↔ Business Confirmation → Capability Questions & Boundary Sample Verification → Business Model Baseline → Ontology Semantic Model.

Step 7: Validate Model with Business Questions and Boundary Samples

Business sign-off is insufficient. Must test with competency questions (CQs) that the scenario must answer:

Which orders enter pending-confirmation risk today, and why?

Which contract version, delivery record, extension approval does each risk conclusion depend on?

How to handle missing/expired/conflicting extension info?

Who can confirm/exclude/escalate risk; which actions cannot auto-execute?

When rules/data/contract versions change, which conclusions need recalculation?

CQs are parameterized and traced to model elements, real evidence, applicable rules, expected results, verification status. Example CQ table shows one row mapping to required model elements, evidence/rules, expected result (Pending Confirmation / No Alert / Pending Manual Review with evidence & rule version).

Prepare at least five real sample types:

Condition Met — Verify: Rule fires, evidence complete → expected judgment & state change

Condition Not Met — Verify: Not overdue / already delivered / valid extension → correctly excluded

Evidence Missing — Verify: Missing contract/delivery/approval → refuses deterministic conclusion

Fact Conflict — Verify: Cross-system/doc contradictions → routes to manual review

Out of Scope — Verify: Not in pilot / high-risk action → stops or escalates

Exceptions and boundary samples expose object confusion, state errors, rule gaps, evidence insufficiency, permission overreach more than happy-path tests.

Organizing a Model Co-Creation Session

Business models cannot be built in isolation or finalized in one meeting. Six-step collaborative process:

Modelers draft v1 objects, processes, states, rules, evidence from scenario card & real cases.

Business experts check flow, object boundaries, rules, exceptions against real work.

Data/system staff confirm key facts have usable evidence — but do not substitute table structures for business model.

Risk/compliance staff confirm rule basis, permissions, human takeover, high-risk action boundaries.

AI/engineering staff confirm model outputs are implementable, testable, auditable.

Team walks through normal, exceptional, conflicting cases together → version baseline + open issues.

Each review distinguishes confirmed facts, tentative assumptions, unresolved issues. Content without factual evidence or formal rule basis cannot become confirmed fact/rule just by being drawn in the model.

Deliverables for Ontology Modeling

A business model baseline ready for ontology engineering includes:

Scenario boundary & value narrative

Core business objects & relationships

Events, processes, states & legal transitions

Business rules, scope, basis, exceptions, responsible parties

Business behaviors, inputs/outputs, permission boundaries

Business fact ↔ data evidence mapping candidate list

Symbolic business model & version history

CQ → model element/evidence/rule/boundary sample/expected result/verification status traceability matrix

Open issues, blocker level, owner, confirmation plan

Complete deliverables ≠ releasable baseline. Blockers (core object identity unconfirmed, state ownership disputed, key rule lacks authoritative basis, core evidence unobtainable, high-risk behavior responsibility/permission unclear) allow exploratory models but forbid freezing tentative content into formal ontology semantic baseline.

Mapping to subsequent ontology/engineering work:

Business objects, relations, processes, events, states → Concept types, relation types, process types, state models

Business rules, exceptions, metric boundaries → Rule constraints, decision logic, semantic quality rules

Business fact ↔ data evidence mapping candidates → Table/field/document/log/interface/manual confirmation semantic mappings

Business behaviors & permission boundaries → Action contracts, service interfaces, MCP tools, approval mechanisms

Competency questions & boundary samples → Query tests, evaluation sets, acceptance baselines

Three boundaries to maintain: identify business objects ≠ equate to DB tables; confirm business logic ≠ rush to OWL/rule code/prompts; specify "what evidence proves what fact" before field-level data lineage mapping.

Summary

Business research results cannot be directly translated into ontology models. An intermediate verifiable business model is needed — confirmable by business, validatable by data, implementable by engineering. Full path: extract objects, relations, events, processes, states, rules, roles, evidence, behaviors from real cases; separately define value, rules, behaviors; eliminate natural-language ambiguity via symbolic models; validate with competency questions and boundary samples; produce ontology-ready business model baseline. This baseline is not the ontology itself but the input baseline for ontology engineering. Next phase: formalize confirmed objects, relations, events, processes, states, rules, evidence, behaviors into computable, queryable, constrainable semantic assets; continue with data mapping, service publishing, runtime governance.

A business model ready for ontology modeling is not about drawing a complete diagram; it is about ensuring key business questions can be answered, rules and states can be verified, conclusions trace back to evidence, and actions find clear responsibility and boundaries.