Research / Knowledge Flow

Knowledge Flow

Enterprises already store more information than any team can read. Storing it and searching it are not the same as an AI understanding it. An AI that can read a document is not yet an AI that can decide.

Documents, PDFs, spreadsheets, design specifications, chat, email, and databases hold enormous amounts of enterprise knowledge — distributed across formats, departments, and systems that were never designed to agree with one another. Knowledge Flow is the discipline of converting that distributed information into Knowledge Assets — Ontology, Knowledge Graph, DSL, Policy, and Constraint — that carry meaning, source, validity, and authority forward into a decision. Its spine is one path: Document → Knowledge → Decision → Trace → Learning. In the Chinoba architecture, Knowledge Flow is the knowledge foundation beneath the Decision Trace Model, the Decision Runtime Kernel, and the Runtime OS.

Knowledge Flow — Documents become Knowledge, Knowledge becomes a Decision, a Decision becomes an Action, and an Action leaves a Trace, forming the enterprise knowledge infrastructure for the AI era.
The path Knowledge Flow exists to carry: Document → Knowledge → Decision → Action → Trace.
Featured Resources

Start Here — Books, Video, and the Blog

The practical guide above leads this line of inquiry. Below it are the neighboring Chinoba books, videos, and essays on Ontology, Knowledge Graph, Semantic Digital Twin, Decision Trace, and Runtime AI Governance that this page draws on.

📚 More Books

Neighboring practical guides on the knowledge, semantic, and runtime layers this page connects.

Japanese Edition
Knowledge Flow実践ガイド: 企業知識をAIが利用できる知識基盤へ変換する →
English
Knowledge Infrastructure: The Knowledge Foundation of the AI Era → A Practical Guide to Semantic Digital Twin for Physical AI → Runtime AI Governance: Practical Guide → Decision Trace Model Practical Guide →
Japanese
知識のインフラ — 知識の流れが、未来の知性を作る →

📺 Watch on YouTube

Visual introductions to Knowledge Flow, Knowledge Infrastructure, and the runtime it feeds.

English
Knowledge Flow: Transforming Enterprise Knowledge into AI-Ready Knowledge Infrastructure → Knowledge Infrastructure: Why Knowledge Must Flow in the Age of AI → Beyond Model Governance: Building Trustworthy AI Through Knowledge Flow → Semantic Digital Twin for Physical AI →
Japanese
Knowledge Flow実践ガイド — 企業知識をAIが利用できる知識基盤へ変換する → Knowledge Infrastructure — AI時代の知識基盤｜Knowledge Flowが未来の知性をつくる →

📰 From the Blog

Long-form essays behind this page's argument, on knowledge infrastructure, retrieval, and runtime governance.

English
Knowledge Infrastructure → Why AI Failed to Eliminate Variability → How to Find Knowledge in the Depths of the Long Tail → Governance Boundary Systems →
Japanese
知識インフラストラクチャ →
03 / Why RAG Alone Is Not Enough

Why RAG Alone Is Not Enough

Retrieval-augmented generation is genuinely useful for surfacing a relevant passage. It was never built to settle whether that passage still holds, for which organization, product, region, or situation it applies, or what exception overrides it. A fluent answer is not the same thing as a usable enterprise decision.

What Retrieval Settles, and What It Cannot

RAG can search documents, summarize them, and answer a question in fluent prose. It cannot, on its own:

  • reason across multiple documents and systems at once
  • evaluate a Policy or a Constraint against the current situation
  • execute a decision rule
  • determine who is authorized to act on what it found
  • decide what happens when two sources disagree

A document being searchable says nothing about whether the knowledge inside it is still valid, or which organization, product line, region, or condition it is allowed to govern.

Context Gap and Knowledge Gap

Two distinct gaps stand between a fluent answer and a correct enterprise decision:

  • Context Gap — the model does not know the specific situation: which entity, process, contract, or event this question is actually about.
  • Knowledge Gap — even once the context is known, the model has no structured way to hold the organization's own terminology, business rules, approval conditions, and cross-department relationships.
AI can answer. It cannot yet decide. Closing that distance is what Knowledge Flow is for.

