2. コアモデル

基本構造

Worldspaceは、LLMが探索できるObjectのTreeとして公開される。

WIPではObjectとエントリを別の構造として定義しない。ObjectをWorldspaceのTree上の位置として扱うとき、そのObjectをエントリと呼ぶ。

したがって、ObjectはTree上で親子関係を持ち得るし、途中のNodeもそのまま操作対象になってよい。例えばarticlesはCollection Objectとして、そのInterfaceにquery等を宣言し、配下に個別Articleを配置できる。

ObjectはWIP上で観測・操作される対象そのものである。

エントリは、そのObjectをTree上の位置として見たときの呼び名である。

エントリがObjectへの参照を別途持つ、という二重構造は前提としない。

Tree上の位置はpathで表される。Pathは恒久的なIdentityではなく、その時点でのnavigation coordinateである。

同じObjectが複数の位置に現れる場合、一つのObjectが複数のエントリとして観測され得る。

ObjectはOperation定義を直接持たず、一つのInterfaceを参照する。

Interfaceの実体は一つのWIP IDL documentであり、document内に宣言された関数の集合が、そのInterfaceのOperation集合となる。複数のObjectが同じInterfaceを共有できる。

ObjectとInterfaceを分離することで、Collection内の多数の同種Objectに同じOperation定義を重複して持たせず、ClientがInterface定義を参照単位でcacheできる。

Objectは必要に応じてrefを公開できる。

refは内部IDそのものではなく、WIP上で同一Objectとして再参照するための外部Handleである。

エントリ自体をObjectとは別実体として扱う必要はない。ただし、あるpath上のObjectを観測した後、Operationを実行するまでの間に、そのpathが別のObjectを指すことはあり得る。

その場合、Client / Runtimeは、以前のObjectを対象としたOperationを新しいObjectへ黙って適用してはならない。実行前に観測時の対応関係を検証し、変化していればOperationを中止する。この性質をobservation consistencyと呼ぶ。

例えば、AIが/issues/currentを観測した時点ではIssue Aだったが、invoke時にはIssue Bへ差し替わっていた場合、AIはIssue Aへ作用するつもりでIssue Bを操作してしまう可能性がある。

この観測整合性は利用者に追跡させるのではなく、クライアントの責務とする。

処理の流れは次の通り。

実装はETagやgeneration、opaque token等の内部メタデータを用いてよいが、それらを利用者へ露出する必要はない。

対応関係が変化していた場合、Clientは新しいObjectに対して操作を自動的に再試行してはならない。操作を中止し、target_changedのような意味的エラーを返して再観測を要求する。

WIPでは次の2つを分けて扱う。

Object identity (ref): 複数の観測にまたがって同一Objectであることを明示するための任意の外部Handle。
Observation consistency: refの有無に関わらず、観測したpath上のObjectと操作対象のObjectが一致していることをClient / Runtimeが保証する仕組み。

したがって、refを持たないObjectであっても安全な操作対象になり得る。refは同一性を公開する仕組みであり、Observation consistencyは操作の安全性を担保する仕組みである。