Atom と関係

Atom は、本文と参照を持つ一つの情報です。メモだけでなく、複数のメモについての説明や、メモ同士の関係も同じ形で保存します。

招待手順なら、次の三つを別々に扱えます。

Atom	本文の例	参照
ルール	招待リンクの有効期限は24時間です。	なし
手順の説明	招待と参加の手順	なし
関係	この手順には有効期限のルールが含まれる。	手順 → 説明、ルール → メモ

ルールを別の手順でも使いたい場合は、もう一つ関係を追加します。本文のコピーや、親となる説明のメンバー一覧の書き換えは必要ありません。

関係には役割と本文がある

次の例では、一つの関係に依頼者・承認者・対象という三つの役割を持たせています。同じ役割に複数の対象も指定できます。

await memory.write({
  text: '参加申請は、担当者の承認を受けて受け付ける。',
  links: {
    依頼者: applicant.ref,
    承認者: [primaryReviewer.ref, backupReviewer.ref],
    対象: application.ref,
  },
});

役割を入れ替えると違う関係になります。役割名の繰り返しや全体の順序を明示したいときは、links: [{ role: '承認者', target: ref }, ...] の配列形式を使えます。

検索は関係の本文からも候補を見つけます。inspect や read は接続を両方向にたどり、結果にも本文と役割を残します。depth、件数、訪問済みの管理により、相互参照があっても有限で停止します。

主張と条件を一緒に渡す

「外部参加者を招待できる」と「管理者の承認が必要」を別の Atom にするなら、条件を required: true の参照として結び付けます。

const condition = await memory.write('外部参加者の招待には管理者の承認が必要です。');
await memory.write({
  text: '外部参加者を招待できます。',
  links: { 条件: { ref: condition.ref, required: true } },
});

read は主張と条件の本文を一緒にパックします。両方を予算内で渡せなければ、主張を省きます。通常の関係は周辺を探す手掛かりになり、required はその本文を読むために欠かせない依存を指定します。

参照は観測した版も覚えている

保存や検索で受け取る ref には、論理的な対象と、そのとき見た版が対応付いています。使う操作によって、どちらを使うかが決まります。

操作	読む・変更する対象
inspect(ref)	そのとき観測した版
inspect(ref, { version: 'latest' })	同じ対象の最新版
draft.revise(ref, content)	観測版を前提に同じ対象を改訂
links: { role: ref }	同じ対象へ接続し、読取時の状態で版を解決
links: { role: { ref, at: 'observed' } }	接続先を観測版に固定

例えば有効期限を改訂しても、手順からルールへの通常リンクは接続し続けます。一方、以前の回答の根拠を調べる inspect は、その回答で参照した版を返します。

整理を更新して、当時の構成も残す

別の視点でまとめた説明は、そのまま並べて保存できます。現在の手順を新しい手順に置き換えたいときは、編集操作 supersede で後継を採用します。

await memory.edit(async (draft) => {
  const next = await draft.write('改定後の招待と参加の手順');
  await draft.write({
    text: '改定後の手順に有効期限のルールを結び付ける。',
    links: { 手順: next.ref, ルール: rule.ref },
  });
  await draft.supersede(topic.ref, next.ref, {
    composition: { relations: [{ parent: '手順', children: ['ルール'] }] },
  });
});

const past = await memory.inspect(topic.ref, { history: 'retained', limit: 20 });

composition は、この整理で「手順」から「ルール」へたどることをホストが指定する計画です。共有されたルールから別の手順へ逆に広がりません。子にも同じ構成を展開する場合は、その規則に recursive: true を付けます。明示した再帰は固定の深さで切らず、訪問済み管理とページ・実行予算で止めます。

通常の検索・readでは採用した後継を優先します。history: 'retained' は置き換える前の読取状態で、この計画を実行します。その後ルールが変わっても、当時の構成を再現できます。

履歴は既定30日です。MemoryStorage・SqliteStorage は版を保持した snapshot を記録し、保存時に子を全列挙しません。保持機能のないadapterでは、同じ計画の結果を既定256 Atomまでの manifest に保存します。保持に失敗すれば編集全体が HISTORY_INCOMPLETE になります。後継の採用は一対一で、競合と循環を拒否します。削除・権限失効は保持期間内でも優先します。

出典と生成された説明

原資料の入力と、エージェントが作った説明は出自を区別します。ホストが書き手の種類を設定し、sources と入力の読取記録から、どの資料を使ったかを追跡します。

生成された説明が参照する資料や関係が変わると、read は依存を検証します。使えなくなった説明は原資料で補い、diagnostics.derived に pending を返します。ホストが生成器を設定した場合は、予算内で一時的な表現を再生成できます。

出典は「誰のどの入力から来たか」を示します。回答に使うときは、発言や仮説の内容も含めて判断できます。具体的な編集方法は API、モデルの読取と書込の流れは Writerを参照してください。