From Organizational Raw Data to an Evidence-Grounded Ontology Evidence-Grounded Ontology Construction Beyond Proper-Noun Collection

🎥 The YouTube version is also available:

From Operational Data to Evidence-Grounded Ontology | Building Knowledge for AI Decisions

Books: KNOWLEDGE FLOW PRACTICAL GUIDE: Transform Enterprise Knowledge into Al-Ready Knowledge Infrastructure

Organizations are filled with operational source data (Raw Data): email, meeting minutes, policies, procedures, contracts, PDFs, spreadsheets, business tickets, system logs, and records of conversations. These sources record the language an organization uses every day, its exception handling, decision criteria, and division of responsibilities.

By broadly extracting proper nouns from such data and using an LLM to supplement them with hypernyms, hyponyms, and similar terms, it is possible to create the seeds of a knowledge graph quickly. This is a useful starting point for exploration.

Yet a different problem appears when those seeds are developed directly into an ontology. Because relationships are expanded around names, unsupported hierarchies and similarity relationships can accumulate in plausible-looking form, without grounding in the source data or the context in which the terms were used.

“Customer” and “user” may sound similar, but they can play different roles in contracting, billing, and support. Likewise, the outcome of a decision changes depending on whether “revenue” means order value, invoiced value, cash received, or net revenue after cancellations.

What is needed is not to proliferate knowledge around nouns. It is to extract the facts, relationships, events, rules, constraints, and intentions present in the source material, then integrate them into concepts together with their evidence.

This article calls that approach Evidence-Grounded Ontology Construction. Within Chinoba’s Knowledge Flow, it is a more verifiable method for constructing ontologies that connect Raw Data to an Ontology, Knowledge Graph, DSL, Decision Trace, and Runtime OS.

The limitations of a proper-noun-centered approach

The conventional approach extracts proper nouns and nouns from Raw Data, then lets an LLM supplement hypernyms, hyponyms, related concepts, and similar concepts. While it is useful for exploratory knowledge discovery, it must overcome the following issues before it can become a knowledge foundation for business use.

The point is not to suppress the generative ability of LLMs. It is to make clear which evidence supports an LLM-proposed relationship, within what scope it applies, and at what status it may be used.

From Raw Data to an approved Ontology

Evidence-Grounded Ontology Construction does not merge extraction, integration, approval, and runtime use into a single process.

flowchart TD
  A["Organizational Raw Data\nEmail / Documents / Tables / Tickets / Logs / Conversations"] --> B["Semantic Chunking\nPreserve context, source, time, and authority"]
  B --> C["Structured Extraction\nEntity / Event / Rule / Constraint"]
  C --> D["Concept Resolution\nMatch, separate, and merge candidates"]
  D --> E["Evidence Graph\nRelationships with evidence"]
  E --> F["Ontology Draft\nVersioned as hypotheses"]
  F --> G["Validation & Human Review"]
  G --> H["Approved Ontology\nSupplied to Runtime / DSL"]
  H --> I["Trace & Feedback"]
  I --> F

In this flow, information extracted from Raw Data does not immediately become a correct ontology. It first becomes an evidence-backed candidate. Only after validation and approval does it become knowledge for decision-making and execution.

Raw Data is not a single kind of source

Organizational knowledge is distributed across multiple media. Each source differs in evidential strength, freshness, and permitted scope of use. Operational source data must therefore not all be treated as the same kind of “text.”

The essential point is that an item in a conversation record or an individual email must not be treated as knowledge of the same strength as a policy or contract. An operational exception shared by a team can be an excellent improvement candidate. It still needs consistency with formal rules, owner confirmation, and a decision on scope before it becomes a formal rule.

Preserving source-specific context through Source Adapters

Before each Raw Data source is transformed into a common Semantic Chunk, it passes through a Source Adapter that extracts the context specific to that medium.

Email Adapter       : sender / recipients / thread / attachment / approval wording
Document Adapter    : title / section / version / effective dates / cited policy
Table Adapter       : schema / unit / grain / refresh cadence / data owner
Ticket Adapter      : status transition / assignee / priority / acceptance criteria
Log Adapter         : event time / actor / system / operation / result / error code
Conversation Adapter: speaker / channel / thread / reply relationship / reaction