Knowledge Flow does not compete with retrieval — it gives retrieval something worth trusting. Ontology resolves company-specific terms to one canonical meaning, the Knowledge Graph holds the relationships a single passage cannot express, and DSL and Policy make the applicable rule explicit rather than implied. Retrieval still finds the candidate; Knowledge Flow is what turns the candidate into knowledge a decision can be built on.

Diagram comparing Traditional RAG — document, embedding, search, answer — with Knowledge Flow — document, ontology, knowledge graph, DSL, decision — captioned that RAG focuses on finding information while Knowledge Flow focuses on building and leveraging knowledge.
Traditional RAG ends at an answer; Knowledge Flow continues on to a structured, governed decision.
04 / The Knowledge Flow Pipeline

The Knowledge Flow Pipeline

Knowledge Flow is not a single transformation but ten stages, each responsible for preserving something specific — meaning, source, validity, accountability, or reproducibility — as information moves from a raw document toward a decision a Runtime can act on.

Pipeline Diagram

Knowledge Flow — the Ten Stages

  1. 01 Source and Ingestion Documents, conversations, and records enter through connectors that preserve who owns each source, not just its text. ingest
  2. 02 Normalization and Metadata Formats are unified and metadata attached, so version, department, and access rights survive the conversion, not just the words. normalize
  3. 03 Semantic Chunking Content splits along headings, procedures, rules, exceptions, and tables — units that preserve meaning, not fixed-length fragments that break it. chunk
  4. 04 Knowledge Extraction Entities, relations, constraints, events, intents, and policy candidates are drawn out — each kept as a candidate with its source attached, not an asserted fact. extract
  5. 05 Ontology Resolution Aliases collapse to one canonical concept, so responsibility for a term's meaning is traceable rather than left to whichever department wrote it first. resolve
  6. 06 Knowledge Graph Construction Entities, relations, and events connect into a graph that keeps provenance intact across every source that contributed a piece of it. connect
  7. 07 DSL / Policy / Constraint Formalization Decision conditions are formalized with scope, authority, and exception intact — reproducible enough for a Runtime to evaluate, not just read. formalize
  8. 08 Human Review and Validation Schema, ontology, and risk-based review put a named person's judgment behind every candidate before it is trusted, proportional to what it could affect. review
  9. 09 Knowledge Repository and Versioning Approved assets are versioned and dated, so a decision made last quarter can be reproduced against the knowledge that was actually in force then. version
  10. 10 Runtime Delivery and Feedback Knowledge reaches the Decision Runtime Kernel, and what the decision produced returns as feedback that keeps the pipeline honest. deliver

None of these ten stages is only data processing. Each one exists to keep a specific property intact — meaning, source, current validity, who is accountable, or whether the result can be reproduced later — as knowledge moves from a document toward a decision.

Knowledge Flow Overview — eight linked stages from Enterprise Documents through Document Ingestion, Knowledge Extraction, Ontology Builder, Knowledge Graph, DSL Generator, and Knowledge Repository, to the Decision Trace Model and Runtime OS.
The pipeline end to end — from enterprise documents to the Decision Trace Model and Runtime OS.
05 / From Documents to Semantic Knowledge Assets

From Documents to Semantic Knowledge Assets

Turning a document into a Knowledge Asset is not one step. It runs from how a source is captured, through how it is split, to how confidently anything extracted from it can be trusted before a human ever signs off on it.

Ingestion, Normalization, Semantic Chunking

Connectors pull in documents, conversations, and operational data while carrying forward what matters beyond the text itself:

  • normalization across formats
  • metadata — owner, version, department, date
  • incremental updates, not full re-ingestion
  • inherited access rights, not flattened permissions

Semantic chunking then splits content along headings, procedures, rules, exceptions, and tables — the units a reader would actually recognize as meaningful — rather than cutting text at a fixed character count that can sever a rule from its exception.

Candidates, Not Facts

An LLM extracts entities, relations, constraints, events, intents, and policy candidates from a chunk. None of this is treated as settled:

  • every extraction is a Candidate, not an asserted fact
  • every Candidate carries its Provenance — the source it came from
  • deterministic processing and LLM processing stay separated
  • Schema Validation and Risk-Based Human Review gate promotion
