From AI That Searches for Meaning to AI That Can Make Decisions Grounded in Meaning — A Semantic Decision Runtime Inspired by EvoOntology

🎥 The YouTube version is also available:

Semantic Decision Runtime: From Data Access to Safe AI Decision Execution

Books: Semantic Chunk Building from Evidence-Grounded Semantic Units: Transforming documents, tables, and business data into explainable, executable knowledge

When generative AI works with enterprise data, two very different capabilities are often conflated: being able to connect to data, and being able to understand that data correctly.

An AI agent can query database tables. It can read CSV files. It can search internal documents. It can even generate SQL. Yet none of this means that it correctly understands business terms such as “revenue,” “customer,” “transaction,” “approved,” or “active contract.”

Revenue may mean order value, invoiced value, cash received, or net revenue after cancellations. A customer may be a prospect, a contracting party, an end user, or a billing recipient. Even when a column exists, its name alone does not reveal when it became valid, which department owns its definition, or how exceptions should be handled.

This gap—data exists, but its meaning is not shared—is a fundamental challenge in connecting AI agents to real business operations.

EvoOntology, recently introduced, offers an important insight into this problem. It packages the meaning of real data as an ontology exposed through an MCP server, allowing agents to browse and resolve semantics at runtime. It also incorporates a self-evolution loop: failures are analyzed, and a revised definition is adopted only when it outperforms the previous version under the same conditions. This reframes semantic definitions from a static dictionary into an operational asset that is continuously evaluated and improved.

Chinoba takes this idea as a starting point, but does not limit the scope to data exploration. The goal is a Semantic Decision Runtime: a foundation that connects meaning, evidence, policy, authority, decision-making, execution, and outcomes.

An ontology is not a glossary

Ontologies are often treated as glossaries or mappings between business terms and data fields. That is important, but enterprise AI requires more.

For a concept such as “net revenue,” a name and a formula are not enough. We also need to know:

• Which transactions are included, and how cancellations and refunds are deducted
• Which policies, data sources, and responsible teams support the definition
• When the definition became effective
• Who may view, aggregate, externally share, or update it
• How far the value may be used for automated decisions and actions

In a Semantic Decision Runtime, a concept is not stored merely as a mapping to data. It is retained as a decision-capable unit with meaning and accountability.

semantic_object:
  id: metric.net_revenue
  label: Net Revenue
  definition: Confirmed revenue after cancellations and refunds are deducted
  sources:
    - table: order_transactions
      columns: [amount, status, refunded_at]
  calculation: "SUM(amount WHERE status='settled') - SUM(refund_amount)"
  owner: finance
  valid_from: 2026-01-01
  evidence:
    - policy: finance_metric_definition_v3
  access_policy: finance_analyst_only
  risk: medium

With this structure, an agent can explain not only which SQL it generated, but also why it generated that SQL and who is allowed to see the result.

Connecting knowledge, decisions, trust, and execution without separating them

Chinoba’s research has treated Knowledge Flow, the Decision Trace Model, Trust Infrastructure, and the Runtime OS not as isolated capabilities, but as one decision loop.

The Semantic Decision Runtime becomes the semantic integration layer within that loop.

1. Knowledge Flow transforms documents, tables, APIs, conversations, and business rules into concepts, relationships, constraints, and metrics.
2. The Semantic Layer resolves the terms in a question or task to actual data, definitions, evidence, and effective periods.
3. The Decision Layer connects situation, goal, constraints, options, and reasons, making clear what must be decided.
4. Trust Infrastructure evaluates the evidence behind knowledge, an agent’s capability, the validity of a decision, and the impact of execution.
5. The Runtime OS selects execution, a request for confirmation, or a stop based on authority, boundaries, and a Human Gate.
6. The Decision Trace records the path from semantic resolution to outcome and feeds it back into the next improvement cycle.

The crucial point is that understanding meaning does not automatically grant permission to act.

An AI may correctly resolve the definition required to determine that a customer has a high churn risk. That does not mean it is permitted to contact the customer automatically. It must still check boundaries related to personal data, contracts, brand, and the responsibility of the account owner, and hand the matter to a person when needed.

Resolving meaning is not permission to execute. This separation is the prerequisite for increasing autonomy safely.

Reading Palantir Ontology as a practical benchmark

An important practical benchmark for this vision is the Ontology in Palantir Foundry.

Palantir positions its Ontology as an “operational layer” for an organization, sitting above digital assets such as datasets, virtual tables, and models. It maps physical entities such as equipment and products, as well as business concepts such as orders and financial transactions, to the real world through Objects, Properties, and Links. It then combines Actions, Functions, and Dynamic Security to connect analytical results to real operational workflows. Palantir Ontology Overview

This is an implementation example of treating an ontology not as a data catalog, but as a shared model through which an organization can decide and act. Palantir’s architectural documentation likewise describes pairing the “nouns” that represent meaning with the “verbs” that cause change, modeling everything from simple updates to complex, multi-step business processes. The Ontology system

What Chinoba should learn from this is not to reproduce a product or a specific implementation approach. It is to adopt three ideas as comparable practical benchmarks.

Palantir’s value lies not only in allowing an organization to observe itself through dashboards, but in closing the loop between analysis and operations through the Ontology. Its documentation also describes the Ontology as a decision-centric organizational model that cohesively governs human and agent activity. Why create an Ontology?

