[Design] AIKernel.NET — A Knowledge OS for Deterministic AI Execution (v0.1.0 Draft)

[egumaru]

AIKernel.NET Architecture Overview

— A Knowledge OS for Deterministic AI Execution (v0.1.0 Draft)

Summary / 概要

This issue describes the reference architecture draft of AIKernel.NET as of v0.1.0, focusing on the ROM-centric knowledge model and the deterministic execution pipeline that enables reproducible, governable, and transparent AI behavior.

本 Issue は、AIKernel.NET v0.1.0 に向けた 参照アーキテクチャ草案（Reference Architecture Draft） です。
特に、ROM を中心とした知識モデル と、再現可能・統治可能・透明な AI 実行を実現する 決定論的実行パイプライン に焦点を当てます。

AIKernel.NET is not an AI wrapper.
It is an execution foundation that treats knowledge as an operating-system-level resource.

AIKernel.NET は AI ラッパーではありません。
知識を OS レベルのリソースとして扱うための実行基盤です。

---

Definition of ROM / ROM の定義

In AIKernel.NET, ROM stands for Relation-Oriented Markdown.

AIKernel.NET における ROM は、Relation-Oriented Markdown の略です。

ROM is the canonical representation format and verification boundary for intelligent assets in AIKernel.
It is a Markdown-based file format that describes knowledge, metadata, relations, disclosure levels, and governance boundaries in a structured and verifiable way.

ROM は、AIKernel における 知能資産の正準表現 であり、同時に 検証境界 です。
Markdown を基盤とし、知識・メタデータ・関係性・開示レベル・統治境界を、構造化され検証可能な形で記述するためのファイル形式です。

In other words, ROM is not merely documentation.
It is the knowledge format that AIKernel mounts, indexes, governs, snapshots, and executes against.

言い換えると、ROM は単なるドキュメントではありません。
AIKernel がマウントし、索引化し、統治し、スナップショット化し、実行時の文脈として扱うための知識フォーマットです。

A ROM file may include:

ROM ファイルには、例えば以下の情報が含まれます。

• Markdown body

• YAML front matter

• rom_id

• tags

• relations

• security

• signature

• semantic structure

• verification boundary

• Markdown 本文

• YAML フロントマター

• rom_id

• tags

• relations

• security

• signature

• 意味構造

• 検証境界

---

Core Principles / 基本原則

AIKernel.NET is based on the following three architectural principles.

AIKernel.NET のアーキテクチャは、以下の 3 つの基本原則に基づきます。

---

1. ROM is the Source of Truth

1. ROM は唯一の正本である

ROM, or Relation-Oriented Markdown, is the single source of truth for AIKernel.

ROM、すなわち Relation-Oriented Markdown は、AIKernel における唯一の正本（Single Source of Truth）です。

• ROM is written as Markdown files with structured metadata.

• ROM is edited with tools such as Obsidian.

• ROM is version-controlled with Git.

• At runtime, ROM is fixed as a ContextSnapshot and treated as immutable.

• ROM becomes the reference point for Deterministic Replay.

• ROM は構造化メタデータを持つ Markdown ファイルとして記述されます。

• ROM は Obsidian などで編集されます。

• ROM は Git によって管理されます。

• 実行時には ContextSnapshot として固定され、不変の参照点として扱われます。

• ROM は Deterministic Replay の基点となります。

---

2. CacheDB is a Disposable Projection

2. CacheDB は再生成可能な射影である

CacheDB is not the source of truth.
It is a disposable projection derived from ROM.

CacheDB は正本ではありません。
ROM から生成される、再生成可能な射影（Projection）です。

• CacheDB accelerates search, indexing, and relation traversal.

• CacheDB can be discarded and rebuilt from ROM.

• The underlying DBMS can be replaced through providers.

• CacheDB は ROM の検索・索引・関係探索を高速化します。

• CacheDB は破棄しても ROM から再生成できます。

