Three-Layer Ontology Intelligence: Separating Semantics, Decisions, and Actions

The previous article established that ontology semantics provide the foundation for AI to understand business, and that ontology intelligence must further bring semantics into decision-making and controlled action.

When moving to architectural design, several questions immediately arise:

If rules are already defined in the ontology, why is a decision layer still needed?

If the decision layer knows what to do, why can't it call APIs directly?

MCP tools can both query semantics and trigger actions—which layer do they belong to?

Agents can reason and select tools; do we still need separate decision and action mechanisms?

If these boundaries are not clarified, the ontology library, rule engine, workflow, tool interfaces, and Agent Runtime all get piled together into a seemingly complete but hard-to-evolve "intelligence center."

The value of the three-layer architecture lies not in splitting the system into three products, but in separating the three responsibilities of "defining meaning, forming decisions, and changing state."

Layering Should Be by Responsibility, Not Technical Components

The semantic, decision, and action layers are logical responsibilities; they do not necessarily map to three independently deployed systems. A single platform can provide all three capabilities, and a single technical component may play different roles in different scenarios.

For example, a rule engine can validate data against semantic constraints (semantic validation) or select a handling strategy based on risk level (decision). An API can query customer state (read) or modify credit limit (write with business side effects). Therefore, layer assignment depends on what the component is responsible for in the current chain, what it outputs, and whether it changes external business state.

Semantic Layer: Defining "What Is"

The semantic layer's core responsibility is to establish a unified, stable, computable meaning for the business world. It must define:

How business objects are identified and where their boundaries lie;

What attributes, relationships, states, and events represent;

How terms, metrics, and classification calibers are unified;

What data, documents, and human confirmations serve as evidence for business facts;

The business meaning, scope, and associated objects of rules and actions.

Take overdue receivables as an example. The semantic layer must clarify what "accounts receivable," "due date," "grace period," "valid repayment," and "commercial dispute" mean, and what evidence supports the fact "this receivable is overdue."

The semantic layer can define the basic semantic condition "past due date, not in grace period, and no valid repayment" constitutes overdue, but it should not directly decide that the customer's credit limit must be restricted.

The semantic layer's main output is a semantic contract: unified object identifiers, fact structures, concept definitions, relationship constraints, evidence references, and version information. It can provide a semantic view of current facts but should not replace the source business system's ultimate authority over real-time state and transactions.

Decision Layer: Judging "What Should Be Done"

The decision layer receives semantically aligned current facts, combines them with business goals, applicable rules, and risk boundaries, and forms an explainable, auditable disposal conclusion.

This layer can combine multiple judgment methods:

Ontology reasoning for concept classification and relationship derivation;

Constraint engines to detect data, state, or relationship violations of business requirements;

Decision tables, rule engines, or business code for deterministic handling strategies;

Large models, constrained by semantics, evidence, and rules, to assist in understanding complex text, identifying special situations, and generating candidate options.

Agents can undertake part of decision orchestration and situational judgment, but decision criteria, evidence conditions, and risk boundaries must not be hidden entirely in prompts or uninspectable reasoning processes. Whether decisions are made by an independent service or inside an Agent, their inputs, outputs, rule versions, and human confirmation boundaries must be testable and auditable.

For example, facing a confirmed overdue receivable, the decision layer must combine overdue days, customer credit level, historical recovery, dispute handling status, and organizational policy to decide whether to send a reminder, create a collection task, suggest credit limit adjustment, or submit for manual review.

The decision layer's output should not be just a sentence like "recommend limit restriction," but a traceable decision record including:

Current judgment and candidate options;

Applicable rules and their versions;

Dependent business facts and evidence;

Uncertainties, risk levels, and exceptional situations;

Recommended actions and their human confirmation requirements.

The decision layer can propose actions but should not itself produce external business side effects.

Action Layer: Solving "How to Execute Under Control"

The action layer receives action requests that have passed decision and permission checks and, where necessary, human confirmation, and translates them into controlled calls to real business systems.

The core of the action layer is not merely "having an API," but defining execution constraints through a complete action contract, then fulfilling guarantees via controlled business services, workflows, and runtime mechanisms:

Which business object the action targets;

What state and evidence conditions must be satisfied before execution;

Who can initiate, and which scenarios require human confirmation;

How to handle idempotency, concurrency, timeouts, retries, and partial failures;

What state transitions and business events should be produced on success;

How to recover, compensate, or escalate to manual handling on failure;

What execution receipts and audit evidence should be returned.

In the overdue handling scenario, "create collection task," "adjust credit limit," and "initiate deduction with valid authorization" are three actions with completely different risk profiles. They should not share the same permission level, human confirmation, or failure handling strategy.

Actions can be invoked via MCP tools, Tool APIs, or workflow task publishing, but protocols and interfaces do not automatically bring the above guarantees. Operations that truly change business state must still be executed by controlled business services or source systems that own transaction responsibility.

A Common Anti-Pattern: Compressing Three Layers into One Prompt

A common practice is to stuff the overdue definition, handling rules, and interface descriptions into a prompt, let the large model read customer data, judge risk, assemble parameters, and directly call update_credit_limit.

This chain looks short but hides three responsibilities in one model output: the overdue caliber cannot be versioned independently, decision rationale cannot be stably reproduced, and action execution lacks preconditions, permissions, idempotency, and failure handling. Once the prompt is modified, the team struggles to identify whether the change affects business semantics, decision strategy, or action boundaries.