Chinoba, by contrast, is not focused on building a particular integrated platform. Its focus is to make the accountability of meaning and decision portable across different data platforms, MCP servers, agents, DSLs, rule engines, and existing business systems. The Semantic Decision Runtime therefore takes the destination demonstrated by Palantir—a Semantic Operational Layer—as a reference point while placing provenance, temporal state, trust evaluation, Human Gates, Decision Trace, and self-improvement more explicitly at its core.

This is not a comparison of superiority. Palantir’s practice of integrating large-scale business data as Objects, Links, and Actions, and Chinoba’s vision of agents that browse meaning, show evidence, and coordinate within boundaries in the MCP era, can be read as mutually connected approaches.

Toward an MCP that returns evidence

The MCP for a Semantic Decision Runtime is not merely an MCP for search or SQL generation. It is an interface for making the way an agent handles meaning verifiable.

In particular, resolve_semantics must not return only an answer. At a minimum, it needs to return in a structured form the adopted definition, data sources, evidence, applicability conditions, ambiguity, and constraints on use.

This is not a design in which an explanation is generated after the fact. It is a design in which the meaning and evidence used as decision inputs are included in the execution path from the outset.

Turning self-evolution into trustworthy improvement

Semantic definitions are never finished. Regulations change, data structures change, and the language used by organizations changes. An agent’s incorrect answer can stem not only from a model limitation, but also from a missing semantic definition, an incorrect relationship, an outdated rule, or an ambiguous area of responsibility.

Failures should therefore be classified as follows:

• The wrong concept was resolved
• The correct concept was resolved, but an outdated definition was referenced
• Evidence existed, but the applicable scope was misunderstood
• Policies, authority, or boundaries were overlooked
• Feedback from outcomes did not return to the definition

An improvement candidate must not be applied directly to production. The old and new versions should be compared using the same data, the same question set, the same model, and the same budget conditions. A revision should be adopted only when, in addition to accuracy, it satisfies the following conditions:

• The correctness of execution outcomes improves, or at least does not deteriorate
• Missing evidence does not increase
• There is no violation of authority, privacy, or boundaries
• Human approval is obtained in high-risk domains
• Cost and response time remain within acceptable bounds
• The diff, evaluation, approval, and reason for release remain in the Trace

Only then does self-evolution become more than “answering better.” It becomes the growth of a knowledge foundation that is more explainable and safer to operate.

A Temporal Semantic Twin

It is equally important not to detach meaning from time.

Organizational state, contract terms, regulations, metric definitions, and authority all change. Today’s definition of a customer segment may not be the same as the definition six months ago. Semantic resolution must therefore answer not only “what does this mean?” but also “when was this meaning valid?”

Chinoba’s Semantic Digital Twin is not a system for monitoring individuals. It is a model for handling the state of organizations, operations, knowledge, and decisions together with their temporal context.

It makes it possible to answer questions such as:

As of March 2026, why did this agent adopt this definition, make this recommendation, and ask for human confirmation?

Reproducing and verifying AI behavior requires more than a model output log. It requires the preservation of the meaning, policy, authority, data state, and reasoning that existed at the time.

Three domains to implement first

There is no need to build an enterprise-wide ontology from the outset. It is better to begin with a small domain in which the round trip between meaning and decision is clear.

The first domain is Chinoba’s research assets. The architecture, concepts, and implementation examples across chinoba.org, blog posts, books, and GitHub can be connected through the relationships among Knowledge Flow, Decision Trace, Trust, Runtime OS, Multi-Agent Coordination, and Runtime Society. This becomes both a knowledge map for the research and a public demonstration of a semantic foundation.

The second is estimation and unit-price agreements. Requirements, suppliers, annual rules, unit prices, acceptable ranges, approvers, and negotiation outcomes can be connected semantically. Here, it is important that AI not only propose a decision, but also show the rules and evidence behind it and choose Act / Ask / Stop.

The third is the Community Intelligence Platform. It can connect Programs, Channels, Campaigns, Members, Rewards, reactions, and notifications to support operational state understanding. At the same time, it must make purpose, consent, data boundaries, and operational accountability explicit both in the ontology and in the Runtime OS, so that it does not become a system for individual surveillance or automatic evaluation.

The evolution of meaning develops an organization’s capacity to decide

In the AI era, it is not enough for a knowledge foundation to search documents. It is not enough to reference data. Nor is it enough for an agent simply to become more capable.

What is needed is a cycle in which AI, people, and organizations refer to the same meanings; attach evidence and accountability to those meanings; make decisions and execute within boundaries; and improve the definitions through outcomes.

Semantic Decision Runtime is not the name of a finished product. It is a direction that Chinoba is exploring.

Knowledge becomes actionable when meaning is traceable.
Intelligence becomes trustworthy when action remains accountable.

From AI that searches for meaning to AI that can make decisions grounded in meaning, explain them, delegate to people when necessary, and learn again from the results.

This transition becomes the next foundation that connects Knowledge Flow to Trust Infrastructure, and ultimately to Runtime Society.

Chinoba

Chinoba

Intelligence as Relationship

Research Platform

founded by

Masao Watanabe

AI Systems Architecture
Decision Trace
Human–AI Coordination
Algorithmic Governance