Kairos 言語仕様 — 付録 A. 発報層プロファイル（適合実装の契約）

本書は仕様ツリーに置く付録で、規範（§1〜7）の一部ではない。「Kairos 適合の発報層はこれを満たす」を文書だけで定める契約である。言語は定義と評価だけを持ち（§1.4）、実行と状態は発報層の責務（§7.8）。本書はその境目を、参照実装を実運用に載せた供給側の実行系からの還流便（2026-07〜10）の知見で具体化する。英訳は en/spec/60。

A.0 この文書は何か

言語は点列を返す。発報層は点列を実行し、状態を持つ。本書はこの境目をどちら側にも越えさせない。適合の段は 3 つ。

MUST＝満たさなければ適合と名乗らない。
SHOULD＝推奨。外すなら理由を記す。
MAY＝任意。

本書の立場。

言語が発報層に求めるのは観測面の読み出しだけ——点列・区間註釈・被覆サマリ・警告・版・指紋。
発報層の機構（タイマー・水位標・冪等・再評価）のための語彙は言語に無い。還流を動機に足した語（空テーブル・external・at＝ADR-45・46・51）は定義側の表現であり、機構を言語へ持ち込んでいない。
発報層の形は問わない。既存の起動装置（cron・systemd・タスクスケジューラ）へ点を流し込む変換器でも、自前のタイマーでも、評価器を自前に持つ実装でも、条件を満たせば適合。
原則は「置き換えない・具現化する」。起動装置は枯れており、壊れるのは規則の表現の段（常駐デーモンで cron を置き換える形は推奨しない）。
本書が守るのは品質の下限。誰が作っても同じ条件で動き、同じ信号が出る。

読む順は §1.4 スコープ → §7.7〜7.8 分業の一般形 → §4.10 評価註釈と被覆サマリ → 本書。

器の正本: schema/cli-report.schema.json・schema/supply.schema.json。
CLI の各節: impl/README.md（--json・--supply・--explain）。
判断の根拠: ADR-37・ADR-45・ ADR-46・ADR-51・ ADR-53。

A.1 評価の契約

言語との境界は CliReport の形。評価器を CLI で呼んでも自前に持ってもよいが、受け渡す器はこの形に揃える。

器

MUST: 評価結果は CliReport（list／next の --json）の形で受ける。必須は command・version、成功時はさらに tz・from・to・results[]・coverage[]・warnings[]（results[] の各項は source・line・uid・dates・points・annotations）。
MUST: 点の同一性は points（epoch ms）で、交差計算も epoch ms のまま行う。dates はその市民ラベル（tz で読む・points と一対一）で、表示と同定（A.3）に使う。
MUST: エラーも JSON で受ける（error.kind は usage・supply・static の 3 種）。発報層はこの種別で起動時の扱いを分ける（A.4）。
註: スキーマは後方互換の追加だけで改訂される（言語側の約束）。
SHOULD: additionalProperties: false の厳格な検証器を使うなら、追加のたびに手元のスキーマを更新する。
SHOULD: 運用の拡張（照合の結果など）は CliReport と同形＋拡張で載せ、既存の項目の意味を変えない。
MAY: --explain（results[].stages）を実体化の記録に添える。

tz と評価範囲

MUST: 暦計算の tz は定義側（premise の tz:）で明示し、実行環境の既定 tz に依存しない。実行環境の TZ が未設定でも点列が変わらないこと。
MUST: 評価範囲 [from, to) は日付単位で、to は含まない。
註: 連続する窓を隙間なく敷き詰めるなら、次の from＝前の to にする（to が排他だから）。重ねて再評価する形（A.2）では、重なり区間の一致が検査になる。
MUST: 時刻起点の切り出しは評価範囲では行わず、式（epochOrdinal の序数比較）か発報層（points を now で切る）で行う（評価範囲は「どこを見るか」であって「どこから数えるか」ではない＝§7.8）。

版

MUST: version を記録する。自前の評価器を持つ実装は、追随する参照実装の版（公開の版番号か sha）を宣言する。
MUST: 版を上げるときは、同じ定義・同じ供給・同じ窓で点列を前後比較し、差を数えてから本番へ反映する。
SHOULD: 言語不変の追補（出力形式の追加など）は自前の評価器に影響しない。CHANGELOG の「言語は不変」を読んで追随の要否を決める。

同一性の鍵（1.0.9）