Source → Evidence → Claim → Knowledge

A chain like this is what lets an organization trace any piece of knowledge a decision relied on back to the document, message, or event it actually came from.

LLM-based Knowledge Extraction — an enterprise document processed by an LLM into six candidate types: Entity, Relation, Constraint, Event, Intent, and Rule, captioned that the LLM is used as a knowledge-extraction engine, not only to generate answers.
Extraction produces candidate Entities, Relations, Constraints, Events, Intents, and Policy Candidates — not settled fact.
06 / Ontology, Knowledge Graph, and Graph RAG

Ontology, Knowledge Graph, and Graph RAG

Extraction produces fragments. Ontology and the Knowledge Graph are what turn those fragments into one coherent, navigable structure — the layer of meaning and relationship that Knowledge Flow actually delivers to a decision.

Ontology: One Vocabulary for the Enterprise

An Ontology defines the organization's own Concepts, Entities, Relations, Attributes, Units, Hierarchies, and Constraints — not a generic vocabulary borrowed from outside it. It also governs how that vocabulary changes over time:

  • alias integration to a single Canonical Name
  • concept merge and concept split
  • version management
  • impact analysis before a change is applied

Knowledge Graph and Graph RAG

The Knowledge Graph connects documents, entities, relations, events, rules, and constraints across every source that touched them — the context a single retrieved passage cannot carry on its own. Graph RAG retrieves against that structure, not against embeddings alone:

  • embedding search
  • entity resolution
  • graph traversal
  • Policy and Constraint retrieval
  • context assembly
  • trace recording
A knowledge graph is not a bigger index. It is the path a decision walks across sources, toward a rule that actually applies.
Knowledge Graph — structured knowledge including entities, relations, constraints, events, and intent connected into a network of relationships such as Customer, Order, Product, Factory, Machine, and Inspection, enabling multi-hop inference, traceability, and explainability.
Knowledge held as a network of relationships, not a set of documents, is what makes multi-hop inference and traceability possible.
07 / DSL, Policy, and Decision-Ready Knowledge

DSL, Policy, and Decision-Ready Knowledge

A regulation or procedure written in natural language cannot be evaluated consistently — its conditions, exceptions, priority, and authority stay implicit. A DSL makes those elements explicit enough for a Runtime to evaluate them the same way every time.

A DSL Is a Knowledge Asset, Not a Program

A DSL is not a direct execution command. It is an input the Decision Runtime evaluates together with Policy, Constraint, Boundary, Risk, and Human Authority — formalizing:

  • Rule Identity and Scope
  • Context Condition
  • Action and Authority
  • Exception and Priority
  • Effective Period
  • Trace Source

Every element here ties the rule back to who is responsible for it, what document it came from, and which version is currently in force.

Validating and Governing a Rule

A rule is not trusted the moment it is generated. Before publication it passes through:

  • schema, ontology, type, and unit validation
  • conflict detection — action, authority, priority, scope, temporal
  • versioning and diff review
  • human review, proportional to risk
  • rollback, if a published rule turns out to be wrong
A DSL is not the decision. It is the condition under which a Runtime is allowed to reach one.
DSL Generator — a natural-language rule from an enterprise document, such as a contract-amount approval condition, passed through LLM-based rule extraction and validation into an executable DSL rule with IF and THEN clauses.
A decision rule buried in a document is extracted, validated, and formalized into an executable — but not self-executing — DSL rule.
08 / Knowledge Governance, Human Review, and Continuous Learning

Knowledge Governance, Human Review, and Continuous Learning

Knowledge Flow does not end once an asset is published. Every Knowledge Asset needs an owner and a lifecycle, and every change to it needs to reach the rest of the system in an order that stays verifiable.

What Every Knowledge Asset Carries

Beyond its content, each asset carries:

  • Owner and Authority
  • Validity and Scope
  • Confidentiality
  • Provenance
  • Version and Lifecycle state

Change arrives from many directions — a new document, an ECN, a revised policy, a conversation, or an event on the floor. Each has to propagate through Knowledge Candidate, Ontology, Knowledge Graph, DSL, and Repository, in an order that keeps the system consistent rather than momentarily contradictory.

