Skip to content

AIKernel.NET v0.0.2 — Interface Rectification & Contract Stabilization Release

Latest
Latest

Choose a tag to compare

View all tags
@egumaru egumaru released this 09 May 08:42
v0.0.2
9ba2005
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

AIKernel.NET v0.0.2

— Interface Rectification & Contract Stabilization Release

May 9th — The day the Kernel received its proper names, boundaries, and Phase 1 slots.
5月9日 — Kernel に正しい名前・境界・Phase 1 の抽象スロットを与えた日。

Rectify the Interfaces. Stabilize the Contracts.
名前を正し、境界を分け、契約を安定させる。

Overview / 概要

This release is not a feature release.

It is a structural refinement release for stabilizing the AIKernel.NET abstract contract layer before v0.1.0.

このリリースは、機能追加リリースではありません。

v0.1.0 に向けて、AIKernel.NET の抽象契約レイヤーを安定化させるための構造的リファクタリングリリースです。

This release includes the work from Issue #4 and Issue #7 through Issue #12, covering VFS capability-based interface segregation, naming normalization, contract purity, provider capability separation, security / policy boundary separation, and Phase 1 Query Processing abstractions.

本リリースでは、Issue #4 および Issue #7 から Issue #12 までの対応を含みます。
VFS の capability-based interface segregation、命名規約の正規化、Contract Purity、Provider Capability 分離、Security / Policy 境界の整理、そして Phase 1 Query Processing 抽象の追加を行いました。

Key Changes / 主な変更点

1. VFS Capability-Based Interface Segregation / VFS の Capability-Based Interface 分離

The VFS abstraction was refined to better express capability-based governance at the type-system level.

VFS 抽象を、型システム上で capability-based governance を表現できるように見直しました。

Instead of forcing every VFS implementation to support read, write, and navigation operations through a single broad contract, VFS responsibilities were separated into smaller capability-oriented interfaces.

すべての VFS 実装に read / write / navigation を単一の巨大な Contract として強制するのではなく、責務を capability 単位の小さな Interface へ分離しました。

This enables implementations such as read-only web providers, writable local providers, and in-memory providers to expose only the capabilities they actually support.

これにより、read-only な Web Provider、書き込み可能な Local Provider、揮発性の Memory Provider などが、実際に対応する capability のみを公開できるようになります。

2. Naming Normalization / 命名規約の正規化

Acronym-based identifiers were normalized according to .NET naming conventions.

.NET の命名規約に従い、頭字語を含む識別子を正規化しました。

Changes include:

  • AIKernel.VFS → AIKernel.Vfs

  • AIKernel.VFS.csproj → AIKernel.Vfs.csproj

  • namespace updates from AIKernel.VFS to AIKernel.Vfs

  • IROMCanonicalizer → IRomCanonicalizer

これにより、コードベース全体の命名が .NET の慣習に沿った自然な形へ整理されました。

3. Contract Purity / 契約純度の向上

Contract objects were reviewed to avoid mixing immutable contract definitions with mutation or transformation behavior.

不変であるべき Contract に mutation や transformation の責務が混入しないよう、契約の純度を見直しました。

Material-related contracts were moved toward immutable views, while normalization, structuring, and processing responsibilities are expected to live in dedicated service interfaces.

Material 系の Contract は immutable view に寄せ、正規化・構造化などの処理責務は専用 service interface 側へ分離する方針に整理しました。

4. Capability-Driven Provider Interfaces / Capability 単位の Provider 分離

Provider interfaces were refined to avoid forcing implementations to support capabilities they do not actually provide.

Provider が実際には対応していない capability の実装を強制されないよう、Interface を capability 単位へ分離しました。

This includes the embedding provider split:

  • ITextEmbeddingProvider

  • IBatchEmbeddingProvider

  • IEmbeddingDimensionProvider

これにより、single embedding / batch embedding / dimension metadata を必要に応じて個別に実装できるようになりました。

5. Provider Capability Metadata / Provider Capability Metadata の拡張

Provider capability metadata was extended to support richer Phase 1 and Provider-routing scenarios.

Phase 1 および Provider Routing のために、Provider capability metadata を拡張しました。

Added or refined concepts include:

  • query-processing capability metadata

  • embedding capability metadata

  • semantic projection capability

  • provider routing metadata

これにより、Provider をモデル名ではなく capability に基づいて選択する設計がさらに明確になりました。

