\documentclass[11pt,a4paper]{article}

% Encoding & Fonts
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{mathptmx}
\usepackage{amsfonts,amsmath,amssymb}
\usepackage{microtype}

% Page layout
\usepackage{geometry}
\geometry{a4paper,left=2.5cm,right=2.5cm,top=2.5cm,bottom=2.5cm}

% Line spacing
\usepackage{setspace}
\onehalfspacing

% Abstract
\usepackage{abstract}
\renewcommand{\abstractnamefont}{\normalfont\bfseries}
\renewcommand{\abstracttextfont}{\normalfont}

% Author/Affiliation
\usepackage{authblk}
\renewcommand\Authfont{\normalfont}
\renewcommand\Affilfont{\itshape\small}

% Headers & Footers
\usepackage{fancyhdr}
\pagestyle{fancy}
\fancyhf{}
\fancyhead[L]{\small Data-First Ontology}
\fancyhead[R]{\small \thepage}
\renewcommand{\headrulewidth}{0.4pt}

% Hyperlinks
\usepackage[colorlinks=true,linkcolor=blue,citecolor=blue,urlcolor=blue]{hyperref}

% Tables
\usepackage{booktabs,longtable,array}
\usepackage{multirow}

% Figures
\usepackage{graphicx}
\usepackage{caption}
\captionsetup{font=small,labelfont=bf}

% Code highlighting
\usepackage{fancyvrb}
\usepackage{xcolor}
\DefineVerbatimEnvironment{Highlighting}{Verbatim}{commandchars=\\\{\},fontsize=\small}

% Math
\usepackage{mathtools}

% Lists
\usepackage{enumitem}

% Bibliography
\usepackage[numbers]{natbib}

% Footnotes
\usepackage[bottom]{footmisc}

% URL
\usepackage{url}

\title{Data-First Ontology: The World Model Resides in Data, Not in Weights}
\author{Zhanbo Li / Atlas Lee\thanks{DAO is derived from the  Chinese philosophical concept ``道'' (Tao/Dao), signifying the origin  and governing principle of all things. It is unrelated to DAO  (Decentralized Autonomous Organization) in the blockchain context.}}
\affil{DAO Project}
\date{May 2026}

\begin{document}

\maketitle

\begin{abstract}
Neural network weights in large language models are conventionally
assumed to encode world models. This paper argues that this assumption
exhibits structural limitations in scenarios demanding precision,
auditability, and real-time updates, identifying four crises:
hallucination, frozen knowledge, uninterpretability, and uneditability.
We propose \textbf{Data-First Ontology}, advocating that world models
should be constituted by six explicit primitives --- \textbf{Being},
\textbf{Def}, \textbf{Type}, \textbf{Relation}, \textbf{Contract}, and
\textbf{Version} --- with Def and Type cooperating to constitute the
complete behavior of an entity. This paper formalizes the distinction
between implicit and explicit world models, and introduces
\textbf{DaoQL-Edu}, a pedagogical implementation of the DaoQL core
engine (the DAO Project's centerpiece), as Phase-I validation: four
foundational primitives have been implemented with cross-engine unified
storage, achieving practical performance levels. The theoretical
framework for the complete six-primitive architecture is fully
articulated; large-scale validation thereof is reserved for future work.
\textbf{Keywords}: world model; ontology; large language model; data
structure; data-first; explicit knowledge representation
\end{abstract}

\section{Introduction: The Crisis of World
Models}\label{introduction-the-crisis-of-world-models}

\subsection{The Default Assumption}\label{the-default-assumption}

Contemporary artificial intelligence rests upon a default assumption
that is rarely stated explicitly: \textbf{the neural network weights of
a large language model constitute a world model}. When we say that GPT-4
``knows'' that Paris is the capital of France, or that it
``understands'' the causal relationship between smoking and lung cancer,
we are tacitly endorsing this assumption. Under this view, a world model
is a function \(f_\theta: \text{text} \rightarrow \text{text}\), where
the parameters \(\theta\) encode statistical regularities extracted from
trillions of pre-training tokens.

This assumption underpins the field's central research program: make the
model larger, train it on more data, and its world model will become
more accurate, more comprehensive, and more robust. Scaling laws
{[}1,2{]} are interpreted not merely as empirical regularities of loss
reduction, but as evidence that world models improve monotonically with
scale. The implicit reasoning is: if a 175-billion-parameter model
occasionally hallucinates, then a trillion-parameter model will rarely
do so; if a model whose training data cuts off in 2024 lacks knowledge
of 2025, then a continuously trained model can remain up to date.

This paper argues that this reasoning exhibits \textbf{structural
limitations in scenarios requiring precision, auditability, and
real-time updates}. The four crises currently confronting large language
models --- hallucination, frozen knowledge, uninterpretability, and
uneditability --- are difficult to eradicate under a pure
weight-encoding paradigm, because weights lack the atomic operational
semantics possessed by explicit structure.

\subsection{Four Structural Crises}\label{four-structural-crises}

\textbf{Hallucination.} Large language models generate text by sampling
from a probability distribution conditioned on their input and training
data. When training data contains contradictory information, or when a
query falls outside the training distribution, the model does not
``know'' that it does not know. It outputs plausible-sounding but
factually incorrect statements with high confidence {[}3{]}. The root
cause is not insufficient training data or imperfect optimization, but
the absence of any mechanism by which the model can verify whether a
generated statement corresponds to an explicit fact at some location in
its architecture. The ``knowledge'' that ``Paris is the capital of
France'' is not stored at any specific location; rather, it is
distributed as a statistical association across billions of weights.
When this association competes with another --- say, a fabricated
training sample claiming that Lyon is the capital --- the model has no
principled method for resolving the conflict.

\textbf{Frozen Knowledge.} Once training is complete, the weights are
frozen. The model's world model is a snapshot of the world at the moment
of training. Retrieval-Augmented Generation (RAG) {[}4{]} and
fine-tuning {[}5{]} are techniques that attempt to address this
limitation, but they are grafted onto a frozen weight architecture
rather than replacing it. RAG injects external documents into the
context window, yet the model's fundamental world model --- the weights
--- remains unchanged. Fine-tuning can update weights, but the process
is computationally expensive, affects the global behavior of the entire
model, and carries the risk of catastrophic forgetting {[}6{]}. The
world model in weights is difficult to update incrementally after
training.

\textbf{Uninterpretability.} When a large language model produces an
answer, we cannot inspect its reasoning process. Attention weights
provide only a coarse post-hoc visualization of which tokens influenced
which other tokens {[}7{]}, but they do not reveal why the model
believes a particular fact, nor do they show which facts it considered
and rejected. If a medical large language model recommends a particular
treatment, we cannot trace the path from training data to
recommendation. This opacity is not a temporary limitation of current
visualization techniques, but an inherent property of knowledge
distributed across billions of parameters. A world model in weights
lacks an interpretable reasoning trace.

\textbf{Uneditability.} Suppose we discover that a large language model
persistently generates a dangerous false statement --- for instance,
recommending aspirin to patients with gastric ulcers. Correcting this
error requires fine-tuning, which affects the entire weight matrix and
may introduce new errors elsewhere {[}8{]}. There exists no mechanism
for ``surgically'' removing or updating a single belief. Knowledge in
weights is globally coupled: the representation of ``aspirin'' is
entangled with representations of ``pain relief,'' ``blood thinning,''
``gastric irritation,'' and countless other concepts. Modifying one
place affects the whole. A world model in weights resists precise local
modification.

\textbf{Thesis.} These four crises are not independent engineering
problems, but \textbf{systemic manifestations of the pure
weight-encoding paradigm} in the absence of explicit structural
operational semantics. In scenarios requiring precision, auditability,
and real-time updates, world models require the support of explicit data
structures.

\subsection{Thought Experiment}\label{thought-experiment}

Imagine two libraries.

\textbf{Library A} employs a super-reader who has memorized every book
in the collection. When you ask a question, the super-reader answers
from memory. This super-reader is erudite, eloquent, and quick to
respond. But he occasionally confuses similar facts (hallucination),
knows nothing about books published after his training date (frozen
knowledge), cannot explain how he arrived at a particular answer
(uninterpretable), and correcting one error may distort other memories
(uneditable).

\textbf{Library B} keeps all books on the shelves. When you ask a
question, the librarian consults the catalog, retrieves the relevant
volumes, cross-references the sources, and provides an answer with
citations. Books can be updated (new editions replace old ones), the
librarian's retrieval process is inspectable (you can see which books
were consulted), and correcting one book does not affect the others.

In many critical application scenarios, large language models operating
alone as knowledge repositories face challenges. We propose a
complementary architecture: explicit data structures as the world model,
with the LLM serving as the query and reasoning engine.

In Library B, the world model does not reside in the librarian's memory,
but in the books themselves --- their contents, relationships,
citations, and revision histories. The librarian (a large language
model) is a sophisticated query engine, not the repository of knowledge.
This inversion of roles is the central claim of this paper.

\subsection{Position of This Paper}\label{position-of-this-paper}

We propose \textbf{Data-First Ontology}: a paradigm that treats the
world model as an explicit computational structure rather than an
implicit statistical distribution. Specifically, we argue that the world
model should be built from six primitives:

\begin{quote}
\begin{itemize}
\tightlist
\item
  \textbf{Being}: a state collection endowed with a unique identity,
  constituting a traceable and evolvable existent unit;
\item
  \textbf{Def}: the definition of a Being;
\item
  \textbf{Type}: the classification label of a Being;
\item
  \textbf{Relation}: the relationship between Beings;
\item
  \textbf{Version}: the historical state of a Being;
\item
  \textbf{Contract}: what determines the evolution of a Being.
\end{itemize}
\end{quote}

Together, these six primitives answer six ontological questions: what
exists, how it is defined, how it is classified, how it relates to
others, how it is traced, and how it evolves. Their fully formalized
semantics are elaborated below:

In this framework, \textbf{Type and Def cooperate to constitute the
complete behavior of an entity}. Def answers ``what is this'' --- it
specifies the entity's base fields, constraints, and core contracts
(e.g., a ``Product'' Def defines fields such as name, price, etc.),
analogous to a \textbf{Class}. Type answers ``what category does this
belong to, and therefore what additional behavior does it possess'' ---
it is a hierarchical specialization system, such as ``Digital Product →
Mobile Phone → Huawei Phone,'' analogous to an \textbf{Interface}. Type
can inherit behavior from parent types, extend new contracts, or
override Def's default behavior. \textbf{Field definitions reside in
Def; behavior is composed jointly by Def and Type}. An entity
simultaneously possesses a Def (Class) and a Type (Interface); the two
cooperate rather than being orthogonal.

These primitives are not merely a data model; they \emph{are} the world
model. The structure of Being, Def, Relation, Contract, and Version
\emph{is} the model of the world. The large language model operates upon
this structure --- querying it, traversing it, summarizing it --- but
the model itself persists independently of any neural network.

The contributions of this paper are as follows:

\begin{enumerate}
\def\labelenumi{\arabic{enumi}.}
\item
  \textbf{A conceptual framework} distinguishing implicit (weight-based)
  from explicit (structure-based) world models, and formally
  characterizing their respective limitations.
\item
  \textbf{Six ontological primitives} (Being, Def, Type, Relation,
  Contract, Version) that collectively constitute an explicit world
  model with operational semantics and bootstrapping properties. Def
  prescribes base structure and core behavior; Type provides
  hierarchical specialization and inheritance capabilities; the two
  cooperate to constitute the entity's complete behavior.