• DBMS は Provider により差し替え可能です。

---

3. Governance is a Cross-Cutting Control Plane

3. Governance は横断的な制御プレーンである

Governance is not merely a final output filter.
It is a cross-cutting control plane that applies across all layers.

Governance は単なる最後の出力フィルタではありません。
全レイヤーを横断して適用される制御プレーンです。

Governance applies to:

Governance は以下に適用されます。

• VFS access / VFS アクセス

• ROM selection / ROM 選択

• relation traversal / relations の探索

• Phase 1 context building / Phase 1 の文脈構築

• Provider routing / Provider ルーティング

• Phase 2 inference / Phase 2 の推論

• output filtering / 出力フィルタ

• Replay access control / Replay アクセス制御

---

Layer Model / レイヤーモデル

AIKernel.NET is organized around the following layers.

AIKernel.NET は以下のレイヤーを中心に構成されます。

VFS        = Grounding Layer / 接地層
ROM        = Source of Truth / 正本となる知識
CacheDB    = Disposable Projection / 再生成可能な索引・検索層
Phase 1    = Context Build / 文脈生成
Phase 2    = Inference / 推論
Governance = Cross-Cutting Control Plane / 横断的な制御・統治

The overall intelligence cycle is:

全体の知能サイクルは以下の通りです。

VFS → ROM → CacheDB → Phase 1 → Governance → Phase 2 → Governance

---

1. Essence of AIKernel.NET / AIKernel.NET の本質

AIKernel.NET is not an AI wrapper.
It is an execution foundation that treats knowledge assets written as ROM like operating-system-level resources.

AIKernel.NET は「AI ラッパー」ではありません。
ROM として記述された知能資産を OS レベルのリソースとして扱う実行基盤です。

Conceptually:

概念的には、以下のように整理できます。

ROM        = Canonical Knowledge Asset / 正準化された知能資産
CacheDB    = High-speed Search Engine / 高速検索エンジン
Phase 1    = Context Build / 文脈生成
Phase 2    = Inference / 推論
Governance = Safety and Control / 安全制御

This structure allows AIKernel.NET to externalize the intelligence cycle as an architecture.

この構造により、AIKernel.NET は知能の実行サイクルをアーキテクチャとして外部化します。

---

2. VFS — Grounding Layer / 接地層

Role / 役割

VFS abstracts where ROM files are physically stored.

VFS は、ROM ファイルが物理的にどこに配置されているかを抽象化します。

Examples:

例：

• Local file system

• GitHub

• Cloud Storage

• Encrypted Storage / 暗号化ストレージ（将来）

Characteristics / 特性

• Separation of Read / Write / List operations

• Provider-based abstraction

• Decoupling of ROM location from the Kernel

• 読み取り / 書き込み / 列挙操作の分離

• Provider による抽象化

• ROM の物理配置と Kernel の分離

Meaning / 意味

ROM can be stored anywhere.
The Kernel can treat it uniformly regardless of location.

ROM はどこに配置されてもよい。
Kernel はどこにあっても同じように扱える。

---

3. ROM & CacheDB — Knowledge Layer / 知識層

3.1 ROM — Relation-Oriented Markdown

ROM is the Markdown-based canonical format for AIKernel knowledge assets.

ROM は、AIKernel の知識資産を表す Markdown ベースの正準フォーマットです。

A ROM file consists of:

ROM ファイルは以下で構成されます。

• Markdown body

• YAML metadata such as rom_id, tags, relations, security, and signature

• Relation definitions that form a knowledge graph

• Security tags that define disclosure levels

• Verification boundaries for governance and replay

• Markdown 本文

• rom_id, tags, relations, security, signature などの YAML メタデータ

• 知識グラフを形成する relations 定義

• 開示レベルを定義する security tags

• Governance と Replay のための検証境界

ROM is editable by humans, but at execution time it is fixed as a snapshot and treated as immutable.

