Company — Concept・Entity・OKR

aachatのteamは、個々の仕事（project）の外側に、会社そのものの共有された文脈を持つ。3つの層がある。Conceptの内部モデル（kind・意味軸・revision・レビュー・リンク・類似ガード）は concept-registry.md、OKRの内部モデル（構造・ライフサイクル・チェックイン契約）は okr.md が正本。Entityの内部モデルはこのページが正本。

層	内容	WebUIの場所	詳細
Concept	チームが合意した判断基準（purpose・戦略・原則・決定・発見など）。全agentと人間が判断の前提として読む	teamサイドバー「Concepts」	`concept-registry.md`
Entity	会社の実体の地図（Company map）。プロダクト・チャネル・資産などの構成要素と、ConceptやOKRとのつながり	teamサイドバー「Entity」	このページ下記
OKR	目標とKey Result。チェックインで実値と確信度を更新する	teamサイドバー「OKRs」	`okr.md`

どこで依頼するか

専用の場所は要らない。どのprojectのsessionでも、通常の依頼と同じようにagentに頼めばよい（例:「この事業のコンセプトを整理して提案して」「今期のOKRを設計して」）。session中のagentは、teamのConcept・Entity・OKRを読み書きするツールをsession内に持っている。

読む: agentはpublish済みのConceptや現在のOKR・Entityを読み、判断の前提として使える
Conceptの提案: agentは新しいConceptや既存Conceptの改訂・リンクを**提案（propose）**として登録する。提案はpendingとして残り、人間がWebUIのConcepts画面でレビューして採否を決める。承認されて初めてチームの判断基準になる（詳細は concept-registry.md）
Entity・OKR: agentはEntity（通常kindのみ、下記参照）の登録・更新、OKRの登録・更新・チェックイン・Conceptへのリンクをsessionから直接行える。提案とレビューを経ずその場で反映される点がConceptと異なる

使い分け

長く効く判断基準・方針・発見を残したい → Concept提案
会社に何があるか・何を作るかを地図にしたい → Entity
目標を立てて計測で追いたい → OKR（実値の更新はチェックイン）

会社の文脈はagentの仕事の入力であり出力でもある。projectで働いたagentが発見をConcept提案として返し、人間が承認すると、次のすべてのsessionがその判断基準の上で働く。これが会社そのものが資産として育つ流れである（concepts.md のcompany assetsの流れの会社版）。

Entityモデル — kind・sensitive境界・階層

Entityは会社の実体の地図（Company map）を構成する。Entityにはproperty・評価・目標・KPI・担当者・進捗を保存しない。それらはConcept（判断基準）・Project/Session（実行中の仕事）・Message/Shared Document（根拠や詳細）が持つ。

kind — 9種

kind	備考
`organization`	通常
`offering`	通常。プロダクト・サービス
`media`	通常。チャネル・媒体
`community`	通常
`system`	通常。社内外のシステム
`facility`	通常
`person`	sensitive
`partner`	sensitive
`agreement`	sensitive

sensitive kindの境界（重要）

person / partner / agreement の3種はagentから登録・変更できない。agentがこれらの登録・改名・status変更・move・Conceptリンクを試みると、サーバーは次のメッセージで拒否する。

person / partner / agreement Entity の変更は human の操作が必要です。Project の human member に依頼するか aachat_ask を使ってください。

agentはsensitive kindを読むことはできる（Company mapの一部として名前・構造を見る）。書き込みができるのはteamのOwner / Adminの人間だけで、一般メンバーの人間も拒否される。読んだ情報からEntityの意味や評価を推測しない — 保存されているのはname・kind・status・parentだけである。

status — 会社構成上の位置

planned / current / retired は会社構成上の位置だけを表し、仕事の進捗（未着手/進行中/完了）ではない。

planned: 会社構成として計画中
current: 現在の会社構成に存在する
retired: 会社構成として終了した

階層制約: activeなEntity（planned / current）をretiredな親の下に置けない。Entityをretiredにする前に、activeな子を移動するかretireする必要がある。

階層（parent/child）

Entityは木構造を持つ。parentは同じteam内のEntity1つだけ、自己参照・循環・team跨ぎのparentは作れない。付け替えはmove操作で行う。複数の構造上の関わりをparentで表現しない（依存・提供・担当などの未定義の関係をhierarchyやnameに埋め込まない）。

Concept link

EntityはpublishedなConceptに対してrealizes（実現する）でリンクできる。v1のrelationはこの1種のみ。archivedや未publishのConceptへはリンクしない。

変更履歴

Entityの変更は追記専用のイベントとして残る: registered（登録） / renamed（改名） / status_changed（状態変更） / moved（親の変更） / concept_link_added（Conceptリンク追加） / concept_link_removed（Conceptリンク削除）。