This preprocessing lets all inputs be searched and compared in a common form without losing the semantics and governance information of their original source. It enables a single knowledge graph to distinguish statements such as: “a director approved this in an email,” “the current policy says otherwise,” and “the logs show that the process actually failed.”

1. Split Raw Data into meaningful units

Operational source data should not be handled merely as strings or records, but as meaningful units. The meaning of a concept depends not only on the words themselves, but on who used them, in which medium, when, and within which topic or business context.

{
  "chunk_id": "raw-20260918-042",
  "text": "If the defect rate exceeds 5%, notify the Quality Assurance Department.",
  "source_type": "operational_document",
  "speaker_role": "quality_manager",
  "timestamp": "2026-09-18T10:15:00+09:00",
  "source_reference": "quality-operations-procedure-v2",
  "authority_hint": "operational_instruction",
  "thread_context": ["Discussion of the previous day’s inspection results"]
}

At this stage, expressions such as timestamps, URLs, counters, and overly generic nouns are excluded. Information such as speaker, sender, role, thread context, recipients, attachments, document version, references, data owner, and access rights is retained.

The later stages need this information to decide whether content is a formal policy or an operational conversation, and whose authority supports it.

2. Extract business semantic frames, not just Entities

Ontology construction requires more than a list of Entities. Each chunk should yield at least the following six kinds of information.

For example, the statement “If the defect rate exceeds 5%, notify the Quality Assurance Department” can be extracted as follows.

{
  "entities": [
    {"mention": "defect rate", "type": "Metric"},
    {"mention": "Quality Assurance Department", "type": "OrganizationUnit"}
  ],
  "event": {
    "type": "ThresholdExceeded",
    "subject": "DefectRate",
    "condition": "> 5%",
    "time": "when_observed"
  },
  "rule": {
    "type": "NotificationRule",
    "if": "DefectRate > 0.05",
    "then": "Notify(QualityAssurance)",
    "modality": "required"
  },
  "evidence": {
    "source_chunk_id": "raw-20260918-042",
    "quote": "If the defect rate exceeds 5%, notify the Quality Assurance Department."
  }
}

The result is not a hypernym for the noun “defect rate.” It is an evidence-backed candidate for an executable business rule: under which condition, who should do what.

3. Separate extraction from Concept Resolution

Integrating an extracted expression into an existing concept must be a separate step.

When the expression “customer” appears, it should not immediately be merged into an existing Customer concept. The system must compare whether it refers to a contracting party, a service user, or a billing recipient.

Every resolution result must fall into one of three states.

• Resolved: It can safely be integrated into an existing canonical concept.
• Candidate: It is similar, but evidence is insufficient for integration.
• Ambiguous: Multiple interpretations exist and it must not be merged.

It is important to retain “unknown” as a knowledge state rather than erasing it as a failure. This prevents an LLM from helpfully but incorrectly merging “customer” and “user.”

4. Manage relationships themselves with evidence

An ontology should manage relationships as well as concepts. Business rules in particular need conditions, validity periods, evidence, and status—not just a subject and an object.

relation:
  id: rule.notify_quality_when_defect_rate_exceeds_threshold
  subject: metric.defect_rate
  predicate: triggers_notification_to
  object: org.quality_assurance
  condition: "value > 0.05"
  source:
    chunk_id: raw-20260918-042
    quote: "If the defect rate exceeds 5%, notify the Quality Assurance Department."
  confidence:
    extraction: 0.94
    resolution: 0.91
  status: candidate
  valid_from: null
  valid_to: null

confidence is useful for prioritizing candidates. It must not, however, be enough to authorize runtime use. Usability must be decided from source, authority, validity period, contradiction, and approval status together.

5. Separate meaning from executable rules

Chinoba does not conflate the layers of knowledge.