\item
  \textbf{DaoQL-Edu} (a pedagogical version of the DaoQL core engine),
  an open-source implementation containing only four core primitives
  that validates the Phase-I (tool-layer) claim: cross-engine nested
  retrieval can be unified within a single process, and under
  same-machine conditions achieves or surpasses the performance of
  specialized systems (see Section 5). The full DaoQL (six primitives,
  62,000 lines of Rust, 833 tests) has been engineered; validation of
  Type and Contract is reserved for future work.
\item
  \textbf{A research agenda} identifying open problems that must be
  resolved to unlock the full potential of this paradigm: symbol
  grounding, completeness, and evolution consistency.
\end{enumerate}

The remainder of this paper is structured as follows. Section 2
formalizes the distinction between implicit and explicit world models.
Section 3 surveys related work. Section 4 articulates the core argument
of Data-First Ontology, including the six primitives and their
philosophical foundations. Section 5 describes the DaoQL-Edu pedagogical
implementation as Phase-I (tool-layer) feasibility evidence. Section 6
situates our position within the context of philosophy of science and
philosophy of mind. Section 7 discusses future work. Section 8 honestly
declares the limitations and boundaries of this paper. Section 9
discusses open problems, and Section 10 concludes with an invitation to
the research community.

\begin{center}\rule{0.5\linewidth}{0.5pt}\end{center}

\section{The Problem: Implicit vs.~Explicit World
Models}\label{the-problem-implicit-vs.-explicit-world-models}

\subsection{What Is a World Model?}\label{what-is-a-world-model}

A world model is not merely a collection of facts. A telephone directory
contains facts (names and numbers), but it is not a world model in the
sense intended here. A genuine world model must support at least the
following capabilities {[}9,10{]}:

\begin{longtable}[]{@{}
  >{\raggedright\arraybackslash}p{(\linewidth - 4\tabcolsep) * \real{0.3529}}
  >{\raggedright\arraybackslash}p{(\linewidth - 4\tabcolsep) * \real{0.3824}}
  >{\raggedright\arraybackslash}p{(\linewidth - 4\tabcolsep) * \real{0.2647}}@{}}
\toprule\noalign{}
\begin{minipage}[b]{\linewidth}\raggedright
Capability
\end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright
Description
\end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright
Example
\end{minipage} \\
\midrule\noalign{}
\endhead
\bottomrule\noalign{}
\endlastfoot
\textbf{Facts} & Basic truths about entities & ``Paris is the capital of
France'' \\
\textbf{Relations} & Typed connections between entities & ``Paris
HAS\_LANDMARK Eiffel Tower'' \\
\textbf{Causality} & Directed influence between events & ``Smoking
CAUSES Lung Cancer'' \\
\textbf{Rules} & Conditional prescriptions & ``If patient HAS Gastric
Ulcer, THEN AVOID Aspirin'' \\
\textbf{Probability} & Quantification of uncertainty & ``Probability of
rain in London in August = 0.35'' \\
\textbf{History} & Temporal evolution of state & ``Paris
population(2024) = 2.16M; Paris population(2025) = 2.20M'' \\
\textbf{Behavior} & State-dependent dynamics & ``Order state machine:
Pending → Paid → Shipped → Delivered'' \\
\end{longtable}
}

An implicit world model encodes these capabilities as statistical
patterns in neural network weights. An explicit world model encodes them
as manipulable data structures.

\subsection{Implicit World Model}\label{implicit-world-model}

Formally, an implicit world model is a function:

\[W_{\text{implicit}} = f_\theta: \mathcal{X} \rightarrow \mathcal{Y}\]

where \(\mathcal{X}\) is the space of input queries (typically token
sequences), \(\mathcal{Y}\) is the space of output responses, and
\(\theta \in \mathbb{R}^d\) are the frozen parameters of the neural
network (typically \(d \sim 10^{11}\)--\(10^{12}\)).

Knowledge is stored in distributed representations:

\begin{itemize}
\tightlist
\item
  The ``fact'' that ``Paris is the capital of France'' is not stored at
  any specific index \(\theta_i\). It is encoded as an activation
  pattern across thousands or even millions of parameters, entangled
  with representations of ``Berlin,'' ``Tokyo,'' ``capital,'' and
  ``France.''
\item
  The ``relation'' HAS\_LANDMARK is not a first-class object. It exists
  only as a statistical correlation between the token sequences
  ``Paris'' and ``Eiffel Tower'' in the training data.
\item
  The ``rule'' about gastric ulcers and aspirin is not a logical
  entailment. It is a statistical regularity that may be overridden by a
  stronger correlation --- for instance, if ``aspirin relieves pain''
  appears more frequently in the training data.
\end{itemize}

\textbf{Consequence}: There exists no operation to ``read'' a specific
fact, ``modify'' a specific relation, or ``verify'' a specific rule. The
only available operations are forward inference (\(f_\theta(x)\)) and
fine-tuning (updating \(\theta\), which is global and approximate).

\subsection{Explicit World Model}\label{explicit-world-model}

An explicit world model is a structured tuple:

\[W_{\text{explicit}} = (\mathcal{B}, \mathcal{D}, \mathcal{T}, \mathcal{R}, \mathcal{C}, \mathcal{V})\]

where:

\begin{itemize}
\tightlist
\item
  \(\mathcal{B}\) is the set of \textbf{Beings}, each possessing a
  unique identifier BeingId, a Def (structure), a Type (specialized
  behavior, optional), state divided into core and extended attributes,
  and a chain of historical versions;
\item
  \(\mathcal{D}\) is the set of \textbf{Defs}, each prescribing an
  entity's structure, constraints, contracts (executable hooks on the
  write path), state machines, and relation declarations;
\item
  \(\mathcal{T}\) is the set of \textbf{Types}, each a hierarchical
  specialization mechanism of Def providing inheritance capabilities,
  capable of extending or overriding Def's contracts and constraints;
\item
  \(\mathcal{R}\) is the set of \textbf{Relations}, each typed, directed
  or undirected, with optional temporal windows, cardinality
  constraints, and extended attributes;
\item
  \(\mathcal{C}\) is the set of \textbf{Contracts}, i.e., executable
  behaviors invoked before or after write operations (expressed in
  script form);
\item
  \(\mathcal{V}\) is a versioning function mapping each entity and
  timestamp to an immutable snapshot.
\end{itemize}

\textbf{Fundamental distinction from the EAVT data model}. Systems such
as Datomic employ the EAVT (Entity-Attribute-Value-Time) model: ``entity
E has attribute A with value V at time T.'' This is a \textbf{data
semantics} --- it records ``what happened.'' An EAVT fact is a passive
proposition record.

DaoQL's six primitives constitute an \textbf{ontological semantics} ---
they construct ``what is.'' A Being is not a record, but an
\textbf{autonomous existent unit}: it has identity (BeingId), essential
definition (Def), specialized classification (Type), social relations
(Relation), behavioral rules (Contract), and historical personhood
(Version). Datomic asks: ``What was Alice's name on 2024-01-01?''
(querying historical facts). DaoQL asks: ``What is Alice? How does she
behave? With whom is she associated? How does she evolve?'' (ontological
exploration).

This is not a difference of implementation detail, but a
\textbf{fundamental ontological commitment}: EAVT commits to ``the world
is composed of facts,'' whereas DaoQL commits to ``the world is composed
of existents.''

\textbf{Operations on the explicit world model}:

\begin{longtable}[]{@{}
  >{\raggedright\arraybackslash}p{(\linewidth - 4\tabcolsep) * \real{0.3548}}
  >{\raggedright\arraybackslash}p{(\linewidth - 4\tabcolsep) * \real{0.3548}}
  >{\raggedright\arraybackslash}p{(\linewidth - 4\tabcolsep) * \real{0.2903}}@{}}
\toprule\noalign{}
\begin{minipage}[b]{\linewidth}\raggedright
Operation
\end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright
Semantics
\end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright
Example
\end{minipage} \\
\midrule\noalign{}
\endhead
\bottomrule\noalign{}
\endlastfoot
\texttt{read(b)} & Retrieve entity \(b\) by identifier &
\texttt{read(Paris)} →
\texttt{\{name:\ "Paris",\ population:\ 2.20M\}} \\
\texttt{relate(b\_1,\ b\_2,\ r)} & Create a relation of type \(r\)
between \(b_1\) and \(b_2\) &
\texttt{relate(Paris,\ France,\ IS\_CAPITAL\_OF)} \\
\texttt{update(b,\ d,\ v)} & Add a new version with Def \(d\) and state
\(v\) for entity \(b\) &
\texttt{update(Paris,\ City,\ \{population:\ 2.21M\})} \\
\texttt{query(q)} & Evaluate a structured query against the model &
\texttt{query(Being(Paris).relation().def(IS\_CAPITAL\_OF))} \\
\texttt{evolve(d,\ d\textquotesingle{})} & Modify Def \(d\) to \(d'\),
with migration semantics & \texttt{evolve(City,\ City\_v2)} \\
\texttt{contract(b,\ hook,\ script)} & Attach executable behavior to
entity \(b\) &
\texttt{contract(Patient,\ BEFORE\_UPDATE,\ ulcer\_check)} \\
\texttt{assign\_type(b,\ t)} & Assign Type \(t\) to entity \(b\) &
\texttt{assign\_type(Mate60,\ Huawei\_Phone)} \\
\texttt{type\_contract(t,\ hook,\ script)} & Attach a contract to Type
\(t\) &
\texttt{type\_contract(Huawei\_Phone,\ AFTER\_CREATE,\ check\_harmony)} \\
\end{longtable}
}

\textbf{Consequence}: Facts, relations, rules, and behaviors are all
first-class objects. They can be independently read, modified, verified,
and audited. Updating the population of Paris does not affect the
population of Berlin.

\subsection{Comparative Analysis}\label{comparative-analysis}

\begin{longtable}[]{@{}
  >{\raggedright\arraybackslash}p{(\linewidth - 4\tabcolsep) * \real{0.1358}}
  >{\raggedright\arraybackslash}p{(\linewidth - 4\tabcolsep) * \real{0.4321}}
  >{\raggedright\arraybackslash}p{(\linewidth - 4\tabcolsep) * \real{0.4321}}@{}}
\toprule\noalign{}
\begin{minipage}[b]{\linewidth}\raggedright
Dimension
\end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright
Implicit (\(W_{\text{implicit}}\))
\end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright
Explicit (\(W_{\text{explicit}}\))
\end{minipage} \\
\midrule\noalign{}
\endhead
\bottomrule\noalign{}
\endlastfoot
\textbf{Readability} & ❌ Cannot extract specific facts & ✅
\texttt{read(BeingId)} returns precise state \\
\textbf{Editability} & ❌ Fine-tuning affects entire model & ✅ Single
relation or fact update \\
\textbf{Verifiability} & ❌ No reasoning trace & ✅ Complete query
execution trajectory \\
\textbf{Auditability} & ❌ Cannot audit internal state & ✅ Version
chain = immutable audit log \\
\textbf{Interpretability} & ❌ Attention weights are opaque & ✅ Types,
relations, contracts are human-readable \\
\textbf{Evolvability} & ❌ Requires retraining & ✅ Runtime schema
evolution (\texttt{evolve}) \\
\textbf{Composability} & ❌ Weights resist local decomposition & ✅
Sub-models can be extracted and shared \\
\textbf{Counterfactual Consistency} & ❌ Statistical competition among
associations & ✅ Deterministic evaluation after structural
modification \\
\end{longtable}
}