6. Security & Policy Boundary Refinement / Security と Policy 境界の整理

Security, policy decision, rule evaluation, and enforcement boundaries were reviewed to avoid overly broad contracts.

Security、Policy Decision、Rule Evaluation、Enforcement の責務が単一の巨大な Contract に混在しないよう、境界を見直しました。

This prepares the ABI for future Governance Plane implementation without forcing premature runtime behavior.

これにより、将来の Governance Plane 実装に向けて、実行時の実装を急がずに ABI 境界を整える準備ができました。

7. Phase 1 Query Processing Abstractions / Phase 1 Query Processing 抽象の追加

New abstractions were added for Phase 1 Context Build.

Phase 1 Context Build のために、Query Processing 系の抽象を追加しました。

Added interfaces and DTOs:

  • IQueryAugmentor

  • IQueryDecomposer

  • IQueryRouter

  • QueryPart

  • IQueryProcessingCapabilities

  • IEmbeddingCapabilityMetadata

These abstractions do not embed RAG directly into Core.

これらの抽象は、RAG を Core に直接組み込むものではありません。

Instead, they define extension slots where RAG and other query-processing strategies can be selected and composed through the pipeline.

RAG を含む Query Processing 技術を Pipeline 上で選択・合成するための抽象スロットを定義するものです。

Documentation Updates / ドキュメント更新

The following documentation areas were updated:

以下のドキュメントを更新しました。

  • README / README-jp

  • Architecture docs

  • Pipeline specs

  • Provider docs

  • Capability definition schema

  • Query Processing interface docs

  • Migration guides

  • Use-case docs

  • Dependency rule documents

Key documentation additions include:

  • VFS capability-based interface segregation

  • Phase 1 Query Processing architecture

  • Provider capability examples

  • Query Processing pipeline flow

  • Embedding capability metadata

  • clarification that RAG remains a provider / pipeline strategy, not Core retrieval

主な追加内容:

  • VFS の capability-based interface segregation

  • Phase 1 Query Processing アーキテクチャ

  • Provider capability 例

  • Query Processing pipeline flow

  • Embedding capability metadata

  • RAG は Core retrieval ではなく Provider / Pipeline strategy であることの明記

Verification / 検証

The solution builds successfully.

ソリューションのビルドが成功することを確認しました。

dotnet build src\AIKernel.NET.slnx

Succeeded.

The abstraction tests also pass successfully.

抽象レイヤーのテストも正常に通過しています。

dotnet test src\tests\AIKernel.Abstractions.Tests\AIKernel.Abstractions.Tests.csproj --no-build

Succeeded: 73 tests passed.

Notes / 補足

Some identifiers were intentionally left unchanged.

一部の識別子は、意図的に変更対象外としています。

  • IOException was left unchanged because it is a .NET BCL type name.

  • DTO, API, and ROM were left unchanged where used as descriptive prose.

  • ProviderId was already using the correct spelling and was left unchanged.

  • IEmbeddingProvider was not recreated because embedding contracts were already split into capability-specific interfaces.

  • IOException は .NET BCL 型名のため変更対象外です。

  • DTO, API, ROM は説明文中の一般語として使われている箇所では変更対象外です。

  • ProviderId はすでに正しい表記だったため維持しました。

  • IEmbeddingProvider は、すでに capability 単位の Interface へ分離済みだったため、重複作成していません。

Why This Matters / このリリースの意味

This release is small in runtime behavior, but large in architectural meaning.

このリリースは、実行時の振る舞いとしては小さいものです。
しかし、アーキテクチャ上の意味は大きいものです。

Before v0.1.0 turns the contracts into executable runtime components, the abstract layer must have correct names, clean boundaries, capability-driven providers, VFS capability separation, and Phase 1 extension slots.

v0.1.0 で Contract を実行可能なランタイムコンポーネントへ進化させる前に、抽象レイヤーには正しい名前、明確な境界、capability-driven な Provider、VFS の capability 分離、そして Phase 1 の拡張スロットが必要です。

This release prepares that foundation.

本リリースは、そのための基盤を整えるものです。

Closing / 結び

Names define boundaries.
Boundaries define contracts.
Contracts define execution.

名前は境界を定義する。
境界は契約を定義する。
契約は実行を定義する。

Rectify the Interfaces. Stabilize the Contracts.
名前を正し、境界を分け、契約を安定させる。

Assets 2
Loading