註: results[].uid は式の指紋。results 内の順番・式の字面・報告の tz から FNV-1a 64 で計算し、.ics の繰り返し予定の UID と同じ値。
MUST: uid を永続 ID として使わない（式の字面・順番・tz のどれかを変えれば別の値になる）。発報層は自前の記録 id を正とし、uid は「同じ定義か」の判定に使う。
MAY: uid を .ics を経由しない予定の更新鍵に使う。冪等キー（A.3）の成分にするなら自前の記録 id に添える形に留める（uid だけを正にすると式の並び替えで鍵が分岐し、配信済みの事象が再送されうる）。

自前の評価器を持つ場合

MUST: 判定の同一性。同じ入力に対し参照実装と同じ可否（受理・拒否）と同じ点列を返し、独自の受理条件やガードを足さない。
MUST: 診断の文言も仕様の一部として写す（誘導の末尾 1 文まで）。witness の文言照合はこの文言を対象にする。
MUST: 意味論の照合は reference/ の doctest（# eval:・#=>・#~>）の期待値一致で行う（#~> の行が無い例は「註釈ゼロ・警告ゼロ」の主張）。
SHOULD: 受理境界を上流と割らない。上流の欠陥を見つけても先行して直さず、失敗期待の witness を置いて報告し、公開版で追随する（やむを得ず差を作るときはコード・テスト・台帳に明記し、上流の是正で解消する）。
SHOULD: 写経の同一性は出力で検査する（定義テキストが同じでも評価器の差で出力は変わりうる）。版更新時は同一の入力で全点比較し、不一致 0・warnings 0 を確かめる。
SHOULD: 自前のキャッシュを持つなら、言語側の文脈キー（在圏 premise 名＋前文メンバー 8 成分＝ADR-53 判断 4）に評価範囲を足した鍵で引き、鍵の違う参照へ値を使い回さない。評価範囲は本書が発報層のキャッシュに足す成分で、言語側の鍵には入っていない（常駐の評価器では解決値の asof も足す＝ADR-46）。

A.2 再評価（rolling horizon）

近未来の有界窓を評価し、定期的に再評価して差し替える。言語の決定性がこの運用を支える。

有界窓と決定性

MUST: 前向きの実体化は有界窓 [today, today+H) で行い、定期（日次かデータ更新時）に同じ定義を再評価して差し替える。H は数十日の目安（例: 45 日）で、秒・分級の格子は全実体化しない。
MUST（決定性）: 同じ定義・同じ評価範囲・同じ供給（同じ asof）からは同じ点列が出る。窓をずらした再評価で重なる区間の点列が一致することを検査で担保する（§7.8）。
註: 位相を持つ語（stride・strideBy・take）の from: は言語側で常に必須（用語集・reference/strideBy）。位相が評価窓に依存しないので、窓をずらした差し替えが安全になる。
SHOULD: 再実体化で発火予定が変わらなければ無音で差し替え、変わったら情報として記録する。
SHOULD: next の確定再評価。消化した点の後の再実体化は次の点へ前進し、同じ入力なら何度走っても同じ next を返す（1 回の評価で供給を何回解決するかは契約の外）。
SHOULD: 評価器を自前に持つ場合、実体化の起点を評価窓へ寄せる最適化は適合。条件は、市民幅の格子の境界を窓起点から tz 射影で求めること、後ろ向きの語（Preceding・first など）が窓以前の目盛りを要求したら需要に応じて遡ること。

水位標と missed-fire

MUST（水位標）: 「前回どこまで発火したか」を持ち、起動時と再起動時に水位標から now までの未発火点（missed-fire）を列挙する。実装形は前回実行位置でも lookback 窓（例: 24 時間）でもよい。
註: 列挙は前向きの窓とは別の評価範囲で行う。§7.8 の停止期間 [down, up) を CLI では日付窓（水位標の日から今日の翌日まで）にして渡し、返った points を水位標と now で切る（評価範囲は日付単位＝A.1）。
MUST: 停止中の発火を黙って消さない。列挙した未発火点は方針に従って実行するか記録する（実行は at-least-once＝A.3）。

タイマーと起床

SHOULD: タイマーの上限（JavaScript の setTimeout は約 24.8 日）が H より短いときは、起床周期（CAP）のタイマーチェーンで繋ぐ。1 ジョブ 1 チェーンにして競合を無くし、起床で日次の再実体化・残走路の監視・劣化運転からの回復を駆動する。
註: リアルタイムの再評価（残り時間の表示・カウントダウン）は発報層かアプリの責務で、言語は再評価の契機を持たない。残りは points を now で切って数える（A.1 の切り出しと同じ）。