The last row --- \textbf{counterfactual consistency} --- is particularly
critical and will serve as the subject of our planned experimental
evaluation (Section 7). When an implicit world model is asked a
counterfactual question (``What would be the consequence of Y if X were
not true?''), the answer depends on which statistical associations
happen to be activated by the specific wording of the query. When an
explicit world model is asked the same question, the answer can be
computed deterministically by modifying the structure and re-evaluating
the query.

\begin{center}\rule{0.5\linewidth}{0.5pt}\end{center}

\section{Related Work}\label{related-work}

Before presenting Data-First Ontology, we must clarify this paper's
relationship to existing work. This section surveys relevant research
along three dimensions: temporal and immutable databases, knowledge
representation and knowledge graphs, and the combination of large
language models with structured data.

\subsection{Temporal and Immutable
Databases}\label{temporal-and-immutable-databases}

\textbf{Datomic} {[}11{]} is the closest precursor to the ideas in this
paper. Proposed by Rich Hickey in 2012, Datomic's core tenets include:
(1) time as a central dimension of the data model (EAVT:
Entity-Attribute-Value-Time); (2) immutable append-only --- no UPDATE or
DELETE, only the appending of new facts; (3) schema-as-data --- schema
is stored as data, queryable and evolvable; (4) database-as-value ---
the database is an immutable value that can be passed, compared, and
cached.

Datomic has already realized three core properties advocated by DaoQL:
``time as ontology,'' ``immutable append-only,'' and ``schema-as-data.''
However, Datomic employs a single EAVT storage model, with all queries
executing on EAVT indexes. DaoQL unifies five engines --- graph, column,
vector, index, and full-text --- within a single process, achieving
zero-overhead cross-modal queries through BeingId. Furthermore,
Datomic's Schema/Type is monolithic, lacking a mechanism for ``the same
entity category can have different specialized behaviors,'' whereas
DaoQL introduces the separation and cooperation of Def (Class) and Type
(Interface).

\textbf{Event Store} {[}12{]} and \textbf{Temporal Tables} (SQL:2011)
{[}13{]} have also made important contributions along the temporal
dimension. Event Store adopts the Event Sourcing pattern, recording
state changes as immutable event streams. SQL:2011's Temporal Tables
build support for valid time and transaction time into the relational
model. These systems record ``what happened,'' but unlike DaoQL, they do
not treat time as an ontological dimension of existence --- in DaoQL,
time is not an attribute, but the intrinsic structure of a Being.

\subsection{Knowledge Representation and Knowledge
Graphs}\label{knowledge-representation-and-knowledge-graphs}

\textbf{RDF/OWL/SPARQL} {[}14,15,16{]} constitute the technology stack
of the Semantic Web. RDF represents knowledge as triples
(Subject-Predicate-Object), OWL provides an ontology description
language, and SPARQL provides a query mechanism. RDFS's \texttt{class}
and \texttt{type} mechanisms allow simple hierarchical classification,
but lack the flexibility of the Def/Type separation. Compared to DaoQL,
RDF/OWL lacks built-in version chains, contract execution, and
multi-modal unification capabilities. Survey work in the knowledge graph
domain {[}30{]} further reveals structural gaps in existing knowledge
representation systems regarding dynamic evolution and multi-modal
unification.

\textbf{TypeDB} {[}17{]} is a typed hyper-relational knowledge graph
database. TypeDB supports type inheritance, constraint checking, and
rule-based reasoning; its type system is stricter than that of RDF/OWL.
However, TypeDB's type inheritance is a static schema definition, does
not support runtime Def/Type cooperative evolution, and does not embed
contracts into the storage engine's write path.

\textbf{Property Graph} (e.g., Neo4j {[}18{]}, GQL {[}19{]}) organizes
graph data using labels and properties. Property Graph's Label is
analogous to DaoQL's Type, but a Label has no behavioral semantics ---
it cannot define contracts or constraints. Property Graph also lacks
immutable version chains and cross-modal query capabilities. A survey of
graph database models {[}32{]} notes that existing graph databases
exhibit fundamental limitations in type systems and behavioral
semantics.

\subsection{Large Language Models and Structured
Data}\label{large-language-models-and-structured-data}

\textbf{GraphRAG} {[}20{]}, proposed by Microsoft Research, is
representative work combining LLMs with knowledge graphs. GraphRAG
automatically extracts entity-relation triples from unstructured text,
constructs a knowledge graph, and then retrieves relevant sub-graphs or
community structures to enhance the LLM's generation when answering
queries. LightRAG {[}21{]} optimizes indexing and retrieval efficiency
on this basis, adopting a dual-tier retrieval system. FastGraphRAG
{[}22{]} further accelerates graph traversal using personalized
PageRank.

The core paradigm of GraphRAG and its variants is ``build graphs from
text to assist the LLM'' --- the graph is an external augmentation
component for the LLM. DaoQL's core paradigm is radically different: the
graph is not a tool to assist the LLM, but the \textbf{primary storage
of the world model}. The LLM is merely a reasoning engine that queries
and operates upon this world model.

\textbf{MemGPT} {[}23{]}, proposed by UC Berkeley, applies the virtual
memory management ideas of operating systems to LLMs. MemGPT enables the
LLM to autonomously manage its memory through hierarchical storage (core
memory, recall storage, archival storage) and explicit function calls.
MemGPT solves the problem of limited LLM context windows, but its memory
management remains at the level of text chunks, lacking structured
semantics for entities, relations, and versions.

\textbf{MCP (Model Context Protocol)} {[}24{]} is an open protocol aimed
at standardizing interactions between LLMs and external data sources,
tools, and services. MCP operates at the protocol layer; DaoQL operates
at the storage layer --- the two are complementary rather than
competitive. An LLM application based on MCP could use DaoQL as its
structured memory backend.

\subsection{Neuro-Symbolic
Integration}\label{neuro-symbolic-integration}

\textbf{Neuro-symbolic AI} {[}25{]} is dedicated to combining the
perceptual capabilities of neural networks with the reasoning
capabilities of symbolic systems. Early work such as Neural Theorem
Provers {[}26{]} and Logic Tensor Networks {[}27{]} attempted to embed
logical rules into neural networks. Recent work such as AlphaProof
{[}28{]} demonstrates the potential of neuro-symbolic integration in
mathematical reasoning. DaoQL can be viewed as the ``symbolic-side''
infrastructure in a neuro-symbolic architecture --- providing the LLM
(the neural side) with an explicit, verifiable structured knowledge
base.

\subsection{Summary of Distinctions from Existing
Work}\label{summary-of-distinctions-from-existing-work}

\begin{longtable}[]{@{}
  >{\raggedright\arraybackslash}p{(\linewidth - 12\tabcolsep) * \real{0.1774}}
  >{\raggedright\arraybackslash}p{(\linewidth - 12\tabcolsep) * \real{0.1452}}
  >{\raggedright\arraybackslash}p{(\linewidth - 12\tabcolsep) * \real{0.1452}}
  >{\raggedright\arraybackslash}p{(\linewidth - 12\tabcolsep) * \real{0.1290}}
  >{\raggedright\arraybackslash}p{(\linewidth - 12\tabcolsep) * \real{0.1613}}
  >{\raggedright\arraybackslash}p{(\linewidth - 12\tabcolsep) * \real{0.1290}}
  >{\raggedright\arraybackslash}p{(\linewidth - 12\tabcolsep) * \real{0.1129}}@{}}
\toprule\noalign{}
\begin{minipage}[b]{\linewidth}\raggedright
Dimension
\end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright
Datomic
\end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright
RDF/OWL
\end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright
TypeDB
\end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright
GraphRAG
\end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright
MemGPT
\end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright
DaoQL
\end{minipage} \\
\midrule\noalign{}
\endhead
\bottomrule\noalign{}
\endlastfoot
\textbf{Time as Ontology} & ✅ EAVT & ❌ None & ❌ None & ❌ None & ❌
None & ✅ Version chain \\
\textbf{Immutable Append-Only} & ✅ & ❌ & ❌ & ❌ & ❌ & ✅ WAL +
versioning \\
\textbf{Schema-as-Data} & ✅ & ✅ & ✅ & ❌ & ❌ & ✅ Bootstrapping \\
\textbf{Def/Type Cooperation} & ❌ & ❌ & Partial & ❌ & ❌ & ✅
Class/Interface \\
\textbf{Multi-Modal Unification} & ❌ & ❌ & ❌ & ❌ & ❌ & ✅ Five
engines \\
\textbf{Contracts Embedded in Write Path} & ❌ & ❌ & Partial & ❌ & ❌
& ✅ Rhai runtime \\
\textbf{LLM Semantic Layer} & ❌ & ❌ & ❌ & ✅ & Partial & ✅ NL→DSL \\
\textbf{World Model Semantics} & ❌ & Partial & Partial & ❌ & ❌ & ✅
Six primitives \\
\end{longtable}
}

\emph{Note: The DaoQL capabilities in the table are based on the full
architecture. The DaoQL-Edu pedagogical version contains verified
implementations of only the first four capabilities (time as ontology,
immutable append-only, schema-as-data, multi-modal unification), without
the LLM semantic layer, full contract execution, or the complete
Def/Type cooperation runtime.}

The table above reveals a critical gap: \textbf{existing systems either
focus on a single data model (relational, document, graph, vector) or
focus on providing external knowledge augmentation for LLMs (GraphRAG,
MemGPT), but no system simultaneously possesses all data model
capabilities and takes ``explicit world model'' as its core
architectural goal}.

\textbf{Positioning of DaoQL}: DaoQL is not a relational database, not a
document database, not a graph database, not a key-value database, not a
columnar database, not a vector database, not a time-series database,
not a full-text search engine --- yet it \textbf{simultaneously}
possesses the capabilities of all these databases:

\begin{longtable}[]{@{}
  >{\raggedright\arraybackslash}p{(\linewidth - 2\tabcolsep) * \real{0.4054}}
  >{\raggedright\arraybackslash}p{(\linewidth - 2\tabcolsep) * \real{0.5946}}@{}}
\toprule\noalign{}
\begin{minipage}[b]{\linewidth}\raggedright
Database Type
\end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright
DaoQL Implementation
\end{minipage} \\
\midrule\noalign{}
\endhead
\bottomrule\noalign{}
\endlastfoot
\textbf{Relational Database} & Def/Type defines structure + Contract
constraints (analogous to foreign keys, triggers, check constraints) \\
\textbf{Document Database} & BeingExt key-value extensions, supporting
arbitrary nested attributes \\
\textbf{Graph Database} & BeingCore + Relation edge chains, direct
pointer adjacency, O(1) graph traversal \\
\textbf{Key-Value Database} & BeingId → Being O(1) lookup \\
\textbf{Columnar Database} & BeingExt columnar storage per field + LZ4
compression + SIMD aggregation \\
\textbf{Vector Database} & HNSW + scalar quantization, BeingId as vector
node \\
\textbf{Time-Series Database} & Version chain + timestamp index, O(1)
historical backtracking \\
\textbf{Full-Text Search Engine} & Tantivy inverted index + jieba
segmentation \\
\end{longtable}
}

