Decision‑Centric Scenario Ontology Design: A Six‑Step Methodology for Fast POC Delivery

Introduction

In the era of enterprise digital transformation, the core challenge has shifted from "lack of data" to "how to organize semantics to support decisions". This article proposes a decision‑centric scenario ontology design methodology that focuses semantic resources on specific decision points rather than building an all‑covering domain model.

Domain Ontology vs. Scenario Ontology

Domain Ontology aims for broad coverage, establishing a stable conceptual skeleton that serves as a macro‑level semantic base. Its responsibilities include providing a reusable meta‑model for core entities and attributes, with high stability.

Scenario Ontology adopts a narrow focus, organizing only the semantics needed for a particular task. It re‑structures domain concepts into a complete situational expression that answers "who does what, and how the situation changes". Its stability is lower and it is tightly coupled to the specific decision context.

In short, domain ontology lays a cross‑scenario semantic foundation, while scenario ontology provides a decision‑oriented execution model.

Why Market‑Side POCs Prefer Scenario Modeling

Business effect validation is faster because the model anchors high‑value decision points, delivering measurable outcomes within short POC cycles.

Scenario modeling bridges the gap between static architectural blueprints (e.g., TOGAF) and executable business‑data‑system integration, turning ontology objects into API endpoints.

The "decision‑starting point" approach limits the ontology to entities, metrics, and logic required for current decisions, allowing natural growth as new decisions emerge.

Six‑Step Standardized Scenario Ontology Design

Define Scene and Goal – Clarify the closed‑loop task domain (e.g., production scheduling: when main line capacity is tight, suggest activating a backup line to optimize cost while meeting delivery deadlines).

Identify Decision Points and Evidence List – List who makes which decision in what context, and enumerate the concrete facts, indicators, and constraints that support each decision (e.g., load rate, order urgency, switch cost, energy quota).

Set Decision‑Effect Key Indicators – Define primary (e.g., conversion rate) and secondary metrics (e.g., demand‑prediction accuracy, response rate, strategy latency).

Break Down Core Business Process into Event Sequence – Decompose the scenario into a dynamic event chain (e.g., load perception → load alert → backup feasibility → cost‑benefit calculation → scheduling recommendation → production status feedback).

Design Core Ontology Elements

Objects & Properties : Define entities (e.g., production line) and attributes (e.g., real‑time load).

Links : Model relationships such as customer‑to‑object, behavior, strategy, and execution‑attribution links.

Logic : Apply rule‑based classifications, hard constraints (privacy, frequency limits), and flexible inference logic (AI‑driven demand matching).

Actions : Specify system commands (e.g., recommendation push) and data write‑backs (e.g., conversion status).

Validate Scene Effect

Capability Question (CQ) scoring: decision questions 2 points, generic questions 1 point; ≥15/18 passes.

Business effectiveness assessment: check conversion rate, prediction precision (>60%), response quality, latency, and compliance red‑line checks (privacy authorization, frequency control, suitability matching, cooling‑off mechanisms).

Insurance Lead‑Marketing Case Study

The six‑step methodology is applied to an insurance clue‑marketing scenario. The process integrates fragmented customer behaviors from mini‑programs, apps, and enterprise WeChat, uses AI to recognize demand stages, and automatically matches optimal operating strategies. The case demonstrates how the ontology transforms fragmented actions into precise decisions, shortens POC delivery, and improves conversion, prediction accuracy, and compliance.

Evolution Path of Ontology Construction

Start with a Minimal Viable Ontology (MVO) that supports 1‑2 key decisions, then let the ontology grow organically from high‑value use cases (production scheduling, risk control, lead marketing). Shared concepts (e.g., Customer, Order) are extracted across fragments to form a common core, while peripheral scenarios attach flexibly. Continuous feedback from runtime signals (field usage, decision path bypasses) drives iterative refinement, ensuring the ontology evolves from data management to a semantic backbone.

Conclusion

Transitioning from "business objects" to "scenario ontologies" enables enterprises to move from merely describing the world to actively operating within it. By integrating objects, links, logic, and actions, the ontology becomes a digital living entity that can reason, execute, and continuously adapt, providing a reusable, growing decision‑support structure.

References

Bob McGrew: Deep sharing on FDE mode as the PMF paradigm of the Agent era.

象生OPM: Decision‑centric ontology forward design – growing domain models from decision points.