ROM は人間が編集可能な形式ですが、実行時にはスナップショットとして固定され、不変の参照点として扱われます。

---

3.1.1 WikiLink and Relations Synchronization / WikiLink と relations の同期方針

In the initial phase, AIKernel does not require authors to manually maintain both YAML relations and body-level [[WikiLink]] entries as separate sources of truth.

初期フェーズにおいて、AIKernel は YAML の relations と本文中の [[WikiLink]] を、人間が二重に管理することを前提とはしません。

Instead, the primary authoring model is human-driven:

基本方針は、人間主導のオーサリングモデルです。

• Humans connect knowledge naturally using Obsidian [[WikiLink]].

• AIKernel parses those links.

• AIKernel infers, complements, and validates relation metadata.

• The resulting relation structure can then be materialized into YAML relations.

• Once verified, the ROM is signed by embedding a hash into the signature field.

• 人間は Obsidian の [[WikiLink]] を使って自然に知識を接続します。

• AIKernel はそれらのリンクをパースします。

• AIKernel は関係性メタデータを推論・補完・検証します。

• 検証された関係構造は YAML の relations に反映できます。

• 検証後、ROM は signature 項目にハッシュ値を埋め込むことで署名されます。

In this model, [[WikiLink]] is treated as the human-editable relation surface, while YAML relations is treated as the normalized and verifiable relation metadata used by AIKernel.

このモデルでは、[[WikiLink]] は人間が編集しやすい関係表現として扱われ、YAML の relations は AIKernel が利用する正規化済み・検証可能な関係メタデータとして扱われます。

Therefore, the system is not intended to introduce unmanaged duplication.
The goal is to establish a semi-automated pipeline:

したがって、この設計は未管理の二重管理を導入するものではありません。
目的は、以下のような半自動化パイプラインを確立することです。

Human-authored WikiLink
→ AI parsing
→ Relation inference
→ Relation validation
→ YAML relations materialization
→ ROM signature
→ Immutable ContextSnapshot

人間が記述した WikiLink
→ AI によるパース
→ 関係性の推論
→ 関係性の検証
→ YAML relations への反映
→ ROM 署名
→ 不変の ContextSnapshot

After signature generation, the ROM becomes a fixed verification boundary for deterministic replay and governance.

署名生成後の ROM は、Deterministic Replay と Governance のための固定された検証境界となります。

This allows AIKernel to support Obsidian-native authoring while still maintaining a canonical, verifiable, and machine-readable knowledge representation.

これにより、AIKernel は Obsidian ネイティブな執筆体験を維持しながら、正準的・検証可能・機械可読な知識表現を保持できます。

---

3.2 CacheDB

CacheDB is a lightweight database used to access ROM efficiently.

CacheDB は ROM を高速に扱うための軽量データベースです。

Possible tables include:

想定されるテーブル：

• rom_index

• tag_table

• relation_table

• hash-based change detection

• FTS, if needed

• rom_index

• tag_table

• relation_table

• ハッシュ差分検出

• 必要に応じた FTS

CacheDB is not authoritative.
It is always derived from ROM.

CacheDB は正本ではありません。
常に ROM から生成される派生物です。

---

3.3 Provider Abstraction

The CacheDB backend can be replaced through providers.

CacheDB のバックエンドは Provider により差し替え可能です。

Examples:

例：

• EF + LocalDB

• SQLite

• LiteDB

• PostgreSQL

• InMemory

This balances developer experience and architectural purity.

これにより、DX とアーキテクチャ純度の両立を目指します。

---

4. Phase 1 & Phase 2 — Reasoning Layer / 推論層

4.1 Phase 1 — Context Build / 文脈生成

Phase 1 searches ROM through CacheDB and follows relations to build the strongest possible context before inference.

Phase 1 は CacheDB から ROM を検索し、relations を辿ることで、推論前に最適な文脈を構築します。

Examples:

例：