A.3 発火と冪等

発火は at-least-once、重複の吸収はジョブ側の冪等。予定側の永続化は要らない。

at-least-once と claim

MUST: 発火（タイマーからの実行・missed-fire の再実行）は at-least-once。発報層は再実行を抑止する層を持たなくてよい。
MUST: 意味を持つ副作用（送信・登録）の前に冪等キーで claim を取り、claim 済みなら送らない。台帳の行は鍵（事象×宛先）につき 1 行で、同じ宛先への重複はゼロ。
MUST: missed-fire の実行は通常の発火と同じ配信処理・同じ冪等キーを通る。
SHOULD: claim を取った時刻と送信完了の印を分けて記録し、再実行時に「claim 済み・未送信」を区別できるようにする。
SHOULD: 同じジョブが実行中でないことを確かめてから配信処理を呼ぶ。
SHOULD: 再実行と再送を区別する。再実行＝点を渡して実行（冪等が二重送信を防ぐ）・再送だけが特別な操作（冪等キーの監査つき削除の後の再実行）。

冪等キー

MUST: 成分は「定義の同一性・点・供給の asof」。宛先が複数なら宛先も成分に入れる。
MUST: 定義の同一性は自前の記録 id で表す（uid を正にすると式の並び替えだけで鍵が分岐し、配信済みの事象が再送されうる＝A.1）。
MUST: 点の成分は粒度で決める。日粒度の事象（1 日 1 点）は premise の tz での暦日、時刻付きの点（毎正時など）は点そのもの（epoch ms か dates[] のラベル）。
註: 時刻付きの点を暦日に畳むと、1 日の発火が同じ鍵に重なり、2 発目以降が落ちる。
MUST: asof は版の識別子（A.5）。成分に含める理由＝供給の更新で同じ事象の日付が動いたとき、別の配信として区別する（asof が同じなら再通知は起きず、別の事象の鍵とは干渉しない）。
SHOULD: 鍵は構造で説明できる形にし、実値（宛先の識別子など）を文書や公開ログに書かない。

点の同定

SHOULD: 発火点と日粒度の供給データ（dates）の行を突き合わせる鍵は premise の tz での所属暦日。発火時の now をその tz で暦日に落として行を引き、ms の同値照合に頼らない（評価器の点とデータ行は生成経路が違う）。
SHOULD: 定義側と同定側の tz を同じ値に固定し、端末の tz を混ぜない。
SHOULD: 同定に失敗した（当日の行が無い）ときは握りつぶさず、文言で可視化して配信 0 で終える。

予定側の永続化を要求しない

註: 予実照合は「定義＋供給からの決定的再評価 × 冪等台帳」で足りる（2026-08 の運用報告で実証・本書で条件に採用）。
SHOULD: 予定側のテーブルを作らず、永続するのは台帳（冪等行）だけにする。発火は定義と供給の再評価で続き、供給を延ばすだけで先まで発報が続く。
註: 発火点への値の随伴（点とペイロードの対応・表示する暦座標）は発報層と供給側の責務。言語は点列まで。

A.4 運用信号の配線

言語は危険を註釈・被覆サマリ・警告で返す。発報層はそれを監視へ配線し、黙らせない。

残走路→監視

MUST: coverage[].runwayDays を閾値と比べ、割ったら警告かデータ取得ジョブを起動する（閾値の例: H+30 日）。
註: 残走路は評価 to から covering 末尾までの日数（今日基準ではない・負値あり・concluded なら null）。源ごとに分離する。
SHOULD: 残走路は covering と評価 to から演繹できる。実装の返す値と演繹値の一致で検算できるようにする。
SHOULD: 残走路警告は実体化のたびに再発火する。台帳と監視では（ジョブ・源・日）で重複排除する。
註: 警告は監視へ、措置は供給側の更新で閉じる。恒久の防御は式の形でなく覆域の更新にある。

区間註釈→警告

MUST: results[].annotations を読み、発火点が註釈区間に入る点は「未知データ上の予定」として扱う。本書の既定は「実行しつつ警告」で、保留にするかは運用の設定（判定は言語の外＝ADR-15・§4.10）。
SHOULD: 信号は 2 つに分ける——「評価時の now が註釈区間に入っている」（自己申告）と「発火予定点が註釈区間に入っている」（交差警告）。覆域内の missed-fire は交差警告を鳴らさない。
註: 註釈なしは正当性の証明ではない（§4.10）。0 点で窓全体が範囲外註釈なら、「評価不能」ではなく「範囲外」の信号として扱う。