A Loop, Not a One-Way Ingestion

For anything that matters — a new extraction, a rule change, a concept change — a human can:

  • Review the diff against the previous version
  • Approve it as-is
  • Reject it
  • Override what the system proposed

And once a decision is made, its Decision Trace and outcome return into the pipeline — improving the knowledge, the rules, and their quality the next time the same situation occurs.

Knowledge is not created by AI alone. It is co-created by humans and AI, reviewed, approved, or overridden, and improved by what happens next.
09 / Knowledge Flow in the Decision Runtime and Runtime OS

Knowledge Flow in the Decision Runtime and Runtime OS

Knowledge Flow and the Runtime OS divide the work cleanly. One builds and governs knowledge; the other resolves a live situation against it and decides what may happen next.

Two Systems, One Loop

Knowledge Flow is responsible for acquiring, structuring, validating, governing, and distributing knowledge. The Runtime OS is responsible for something different — resolving the current Context and evaluating Ontology, Knowledge Graph, DSL, Policy, Boundary, Risk, and Human Authority against it, live, at the moment a decision is needed.

Neither replaces the other. Knowledge Flow without a Runtime is an archive; a Runtime without Knowledge Flow is a model guessing at rules it was never given.

The Decision Runtime Kernel

The kernel connects, in sequence:

  • Context Loading
  • Ontology Resolution
  • Knowledge Graph Retrieval
  • DSL Evaluation
  • Policy, Boundary, and Risk Evaluation
  • Human Authority
  • Execution Permission
  • Decision Trace
The LLM is not the final authority. Execution permission and the reasoning behind it stay separate — and on failure, the system falls to the safe side, traceable back to the source document.
Connection with Decision Runtime — Knowledge Flow produces Ontology, Knowledge Graph, DSL, Policy, and Constraint, which feed the Decision Runtime Kernel, the Runtime OS, a Decision, and finally an Action.
Knowledge Flow creates knowledge; the Decision Runtime Kernel and Runtime OS use it to decide and act.
10 / Applications

Applications

In each domain below, what decides the outcome is not how fluent the underlying model sounds. It is whether the knowledge behind an answer carries the right meaning, source, validity, authority, Decision Trace, and human review for that domain.

Manufacturing

Manufacturing

Design standards, quality criteria, ECNs, CAPA, and equipment maintenance rules all change on their own schedules. What matters is not whether an AI can summarize a spec, but whether it can trace a current rule back to the ECN that changed it, and whether a CAPA-derived constraint reaches the shop floor as a validated rule rather than a paraphrase.

Finance

Finance

Credit, contract, risk, and compliance decisions depend on rules that are explainable and separable from the score that feeds them. A credit judgment is only as good as its ability to show which policy, which contract clause, and which risk limit it applied — and who is authorized to override it.

Healthcare

Healthcare

Clinical guidelines are not absolute commands, and AI is not the final diagnostician. Contraindications, patient context, and evidence level all have to be tracked with their own provenance, and a human retains authority over anything the system proposes — especially where guidelines conflict.

Enterprise Knowledge

Enterprise Knowledge

SharePoint, Teams, Slack, and wikis hold both formal and informal knowledge side by side, and they disagree with each other constantly. Turning a Slack thread into a Knowledge Candidate, detecting when it contradicts a formal document, and keeping access control inherited from the source — not flattened — matters more than making search feel faster.

Knowledge Flow ↓ Decision Trace ↓ Governance ↓ Trust ↓ Coordination ↓ Runtime Society
Knowledge Flow is not a way to collect more information. It is how distributed, siloed information becomes a Knowledge Asset — one that carries meaning, source, validity, scope, responsibility, and the ability to be updated.   That is the condition on which AI and humans can make a better decision together, not merely a faster one.   Chinoba studies how Ontology, Knowledge Graph, DSL, Decision Trace, the Decision Runtime Kernel, and the Runtime OS connect, so that knowledge keeps circulating through decision, execution, and learning — rather than stopping at an answer.
Chinoba.org

Explore the Books, Videos, and Essays above ↑