• derives_from → trace background knowledge / 背景知識を遡る

• depends_on → resolve required dependencies / 必須依存を解決する

• related → enrich context / 文脈を補強する

• security tags → filter by disclosure level / 開示レベルでフィルタする

• Capability → restrict accessible knowledge / 参照可能な知識範囲を制限する

Phase 1 is where AIKernel controls what the model is allowed to know before inference.

Phase 1 は、推論前に「モデルが何を知ることを許されるか」を制御する層です。

---

4.2 Phase 2 — Inference / 推論

Phase 2 sends the context built by Phase 1 to an AI Provider.

Phase 2 は、Phase 1 が構築した文脈を AI Provider に投入します。

Examples:

例：

• OpenAI

• Azure OpenAI

• Local models

• Other provider implementations

Provider abstraction absorbs differences between models and endpoints.

Provider 抽象化により、モデルやエンドポイントの違いを吸収します。

The goal is not to make the LLM itself deterministic.
The goal is to make the execution process reproducible and governable.

目的は LLM そのものを完全に決定論的にすることではありません。
目的は、実行プロセスを再現可能かつ統治可能にすることです。

---

5. Governance — Cross-Cutting Control / 横断的制御

Governance ensures safety, transparency, and controllability across AIKernel.NET.

Governance は AIKernel.NET 全体の安全性・透明性・制御性を担保します。

---

5.1 Disclosure Level Tags / 開示レベルタグ

ROM may define disclosure levels such as:

ROM には以下のような開示レベルを定義できます。

• public

• internal

• private

• secret

• system

---

5.2 Capability × Disclosure Level Access Control

5.2 Capability × 開示レベルのアクセス制御

Governance controls:

Governance は以下を制御します。

• which Capability

• can access which ROM

• in which Phase

• どの Capability が

• どの ROM を

• どの Phase で参照できるか

---

5.3 Output Filtering / 出力フィルタ

Example policy:

ポリシー例：

private  → must not be exposed directly / 直接出力禁止
secret   → must not be passed to Phase 2 / Phase 2 に渡さない
internal → excluded from external output / 外部出力時に除外

Governance is therefore not only a safety mechanism.
It is part of the execution model itself.

Governance は単なる安全機構ではありません。
実行モデルそのものの一部です。

---

6. Intelligence Execution Cycle / 知能の実行サイクル

The overall execution flow is as follows.

全体の実行フローは以下の通りです。

---

1. Human / 人間

• Edit ROM with Obsidian

• Build the knowledge graph through [[WikiLink]]

• Optionally review generated YAML relations

• Obsidian で ROM を編集する

• [[WikiLink]] により知識グラフを構築する

• 必要に応じて生成された YAML relations を確認する

---

2. Indexer

• Watches VFS

• Detects ROM changes

• Parses Markdown, YAML metadata, and [[WikiLink]]

• Updates CacheDB

• VFS を監視する

• ROM の変更を検知する

• Markdown、YAML メタデータ、[[WikiLink]] をパースする

• CacheDB を更新する

---

3. Kernel — Phase 1

• Receives intent

• Extracts the optimal ROM set from CacheDB

• Traverses normalized relations

• Builds context

• Intent を受け取る

• CacheDB から最適な ROM セットを抽出する

• 正規化された relations を辿る

• 文脈を構築する

---

4. Governance — Pre-Inference / 前段 Governance

• Filters ROM by disclosure level

• Checks Capability-based access rights

• Verifies signature and snapshot boundary

• 開示レベルで ROM をフィルタする

• Capability によるアクセス権を確認する

• 署名とスナップショット境界を検証する

---

5. AI Provider — Phase 2

• Executes inference with safe, governed context

• 安全に統治された文脈で推論を実行する

---

6. Governance — Post-Inference / 後段 Governance

• Sanitizes output according to policy

• Returns the result to the user

• 出力ポリシーに従ってサニタイズする

• ユーザーへ返却する

---