供給の失敗→劣化運転

MUST: 起動時検査（boot）で止めないのは error.kind が supply のときだけ。static（定義の欠陥＝字句・構文・静的・評価のエラー）と usage（呼び出し側の欠陥＝引数・ファイル・--supply の JSON 自体の誤り）は止める。
MUST: supply（供給の解決失敗）では止めず、空の予定で起動して起床ごとに再試行する（劣化運転）。
註: 参照実装（1.0.10）では、supply は解決失敗（供給が来ない・解決子が無い）と --supply の束の形の誤り（covering／asof の欠落など）。static は定義の誤りに加えて、評価器の契約検査が割る違反（乱順・覆域の外・同長違反・実在しない日付・無宣言のラベル＝ADR-46 判断 7）を含む。
註: usage は評価が走る前の失敗で、供給の欠落ではない。劣化運転（空の予定で起動して再試行）の対象にならない。
MUST: 「まだ無い」（空テーブル＋covering＝正当な空・点ゼロ・残走路警告）と「解決失敗」（供給エラー）を型で区別し、ログで読み分けられるようにする（ADR-45・ADR-46）。
SHOULD: 劣化運転中は旧スナップショットを温存し、回復（実体化の成功）を情報として記録する。
SHOULD（CAP > TTL）: 供給キャッシュに TTL を置き、失敗した更新でも有効期限が進む実装では、起床周期（CAP）を TTL より長くする。回復は「次の起床」かつ「TTL 切れ後」に起きるため、不等式を破ると劣化運転から戻らない（2026-07 の運用報告の前倒し検証で実測）。

警告

SHOULD: warnings[] を採取する。horizon-clip は発火予定に影響しない既知の動作（ADR-37 判断 8）で件数は窓の取り方で決まるため、監視の閾値にしない。
SHOULD: window-clip は評価範囲を広げるのが直し方（§7.8）。
SHOULD: 運用信号の件数（missed-fire・供給の解決・horizon-clip・誤報と見逃し）を数えて記録する。

信号台帳

SHOULD: 1 発火 1 レコード——信号種別・実時刻・源（束縛名）・評価文脈（ジョブ）・残走路値と閾値・警告文言の全文・措置。評価窓（from／to）を入れて 1 レコードで自己完結させる。
SHOULD: 前倒し検証（閾値の一時操作・短い covering・供給の意図的な失敗）は「機構が動く」確認、本番の自然発火は「運用が回る」確認。別物として扱い、検証でも本番と同じログ経路を通す。

A.5 供給（supply）

式は静的・データは実行時に解決。1 回の評価で供給は 1 回固定する。

静的束と一評価一解決

MUST: external の解決値は静的束で渡す（束縛名ごとに dates か instants・covering・asof・任意の labels＝schema/supply.schema.json）。契約検査（覆域の包含・昇順・実在日・ラベルの域）は評価器に委ねる。
MUST: 一評価一解決。1 回の評価の中で asof と source を固定し、評価中に変えない（解決値の asof が被覆サマリへ出る）。
註: 評価の決定性は「同じ asof」の下で言う。

asof と covering

MUST: asof は版の識別子で、同一性比較だけに使い、順序や日付として読まない（§3.8）。版を切る識別子が無ければ観測日 YYYY-MM-DD を使う（supply schema の asof）。
MUST: データを持つ premise は covering: と tz: を明示する。覆域の外は「未知」と申告し、偽の安心（広すぎる covering・開端の濫用）を作らない。
SHOULD: 供給は閉じられる区間だけを運ぶ。覆域の年次更新は供給側で閉じ、利用者の式の字面を変えない（segmentBy の label: 射影など）。
註: 配信前に再取得で asof が変わっても、冪等キーの asof 成分が変わるだけで再通知は起きない（2026-08 の運用報告）。配信後に asof が変われば新しい鍵で claim が通り、別の配信として扱われる（鍵の構造からの帰結・A.3）。

供給路

SHOULD: 供給の連続性（抜け・順序）の検査は供給路に置く。ラベル列の 1 点欠落が黙って意味を変える形がある。
SHOULD: 供給契約の値域は supply schema に従う（instants は epoch ms・昇順・±8.64e15 以内）。解決子は同期の値を返す（参照実装の RunOptions.resolve）。

A.6 照合（予実）

照合は意味を持つ副作用にだけ要る。予定側のテーブルは作らない。