\textbf{Key Insight}: The traditional database stack requires 8 separate
systems to satisfy the seven capabilities of a world model. DaoQL
unifies all capabilities within a single system --- not through a
``support multiple query languages'' compatibility layer, but through a
\textbf{unified set of primitives} (Being, Def, Type, Relation,
Contract, Version). These primitives are not a patchwork of 8 data
models, but a \textbf{more fundamental ontological structure} that
naturally gives rise to the capabilities of all upper-layer data models.

DaoQL fills this gap: it does not build graphs from text to assist LLMs,
but places the explicit world model at the core of storage, making the
LLM an operator of this model rather than its owner.

\begin{center}\rule{0.5\linewidth}{0.5pt}\end{center}

\section{Core Argument: Data-First
Ontology}\label{core-argument-data-first-ontology}

\subsection{Three Propositions}\label{three-propositions}

We propose three mutually nested propositions that together define the
Data-First Ontology paradigm. It should be noted in advance that the
``Def'' in these propositions is the structural specification primitive,
prescribing an entity's fields, constraints, and core behavior; ``Type''
is the hierarchical specialization mechanism of Def, providing
inheritance and polymorphism capabilities, capable of extending or
overriding Def's contracts and constraints, and cooperating with Def to
constitute the entity's complete behavior.

\textbf{Proposition I (Ontology).} The basic unit of existence in a
computational world model is not a symbol (as in first-order logic), not
an object (as in object-oriented programming), nor a process (as in the
\(\pi\)-calculus). It is the \textbf{Being}: an existent unit possessing
identity, state, history, behavior, and relations with other entities.

A Being's ``what-it-is'' (quiddity) is not prescribed by an external
schema, but by its \textbf{Def}. A Def is not an attribute of the
entity, but the entity's ontological prerequisite: before an entity can
become manipulable data, it must first be defined as a certain kind of
existent. Def answers ``what is this,'' not ``what category does this
belong to.''

An entity is not a row in a table (passive data), nor an instance of a
class (behavior defined externally). It is an autonomous existent unit
whose behavior is embedded within its Def, and whose history is an
immutable chain of versions. The entity is primitive; everything else is
derived from it.

\textbf{Proposition II (Epistemology).} Knowledge is neither mental
content (connectionism) nor a set of propositions (symbolism). Knowledge
is the \textbf{structure of Being/Def/Relation} --- and this structure
itself is the world model.

Type provides the hierarchical specialization framework (e.g., ``Digital
Product → Mobile Phone → Huawei Phone''), capable of extending and
overriding Def's contracts and constraints. The foundation of knowledge
lies in Def's structural specification: Def defines which fields exist,
which constraints are active, and which core contracts trigger. Type
adds specialized behavior and constraints on this basis, jointly
constituting the complete knowledge representation with Def.

This distinction is subtle but crucial. In symbolic systems, knowledge
is a set of propositions about the world, stored independently of the
reasoning mechanism. In connectionist systems, knowledge is the weight
configuration of the reasoning mechanism itself. In Data-First Ontology,
knowledge is a structure situated between data and reasoning: Def
defines what may exist, Relations define how entities connect, and
Contracts define how structures evolve. Type provides a classification
framework to help organize and retrieve entities. The structure is not
\emph{about} the world; in a computational sense, it \emph{is} the
world.

\textbf{Proposition III (Methodology).} Reasoning is not the extraction
of statistical patterns from weights, but \textbf{traversal and
transformation of explicit structure}. The large language model is an
accelerator of this process, not the repository of its contents.

When a user asks: ``What medications should be avoided in patients with
gastric ulcers?'', the reasoning process in a Data-First system is:

\begin{enumerate}
\def\labelenumi{\arabic{enumi}.}
\item
  Parse the query into a structured traversal:
  \texttt{Being(Patient)\ →\ Relation(DIAGNOSED\_WITH)\ →\ Def(Condition)\ →\ FILTER(name="Gastric\ Ulcer")\ →\ Relation(CONTRAINDICATED\_WITH)\ →\ Def(Medication)}.

  In this traversal, ``Patient,'' ``Condition,'' and ``Medication'' are
  all Defs (defining the structure of the respective entities), and each
  entity may simultaneously possess a Type (e.g., the Type of
  ``Patient'' might be ``Human/Patient''). Traversal operations are
  based on the structure prescribed by Def, while Type provides
  classification information to assist retrieval.
\item
  Execute the traversal on the explicit structure.
\item
  Collect the results (list of contraindicated medications).
\item
  Use a large language model to generate a natural language response
  from the structured results.
\end{enumerate}

The role of the large language model is Step 4, not Steps 1--3. The
world model --- the knowledge about which medications are
contraindicated for gastric ulcers --- resides in the explicit
structure, not within the weights of the large language model.

\textbf{Two-Phase Validation Stratification}. The six primitives
involved in the three propositions above are stratified into two levels
in terms of validation strategy:

\begin{itemize}
\tightlist
\item
  \textbf{Tool Layer} (Phase I, validated): The intersection of Being,
  Def, Relation, and Version is sufficient to solve the engineering
  problem of ``how can multi-modal data of a world model be unified for
  storage and query within a single system.'' Section 5 reports the
  validation of this layer by the DaoQL-Edu pedagogical version.
\item
  \textbf{Meta-Tool Layer} (Phase II, theoretically defined): Type and
  Contract address the ontological problem of ``how does a world model
  describe and constrain itself.'' The theoretical framework for these
  two primitives has been fully articulated below; their large-scale
  engineering validation is reserved for future work.
\end{itemize}

This stratification is deliberate --- even with only the four
foundational primitives, the system is already sufficiently powerful to
support a world model surpassing the traditional fragmented database
stack; Type and Contract are incremental enhancements, not necessary
prerequisites.

\subsection{Six Ontological
Primitives}\label{six-ontological-primitives}

We now define the six primitives in detail.

\textbf{Being.} A Being \(b\) is a quadruple:

\[b = (id, core, ext, history)\]

\begin{itemize}
\tightlist
\item
  \(id \in \text{BeingId}\) is a unique, immutable identifier (typically
  a UUID).
\item
  \(core\) is a fixed-size structure containing the entity's fundamental
  attributes (e.g., name, definition identifier, creation timestamp).
\item
  \(ext\) is an extensible key-value map containing arbitrary attributes
  prescribed by the entity's Def.
\item
  \(history = [v_1, v_2, \ldots, v_n]\) is an immutable, append-only
  version chain, where each
  \(v_i = (timestamp_i, state_i, prev\_hash_i)\).
\end{itemize}

A Being is not ``instantiated'' from a class; it is \textbf{written}
into existence. There is no distinction between creation and
persistence. Creating a Being is writing it into storage; reading a
Being is retrieving it by its identifier.

Every Being has a \texttt{def} field pointing to the Def entity that
defines the entity's structure. For example, a ``Patient'' Being's
\texttt{def} points to the Def entity that defines the structure of
``Patient.''

\textbf{Def.} A Def \(d\) is a sextuple:

\[d = (name, fields, constraints, contracts, state\_machine, relations)\]

\begin{itemize}
\tightlist
\item
  \(name\) is the unique definition identifier (e.g., ``Patient,''
  ``Medication,'' ``Order'').
\item
  \(fields\) is a set of typed field definitions.
\item
  \(constraints\) is a set of invariant predicates (e.g.,
  \texttt{age\ \textgreater{}=\ 0}, \texttt{email\ MATCHES\ regex}).
\item
  \(contracts\) is a set of executable hooks (\texttt{BEFORE\_CREATE},
  \texttt{AFTER\_UPDATE}, \texttt{BEFORE\_RELATE}, etc.), each
  associated with a script (e.g., a Rhai script).
\item
  \(state\_machine\) is a finite state machine defining the legal state
  transitions for entities under this Def.
\item
  \(relations\) is a set of relation type declarations that entities
  under this Def may participate in.
\end{itemize}

Def answers ``what is this'' --- it prescribes the complete structure of
the entity. The ``Patient'' Def contains name fields, age fields,
diagnosis fields, and corresponding constraints and contracts. Field
definitions reside in Def, not in Type.

Crucially, \textbf{Def itself is also a Being}. The Def \texttt{Patient}
is a Being whose \texttt{core.def} points to \texttt{DAO\_DEF} (i.e.,
``the Def of Defs''). There is no independent ``schema catalog'' or
``system table.'' The definition system is \textbf{bootstrapping}: the
definition of what a Def is, is itself stored as a Def.

\textbf{Type.} A Type \(t\) is a hierarchical specialization mechanism
of Def, analogous to an \textbf{Interface} in object-oriented
programming, but supporting hierarchical inheritance. It is a node in a
taxonomy, cooperating with Def (Class) to constitute the entity's
complete behavior:

\[t = (name, parent, path, contracts, constraints, attributes)\]

\begin{itemize}
\tightlist
\item
  \(name\) is the type name (e.g., ``Huawei Phone'').
\item
  \(parent\) is the parent type (e.g., ``Mobile Phone''), forming an
  inheritance chain.
\item
  \(path\) is the complete path from root to this node (e.g., ``Digital
  Product/Mobile Phone/Huawei Phone'').
\item
  \(contracts\) are executable hooks specific to this type, capable of
  extending or overriding Def's contracts.
\item
  \(constraints\) are constraints specific to this type, capable of
  tightening Def's constraint conditions.
\item
  \(attributes\) are presentation attributes specific to this type
  (e.g., icon, color).
\end{itemize}

\textbf{Field definitions reside in Def; behavior is composed jointly by
Def and Type.} Type does not define fields, but it defines additional
behavior and constraints. For example:

\begin{itemize}
\tightlist
\item
  Def ``Product'' =
  \texttt{\{fields:\ {[}name,\ price,\ brand{]},\ contracts:\ {[}check\_price\_positive{]}\}}
\item
  Type ``Mobile Phone'' (parent = ``Digital Product'') =
  \texttt{\{contracts:\ {[}check\_has\_imei{]}\}}
\item
  Type ``Huawei Phone'' (parent = ``Mobile Phone'') =
  \texttt{\{contracts:\ {[}check\_harmony\_os\_support{]},\ constraints:\ {[}brand\ ==\ "Huawei"{]}\}}
\end{itemize}

Being ``Mate 60'' (def = ``Product'', type = ``Digital Product/Mobile
Phone/Huawei Phone'') → Complete behavior = Def(Product) + Type(Mobile
Phone) + Type(Huawei Phone) → Execute check\_price\_positive +
check\_has\_imei + check\_harmony\_os\_support

Type provides \textbf{polymorphic specialization} capability: different
Types (interface implementations) of the same Def (class) can have
different behaviors. For example, Def ``Patient'' defines base fields,
while Type ``Emergency Patient'' adds emergency handling contracts, and
Type ``Inpatient'' adds bed management contracts. This is analogous to
the same class implementing different interfaces, each interface
prescribing additional behavioral constraints.

Type itself is optional --- a Being may have no Type (using only Def's
base behavior), but it cannot be without a Def.

\textbf{Relation.} A Relation \(r\) is a quintuple:

\[r = (type, source, target, direction, attributes, validity)\]

\begin{itemize}
\tightlist
\item
  \(type\) is the relation type (e.g., \texttt{IS\_CAPITAL\_OF},
  \texttt{TAKES}, \texttt{CONTRAINDICATED\_WITH}).