The three-layer architecture is not about deliberately lengthening the chain, but about splitting the call into verifiable handoffs:

Semantic context → Decision record → Audited action request → Controlled execution → Execution receipt.

Beyond Three Layers: Capabilities That Should Not Be Forced In

Semantics, decisions, and actions are the three core logical responsibilities of ontology intelligence, but they do not equal a complete enterprise runtime architecture.

Business systems and data platforms provide raw facts, historical data, and real-time state; source business systems retain transaction authority;

Object runtime (optional) organizes current object state, state transitions, events, and action results under unified semantics;

Agent Runtime handles task orchestration, session state, pause/resume, retry strategies, and human takeover;

Security and governance system vertically spans all three layers, managing identity, permissions, risk, audit, versioning, and release;

MCP, API, and messaging protocols handle capability publishing and interaction; they are connection methods, not new business layers.

Forcing these capabilities into one of the three layers easily blurs responsibility boundaries. A more reasonable approach is to let the three layers define core business responsibilities, while these lateral or peripheral capabilities provide data, runtime, security, and connectivity support.

Four Questions to Judge Where a Capability Belongs

When a rule, service, or tool doesn't know which layer it belongs to, ask four questions sequentially:

Is it defining meaning? If it defines objects, relationships, states, calibers, evidence, or rule semantics, it belongs to the semantic layer.

Is it selecting a handling option? If it forms a judgment based on current facts, goals, and rules, it belongs to the decision layer.

Does it change external business state? If it creates tasks, sends instructions, modifies state, or produces transactions, it belongs to the action layer.

Is it actually managing data, tasks, or security? If it manages source data, task state, identity permissions, or communication connections, it should not be forced into the three layers just to fit.

These four questions clarify real boundaries better than looking at product menus, technical names, or deployment locations.

Layering Is Not Isolation: Three Layers Must Have Verifiable Handoff Contracts

After responsibilities are separated, the three layers cannot rely only on natural language, prompts, or ad-hoc conventions; they need explicit engineering contracts.

The semantic layer passes semantic context to the decision layer. It includes at least object identifiers, semantically interpreted current facts, states, relationships, evidence references, candidate rules, applicability conditions, and semantic version.

The decision layer passes an auditable action request to the action layer. It includes at least decision record ID, decision conclusion, rationale, risk, recommended action, target object, preconditions, and human confirmation requirements.

The action layer returns a reconcilable execution receipt. It includes at least action contract version, idempotency key, execution status, external transaction ID, state transition, business events, failure reason, and audit information.

In actual flow, semantic context, decision record, and action request are generated and passed stepwise by layer, not as a single payload in one API call. To centrally show field correlations, a simplified combined structure can be used for understanding:

{
  "semantic_context": {
    "object_type": "Receivable",
    "object_id": "AR-20260722-001",
    "facts": {
      "overdue_days": 35,
      "dispute_status": "none_confirmed"
    },
    "evidence_refs": [
      "invoice:INV-001",
      "payment-ledger:PL-001",
      "dispute-check:DC-001"
    ],
    "observed_at": "2026-07-22T10:00:00+08:00",
    "semantic_version": "receivables-2.3"
  },
  "decision": {
    "decision_id": "DEC-20260722-001",
    "rule_version": "collection-policy-4.1",
    "risk_level": "high",
    "recommended_action": "adjust_credit_limit",
    "requires_human_confirmation": true
  },
  "action_request": {
    "action": "adjust_credit_limit",
    "action_contract_version": "adjust-credit-limit-1.4",
    "target_object_id": "CUS-001",
    "decision_id": "DEC-20260722-001",
    "input": {
      "new_credit_limit_cny": 500000
    },
    "approval_id": "APR-001",
    "idempotency_key": "CUS-001:DEC-20260722-001"
  }
}

Here none_confirmed is not a default "no dispute record found" but indicates the system completed a dispute check at a specific query time and data coverage range, supported by dispute-check evidence. If coverage or evidence is insufficient, it should return unknown or evidence_insufficient, not be interpreted as no dispute.

After action completion, the response should not just return a success but a reconcilable result:

{
  "action_contract_version": "adjust-credit-limit-1.4",
  "idempotency_key": "CUS-001:DEC-20260722-001",
  "execution_status": "succeeded",
  "external_transaction_id": "CRM-TX-001",
  "state_transition": {
    "from": "credit_normal",
    "to": "credit_restricted"
  },
  "audit_id": "AUD-001"
}

This is only a structural illustration; specific fields must be designed according to business risk, existing interfaces, and audit requirements. Its value lies in making semantics, decisions, and actions not just a piece of model context, but engineering contracts that can be separately validated, versioned, and audited.

Runtime failures, human rejections, and business results must also flow back to determine whether issues originate from semantic definitions, decision rules, or action implementations, then enter their respective versioning and evaluation processes.

Summary

The semantic layer, decision layer, and action layer are not three trendy names but three categories of engineering responsibilities that must be governed separately.

The semantic layer stabilizes business meaning, the decision layer selects options based on current facts and rules, and the action layer changes real business state under permission, transaction, and audit constraints. The three layers establish verifiable handoffs through semantic context, action requests, and execution receipts, while data, runtime, security, and protocol capabilities provide peripheral support.

Only by separating "defining business meaning, forming decisions, and executing actions" can an enterprise version, test, and govern semantics, rules, and business side effects independently.

Reference: China Artificial Intelligence Industry Development Alliance, Big Data Technology Standard Promotion Committee, "Ontology Intelligence Research Report (1.0)".