MUST: 予実照合は決定的再評価と冪等台帳の突き合わせで行う。
MUST: 時刻は 3 つ——発火（タイマーが起きた時刻）・予約（claim を取った時刻）・送信完了——を区別して記録する。観測値を報告するときはどの時刻かを添える。
註: 予約の時刻と予定の差は、タイマーが予定より前に起きない前提で、発火の遅れの上界。
SHOULD: 対象は意味を持つ副作用（送信・登録）だけ。ログのみのジョブは対象外とし、ローテートする簡単なログで足りる。
SHOULD: 点ごとの verdict（例: delivered・failed・partial・missing・future）と summary を CliReport の拡張として載せる。
SHOULD: 計測の基準を 1 つに決めて明記する。台帳の記録時刻とログ行の時刻は同じ配信でも違う。
SHOULD: 観測は本番へ読み取りのみで行い、採取器の版を記録する。「機構の確認（演繹）」と「統計的裏付け（標本数）」を分けて書く。

A.7 観測例

言語側の試作実測と、供給側の実行系（自前の評価器・external 供給・通知の配信）からの還流便に記録された値。供給側の固有名は伏せ、「供給側の記録では」の枠で引く。

言語側の試作実測（2026-07-09）

評価窓を 3 日ずらした再評価で重なる区間の点列は 30/30 一致。営業日 9〜18 時の毎正時は 1 週 50 点。
同じ試作で、停止 10:30 → 再起動 14:10 の未発火 4 点（11:00〜14:00）が列挙され、翌年 2 月 1 日の発火点に範囲外註釈と残走路が付く。

供給側の本番値（測定条件は本番環境・各事象 1 発火・ベンチマークではない）

決定性の実運用（2026-07-23）: 10 日前の起動時の実体化（同じ起動で missed-fire 9 点を回復）が予告した発火予定が、その後の 10 日間（再起動 1 回・missed-fire 10 点の回復を含む）を通じて不変。配信は予告どおりで配信記録は 1 行（claimed 1／delivered 1）。
冪等 claim（2026-08-07）: 実行環境の移行の後の最初の worker の起動で、24 時間の lookback 窓内の発火を missed-fire として再実行（missed 1・execute true）。移行済みの冪等行に claim が当たり claimed 0／delivered 0、再送なし（配信記録 1 行のまま）。
決定性の継続（2026-08-07〜2026-08-23）: 移行後の 16 日間、同じ実行ホストの上でのコンテナの作り直し 10 世代を跨いで next 不変。実行ホストを跨いだ実証は、移行の前後の 1 組（1 台 → 1 台）。
宛先 2 件（2026-09-07）: 同一発火から宛先 2 件へ配信（claimed 2／delivered 2）。配信ジョブは当日 3 回走り、残り 2 回の再実行は claimed 0／delivered 0 で、配信記録は宛先ごと 1 行の 2 行のまま。
予定比（すべて「配信を予約した時刻」の差。発火はそれ以前・送信完了はそれより後）: +0.728 秒（約 0.7 秒・2026-07-23）・+15.958 秒（2026-08-07）・+0.032 秒（2026-08-23）・+0.037 秒（2026-09-07・宛先 2 件の 1 件目）。
限界: 各値は各事象 1 発火の記録（配信を予約した時刻）で、宛先側の応答時間は含まない。2026-07-23 は、実体化と配信完了のログが供給側の還流文書にだけ残る（配信記録の行は供給側の DB に残る）。

A.8 適合の自己申告（チェックリスト）

発報層が「Kairos 適合」を名乗るときに添える一覧。MUST は全部に印を付け、SHOULD は外した項目と理由を書く。

MUST

CliReport の形で評価結果を受け、points を点の同一性にしている（A.1）
エラーも JSON で受け、error.kind で起動時の扱いを分けている（A.1）
tz は定義側で明示し、実行環境の既定 tz に依存しない（A.1）
評価範囲は日付単位の半開区間（to は含まない）である（A.1）
時刻起点の切り出しを評価範囲で行っていない（A.1）
version を記録し、版更新時に点列を前後比較している（A.1）
uid を永続 ID に使っていない（A.1）
自前の評価器は判定の同一性（診断の文言を含む）と doctest 照合を満たす（A.1・該当時）
有界窓の定期再評価で差し替え、重なる区間の一致を検査している（A.2）
水位標を持ち、未発火点を列挙して黙って消さない（A.2）
発火は at-least-once・副作用の前に claim・台帳は鍵（事象×宛先）につき 1 行（A.3）
missed-fire が通常の発火と同じ配信処理・同じ冪等キーを通る（A.3）
冪等キーの成分に定義の同一性（自前の記録 id）・点（粒度に応じて暦日か点そのもの）・asof（複数宛先なら宛先）が入っている（A.3）
残走路を閾値監視に配線している（A.4）
発火点と註釈区間の交差を扱っている（A.4）
boot で止めないのは error.kind が supply のときだけ（劣化運転）・static と usage は止める（A.4）
「まだ無い」と「解決失敗」を型で区別している（A.4）
供給は静的束・一評価一解決・asof は同一性比較のみ（A.5）
データを持つ premise に covering と tz を明示している（A.5）
予実照合は決定的再評価 × 冪等台帳（A.6）
発火・予約・送信完了の 3 つの時刻を区別して記録している（A.6）