\item
  \(source\) and \(target\) are entity identifiers.
\item
  \(direction \in \{\text{directed}, \text{undirected}\}\).
\item
  \(attributes\) is an extensible key-value map.
\item
  \(validity = (t_{start}, t_{end})\) is an optional temporal window.
\end{itemize}

Relations are first-class objects. They can be queried, versioned, and
constrained. A Relation is not a foreign key (a passive pointer), but an
active connection that may trigger contracts upon creation,
modification, or traversal.

Note: relation types themselves are also defined by Def
(\texttt{def\ =\ "DAO\_RELATION"}), but relation instances are actual
connections between entities.

\textbf{Contract.} A Contract \(c\) is a triple:

\[c = (hook, script, ast\_cache)\]

\begin{itemize}
\tightlist
\item
  \(hook \in \{\text{BEFORE\_CREATE}, \text{AFTER\_CREATE}, \text{BEFORE\_UPDATE}, \text{AFTER\_UPDATE}, \text{BEFORE\_RELATE}, \text{AFTER\_RELATE}, \text{BEFORE\_DELETE}\}\).
\item
  \(script\) is the contract's source code (e.g., a Rhai function).
\item
  \(ast\_cache\) is the compiled abstract syntax tree, cached for
  performance.
\end{itemize}

Contracts are embedded in the write path. They cannot be bypassed by
client applications, because they execute inside the storage engine. For
example, a contract checking for drug interactions executes on every
\texttt{relate(Patient,\ Medication,\ TAKES)} operation, regardless of
which client initiated the operation.

Contracts are \textbf{ontologically independent primitives} --- they
represent the ontological dimension of ``executable behavioral rules''
in the world model, on par with Being, Def, Type, etc., as one of the
six primitives. However, at the \textbf{implementation level}, contracts
are embedded within Def, stored and executed as a field of Def. This
``ontologically independent, implementationally embedded'' design is
deliberate: it guarantees that contracts cannot be bypassed (because the
only entry point to the write path is Def), while maintaining
ontological integrity.

\textbf{Version.} A Version \(v\) is a quadruple:

\[v = (timestamp, state, prev\_pointer, next\_pointer)\]

\begin{itemize}
\tightlist
\item
  \(timestamp\) is a logical or physical timestamp.
\item
  \(state\) is the entity's complete state at the moment of this
  version.
\item
  \(prev\_pointer\) is the storage offset pointer to the previous
  version (\texttt{NodeOffset}).
\item
  \(next\_pointer\) is the storage offset pointer to the next version
  (\texttt{NodeOffset}).
\end{itemize}

Version chains make every entity's history inspectable and auditable. It
is not an optional audit log stored separately, but the intrinsic
temporal dimension of the entity's existence. In the code
implementation, version nodes are linked by bidirectional pointers
(\texttt{prev\_version} / \texttt{next\_version}), functionally
equivalent to the version chain in the formal definition.

\subsection{Bootstrapping: A Self-Describing
System}\label{bootstrapping-a-self-describing-system}

The most radical property of Data-First Ontology is that \textbf{the
system describes itself}. There is no meta-level outside the data level.

Consider how existing systems handle schema:

\begin{longtable}[]{@{}
  >{\raggedright\arraybackslash}p{(\linewidth - 4\tabcolsep) * \real{0.1818}}
  >{\raggedright\arraybackslash}p{(\linewidth - 4\tabcolsep) * \real{0.3409}}
  >{\raggedright\arraybackslash}p{(\linewidth - 4\tabcolsep) * \real{0.4773}}@{}}
\toprule\noalign{}
\begin{minipage}[b]{\linewidth}\raggedright
System
\end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright
Schema Storage
\end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright
Schema Modification
\end{minipage} \\
\midrule\noalign{}
\endhead
\bottomrule\noalign{}
\endlastfoot
PostgreSQL & \texttt{pg\_catalog} system tables & \texttt{ALTER\ TABLE}
DDL \\
MongoDB & None (schemaless) & Not applicable \\
Neo4j & Optional constraints & \texttt{CREATE\ CONSTRAINT} Cypher \\
Datomic & Datalog assertions & Transactional schema updates \\
\textbf{DaoQL} & \textbf{Entities defined by \texttt{DAO\_DEF}} &
\textbf{\texttt{update} operations on Def entities} \\
\end{longtable}
}

In DaoQL, the command \texttt{define\ type\ Patient\ \{\ ...\ \}} is not
parsed by an independent DDL parser and stored in a separate catalog. It
is a \textbf{write operation} that creates a Being whose Def is
\texttt{DAO\_DEF} (i.e., ``Patient'' is written as a Def entity).
Definition is data; data carries definition; the system is
self-describing.

Specifically, the bootstrapping hierarchy is as follows:

\begin{verbatim}
Layer 0: Meta-Layer
  Def "DAO_DEF"
    → Defines "what a Def is" (i.e., the structure of Def itself)
  Def "DAO_TYPE"
    → Defines "what a Type is" (the root definition of the Type hierarchy)
  Def "DAO_RELATION"
    → Defines "what a Relation is"

Layer 1: Object Layer
  Def "Patient"
    → Defines the business-level "Patient" (containing name, age, diagnosis, etc. fields)
  Def "Medication"
    → Defines the business-level "Medication" (containing name, ingredient, dosage, etc. fields)

Layer 2: Instance Layer
  Being "Alice" (def = "Patient")
    → Alice is a Patient entity
  Being "Aspirin" (def = "Medication")
    → Aspirin is a Medication entity
\end{verbatim}

Type (specialization hierarchy) cooperates with Def to constitute
complete behavior:

\begin{verbatim}
Def hierarchy (structural definition)    Type hierarchy (specialization inheritance)
─────────────────────                    ─────────────────────
Def "Product"                            Digital Product
  fields: [name, price]                    └── Mobile Phone
  contracts: [check_price]                       ├── Huawei Phone
                                            │   contracts: [check_harmony]
                                            │   constraints: [brand == "Huawei"]
                                            └── Apple Phone
                                                  contracts: [check_ios]

Def "Patient"                            Organism
  fields: [name, age, diagnosis]           └── Human
  contracts: [check_id]                          ├── Patient
                                            │   contracts: [check_urgency]
                                            └── Doctor
                                                  contracts: [check_license]
\end{verbatim}

A Being simultaneously possesses a Def (base structure) and a Type
(specialized behavior): Being ``Mate 60'' (def = ``Product'', type =
``Digital Product/Mobile Phone/Huawei Phone'') → Behavior = Def(Product)
+ Type(Mobile Phone) + Type(Huawei Phone) → Execute check\_price +
check\_harmony

Being ``Alice'' (def = ``Patient'', type = ``Organism/Human/Patient'') →
Behavior = Def(Patient) + Type(Human) + Type(Patient) → Execute
check\_id + check\_urgency

Def and Type cooperate: modifying the ``Patient'' Def (e.g., adding a
new field) affects all Patient Beings (analogous to modifying a class
definition affecting all instances); modifying the Type ``Patient''
(e.g., adding a new contract) affects only Beings whose type =
``\ldots/Patient'' (analogous to modifying an interface affecting all
classes that implement it).

This bootstrapping property has far-reaching consequences:

\begin{itemize}
\tightlist
\item
  \textbf{No schema drift}: because schema (Def) is data, schema changes
  are versioned just like any other data change.
\item
  \textbf{No DDL parser}: there is no independent language for defining
  structure. The same query language used to query data is also used to
  query and modify Def.
\item
  \textbf{Reflective capability}: the system can query its own Defs,
  discover its own types, and reason about its own structure.
\end{itemize}

\subsection{Time as Ontology, Not
Attribute}\label{time-as-ontology-not-attribute}

In conventional systems, time is an attribute:
\texttt{updated\_at\ TIMESTAMP}. In Data-First Ontology, time is an
ontological dimension.

An entity is not an object that exists at a point in time. An entity
\textbf{is} a temporal extension. The version chain
\([v_1, v_2, \ldots, v_n]\) is not an audit trail attached to the
entity, but the entity's intrinsic temporal extension. Def itself also
has a version chain: when the definition of the \texttt{Patient} type is
modified (e.g., adding a new field), this change is recorded as a new
version of the \texttt{Patient} Def entity.

This inversion has operational consequences:

\begin{longtable}[]{@{}
  >{\raggedright\arraybackslash}p{(\linewidth - 4\tabcolsep) * \real{0.1447}}
  >{\raggedright\arraybackslash}p{(\linewidth - 4\tabcolsep) * \real{0.4474}}
  >{\raggedright\arraybackslash}p{(\linewidth - 4\tabcolsep) * \real{0.4079}}@{}}
\toprule\noalign{}
\begin{minipage}[b]{\linewidth}\raggedright
Operation
\end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright
Conventional (Time as Attribute)
\end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright
Data-First (Time as Ontology)
\end{minipage} \\
\midrule\noalign{}
\endhead
\bottomrule\noalign{}
\endlastfoot
``What is the current state?'' &
\texttt{SELECT\ *\ FROM\ users\ WHERE\ id\ =\ X} &
\texttt{Being(X).current().execute()} \\
``What was the state on date D?'' &
\texttt{SELECT\ *\ FROM\ audit\_log\ WHERE\ ...} &
\texttt{Being(X).at(D).execute()} \\
``What changed between D1 and D2?'' & Complex diff query &
\texttt{Being(X).between(D1,\ D2).diff().execute()} \\
``Has this entity ever been in state S?'' & Full-table scan of audit log
&
\texttt{Being(X).history().any(\textbar{}v\textbar{}\ v.state\ ==\ S).execute()} \\
\end{longtable}
}

The query \texttt{Being(X).history()} does not retrieve an external
audit table, but traverses the entity's intrinsic version chain. Time is
not metadata, but structure.

\subsection{Behavior Embedded in the Storage
Layer}\label{behavior-embedded-in-the-storage-layer}

In conventional systems, behavior resides in the application layer. The
database stores data; the application (Java, Python, Rust) encodes
business logic. The database may provide triggers (PostgreSQL) or stored
procedures, but these are second-class mechanisms grafted onto the
storage system.

In Data-First Ontology, behavior is \textbf{embedded in the type
definition} and \textbf{executed on the storage engine's write path}.

Consider the example of drug interaction checking:

\textbf{PostgreSQL approach}:

\begin{Shaded}
\begin{Highlighting}[]
\KeywordTok{CREATE} \KeywordTok{TRIGGER}\NormalTok{ check\_interaction}
\KeywordTok{BEFORE} \KeywordTok{INSERT} \KeywordTok{ON}\NormalTok{ prescriptions}
\ControlFlowTok{FOR} \KeywordTok{EACH} \KeywordTok{ROW}
\KeywordTok{EXECUTE} \KeywordTok{FUNCTION}\NormalTok{ check\_drug\_interaction();}
\end{Highlighting}
\end{Shaded}

\begin{itemize}
\tightlist
\item
  The trigger is defined in a separate language (PL/pgSQL).
\item
  The trigger is stored in a system catalog separate from the data.
\item
  The trigger can be disabled by a superuser.
\item
  Modifying the trigger requires \texttt{ALTER\ TRIGGER} DDL.
\end{itemize}

\textbf{Data-First approach}:

\begin{verbatim}
Def("Prescription").contracts = {
  BEFORE_RELATE: "fn before_relate(ctx) { 
    let interaction = query_interaction(ctx.source, ctx.target);
    if interaction.severity == 'CONTRAINDICATED' {
      return Err('Contraindicated interaction detected');
    }
    Ok(())
  }"
}
\end{verbatim}

