Concept Registry — 判断基準の型とライフサイクル

company.md で示した3層のうち、Conceptの内部モデルをこのページで扱う。Conceptはteamが合意した判断基準の登録簿（Registry）であり、agentは提案（propose）と閲覧（read）ができ、公開（publish）は人間だけが行う。ユーザーやagentから「Conceptのkindは何がある」「提案したら弾かれた」「レビューって何」と聞かれたら、このページの事実で答える。

kind — 14種

Conceptには14種のkindがある。kindは分類であり、後述の意味軸（guidance_strength等）はkindから自動では決まらない。

kind	用途の例
`purpose`	存在意義・目的
`value_proposition`	提供価値の定義
`principle`	判断の原則
`strategy`	戦略
`goal`	目指す状態
`metric`	測定指標の定義
`policy`	方針・ルール
`problem`	課題
`question`	未解決の問い
`hypothesis`	仮説
`solution`	解決策
`decision`	決定事項
`idea`	アイデア
`finding`	発見・観測事実

意味軸 — 6種

Conceptにはkindとは独立に6つの意味軸がある。aachat_concept_propose は scope（domain・tags）・abstraction_level・time_horizon・guidance_strength・maturity を必須で指定する。policy = governing のようなkindとの自動対応はなく、review件数からの推測もしない。

軸	値	意味
guidance_strength（判断への影響度）	`contextual` / `guiding` / `governing`	`governing` は標準前提として使われ、逸脱するなら理由が要る。`guiding` は原則として沿うが、より強い根拠があれば理由付きで変えられる。`contextual` は関連がある時だけ判断材料にする
maturity（確定度）	`exploratory` / `provisional` / `established`	`established` は再検討せず前提にできる。`provisional` は影響の大きい判断では出典や最新レビューを確認する。`exploratory` はpublished contextに含めてよいが、確定事実として言い換えない
abstraction_level（影響範囲）	`foundational` / `directional` / `structural` / `tactical` / `operational`	kindからは推測せず、その判断がどの範囲に影響するかで選ぶ
time_horizon（時間軸）	`today` / `one_week` / `one_month` / `three_months` / `one_year` / `three_years` / `ten_years` / `enduring`	`enduring` 以外は `expires_at`（期限）が必須。期限切れ後はcurrent published contextに含まれない
domain（適用領域）	`company` / `organization` / `product` / `marketing` / `sales`	そのConceptが適用される大枠を1つ選ぶ。product・顧客層・施策などteam内の分類は`scope.tags`（最大20件）に付ける
applicability（有効性）	`active` / `expired`	`expires_at` 由来の派生状態

governing + established は標準前提。governing + provisional は必ず考慮した上でsourceや最新レビューを確認する。governing + exploratory は必ず表面化させるが盲従しない。governing同士が矛盾する場合や未解決のconcernがある場合はスコアで勝者を決めず、リンク・出典・レビューを読んで衝突を明示する。

revisionモデル

Conceptは不変のrevisionの積み重ねである。current revisionを直接書き換えることはなく、変更は常に新しいrevisionの提案として残る。

revisionの status は pending / published / declined の3つ
1つのConceptにつきpending revisionは常に1件まで。既存のpendingがある間は新しいproposalを出せない
publish / declineは人間（teamのOwner/Admin）だけが行える。agentは提案までしかできない
declineには理由が必須。次のsessionはその理由を読み、基準を較正してから再提案するかを判断する
revision作成後の内容は不変。表現・出典・scope・時間軸を変える場合も新しいrevisionを積む

title は80文字、description は300文字までの入口であり、詳細な根拠は出典（下記）を通じて読む。要約ではなく入口として書く。

レビュー

published / pendingどちらのrevisionにも endorse（賛同）・concern（懸念）の2種のレビューを付けられる。concern はコメント必須（endorse は任意）で、解決ノート付きでresolveできる。published revisionにopenな concern があっても前提として読んでよいが、そのConceptに強く依存する判断では aachat_concept_reviews でcurrent revisionのコメントを確認し、concernの存在を明示する。読み取りは aachat_concept_reviews、aachat_concepts は件数（open_concern_count / endorse_count）だけを返す。

Concept間のリンク

Concept同士は8種の有向関係でつながる。

relation	意味
`realizes`	実現する
`constrains`	制約する
`addresses`	対処する
`measures`	測定する
`supports`	支持する
`contradicts`	矛盾する
`refines`	精緻化する
`depends_on`	依存する

リンクにも candidate / accepted / retired / rejected のライフサイクルがある。agentは aachat_concept_link_propose で candidate として提案でき、acceptして初めてConcept Mapや判断で有効な関係として扱われる。accept / reject / retireは人間（teamのOwner/Admin）だけが行える。

提案時の類似ガード（similarity gate）

aachat_concept_propose は登録前に既存Conceptと自動で照合される。類似があると登録されず、similar_found として返る。

published の類似 — 既に判断基準として存在する。取り下げるか、関係があればリンク提案やレビューに切り替える。矛盾するなら finding + contradicts リンクを検討する
declined の類似 — 過去に人間が却下している。却下理由（status_reason）を読み、同じ提案を繰り返さない
pending の類似 — 誰かのrevision proposalがレビュー待ち。重複提案しない
権限のない pending / declined の一致は内容やIDを返さず、hidden_match_count だけを返す
本当に別物だと判断した場合だけ、返ってきた proceed_token を付けて再送すると登録できる

出典（source）

提案は出典付きで出す。種類は6つ。

kind	指す先
`project_message`	projectのメッセージ
`shared_document`	Shared Document
`session`	session
`repository`	repositoryの特定ファイル・行
`external`	外部URL
`human_decision`	人間の決定（ノート）

最低1件は提案元のprojectに属する出典を指定する。出典の可用性は accessible / restricted / unavailable の3段階で示され、restricted なsourceの中身を推測しない。unavailable は削除済みの根拠として扱う。

アーカイブ / 復元

Conceptはアーカイブ・復元できる。この操作はWebUI/人間の操作であり、agent向けMCP toolには含まれない。archivedなConceptやpublished contentを持たないConceptへ新しくリンクしない。

Concept Mapでの自由配置

WebUIのConcepts画面はマップビューを持ち、カードの位置（free_position）を人間またはagentが aachat_concept_position_set で動かせる。配置は共有のsoft contextであり、近いConcept同士の位置は関連を検討する手掛かりにはなるが、source・typed link・意味軸と矛盾する場合はそちらを優先する。配置だけに現れる関係を事実として断定せず、重要そうならリンク提案の候補として扱う。