適合検査の最小セット（SHOULD）

評価窓をずらした二度評価で重なる区間の点列が一致する。
停止→再起動で未発火点が列挙され、冪等で再送が起きない。
covering 切れで残走路の信号が出て、監視へ届く。
自前の評価器は doctest の期待値と一致する。witness は変異（退行版へ戻す・修正を落とす）で赤を確かめてから数える。

報告の定型（SHOULD）

実行環境欄＝OS・実行環境・ランタイムの版・実行既定の tz・追随する参照実装の版。
「評価器の実測」と「本番の観測」を分け、未検証の範囲を書く。再現材料は全文を載せ、参照 CLI でそのまま走る形にする。
送達済みの報告は改稿せず、訂正は追記で残す。

A.9 用語

用語	定義	参照
発報層	言語の点列を解釈して実際に起動・実行・管理する実装系。言語のスコープ外	§1.4・§7.8
rolling horizon	近未来の有界窓 [today, today+H) で評価し、定期的に再実体化して差し替える実行モデル	A.2
実体化	評価窓で定義を評価し、発火予定（missed と next）を確定する処理。起動時・日次・回復時に走る	A.2
水位標	前回どこまで発火したかの記録。実装形は前回実行位置や lookback 窓	A.2
missed-fire	停止中に過ぎた発火点。水位標から now までの列挙で得る。通常の発火と同じ配信処理を通る	A.2・A.3
決定性	同じ定義・同じ範囲・同じ供給から同じ点列。環境を跨いでも next が変わらない	§7.8
at-least-once	取りこぼさず実行する保証。重複はジョブ側の冪等で吸収する	A.3
冪等 claim	副作用の前に冪等キーで台帳の行を取る操作。claimed／delivered の計数で表す。行は鍵（事象×宛先）につき 1 つ	A.3
冪等キー	定義の同一性（自前の記録 id）・点（粒度に応じて暦日か点そのもの）・asof（複数宛先なら宛先）の成分で組む鍵	A.3
uid	式の指紋。順番・字面・tz から計算。永続 ID ではない	A.1
残走路	被覆サマリの各源について、評価 to から covering 末尾までの日数	§4.10
区間註釈	範囲外出自の註釈区間。結果に並走し、空でない結果にも付く	§4.10
被覆サマリ	参照した各源の covering・asof・完結主張・残走路。評価範囲でクリップしない	§4.10
劣化運転	供給の解決失敗時に空の予定で起動し、起床ごとに再試行する状態	A.4
供給エラー	external の解決失敗。CLI の `--supply` では束の形の誤りも含む。機械可読な部分類（error.kind が supply）	ADR-46
正当な空	空テーブル＋covering。実体化は成功・点ゼロ・残走路の警告は出る	ADR-45
CAP／TTL／H	起床周期／供給キャッシュの有効期限／評価地平線。失敗した更新でも TTL が進む実装では CAP > TTL が回復の条件	A.2・A.4
horizon-clip／window-clip	実装地平線の越えの警告／評価範囲内の点が段で外へ動いた警告	§7.8・ADR-37
一評価一解決	1 回の評価で供給を 1 回だけ解決し、asof を固定する	A.5
静的束	external の解決値を dates／instants・covering・asof・labels の形で渡す束	A.5
予実照合	決定的再評価と冪等台帳の突き合わせ。意味を持つ副作用にだけ要る	A.6
3 つの時刻	発火・予約（claim）・送信完了。観測値にはどれかを添える	A.6
写経／追随	参照実装を自前の評価器へ移す行為と、公開版への追従	A.1
判定の同一性	参照実装と同じ可否（受理・拒否）・点列・診断の文言を返す性質。独自ガードを足さない	A.1
信号台帳	運用信号を 1 発火 1 レコードで残す記録	A.4