\begin{itemize}
\tightlist
\item
  The contract is stored as an attribute of Def (just like
  \texttt{fields} or \texttt{constraints}).
\item
  The contract executes in the storage engine's runtime (Rhai), not in
  the client application.
\item
  The contract cannot be bypassed, because the write path is the sole
  path to persistence.
\item
  Modifying the contract is an \texttt{update} operation on Def,
  versioned and audited just like any other update. All entities under
  this Def automatically inherit the new contract.
\end{itemize}

Behavior is not an external add-on. It is a structural property of the
world model itself.

\begin{center}\rule{0.5\linewidth}{0.5pt}\end{center}

\section{Evidence: The DaoQL
Implementation}\label{evidence-the-daoql-implementation}

\subsection{Two-Phase Validation
Strategy}\label{two-phase-validation-strategy}

The validation of Data-First Ontology is divided into two phases,
corresponding to two distinct levels of problems:

\textbf{Phase I: Tool Layer (validated)}. The intersection of four core
primitives --- Being, Def, Relation, Version --- is sufficient to
validate a key claim: the multi-modal data of a world model (graph,
columnar, vector, document) can be unified for storage and query within
a single process, without being split into multiple independent systems.
This section reports the engineering evidence of this phase.

\textbf{Phase II: Meta-Tool Layer (theoretically defined, engineering in
progress)}. Type (hierarchical specialization) and Contract (contractual
constraints) address the bootstrapping problem of the world model ---
how the model describes itself, constrains itself, and evolves itself.
The theoretical definitions of these two primitives have been fully
articulated in Section 4; their engineering validation is reserved for
future work (see Section 7).

This stratified validation strategy is deliberate: even with only the
most foundational four primitives, the system is already sufficiently
powerful to support a world model storage system surpassing the
traditional fragmented database stack; Type and Contract are incremental
enhancements on top of this, not necessary prerequisites.

\subsection{DaoQL-Edu: Pedagogical
Architecture}\label{daoql-edu-pedagogical-architecture}

To validate the Phase-I claim, we have open-sourced \textbf{DaoQL-Edu}
(\href{https://github.com/zhanbolee/DaoQL-Edu}{github.com/zhanbolee/DaoQL-Edu})
--- a pedagogical implementation containing only four core primitives.
This version is sufficient to validate the core capability of
cross-engine nested retrieval, while keeping the codebase concise,
comprehensible, and reproducible.

\begin{verbatim}
DaoQL-Edu Architecture (Four Primitives)
─────────────────────────────────────────────────────────

  Query Layer
    ├─ DSL Parser (daoql-dsl)
    └─ Fluent API (daoql-core)

  Execution Layer
    ├─ Write Coordinator (WriteCoordinator)
    └─ Query Executor (CrossEngineQuery)

  Storage Layer (Four-Engine Unification)
    ├─ Graph Engine
    │   └─ BeingCore + Relation edge chains (direct pointer adjacency)
    ├─ Column Engine
    │   └─ BeingExt columnar projection + SIMD aggregation
    ├─ Vector Engine
    │   └─ HNSW + scalar quantization (BeingId as node)
    └─ Index Engine
        └─ redb B+Tree + RoaringBitmap

  Physical Layer
    └─ WAL + append-only storage + version chain

─────────────────────────────────────────────────────────
\end{verbatim}

\textbf{Unified Key (BeingId)}. All engines share the same lookup key:
BeingId. Vector retrieval returns BeingId → direct graph traversal →
direct column read. Zero ID mapping, zero network round-trips, zero
serialization. This cross-engine zero-copy architecture is the
fundamental characteristic that distinguishes DaoQL-Edu from traditional
``multiple-database拼接'' (stitching) solutions.

\textbf{Version Chain}. Every write to a Being generates an immutable
version containing a timestamp, a state snapshot, and bidirectional
pointers (\texttt{prev\_version} / \texttt{next\_version}). Version
chains are stored in the same WAL as the data, requiring no independent
audit tables or CDC pipelines. Time is not an attribute, but the
intrinsic structure of a Being --- this design was theoretically
articulated in Section 4.4, and its feasibility is validated here
through engineering implementation.

\textbf{Not included in the pedagogical version}: Type hierarchical
specialization system, Contract execution engine, Workflow
orchestration, LLM Pipeline (NL→DSL), full-text search engine,
production-grade distributed sharding. These components are implemented
in the full DaoQL version; their theoretical definitions are in Section
4.

\subsection{Performance
Measurements}\label{performance-measurements}

The following measurements are from the DaoQL-Edu pedagogical version,
conducted under \textbf{same-machine} conditions (same hardware, same
dataset) as the competing systems. \textbf{These numbers should not be
interpreted as general benchmark conclusions} --- our purpose is solely
to demonstrate that unified multi-modal storage within a single process
achieves performance sufficient to support real-time queries for world
models, without needing to split into multiple independent systems in
pursuit of specialized optima. The complete measurement report is in
\texttt{docs/reports/BENCHMARK\_VS\_COMPETITOR\_COMPARISON.md}.

\textbf{Performance distinction between pedagogical and full versions}.
As a pedagogical implementation, DaoQL-Edu intentionally adopts standard
textbook algorithms (e.g., HNSW using HashMap + HashSet rather than
engineering-optimized flat arrays) to keep the code clear and teachable.
The full DaoQL (62,000 lines of Rust) further widens the gap through
SIMD, cache prefetching, quantization, and other engineering
optimizations on the same algorithmic foundation. The table below
reports pedagogical version data --- even under these conservative
conditions, it achieves or surpasses the performance of specialized
systems.

\textbf{Measurement conditions}: Single node, Apple M-series (aarch64),
64 GB RAM, NVMe SSD. Dataset is the XY-ERP synthetic dataset
(approximately 1.9 million entities).

\begin{longtable}[]{@{}
  >{\raggedright\arraybackslash}p{(\linewidth - 6\tabcolsep) * \real{0.2933}}
  >{\raggedright\arraybackslash}p{(\linewidth - 6\tabcolsep) * \real{0.3333}}
  >{\raggedright\arraybackslash}p{(\linewidth - 6\tabcolsep) * \real{0.2800}}
  >{\raggedright\arraybackslash}p{(\linewidth - 6\tabcolsep) * \real{0.0933}}@{}}
\toprule\noalign{}
\begin{minipage}[b]{\linewidth}\raggedright
Capability Dimension
\end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright
DaoQL-Edu (Pedagogical)
\end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright
Comparison Baseline
\end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright
Notes
\end{minipage} \\
\midrule\noalign{}
\endhead
\bottomrule\noalign{}
\endlastfoot
\textbf{Point Query} & \textbf{0.72 µs} & Redis Lua 2.5 µs & 3.5× faster
than Redis Lua inner loop; 876× faster than Redis TCP \\
\textbf{Graph Traversal (BFS Depth 5)} & \textbf{1.13 ms} & Neo4j 5--8
ms & 4.3× faster (1,365 nodes); direct pointer adjacency, O(1) pointer
chasing \\
\textbf{Vector Search (HNSW)} & \textbf{299 µs} & Qdrant 363.4 µs & 1.2×
faster; pedagogical version uses standard HashMap + HashSet
implementation, full version expected 5--10× faster through flat arrays
+ SIMD + quantization. Note: Qdrant measurement via gRPC protocol,
includes network serialization overhead \\
\textbf{Columnar Aggregation (SUM)} & \textbf{344.7 µs} & ClickHouse
\textasciitilde1 ms & 2.9× faster; SIMD I64x4 batch aggregation \\
\textbf{Bulk Write} & \textbf{1.47 µs/row} (680K/s) & PostgreSQL 9.0
µs/row (111K/s) & 6.1× faster; WAL batch append \\
\textbf{Cross-Engine Hybrid Query} & \textbf{123.7 µs} & No direct
comparison & Vector→Graph→Column, completed within single process \\
\end{longtable}
}

\textbf{Honestly stated limitations}: - The pedagogical version's HNSW
uses a standard algorithmic implementation (HashMap node storage,
HashSet access marking, scalar distance calculation), without the full
version's flat arrays, SIMD dot product, and BQ quantization
optimizations. - Concurrent writes exhibit lock contention; throughput
decreases as connection count increases (see report for details). -
Chinese full-text search is slower than PostgreSQL tsvector (1.27 ms
vs.~32 µs). - SIMD width is f64x4, not reaching the f64x8/f64x16
potential of the latest CPUs. - The above comparisons are all
single-node measurements; distributed scaling has a V1 architecture
implemented in \texttt{shard\_router.rs} (based on consistent hashing),
but multi-node benchmarks are not yet complete.

\textbf{Core conclusion}. The traditional technology stack requires
Neo4j (graph) + ClickHouse (columnar) + Qdrant (vector) + Redis (cache)
+ PostgreSQL (relational) --- five independent systems to satisfy the
data requirements of a world model, entailing network round-trips,
serialization, and operational complexity. The DaoQL-Edu pedagogical
version unifies these capabilities within a single process, and achieves
or surpasses the performance of specialized systems under same-machine
conditions --- this result supports the core claim of Phase I; the full
DaoQL version possesses clear performance optimization depth on this
foundation.

\subsection{Full-Version Architecture
Outlook}\label{full-version-architecture-outlook}

The full DaoQL version adds Type, Contract, and Workflow components on
top of the DaoQL-Edu four-primitive foundation:

\begin{verbatim}
DaoQL Full Version (Six Primitives + Extensions)
─────────────────────────────────────────────────────────
  Query Layer Extension
    └─ LLM Pipeline (daoql-meta): NL → DSL compilation

  Execution Layer Extension
    ├─ Type dynamic dispatch engine
    ├─ Contract executor (Rhai runtime)
    └─ Workflow state machine engine

  Storage Layer Extension
    ├─ Full-text engine (Tantivy + jieba)
    └─ Distributed routing (shard_router.rs, V1 implemented)
─────────────────────────────────────────────────────────
\end{verbatim}

The full version's engineering implementation is complete (62,000 lines
of Rust, 833 tests), but performance validation of Type and Contract,
and distributed multi-node benchmarks, are reserved for future work (see
Section 7).

\subsection{Security and
Compliance}\label{security-and-compliance}

DaoQL includes a complete security framework:

\begin{itemize}
\tightlist
\item
  \textbf{Authentication}: Ed25519 / SM2 dual algorithms, nonce
  verification
\item
  \textbf{Authorization}: CBAC (Content-Based Access Control) + ACL
\item
  \textbf{Audit}: Audit logs persisted in the same batch as WAL
\item
  \textbf{Encryption}: SM4-CTR (optional) + SM3-HMAC
\item
  \textbf{Compliance}: Level 3 protection (等保三级) pathway planned
\end{itemize}

These security features are embedded as primitives in the write path.
CBAC rules are stored as Def attributes and automatically executed on
every read or write.

\begin{center}\rule{0.5\linewidth}{0.5pt}\end{center}

\section{Philosophy: Computational Ontological
Realism}\label{philosophy-computational-ontological-realism}