• Ontology: What are a customer, defect rate, contract, and Quality Assurance Department?
• Knowledge Graph: Who relates to what, and what happened when?
• DSL / Policy: When conditions are met, what should be permitted, requested, or stopped?
• Runtime OS: Is the operation permitted under the current situation and authority?

Even if the operational source data contains the statement “send an email to the customer,” it does not become an automatic execution rule.

candidate_rule:
  if: "churn_risk > 0.8"
  then: "send_email(customer)"
  status: draft
  concerns:
    - consent_unknown
    - message_template_unknown
    - owner_authority_unknown
  runtime_decision: ask

Only after consent, ownership, a template, and sending authority are satisfied can the candidate be handed to the Runtime OS as an approved rule. Understanding meaning and being permitted to act are different things.

6. Treat the Ontology Repository as a versioned knowledge asset

An ontology is not a finished diagram. It is a knowledge asset that changes, is corrected, and becomes outdated. Concepts, relationships, and rules should therefore be managed in the following states.

Every change should retain at least the following information:

• What was added, merged, separated, or retired
• Which Raw Data supports it
• Which evaluation judged it appropriate
• Who or which Policy approved it
• When it is valid from and until
• Which Decision Trace or business outcome prompted the change

In other words, changes to the Ontology itself become subjects of the Decision Trace.

7. Turn automatic improvement into evaluated proposals

Agent misunderstandings, human corrections, and exception handling are important materials for improving an ontology. Improvement, however, is not self-rewriting.

1. Collect agent misunderstandings, human corrections, and exception handling.
2. Classify their causes.
   • Entity extraction errors
   • Incorrect merging of synonyms or polysemous terms
   • Relationship errors
   • Missing rules
   • Expired validity
   • Missing Policy or Boundary
3. Generate a proposed ontology diff.
4. Compare the old and new versions using the same questions, data, model, and budget.
5. Send high-risk changes to Human Review.
6. Promote only passing diffs to approved.

Evaluation must not end with extraction F1 alone.

This mechanism connects with the EvoOntology idea of adopting a change only when it improves under the same conditions. Chinoba extends the evaluation beyond accuracy to include evidence, constraint compliance, reproducibility, and a Human Gate.

A minimal implementation can begin with four layers

There is no need to create an enterprise-wide ontology from the beginning. Start with the operational source data relevant to one business domain and implement the following four layers.

Organizational Raw Data
  └ Email / Document / Table / Ticket / Log / Conversation
  → Semantic Chunk Store
  → Extraction Store
     └ Entity / Relation / Event / Rule / Constraint / Evidence
  → Ontology Draft Repository
  → Approved Ontology + Knowledge Graph

The MCP can begin with these six tools.

• browse_semantics: Explore concepts, relationships, and rule candidates.
• resolve_semantics: Map words in a question to canonical concepts and evidence.
• explain_semantics: Return definitions, original sources, confidence, and validity periods.
• propose_semantic_change: Create candidate diffs.
• evaluate_semantic_change: Compare the old and new versions.
• trace_semantic_decision: Store semantic resolution, decisions, and outcomes.

Turning operational source data into verifiable organizational knowledge

With this approach, operational source data distributed throughout an organization ceases to be a collection of disconnected records. Its tacit knowledge, formal definitions, exceptions, decision criteria, actual outcomes, and role allocations are transformed into a verifiable knowledge foundation without losing their source or context.

Raw Data → Semantic Chunk → Evidence Extraction → Concept Resolution → Ontology / Knowledge Graph → DSL / Policy → Runtime OS → Decision Trace → Evaluated Evolution

The shift is from a model in which an LLM proliferates knowledge around proper nouns to one that starts from facts present in Raw Data, constructs meanings, relationships, and rules with evidence, and uses only approved knowledge for decisions.

Through this transition, Knowledge Flow becomes more than preprocessing for search. It becomes the knowledge infrastructure through which an organization can decide, explain, and learn again.

Chinoba

Chinoba

Intelligence as Relationship

Research Platform

founded by

Masao Watanabe

AI Systems Architecture
Decision Trace
Human–AI Coordination
Algorithmic Governance