7. Current Conclusion / 現時点での結論

At this point, the AIKernel.NET architecture can be summarized as follows:

現時点で、AIKernel.NET のアーキテクチャは以下のように整理できます。

• All major layers are connected around ROM.

• ROM is defined as Relation-Oriented Markdown, the canonical representation of intelligent assets.

• [[WikiLink]] is treated as the human-editable relation surface.

• YAML relations is treated as normalized and verifiable relation metadata.

• The flow VFS → ROM → CacheDB → Phase 1 → Phase 2 → Governance forms a coherent intelligence cycle.

• The remaining major design area is the integration of Capability × Disclosure Level in Governance.

• Implementation of the full Governance model can be deferred until the surrounding layers are stable.

• AIKernel.NET の主要レイヤーは ROM を中心に連動している。

• ROM は Relation-Oriented Markdown、つまり知能資産の正準表現として定義される。

• [[WikiLink]] は人間が編集しやすい関係表現として扱う。

• YAML relations は正規化済み・検証可能な関係メタデータとして扱う。

• VFS → ROM → CacheDB → Phase 1 → Phase 2 → Governance の流れは、ひとつの知能サイクルとして成立している。

• 残る主要な未設計領域は、Governance における Capability × 開示レベル の統合である。

• 完全な Governance モデルの実装は、周辺機能が安定してからでよい。

---

Discussion Points / 議論したいポイント

Feedback is especially welcome on the following areas:

特に以下についてフィードバックを歓迎します。

• Is ROM correctly defined as Relation-Oriented Markdown, the canonical representation of intelligent assets?

• Is the ROM-centric architecture appropriate as the foundation of AIKernel.NET?

• How should [[WikiLink]] and YAML relations be synchronized without introducing unmanaged duplication?

• Is CacheDB correctly positioned as a disposable projection rather than a source of truth?

• Should Governance be implemented as a cross-cutting control plane from the beginning?

• How should Capability × Disclosure Level × Phase be modeled?

• What should be included in v0.1.0, and what should remain future work?

• ROM を Relation-Oriented Markdown、つまり知能資産の正準表現として定義することは妥当か？

• ROM 中心アーキテクチャは AIKernel.NET の基盤として妥当か？

• [[WikiLink]] と YAML relations を、未管理の二重管理にならない形でどのように同期すべきか？

• CacheDB を正本ではなく再生成可能な射影として位置づける設計は妥当か？

• Governance は初期段階から横断的制御プレーンとして扱うべきか？

• Capability × 開示レベル × Phase をどのようにモデル化すべきか？

• v0.1.0 に含めるべき範囲と、将来対応に回すべき範囲はどこか？

---

Closing / 結び

AIKernel.NET does not merely call AI models.
It constructs, governs, and executes context.

AIKernel.NET は単に AI モデルを呼び出すものではありません。
文脈を構築し、統治し、実行するための基盤です。

It constructs, governs, and executes context.
文脈を構築し、統治し、実行する。

AIKernel is expected to evolve not only as a consumer of ROM,
but also as a system capable of producing and publishing ROM as knowledge.

AIKernel は ROM を消費するだけでなく、
知識として生成・公開する能力を持つ実行基盤へと進化することが想定される。

---

Implementation Note / 実装に関する補足

This architecture describes the intended direction for AIKernel.NET v0.1.0.

Implementation will proceed incrementally, and not all components described in this document will be fully realized at once.

This document serves as the reference model for future development, guiding AIKernel.NET toward a consistent, reproducible, governable, and verifiable architecture.

本アーキテクチャは、AIKernel.NET v0.1.0 における将来像を示すものです。

実装は段階的に進められ、本ドキュメントに記載されたすべての要素が一度に実現されるわけではありません。

本ドキュメントは、今後の開発における参照モデルとして機能し、AIKernel.NET を一貫性・再現性・統治性・検証可能性を備えたアーキテクチャへ導くものです。