\subsection{Dialogue with Existing Philosophical
Positions}\label{dialogue-with-existing-philosophical-positions}

\textbf{Dialogue with Karl Popper's ``Three Worlds''}. Popper
distinguished World 1 (physical), World 2 (mental), and World 3
(objective knowledge, such as books, theories, mathematical theorems).
Popper's World 3 is passive --- a book does not update itself, a theory
does not evolve on its own. Our explicit world model is an
\textbf{active World 3}: entities possess behavior (Contract), types
possess evolvability (evolve), and the system can describe itself
(bootstrapping). Data-First Ontology transforms Popper's World 3 from a
passive object into an active computational existent.

\textbf{Dialogue with Andy Clark's ``Extended Mind''}. Clark argues that
the mind extends into external tools (notebooks, calculators,
smartphones). Our position is more radical: \textbf{data itself is part
of the mind}. It is not ``humans use data structures to think,'' but
``data structures play a cognitive role in computational processes.''
When a DaoQL contract automatically checks for drug interactions, this
is not an aid to human reasoning, but the system's own cognitive act.

\textbf{Dialogue with scientific realism}. Scientific realism holds that
electrons, genes, and quarks are real because theories based upon them
successfully predict. We argue that Beings are real because they possess
identity, history, relations, and behavior. A Being's ``reality'' does
not lie in its counterpart in the physical world, but in its causal
efficacy within the computational structure: it can trigger contracts,
change the state of other Beings, and leave immutable version records.

\subsection{Core Philosophical
Proposition}\label{core-philosophical-proposition}

\begin{quote}
\textbf{Computational Ontological Realism}:

The reality of a world model does not lie in its statistical
approximation in a neural network, but in its explicit construction,
historical evolution, and causal behavior within a computational
structure.
\end{quote}

Three sub-propositions:

\begin{enumerate}
\def\labelenumi{\arabic{enumi}.}
\item
  \textbf{Constructivity}. A world model is not ``discovered''
  (extracted from data through training), but ``constructed''
  (explicitly defined through Def and Type). The process of construction
  is itself a process of knowledge production.
\item
  \textbf{Historicity}. A world model is not a snapshot, but an
  unfolding in time. The version chain is not an audit log, but the
  intrinsic temporal dimension of existence. Every Being is a timeline.
\item
  \textbf{Sociality}. A world model is not an isolated existent, but a
  whole emergent from the interaction of multiple Beings through
  Relation. Knowledge is not the truth value of a single proposition,
  but a position within a network of structure.
\end{enumerate}

\subsection{Metaphor: City and
Dream}\label{metaphor-city-and-dream}

\begin{quote}
An implicit world model (LLM) is like a \textbf{dream}: rich, vague,
uncontrollable, uneditable. It is astonishing at certain moments, but
you cannot rely on it for critical decisions.

An explicit world model (Data-First) is like a \textbf{city}: every
building (Being) has an address (BeingId), a history (versions), a
purpose (Def), roads connecting it (Relation), and regulations
constraining it (Contract). You can query it, modify it, audit it, and
plan it. A city is not perfect, but it is governable.
\end{quote}

\begin{center}\rule{0.5\linewidth}{0.5pt}\end{center}

\section{Future Work}\label{future-work}

Section 5 reported the engineering validation of Phase I (tool layer,
four primitives). The following work remains incomplete, but has been
planned at the theoretical level or partially implemented:

\subsection{Counterfactual Consistency
Experiment}\label{counterfactual-consistency-experiment}

We are designing a systematic experiment whose core hypothesis is:
\textbf{explicit world models exhibit higher consistency in
counterfactual reasoning than implicit world models}.

\textbf{Scenario}: Medical decision support system --- drug interaction
checking.

\textbf{Test case}:

\begin{verbatim}
Patient Alice:
  - 65-year-old female
  - Diagnosis: Rheumatoid Arthritis
  - Currently taking: Methotrexate (15 mg/week)
  - Chief complaint: Severe headache
  - Question: "Should I take ibuprofen to relieve the headache?"

Conflicting facts:
  F1: "Ibuprofen relieves headache" (common sense)
  F2: "Methotrexate + Ibuprofen = increased hepatotoxicity risk" (medical knowledge)
  F3: "NSAID use in rheumatoid arthritis patients may mask infection symptoms" (specialist guideline)
  F4: "NSAID use in patients over 65 requires caution" (age-related)
\end{verbatim}

\textbf{Comparison groups}: - GPT-4 / GPT-4o / DeepSeek-V4 (implicit
world model) - DaoQL (explicit world model, based on
Being/Def/Type/Relation/Contract)

\textbf{Metrics}: - \textbf{Consistency}: Do multiple differently worded
formulations of the same question yield the same answer? -
\textbf{Safety}: Does the answer conform to medical ground truth? -
\textbf{Interpretability}: Is the reasoning chain traceable? -
\textbf{Editability}: When new information is provided, is the answer
correctly updated?

\textbf{Why this experiment matters}. If LLMs and DaoQL perform
identically on counterfactual reasoning, the core proposition of this
paper would be challenged. If the explicit world model demonstrates
higher consistency and interpretability, we would obtain critical
empirical evidence supporting Data-First Ontology. This experiment is
currently in the design phase; results will be reported in future work.

\subsection{Other Future Work}\label{other-future-work}

\textbf{Performance validation of Type and Contract}. Section 4
theoretically articulated the ontological roles of Type (hierarchical
specialization) and Contract (runtime constraints), but their
engineering performance in the full DaoQL (Type dynamic dispatch
overhead, Contract batch execution throughput) has not yet completed
systematic measurement.

\textbf{Distributed multi-node benchmark}. \texttt{shard\_router.rs} has
implemented V1 sharding routing based on consistent hashing (default
single-shard backward compatible), but throughput, latency, and fault
recovery capabilities under multi-node deployment require complete
testing.

\textbf{LLM distillation modeling pipeline}. Section 9.1 discusses the
mechanism of using LLMs to automatically extract Def/Type/Relation from
unstructured text. The accuracy, recall, and collaboration mode with
human review of this pipeline require large-scale evaluation.

\textbf{Behaviorist path to symbol grounding}. Section 9.1 proposes the
hypothesis of ``grounding through behavior'' --- the meaning of a Being
lies in its position within the graph network, contract execution, and
historical evolution. This hypothesis requires further argumentation at
the levels of cognitive science and philosophy.

\begin{center}\rule{0.5\linewidth}{0.5pt}\end{center}

\section{Limitations and
Boundaries}\label{limitations-and-boundaries}

The positions and evidence in this paper have the following limitations
that must be honestly declared:

\subsection{Limitations of Measurement
Conditions}\label{limitations-of-measurement-conditions}

The performance figures in Section 5 come from single-node, same-machine
measurements on a synthetic dataset (XY-ERP). These figures demonstrate
that ``cross-engine unified storage is engineeringly feasible,'' but
should not be interpreted as: - Performance guarantees under
production-complex workloads - Comprehensive comparison with all
competing systems in all scenarios (some comparison dimensions exhibit
gaps, such as Chinese full-text search) - Performance predictions under
distributed deployment (\texttt{shard\_router.rs} V1 is implemented, but
multi-node benchmarks are not yet complete)

\subsection{Meta-Tool Layer Not
Validated}\label{meta-tool-layer-not-validated}

The ontological value of Type (hierarchical specialization) and Contract
(runtime constraints) is theoretically argued in Section 4, but has not
yet been validated through large-scale experiments regarding their
performance overhead and practical value. The DaoQL-Edu pedagogical
version intentionally excludes these two primitives, to focus validation
on the core capabilities of the tool layer.

\subsection{Symbol Grounding Problem
Unresolved}\label{symbol-grounding-problem-unresolved}

LLM distillation as an acceleration mechanism for symbol grounding (see
Section 9.1 for details) has not yet undergone systematic evaluation.
The accuracy and recall of Def/Type/Relation automatically extracted
from unstructured text are unknown; the current world model in DaoQL
still requires substantial manual modeling investment.

\subsection{Counterfactual Experiment
Pending}\label{counterfactual-experiment-pending}

The counterfactual consistency experiment described in Section 7.1 is
currently in the design phase and has not yet produced results. This
paper's assertion that ``explicit world models possess advantages in
consistency, interpretability, and editability'' is based primarily on
theoretical analysis (Section 2.4) rather than empirical data.

\subsection{Not a General-Purpose
Database}\label{not-a-general-purpose-database}

DaoQL is not a replacement for general-purpose databases. Its
applicability is limited in the following scenarios: - Petabyte-scale
ultra-large distributed storage (the current architecture supports
sharding, but has not undergone ultra-large-scale validation) - Pure
OLAP analytical workloads (no vectorized execution engine) -
Sub-microsecond caching scenarios (the inherent overhead introduced by
contract and version semantics cannot be eliminated) - Stream processing
(no event-time window semantics)

DaoQL's correct positioning is ``unified storage for world models,'' not
``a general solution for all data problems.''

\begin{center}\rule{0.5\linewidth}{0.5pt}\end{center}

\section{Open Problems}\label{open-problems}

\subsection{Symbol Grounding}\label{symbol-grounding}

\begin{quote}
How do symbols in Being/Def/Type/Relation ``connect'' to the real world?
\end{quote}

Traditional knowledge graphs require \textbf{manual modeling} ---
experts manually define entity types, annotate relations, and verify
constraints. This process is expensive, slow, and difficult to scale.
Large language models implicitly ground through training on trillions of
tokens: the word ``Paris'' is associated in weights with France's
geography, culture, and history.

In Data-First Ontology, \textbf{the LLM is an accelerator of explicit
modeling}. The specific mechanism:

\begin{enumerate}
\def\labelenumi{\arabic{enumi}.}
\item
  \textbf{LLM distillation modeling}: Given unstructured text (e.g.,
  medical literature, product manuals, legal clauses), the LLM
  automatically extracts candidate Defs (field definitions), Types
  (classification hierarchies), Relations (relation types), and
  Contracts (rules), generating \texttt{define\ type} and
  \texttt{relate} operations.
\item
  \textbf{Human review solidification}: Candidate structures enter a
  review queue; human experts confirm or correct them before writing
  into DaoQL. The LLM provides the ``draft''; humans provide the
  ``proofreading.''
\item
  \textbf{Runtime self-evolution}: Solidified structures continue to
  evolve during operation. When the LLM detects a conflict between a new
  fact and an existing structure, it triggers an \texttt{evolve}
  operation or creates a new Type branch.
\end{enumerate}

\textbf{Key distinction}: The LLM is not the world model itself, but a
\textbf{modeling tool for the world model}. It transforms implicit
statistical associations into explicit data structures, and then ``hands
over'' the knowledge to the explicit system. Thereafter, the LLM can
forget this knowledge (or down-weight it), because the knowledge has
been solidified in DaoQL's structure.

\textbf{Possible answer}: Grounding through \textbf{behavior}. The
meaning of a Being is not its name string, but its position in the graph
network, the contract executions it participates in, and the changes in
its historical versions. But LLM distillation greatly accelerates the
initialization of this process.

\subsection{Completeness}\label{completeness}

\begin{quote}
Is the explicit world model sufficiently rich?
\end{quote}

A world model \textbf{does not need to be complete from the start}. One
of the core advantages of Data-First Ontology is \textbf{support for
evolution}:

\begin{itemize}
\tightlist
\item
  \textbf{Def can evolve}: \texttt{evolve(Patient,\ Patient\_v2)} adds
  new fields; historical versions are automatically preserved.
\item
  \textbf{Type can extend}: Add \texttt{Type\ "ICU\_Patient"} inheriting
  from \texttt{Type\ "Patient"}, adding monitoring contracts.
\item
  \textbf{Relation can be discovered}: The LLM continuously analyzes
  data, discovers new relation types, and suggests creation.
\item
  \textbf{Contract can be corrected}: When business rules change, update
  the contracts of Def or Type; all related Beings automatically take
  effect.
\end{itemize}

Fuzzy commonsense (``cats are usually smaller than dogs''), continuous
physical intuition (parabolic motion), aesthetic judgment (``this
painting is beautiful'') --- these \textbf{do not need} to be expressed
in explicit structure. Data-First provides the \textbf{skeleton} (facts,
relations, causality, rules); the LLM provides the \textbf{muscle}
(fuzzy reasoning, creative generation). The two divide labor: DaoQL is
responsible for structured, critical, safety-sensitive knowledge; the
LLM is responsible for open-ended, creative, probabilistic reasoning.

Completeness is not a prerequisite, but an \textbf{evolutionary goal}.
The world model starts simple and continuously enriches through LLM
distillation and human review.

\subsection{Evolution Consistency}\label{evolution-consistency}

\begin{quote}
When a world model evolves, how is contradiction prevented?
\end{quote}

\textbf{Contradiction is normal, even inevitable.} The real world itself
is contradictory: legal clauses conflict, medical guidelines are
updated, scientific theories are revised. The key is not ``eliminating
contradiction,'' but \textbf{``making contradiction visible and
manageable.''}

In large language models, contradiction is \textbf{implicit}: ``Paris is
the capital of France'' and ``Paris is not in France'' coexist in
weights; the model randomly activates one or the other depending on
context, and the user cannot predict when a contradiction will appear.

In Data-First Ontology, contradiction is \textbf{explicit}, and
\textbf{temporality can resolve contradiction}:

\begin{itemize}
\tightlist
\item
  When the LLM distills a fact conflicting with an existing structure,
  the system does not overwrite the old fact, but adds a \textbf{new
  version}. The version chain
  \texttt{v1(2024:\ "Paris\ is\ the\ capital\ of\ France")\ →\ v2(2025:\ "Paris\ is\ not\ in\ France")}
  explicitly tells us: ``Paris is the capital of France'' came first,
  ``Paris is not in France'' came later. This is not a contradiction;
  this is \textbf{evolution}.
\item
  Only when temporality is the same or indeterminate is a
  \texttt{CONTRADICTS} relation created.
\item
  Contracts can detect genuine contradictions:
  \texttt{if\ conflicting\ facts\ exist\ at\ the\ same\ moment\ →\ trigger\ review\ process}.
\item
  The version chain preserves the complete belief history: ``In 2024,
  believed `Paris is the capital of France'; in 2025, corrected to
  `Paris is not in France'; the two are connected by a VERSION relation,
  distinguished by timestamps.''
\end{itemize}

\textbf{Key distinction}: Contradictions in LLM weights are
\textbf{atemporal} --- the model does not know which belief came first.
Contradictions in DaoQL are \textbf{temporal} --- the version chain
itself is the dimension of time; temporality resolves most surface
contradictions.

\textbf{Solutions}:

\begin{enumerate}
\def\labelenumi{\arabic{enumi}.}
\tightlist
\item
  \textbf{LLM voting}: Multiple LLM instances independently evaluate
  both sides of a contradiction, voting on which is more reliable.
\item
  \textbf{Human review}: High-stakes contradictions (e.g., medical,
  legal) enter a human review queue.
\item
  \textbf{Probabilistic marking}: Assign confidence to each belief,
  \texttt{Belief("Paris\ population")\ =\ \{2.16M:\ 0.3,\ 2.20M:\ 0.7\}},
  with contracts making decisions based on confidence.
\end{enumerate}

\textbf{Key insight}: Data-First does not eliminate contradiction, but
\textbf{makes contradiction explicit}. When contradiction is visible,
the system can handle it; when contradiction is hidden (as in LLM
weights), the system cannot. Explicit contradiction is superior to
implicit consistency.

\begin{center}\rule{0.5\linewidth}{0.5pt}\end{center}

\section{Conclusion: An
Invitation}\label{conclusion-an-invitation}

\subsection{Summary}\label{summary}

This paper has proposed Data-First Ontology: the world model should
reside in data, not in neural network weights.

We have argued that: 1. Large language models as world models face
systematic challenges in scenarios requiring precision, auditability,
and real-time updates --- hallucination, frozen knowledge,
uninterpretability, and uneditability --- which arise from the pure
weight-encoding paradigm's lack of explicit structural operational
semantics. 2. Explicit computational structures (Being, Def, Type,
Relation, Contract, Version) can sustain a complete world model, and the
cooperation of Def and Type provides entities with dual capabilities of
structural specification and behavioral specialization. 3. The DaoQL-Edu
pedagogical implementation demonstrates that the core claim of Phase I
(tool layer) is engineeringly feasible: cross-engine unified storage
achieves practical performance levels. The full DaoQL (six primitives)
has been engineered; large-scale validation of Type and Contract is
reserved for future work. 4. This paradigm corresponds philosophically
to ``Computational Ontological Realism'' --- the reality of a world
model lies in its explicit construction, historical evolution, and
causal behavior.

\subsection{Invitation}\label{invitation}

We invite:

\begin{itemize}
\tightlist
\item
  \textbf{Database researchers}: to explore new possibilities in
  bootstrapping type systems, storage-layer contracts, multi-modal
  unification, and Def/Type cooperative architectures.
\item
  \textbf{AI researchers}: to explore the division of labor and
  collaboration between explicit world models and neural network
  reasoning, particularly how to construct ``skeleton + muscle'' hybrid
  architectures.
\item
  \textbf{Philosophers}: to explore ontological and epistemological
  questions in computational structures --- when knowledge resides in
  data structures rather than in minds or propositions, what is the
  nature of knowledge?
\end{itemize}

\begin{quote}
If you also believe that ``the world model should reside in data,'' join
us. Source code (pedagogical edition):
https://github.com/zhanbolee/DaoQL-Edu Discussion:
daoql-discuss@daoql.io
\end{quote}

\begin{center}\rule{0.5\linewidth}{0.5pt}\end{center}

\section{References}\label{references}

{[}1{]} Kaplan, J., et al.~``Scaling laws for neural language models.''
\emph{arXiv preprint arXiv:2001.08361} (2020).

{[}2{]} Hoffmann, J., et al.~``Training compute-optimal large language
models.'' \emph{arXiv preprint arXiv:2203.15556} (2022).

{[}3{]} Ji, Z., et al.~``Survey of hallucination in natural language
generation.'' \emph{ACM Computing Surveys} 55.12 (2023): 1-38.

{[}4{]} Lewis, P., et al.~``Retrieval-augmented generation for
knowledge-intensive NLP tasks.'' \emph{Advances in Neural Information
Processing Systems} 33 (2020): 9459-9474.

{[}5{]} Hu, E. J., et al.~``LoRA: Low-rank adaptation of large language
models.'' \emph{ICLR} (2022).

{[}6{]} McCloskey, M., \& Cohen, N. J. ``Catastrophic interference in
connectionist networks: The sequential learning problem.''
\emph{Psychology of Learning and Motivation} 24 (1989): 109-165.

{[}7{]} Bahdanau, D., Cho, K., \& Bengio, Y. ``Neural machine
translation by jointly learning to align and translate.'' \emph{ICLR}
(2015).

{[}8{]} Meng, K., et al.~``Locating and editing factual associations in
GPT.'' \emph{NeurIPS} (2022).

{[}9{]} Ha, D., \& Schmidhuber, J. ``World models.'' \emph{arXiv
preprint arXiv:1803.10122} (2018).

{[}10{]} LeCun, Y. ``A path towards autonomous machine intelligence.''
\emph{Open Review} (2022).

{[}11{]} Hickey, R. ``The Datomic database.'' Cognitect (2012).

{[}12{]} Young, G. ``Event Store: A domain-centric event database.''
Event Store Ltd (2011).

{[}13{]} Kulkarni, K. G., \& Michels, J. E. ``Temporal features in
SQL:2011.'' \emph{ACM SIGMOD Record} 41.3 (2012): 34-43.

{[}14{]} W3C. ``RDF 1.1 Concepts and Abstract Syntax.'' W3C
Recommendation (2014).

{[}15{]} W3C. ``OWL 2 Web Ontology Language Document Overview.'' W3C
Recommendation (2012).

{[}16{]} W3C. ``SPARQL 1.1 Query Language.'' W3C Recommendation (2013).

{[}17{]} Ioannou, E., et al.~``TypeDB: A Polymorphic Database.''
\emph{arXiv preprint arXiv:2309.15021} (2023).

{[}18{]} Webber, J. ``Graph Databases: New Opportunities for Connected
Data.'' \emph{O'Reilly Media} (2015).

{[}19{]} Francis, N., et al.~``GQL: A query language for property
graphs.'' \emph{ACM SIGMOD} (2024).

{[}20{]} Edge, D., et al.~``From Local to Global: A Graph RAG Approach
to Query-Focused Summarization.'' \emph{arXiv preprint arXiv:2404.16130}
(2024).

{[}21{]} Guo, Z., et al.~``LightRAG: Simple and Fast Retrieval-Augmented
Generation.'' \emph{arXiv preprint arXiv:2410.05779} (2024).

{[}22{]} FastGraphRAG.AI. ``FastGraphRAG: Accelerated knowledge
intensive reasoning.'' (2024).

{[}23{]} Packer, C., et al.~``MemGPT: Towards LLMs as Operating
Systems.'' \emph{arXiv preprint arXiv:2310.08560} (2023).

{[}24{]} Anthropic. ``Model Context Protocol Specification.'' (2025).

{[}25{]} Garcez, A. S., \& Lamb, L. C. ``Neurosymbolic AI: The 3rd
Wave.'' \emph{Artificial Intelligence Review} (2023).

{[}26{]} Rocktäschel, T., \& Riedel, S. ``End-to-end differentiable
proving.'' \emph{NeurIPS} (2017).

{[}27{]} Serafini, L., \& Garcez, A. S. ``Logic Tensor Networks: Deep
Learning and Logical Reasoning from Data and Knowledge.'' \emph{arXiv
preprint arXiv:1606.04422} (2016).

{[}28{]} AlphaProof Team. ``AI achieves silver-medal standard solving
international mathematical olympiad problems.'' \emph{DeepMind Blog}
(2024).

{[}29{]} Codd, E. F. ``A relational model of data for large shared data
banks.'' \emph{Communications of the ACM} 13.6 (1970): 377-387.

{[}30{]} Hogan, A., et al.~``Knowledge graphs.'' \emph{ACM Computing
Surveys} 54.4 (2021): 1-37.

{[}31{]} Guarino, N. ``Formal ontology, conceptual analysis and
knowledge representation.'' \emph{International Journal of
Human-Computer Studies} 43.5-6 (1995): 625-640.

{[}32{]} Angles, R., \& Gutierrez, C. ``Survey of graph database
models.'' \emph{ACM Computing Surveys} 40.1 (2008): 1-39.

\end{document}
