OKR — 構造とライフサイクル

company.md で示した3層のうち、OKRの内部モデルをこのページで扱う。OKR RegistryはteamがKPIとして持つべき outcome の正本である。Objectiveは目指す変化、Key Resultは測定契約、チェックインはその時点の値と確信度の記録である。Project / Sessionはoutcomeを実現するための仕事、ConceptはOKRの意味を導く判断基準、Company EntityはOKRとは別の会社構成の実体であり、OKRの代わりにはならない。

構造

Objective: title + description
Key Result: 2〜5個必須。それぞれ title・description・metric（測定する対象）・unit（単位）・baseline_value（開始時点の値）・target_value（目標値）を持つ。baselineとtargetは同じ値にできない
期間: starts_on < ends_on
数値（baseline_value / target_value / チェックインのcurrent_value）はロスレスな文字列decimalで送受信され、percentや達成率をdocsやagentが自動計算しない

ライフサイクル

draft → active → closed / cancelled の一方向。

status	意味・制約
`draft`	Objective・期間・KRを登録・変更できる
`active`	activate後はKRの定義が凍結される。活性化にはowner設定と初回チェックインが必要
`closed`	最終チェックインとretrospective（振り返り）を1つの操作で保存して終了
`cancelled`	理由（reason）付きで終了

終端状態（closed / cancelled）は不変・削除不可。測定契約自体が誤っていた場合は既存OKRをキャンセルし、正しいKRを持つ新しいOKRを登録し直す。

チェックインの契約

チェックインはその回に全KRの実値を揃えて出す。変化していないKRも省略しない。

current_value: その時点で確認した実測値（decimal文字列）。外部計測値を取得できない時に推測値を作らない
confidence: KRごとに0〜10の整数。OKR全体のスコアには集約しない
summary はそのチェックインの要点。confidenceが下がった理由・blocker・不確実性・次に検証すべきことはdescriptionに書く
チェックインは追記専用の記録であり、activate時の初回チェックイン・通常のチェックイン・close時の最終チェックインはすべて同じ完全snapshot契約を使う
楽観的並行性制御を持つ。直前に読んだ updated_at を渡し、他の変更と競合したら最新状態を読み直してから再送する

ownerモデル

OKRのownerは最大1名。draftはownerなしで登録でき、ownerが必須になるのはactivateの時である。ownerは人間だけでなく、teamのactiveなProject/DMに参加しているdormantでないagentもなれる。候補はowner_candidatesから選ぶ。

Concept / Entityへのリンク

OKRはConceptとEntityの両方にリンクできる。関係型は特に持たない（存在するかどうかだけの単純なリンク）。

Conceptへのリンク: その判断基準・戦略がOKRの意味を理解するために必要な時に使う
Entityへのリンク: outcomeが対象にする会社構成を示す時に使う
終端後（closed / cancelled）はリンクを変更できない

変更履歴

OKRのlifecycleと定義変更は追記専用のイベントとして残る（登録・定義更新・activate・owner変更・Concept/Entityリンクの追加削除・チェックイン作成・close・cancel）。

構造

ライフサイクル

チェックインの契約

ownerモデル

Concept / Entityへのリンク

変更履歴

関連ページ