ADR-18: premise 層と本体層の二層構造。語彙は共有し型は分離する

判断: 言語を二層に分ける。premise 層（暦法・カレンダーを組み立てる層。多行・宣言的でよい）と、本体層（スケジュールを紡ぐ層。一行・パイプ的でありたい）。SQL の DDL と DML の関係に対応する。両層は同じストリーム語彙（生成子・結合子・窓等）を共有するが、扱う型は分かれる。本体層の第一級値は時間ストリーム（外延・点の列）、premise 層が構築するのは premise（内包・生成規則）であり、両者は別の型。

背景: 「本体式は可能な限り一行、premise 宣言は一行にこだわらない」という要求は、書式の希望ではなく「premise を定義する言語と premise の上で式を書く言語は別」という宣言だった。この分離は、premise の含む／含まないの線引き（3.0：ストリームと演算子は premise でない）と同じ場所で割れており、モデルの自己整合を示す。複雑さは消せず保存される（ADR-16 のトレードオフ）ため、本体式が簡潔でいられるのは premise 層が複雑さを引き受けるからである。ゆえに premise 層は複雑になることを許容する。ただし許容するのは「表現力」（表せる暦法の範囲）であって「構文の華美」（独自記法の積み増し）ではない。後者は二重学習コストに反転する罠。両立の鍵は、premise 層の操作を本体式と同じストリーム代数で書くこと。祝日の増減＝ストリームの和・差、暦法の合成＝積、会計暦の境界ずらし＝窓操作。新しい演算子を足さずに表現力だけを上げる。

時間ストリームで premise を表現することは原理的に不可能である。時間ストリームは外延（生成された点の列）、 premise は内包（生成規則）であり、外延から内包は復元できない（3 月末という点列から「月末とは何か」の規則は逆算できない。情報が落ちている）。ゆえに両者は別の型でなければならず、これは設計判断ではなく情報量の差という事実の反映である。両者の関係は非対称で、premise を評価すると時間ストリームが出る（レシピを実行すると料理ができる）が、逆は不可。

却下した案:

一層に統一し premise も時間ストリームで表す案。外延に内包の情報が無く原理的に不可能。
二層を別言語（別文法）にする案。表現力は上がるがユーザに二つの文法を強い、二層化の利点を二重学習コストに反転させるため却下。語彙は共有する。

帰結:

語彙は共有され型は分かれる。premise は時間ストリームを材料に定義される（レシピは食材を使うが食材ではない）。
ADR-05「型は一本」は本体層内に限定される（ADR-05 改訂を参照）。言語全体では時間ストリーム型と premise 型の二型。
用語 DateStream は ADR-10（基底を時間軸へ降格）以降すでに誤称であり、時間ストリーム（TemporalStream）へ改名する。日も秒もセッション窓も対等な粒度であり、型名が「Date」を特権化するのは実態に反する。

改訂（ADR-25 による）: 値型（数値・論理・列挙・将来の文字列）の追加で、言語全体の型は「時間ストリーム型・ premise 型・値型」の三系統になる。二層構造・語彙共有・型分離という本判断は不変で、型の系統数のみ更新される。