100年、古びない道具を、職種の数だけ。

どんな困りごとを解くか

「ログインできた」で終わってしまい、トークンの検証の中身が見えないことを防ぎます。alg: none や許可していない alg、別の相手向けの aud、pin していない発行者、期限切れのトークンを、判定の段階で必ず止めるための検めです。

使う場面

• OIDC/OAuth のトークンの alg・aud・iss・exp を、決めた規則どおりに検めたいとき。
• alg: none や許可していない alg（例: HS256）のトークンを確実に拒否したいとき。
• 署名の検証は自分の側（pin した JWKS・鍵）で済ませ、その結果と claims の突き合わせを、通信のない純粋な関数で判定したいとき。
• トークンの正当性の判定結果を、認可の判定（policy-facts）や監査・来歴（token-facts）の核へ継ぎたいとき。

使わない場面

• トークンの署名そのものを検証してほしいとき。この継手は署名を検証しません。signature_valid（真偽値）を呼び出し側から受け取り、それが検証済みでなければ拒否するだけです。
• IdP や JWKS の取得までまかせたいとき。取得は含みません。
• nbf・iat・kid を検めたいとき、または aud が配列のトークンを扱いたいとき。aud は 1 つの値として照合し、配列の aud は扱いません。
• 認可（誰に何を許すか）を決めたいとき。認可の判定は policy-facts 核へ渡します。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。

検査すること

• alg を検めます。alg: none と、許可一覧（allowed_algs）に無い alg（例: HS256）は拒否します。
• aud を検めます。許可した aud（allowed_aud）と一致しない aud（aud の混同）は拒否します。
• iss を検めます。pin した iss（allowed_iss）以外の発行者は拒否します。
• exp を検めます。猶予（leeway_seconds、既定 0）を含めて期限を過ぎたトークンと、exp が無いトークンは拒否します。
• signature_valid を検めます。署名が検証済みでない（signature_valid が真でない）トークンは拒否します。
• どれか一つでも外れたら { ok: false, errors: [...] } を返し、通しません（fail-closed）。

しないこと・既知の限界

• トークンの署名の実際の検証（pin した JWKS・鍵による検証）はしません。signature_valid は呼び出し側が検証して渡す値で、この継手はその値を信じて判定します。
• IdP・JWKS の取得はしません。通信をしない判定だけの部品で、port もありません。
• nbf・iat・kid は検めません。配列の aud も扱いません。
• 検めるのは claims の alg・aud・iss・exp・signature_valid の 5 つだけです。カタログの一言にある「失効」は、この継手では exp による期限切れの拒否（leeway 込み）として扱います。
• 実 JWKS・鍵には、この部品の中ではつないでいません。配備するときに pin します。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• IdP の使い方の雛形ではありません。

つなぎ方

src/guards.js の verifyClaims(cfg, claims, now) を呼びます（純粋な関数で、通信はしません）。cfg には allowed_algs・allowed_aud・allowed_iss・leeway_seconds を、claims には { alg, aud, iss, exp, signature_valid } を、now には検証時刻（秒）を渡すと、{ ok: true, errors: [] } か { ok: false, errors: [...] } を返します。利用側が用意するもの: トークンの署名の検証（pin した JWKS・鍵）とその結果の signature_valid、IdP・JWKS の取得。port は無く、外部への副作用はありません。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

外の判断点の許可の判断を受け渡すとき、pin していない方針の判断を運んでしまうこと、判断を名乗る receipt から許可の権限を導いてしまうこと、そして判断を受け取ったことを承認と取り違えることを防ぎます。

使う場面

• 外の判断点が出した許可の判断を、参照（decision_ref）として、pin した許可の方針（policy_refs）の範囲でだけ基盤へ運びたいとき。
• 運んだ結果を、request_id・request_digest・参照の一致で照合してから受け取りたいとき。DONE の result には decision・decision_ref・permission_authority が添えられます。
• 判断の受け渡しで外への効果を起こしたくないとき。許可の判断の参照の副作用は NONE です。
• 基盤の障害で結果が不明になっても、同じ request_id を二度送らず、lookup で解きたいとき。

使わない場面

• RBAC/ABAC で「この人はこれをしてよいか」を評価させたいとき。この継手は外の判断点の判断を参照として運ぶ継手で、許可の評価の機能は含みません。
• 受け取った PERMIT を許可の権限として使いたいとき。PERMIT を受け取っても許可の権限は導かず、permission_authority を導いたと名乗る receipt は受理しません。
• 判断が正しいかを確かめたいとき。許可の判断そのものは確かめません（外の判断と基盤の役目）。
• すぐに使える判断点がほしいとき。実の基盤（どの判断点か）は含まず、未定です。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。
• A-02 だけの部品を求めるとき。この継手は A-02・A-04・A-05・A-06・A-07 を契約上 1 つの部品として担い、試験と検査も共通です。A-01 は token-verify 継手、A-03・A-08 は session 継手が担います。

検査すること

• 方針を検めます。pin していない許可の方針の要求は送りません。空の一覧は何も許しません。
• 本人の参照と参照の形を検めます。メールアドレス・電話番号の形の本人の参照、パスや .. を含む参照（path traversal）、追加のフィールドは送りません。
• 許可の権限を導いたと名乗る receipt は受理しません。
• receipt の request_id・request_digest・参照が要求と一致しなければ受理しません。request_digest を偽った receipt も受理しません。
• 外への効果を増やす receipt、効果が UNKNOWN の receipt は受理しません。受理できない receipt が来たら停止します（HALTED）。
• 同じ request_id は二度送りません。基盤の障害は UNKNOWN とし、再送は lookup で解きます。

しないこと・既知の限界

• 許可の評価をしません。この継手は外の判断点の判断を参照として運ぶ継手で、RBAC/ABAC の評価の機能は含みません。許可の判断は外の判断点、許可の方針の事実は核（policy-facts）の役目です。
• PERMIT は許可の権限ではありません。判断を受け取ったことから、許可・権限を導きません。
• 判断を受け取ったことは承認ではありません（approval: false）。
• 実の基盤（どの判断点か）を含みません。port の実装と pin する一覧は未定で、接続するときに別の関門で決めます。
• 直接の識別子のすべてを見分けるものではありません。検出はメールアドレスと電話番号の代表的な形だけです。
• 特定の IdP や判断点の使い方の雛形ではありません。契約も変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/identity-ext/v1 でつなぎます。createIdentityExtClient({ cfg, port }) の submit(request) に AuthzDecisionRefRequest を渡すと、DONE・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED のどれかを返します（どれも approval: false）。DONE の result: decision・decision_ref・permission_authority。cfg には pin する一覧 6 つ（policy_refs ほか）がどれも要ります。利用側が用意するもの: 基盤への port（submit、任意で lookup）。副作用は NONE。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

「ログイン状態」は当然のものと思われがちですが、期限を過ぎた session、同時数の上限を超えた session、失効・終了したはずの session が使われ続けることがあります。この継手は、session の発行・再開・終了・失効を検めて送り、store の受領を照合できない限り、その session を使える扱いにしないための検めです。

使う場面

• session の発行・再開・終了・失効を、外部の session store に対して行い、その結果を照合してから状態を進めたいとき。
• session の最長の長さ（max_session_seconds）と同時に使える数の上限（max_concurrency）を、開く時点で必ず守らせたいとき。
• ある時刻にある session を使ってよいかを、照合済み・開いている・期限内・未確定の操作が無い、のすべてがそろうときだけ「使ってよい」と判定したいとき。
• store の障害で結果が分からないとき、その session を解決まで使えない扱いにしたいとき。

使わない場面

• session があることを、本人確認や権限の代わりにしたいとき。session は本人確認でも権限でもありません（authority: NOT_DERIVED、approval: false）。
• トークンそのものを検証したいとき。それは A-01（token-verify-tsugite）の役目で、この継手は session の操作と失効の伝播だけを扱います。
• すぐに使える session store がほしいとき。実 session store は含まず、どれにつなぐかはまだ決まっていません。
• session の期限や同時数の上限そのものを決めてほしいとき。決定は核（session-facts・policy-facts・timestamp-facts）の役目で、この継手は上限と状態を受け取って検めるだけです。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。

検査すること

• 同時数を検めます。同時に使える session の上限（max_concurrency）を超える OPEN は送りません。
• 期限と時刻を検めます。期限の巻き戻しと時刻の巻き戻しを拒否します。OPEN には期限（expiry）と同時数の上限（concurrency_limit）を必須とし、OPEN 以外では期限・同時数を変えさせません。
• 失効・終了した session の再開を拒否します。store が失効後に RESUMED と返したら、受理せず停止します。
• 受領（SessionReceipt）を照合します。操作と食い違う状態（session_state は op から決まる。NONE・UNKNOWN も照合しない）、別の session の受領、request_digest の偽りがあれば受理せず、以後は HALTED にします。
• 権限や本人確認を持ち込む受領を拒否します。authority を導いたもの、検証者の無い本人確認済み（VERIFIED）は受理しません。
• SecretRef の隣に生の秘密が置かれた要求を拒否します。
• 失効（REVOKE）の受領には伝播の参照を必須とし、pin した伝播先すべてに証拠つきで届くまでは「未完了」（REVOKED_PROPAGATION_INCOMPLETE）とします。詳しくは A-08（失効伝播）で扱います。
• store の障害は UNKNOWN とし、その session は解決まで使えない扱いにします。

しないこと・既知の限界

• session は本人確認でも権限でもありません。どの結果にも authority: NOT_DERIVED と approval: false が付きます。
• トークンの検証はしません。A-01（token-verify-tsugite）の役目です。
• 実 session store と伝播先（各サービスの失効受付）を含みません。どれにつなぐか、port の実装、pin する対象は未定で、接続するときに別の関門で決めます。
• session の上限や規則を決めません。決定は核（session-facts・policy-facts・timestamp-facts）の役目で、この継手は受け取った上限と状態を検めるだけです。
• 契約を変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。なお、OPEN の必須項目などで契約より厳しくした点があります。
• A-03 と A-08 は契約上 1 つの部品です。ID ごとの行（A-03・A-08）が、この部品を指します。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• session store の使い方の雛形ではありません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/request-receipt-group/v1 でつなぎます。createSessionClient({ cfg, port }) の apply に SessionOpRequest（OPEN・RESUME・TERMINATE・REVOKE）を渡すと、APPLIED・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED・REVOKED_EVERYWHERE・REVOKED_PROPAGATION_INCOMPLETE を返します（approval: false 付き）。isUsable(session_ref, now) で使えるかを判定。利用側が用意するもの: store と伝播の port（apply・propagation）。副作用: EXTERNAL_REVERSIBLE。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

重要な操作の直前に追加認証を挟むとき、送っていない問いかけや別の本人の問いかけに対して照合してしまうこと、token の形の値をそのまま運んでしまうこと、そして追加認証を満たしたことを許可と取り違えることを防ぎます。

使う場面

• 重要な操作の直前だけ、追加認証の問いかけを基盤へ送り、その答えを照合したいとき。
• 追加認証の要素を、許す要素の一覧（allowed_factors）の範囲にとどめたいとき。
• 照合を、この継手が同じ本人へ送って CHALLENGED と照合した問いかけに限りたいとき。状態は CHALLENGE→CHALLENGED・FAILED・UNKNOWN、VERIFY→SATISFIED・FAILED・UNKNOWN です。
• 運んだ結果を、request_id・request_digest・参照の一致で照合してから受け取りたいとき。DONE の result には step_up_state・satisfied・authorization が添えられます。
• 基盤の障害で結果が不明になっても、同じ request_id を二度送らず、lookup で解きたいとき。

使わない場面

• 追加認証を満たしたことを、操作の許可として使いたいとき。満たしても許可や権限ではなく、許可を導いたと名乗る receipt は受理しません。
• 追加認証が正しいか、資格情報が有効かを確かめたいとき。これらは確かめません（外の判断と基盤の役目）。
• 秘密や token の値そのものを運びたいとき。秘密・token の bytes は運ばず、参照だけです。
• すぐに使える追加認証の基盤がほしいとき。実の基盤（どの IdP か）は含まず、未定です。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。
• A-04 だけの部品を求めるとき。この継手は A-02・A-04・A-05・A-06・A-07 を契約上 1 つの部品として担い、試験と検査も共通です。A-01 は token-verify 継手、A-03・A-08 は session 継手が担います。

検査すること

• 要素を検めます。許す一覧にない要素、契約にない要素の要求は送りません。空の一覧は何も許しません。
• 照合の相手を検めます。この継手が送っていない問いかけ、別の本人への問いかけ、失敗した問いかけに対する照合は送りません（REFUSED）。
• 資格情報の参照を検めます。pin していない資格情報の要求は送りません。資格情報の参照・assertion_ref が bytes や token の形なら、pin されていても送りません。
• 本人の参照と参照の形を検めます。メールアドレス・電話番号の形の本人の参照、パスや .. を含む参照（path traversal）、追加のフィールドは送りません。
• 追加認証から許可を導いたと名乗る receipt は受理しません。
• receipt の request_id・request_digest・参照が要求と一致しないもの、外への効果を増やすもの、効果が UNKNOWN のものは受理しません。受理できない receipt が来たら停止します（HALTED）。

しないこと・既知の限界

• 追加認証を満たしたことは、許可や権限ではありません。許可の判断は外の判断点と人・組織の役目で、継手は送る前と受け取った後の検めだけをします。
• 追加認証の正しさ・資格情報の有効さは確かめません（外の判断と基盤の役目）。
• 満たしたことは承認ではありません（approval: false）。
• 実の基盤（どの IdP か）を含みません。port の実装と pin する一覧は未定で、接続するときに別の関門で決めます。
• すべての秘密を見分けるものではありません。token や鍵の形の検出は代表的な形だけを見る網で、本当の守りは pin した参照の一覧です。直接の識別子の検出もメールアドレスと電話番号の代表的な形だけです。
• 特定の IdP の使い方の雛形ではありません。契約も変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/identity-ext/v1 でつなぎます。createIdentityExtClient({ cfg, port }) の submit(request) に StepUpAuthRequest を渡すと、DONE・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED のどれかを返します（どれも approval: false）。DONE の result: step_up_state・satisfied・authorization。cfg に pin する一覧 6 つが要ります。利用側が用意するもの: port（submit、任意で lookup）。副作用: 問いかけ EXTERNAL_REVERSIBLE、照合 NONE。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

サービス同士の認証を基盤へ運ぶとき、pin していないワークロードや資格情報で要求を出してしまうこと、資格情報の bytes や token の形の値をそのまま運んでしまうこと、そして認証できたことを権限と取り違えることを防ぎます。

使う場面

• サービス（ワークロード）同士の認証の要求を、pin したワークロード（workload_refs）と資格情報の参照（credential_refs）の範囲でだけ基盤へ運びたいとき。
• 資格情報を bytes ではなく参照だけで扱いたいとき。
• 運んだ結果を、request_id・request_digest・参照の一致で照合してから受け取りたいとき。DONE の result には auth_state・authority が添えられます。
• 基盤の障害で結果が不明になっても、同じ request_id を二度送らず、lookup で解きたいとき。

使わない場面

• Workload Identity や mTLS の仕組みそのものがほしいとき。この継手はワークロードの認証の要求を参照で運ぶ継手で、その仕組みの機能は含みません。
• ワークロードが認証できたことを、権限として使いたいとき。権限は導かず、ワークロードの権限を導いたと名乗る receipt は受理しません。
• 資格情報が有効かを確かめたいとき。資格情報の有効さは確かめません（外の判断と基盤の役目）。
• 資格情報や token の値そのものを運びたいとき。秘密・token の bytes は運ばず、参照だけです。
• すぐに使える認証の基盤がほしいとき。実の基盤は含まず、未定です。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。
• A-05 だけの部品を求めるとき。この継手は A-02・A-04・A-05・A-06・A-07 を契約上 1 つの部品として担い、試験と検査も共通です。A-01 は token-verify 継手、A-03・A-08 は session 継手が担います。

検査すること

• ワークロードを検めます。pin していないワークロードの要求は送りません。空の一覧は何も許しません。
• 資格情報の参照を検めます。pin していない資格情報の要求は送りません。資格情報の参照・assertion_ref が bytes や token の形なら、pin されていても送りません。
• 参照の形を検めます。パスや .. を含む参照（path traversal）、追加のフィールドは送りません。
• ワークロードの権限を導いたと名乗る receipt は受理しません。
• receipt の request_id・request_digest・参照が要求と一致しなければ受理しません。request_digest を偽った receipt も受理しません。
• 外への効果を増やす receipt、効果が UNKNOWN の receipt は受理しません。受理できない receipt が来たら停止します（HALTED）。

しないこと・既知の限界

• Workload Identity・mTLS の仕組みそのものは含みません。ワークロードの認証の要求を、参照で検めて運ぶだけです。
• 認証できたことは権限ではありません。身元や資格情報の状態から、許可・権限を導きません。
• 資格情報の有効さは確かめません（外の判断と基盤の役目）。認証できたことは承認でもありません（approval: false）。
• 実の基盤を含みません。port の実装と pin する一覧は未定で、接続するときに別の関門で決めます。
• すべての秘密を見分けるものではありません。token や鍵の形の検出は代表的な形だけを見る網で、本当の守りは pin した参照の一覧です。
• 特定の IdP の使い方の雛形ではありません。契約も変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/identity-ext/v1 でつなぎます。createIdentityExtClient({ cfg, port }) の submit(request) に WorkloadAuthRequest を渡すと、DONE・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED のどれかを返します（どれも approval: false）。DONE の result: auth_state・authority。cfg に pin する一覧 6 つ（workload_refs ほか）が要ります。利用側が用意するもの: 基盤への port（submit、任意で lookup）。副作用は NONE か EXTERNAL_REVERSIBLE。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

外部連携の API キーを払い出し・回し・失効させるとき、pin していない鍵や置き場所を扱ってしまうこと、鍵の bytes をそのまま運んでしまうこと、基盤が鍵の中身を返してくるのを受け取ってしまうこと、そして鍵の状態を権限と取り違えることを防ぎます。

使う場面

• API キーの発行・回転・失効の要求を、pin した鍵（key_refs）と鍵の置き場所（secret_refs）の範囲でだけ基盤へ運びたいとき。
• 新しい鍵を、中身ではなく置き場所の参照（secret_ref）だけで受け渡したいとき。secret_ref は ISSUE・ROTATE のときだけ必須で、状態は ISSUE→ISSUED_REF・ROTATE→ROTATED_REF・REVOKE→REVOKED か FAILED です。
• 運んだ結果を、request_id・request_digest・参照の一致で照合してから受け取りたいとき。DONE の result には key_state・key_material_disclosed が添えられます。
• 基盤の障害で結果が不明になっても、同じ request_id を二度送らず、lookup で解きたいとき。

使わない場面

• 鍵の中身を受け取りたいとき。鍵の中身を開示する receipt は受理しません。
• 鍵の保管そのものがほしいとき。この継手は発行・回転・失効の要求を参照で基盤へ運ぶ継手で、鍵の保管は含みません（どの鍵の保管かは未定）。
• 鍵が有効であることを、許可や権限として使いたいとき。資格情報が有効でも、許可や権限ではありません。
• 資格情報が有効かを確かめたいとき。資格情報の有効さは確かめません（外の判断と基盤の役目）。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。
• A-06 だけの部品を求めるとき。この継手は A-02・A-04・A-05・A-06・A-07 を契約上 1 つの部品として担い、試験と検査も共通です。A-01 は token-verify 継手、A-03・A-08 は session 継手が担います。

検査すること

• 鍵と置き場所を検めます。pin していない鍵、pin していない秘密の置き場所の要求は送りません。空の一覧は何も許しません。
• secret_ref を検めます。鍵の形の secret_ref は、pin されていても送りません。REVOKE に secret_ref を付けた要求も送りません。
• 鍵の中身を開示する receipt は受理しません。
• 参照の形を検めます。パスや .. を含む参照（path traversal）、追加のフィールドは送りません。
• receipt の request_id・request_digest・参照が要求と一致しなければ受理しません。request_digest を偽った receipt も受理しません。
• 外への効果を増やす receipt、効果が UNKNOWN の receipt は受理しません。受理できない receipt が来たら停止します（HALTED）。

しないこと・既知の限界

• 鍵の中身を運ばず、受け取りません。扱うのは鍵と置き場所の参照だけです。
• 鍵の状態から許可・権限を導きません。資格情報の有効さも確かめません（外の判断と基盤の役目）。
• 発行・回転・失効ができたことは承認ではありません（approval: false）。
• 実の基盤（どの鍵の保管か）を含みません。port の実装と pin する一覧は未定で、接続するときに別の関門で決めます。
• すべての秘密を見分けるものではありません。token や鍵の形の検出は代表的な形だけを見る網で、本当の守りは pin した参照の一覧です。
• 特定の鍵の保管サービスの使い方の雛形ではありません。契約も変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/identity-ext/v1 でつなぎます。createIdentityExtClient({ cfg, port }) の submit(request) に ApiKeyLifecycleRequest を渡すと、DONE・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED のどれかを返します（どれも approval: false）。DONE の result: key_state・key_material_disclosed。cfg に pin する一覧 6 つが要ります。利用側が用意するもの: 基盤への port（submit、任意で lookup）。副作用は EXTERNAL_REVERSIBLE（FAILED は NONE）。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

「本人に代わって」の委任を基盤へ運ぶとき、人・組織の根拠の無い委任を運んでしまうこと、ERABAZU 自身を委任の出どころにしてしまうこと、そして委任の権限を作ったと名乗る receipt を受け取ってしまうことを防ぎます。

使う場面

• 人・組織が出した委任の根拠を recordAuthorityEvidence(evidence_ref, origin) で受け取り（origin は HUMAN か ORGANIZATION だけ）、その根拠がある委任の参照だけを基盤へ運びたいとき。
• 委任の当事者を、メールアドレス・電話番号ではなく仮名の参照だけで扱いたいとき。
• 委任の受け渡しで外への効果を起こしたくないとき。委任の参照の副作用は NONE です。
• 運んだ結果を、request_id・request_digest・参照の一致で照合してから受け取りたいとき。DONE の result には delegation_state・authority_origination が添えられます。
• 基盤の障害で結果が不明になっても、同じ request_id を二度送らず、lookup で解きたいとき。

使わない場面

• 委任の権限を ERABAZU に作らせたいとき、または権限の受け渡しそのものをさせたいとき。この継手は委任の参照を運ぶ継手で、ERABAZU は委任の権限を作りません。
• 人・組織の根拠が無いまま委任を運びたいとき。その要求は送りません（REFUSED）。
• 委任が本物かを確かめたいとき。委任の根拠の中身は検めず、人・組織から受け取った参照かだけを見ます。
• すぐに使える基盤がほしいとき。実の基盤は含まず、未定です。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。
• A-07 だけの部品を求めるとき。この継手は A-02・A-04・A-05・A-06・A-07 を契約上 1 つの部品として担い、試験と検査も共通です。A-01 は token-verify 継手、A-03・A-08 は session 継手が担います。

検査すること

• 委任の根拠を検めます。根拠の無い委任、recordAuthorityEvidence で受け取っていない根拠による委任、出どころを ERABAZU とした委任は送りません。
• 委任の権限を作ったと名乗る receipt は受理しません。
• 当事者の参照と参照の形を検めます。メールアドレス・電話番号の形の参照、パスや .. を含む参照（path traversal）、追加のフィールドは送りません。
• receipt の request_id・request_digest・参照が要求と一致しなければ受理しません。request_digest を偽った receipt も受理しません。
• 外への効果を増やす receipt、効果が UNKNOWN の receipt は受理しません。受理できない receipt が来たら停止します（HALTED）。
• 同じ request_id は二度送りません。基盤の障害は UNKNOWN とし、再送は lookup で解きます。

しないこと・既知の限界

• ERABAZU は委任の権限を作りません。委任の権限は外の人・組織の根拠からだけ来ます。この継手は委任の参照を運ぶ継手で、権限の受け渡しの機能は含みません。
• 委任の根拠の中身（本物の委任か）は検めません。人・組織から受け取った参照かだけを見ます。
• 委任を運べたことは承認ではありません（approval: false）。
• 実の基盤を含みません。port の実装と pin する一覧は未定で、接続するときに別の関門で決めます。
• 直接の識別子のすべてを見分けるものではありません。検出はメールアドレスと電話番号の代表的な形だけです。
• 特定の IdP の使い方の雛形ではありません。契約も変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/identity-ext/v1 でつなぎます。createIdentityExtClient({ cfg, port }) の recordAuthorityEvidence(evidence_ref, origin) で人・組織の根拠を受け取ってから、submit(request) に DelegationRefRequest を渡すと、DONE・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED を返します（どれも approval: false）。DONE の result: delegation_state・authority_origination。利用側が用意するもの: 基盤への port（submit、任意で lookup）。副作用は NONE。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

「ログアウトしたのに残る」事故を防ぎます。失効を一か所で受け付けただけで「全体に行き渡った」と扱ってしまうこと、そして証拠の無い到達の知らせや pin していない先からの知らせを信じてしまうことを防ぎ、失効を全系へ行き渡らせたかを照合できる形で確かめるための検めです。

使う場面

• ログアウトや失効を、決めた伝播先（propagation_targets）すべてに届けたかどうかを、到達の受領で確かめたいとき。
• どの伝播先にまだ届いていないかを知りたいとき。未完了のときは、届いていない先（missing_targets）を添えて返します。
• 受領の不整合で停止している最中でも、失効だけは止めずに送りたいとき。この継手が知らない session の失効も受け付けます。
• 失効した session が、その後に再開されないようにしたいとき。

使わない場面

• 伝播先への失効の送り届けそのものをまかせたいとき。到達は、port（propagation）が返す到達の受領で検めるだけで、伝播先の実装は含みません。
• すぐに使える伝播先や session store がほしいとき。実 session store と伝播先（各サービスの失効受付）は未定です。
• トークンそのものを失効・検証したいとき。トークンの検証は A-01（token-verify-tsugite）の役目で、この継手は session の操作と失効の伝播だけを扱います。
• 失効が行き渡ったことを、本人確認や権限・承認として扱いたいとき。どの結果も authority: NOT_DERIVED・approval: false です。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。

検査すること

• 伝播先の欠けを検めます。pin した伝播先のどれか一つでも到達の受領が無ければ、完了とせず REVOKED_PROPAGATION_INCOMPLETE を返します。
• 到達の証拠を検めます。証拠（evidence_ref）の無い到達の知らせは、届いたとは認めません。
• 伝播先の pin を検めます。pin していない先からの到達の知らせは、届いたとは認めません。
• 失効の受領を照合します。REVOKE の受領には伝播の参照を必須とし、状態の食い違い（REVOKE なら REVOKED）、別の session の受領、request_digest の偽りがあれば受理しません。
• 失効後の残存を拒否します。失効・終了した session は再開せず、store が失効後に RESUMED と返したら受理せず停止します。
• 失効が完了していても未完了でも、その session は使えない扱いにします。store の障害（UNKNOWN）のときも、解決まで使えない扱いです。

しないこと・既知の限界

• 伝播先へ失効を届ける仕組みそのものは持ちません。到達の受領の形（target_ref・session_ref・revoked・evidence_ref）は契約に無く、継手の側の定めです。
• 実 session store と伝播先（各サービスの失効受付）を含みません。port の実装と pin する対象は未定で、接続するときに別の関門で決めます。
• トークンの検証・失効はしません。トークンの検証は A-01（token-verify-tsugite）の役目です。
• 失効が行き渡ったことは、本人確認でも権限でもありません（authority: NOT_DERIVED、approval: false）。
• A-08 は A-03（セッション管理）と契約上 1 つの部品です。ID ごとの行（A-03・A-08）が、この部品を指します。
• 契約を変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• session store の使い方の雛形ではありません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/request-receipt-group/v1 でつなぎます。createSessionClient({ cfg, port }) の apply に REVOKE の SessionOpRequest を渡すと、REVOKED_EVERYWHERE か REVOKED_PROPAGATION_INCOMPLETE（missing_targets 付き）などを返します（authority: NOT_DERIVED・approval: false 付き）。伝播先は cfg の propagation_targets に pin します。利用側が用意するもの: store の port（apply）と、到達の受領の一覧を返す port（propagation）。副作用は EXTERNAL_REVERSIBLE。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

「ドメインを確認しました」と言うとき、どこを読み、どの答えを信じたかが見えなくなることを防ぎます。名前や URL はドメインだけから組み立て、転送・TLS・DNSSEC・大きさを検め、受け取ったままの答えを digest とともに運びます。照会を管理権の証明と取り違えず、答えを別の目的に使い回しません。

使う場面

• 組織のドメインに置かれた印を、DNS TXT（`_kokoroamu.<domain>`、method DNS_TXT）か HTTPS の決まった場所（`/.well-known/kokoroamu-org.json`、method HTTPS_WELL_KNOWN）で照会し、その答えをあとで読む側へ渡したいとき。
• 呼ぶ側にはドメインだけを渡させ、DNS の名前・URL・port 番号・path は呼ぶ側に決めさせたくないとき。
• 1 つのドメインを、目的ごとに別々の照会で使いたいとき（今の目的の表は `seat8`）。目的は依頼と答えの両方に入り、答えは別の目的に使い回しません（reusable_for_other_purpose false）。
• TXT の行を受け取った順のまま、HTTPS の本文を bytes（base64）のまま、それぞれの digest とともに残したいとき。

使わない場面

• 印を読んで、目的と鍵 ID を照合し、期限を決めたいとき。それは A-10 の部品（org-domain-claim-primitive）と規則・人の役目で、この継手は照会だけをします。
• 照会の結果を、そのまま管理権の証明として使いたいとき。この継手の答えは、管理権を認めるものではありません（ownership_decision NOT_DERIVED）。
• 任意の URL・port 番号・path を照会したいとき。要求にその欄は無く、受け取りません。
• すぐに使える照会の仕組みがほしいとき。実の DNS・HTTPS への照会は 0 回で、port の実装・resolver・信頼する CA の一覧・設定の値は、接続するときに別の関門で決めます。
• 照会の記録を長く残したいとき。記録はこの継手の中だけで、再起動で消えます。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。

検査すること

• 設定と目的を検めます。要求の contract_pin が設定 contract_schema_digest と違うとき、設定が無いとき、目的が allowed_purposes に無いとき、resolver が resolver_profile_refs に無いときは送りません（REFUSED）。空の表は何も許しません。
• receipt の名前と URL が、ドメインから組み立てたものと同じことを照合します。答えの目的・ドメイン・鍵 ID が依頼と違う receipt は受理しません。
• 答えの中身を照合します。TXT の順・行数・digest、本文の大きさ・digest・content type（JSON か text、charset=utf-8 だけ）が合わない答えは受理しません。受け取りと要求の文字列は、正しい Unicode のときだけ受け取ります。
• 転送と TLS を検めます。別のホスト・http・上限を超える転送をたどった答えは受理しません（たどらなかった転送は REDIRECT_REFUSED）。TLS の検めが外れた FOUND・NOT_FOUND、DNSSEC の BOGUS を含む答え、TIMEOUT の途中の答えも受理しません。
• つないだアドレス（connected_address）を検めます。IANA の特別用途アドレスの登録の、そのアドレスを含むいちばん狭い行で global のものだけを受け取ります。NAT64 の prefix の中へつないだ答えは、RFC 6052 で取り出した中の IPv4 も global のときだけ受け取ります。
• 判断しない印と効果を照合します。claim_evaluation NOT_PERFORMED・ownership_decision NOT_DERIVED・side effect NONE を守らない receipt は受理せず、照合できない receipt のあとは停止します（RECEIPT_REJECTED のあとは HALTED）。
• 同じ request_id の違う中身は送りません。port の障害や時間切れ（limits.timeout_ms と猶予 1 秒）は UNKNOWN とし、同じ要求を送り直して解きます（port.lookup があればまずそれで）。

しないこと・既知の限界

• 印（`v=kokoroamu-org1`）を読む・目的と鍵 ID を照合する・期限を決める・管理権を認めることはしません。照会できた・印が見つかったことは、管理権の証明ではありません。
• 解決したアドレスがすべて global だったか、cookie・資格情報を送らなかったか、名前と URL を実際にドメインから組み立てたかは確かめません（port の役目）。この継手が検めるのは、receipt の connected_address が global であることまでです。
• DNSSEC の SECURE・INSECURE、TLS の 3 つの検めの結果、TTL は port の申告で、この継手は形と組み合わせだけを検めます。
• global の範囲の表は、IANA の登録をページとして読んだ写しで、生の登録の bytes とは照らしていません。公開の前に生の CSV と照らし直す必要があります。
• local の NAT64 の prefix を知りません。nat64 を返さない port の答えでは、local の prefix の中に埋められた IPv4 が global かを照らせません。
• 何も書きません（side effect NONE）。運べた・照会できたことは承認ではありません（どの結果にも approval: false が付きます）。
• 契約を変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/org-domain-control/v1（OrgDomainControlRequest / OrgDomainControlReceipt）でつなぎます。createOrgDomainControlClient({ cfg, port }) の submit(request) は、DONE・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED のどれかを返します（常に approval: false）。利用側の用意: 照会の port（submit と任意の lookup）と cfg（contract_schema_digest・allowed_purposes・resolver_profile_refs）。副作用: NONE。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

印の書き方の揺れや期限切れは、表から見えません。この部品は、知らない欄・重なる欄・知らない版の印を読まず、目的は呼ぶ側の allowed_purposes にあるものだけを通します。1 つのドメインの確認が別の目的に流用されて権限が広がることを防ぎ、期限は観測の時刻と日数から決めます。

使う場面

• DNS TXT の答え（txt_records）か、well-known の本文（body_base64・content_type）から、印（目的と鍵 ID）の一覧を読みたいとき（parseMarks）。
• ある目的・ある鍵 ID の印があるかを文字列の完全一致で確かめ、domain・method・purpose・key_id・observed_at・expires_at の記録（claim）を作りたいとき（checkClaim）。
• 読めない行・ほかの用途の行（SPF など）を、黙って捨てずに理由つき（ignored の reason）で残したいとき。
• 記録が期限の内かを、渡した時刻（at）で確かめたいとき（isClaimCurrent。外なら reason は NOT_YET_OBSERVED か EXPIRED）。
• 記録から、attestation の属性（domain:<domain> と purpose:<purpose> をこの順に 1 つずつ）を作りたいとき（claimToAttestationAttributes）。
• 時計・乱数・外の接続を持たない、決定的な処理として手元で呼びたいとき。目的の表は部品の中に持たず、呼ぶ側が allowed_purposes で渡します。

使わない場面

• 印がそのドメインから来たこと（DNS の名前・DNSSEC・HTTPS の証明書・リダイレクト）を確かめたいとき。この部品は、渡された答えがそのドメインのものだとして読みます。照会とその検めは、照会の部品（A-09 の案）と呼ぶ側の役目です。
• ドメインの持ち主の本人性（個人・組織の実在）を確かめたいとき。この部品が読むのは、ドメインを管理していることの印だけです。
• 大文字・末尾の点・前後の空白を含むドメインや IP アドレスを、直して受け取ってほしいとき。名前は直さずに INVALID_DOMAIN で断ります。
• 国際化ドメインを Unicode の形で渡したいとき。xn-- の形だけを受け取り、punycode の中身は確かめません。
• 有効期間を 90 日より長くしたいとき。valid_days は 1〜90 の整数だけで、外れると INVALID_VALID_DAYS で止めます。
• Node.js v24.21.0 のほかの版で使うとき。ほかの版は確かめていません（NOT_VERIFIED）。

検査すること

• DNS TXT の行は、最初の欄がちょうど決まった版の名前（`v=kokoroamu-org1`）で、残りが purpose=<目的> と key=<鍵 ID> を 1 つずつのときだけ印として読みます。知らない欄・重なる欄・空の欄・欠けた欄・知らない版の行は読まず、ignored に理由（UNKNOWN_FIELD・DUPLICATE_FIELD・MISSING_FIELD・UNKNOWN_VERSION・MALFORMED_MARK など）を付けて返します。
• 4096 文字を超える行は TOO_LONG、UTF-8 でない行（{ undecodable_base64 } の形）は復号せずに NOT_UTF8、文字列でない行は NOT_TEXT として ignored に入れます。txt_records が配列でない・64 個を超えるときは INVALID_RECORDS・TOO_MANY_RECORDS で止めます。
• well-known の本文は、content_type が application/json・text/plain（任意で ; charset=utf-8）でないとき UNSUPPORTED_CONTENT_TYPE、body_base64 が正準の base64 でない・復号して 64 KiB を超えるとき INVALID_BODY で止めます。UTF-8 でない・JSON でない・文書の形が違う・entries が 1000 個を超える本文は、NOT_UTF8・NOT_JSON・MALFORMED_DOCUMENT・TOO_MANY_ENTRIES の事実で返します。
• purpose が allowed_purposes に無いときは matched: false で、reasons に PURPOSE_NOT_ALLOWED を記します。同じ鍵 ID でも、ほかの目的の印では通さず KEY_UNDER_OTHER_PURPOSE を記します。
• 目的と鍵 ID は文字列の完全一致で比べます。鍵 ID は大文字と小文字を区別し、Unicode の正規化・大文字小文字の畳み込みはしません。
• domain・purpose・key_id・allowed_purposes・observed_at・valid_days・marks の形が違うとき、INVALID_DOMAIN・INVALID_PURPOSE・INVALID_KEY_ID・INVALID_ALLOWED_PURPOSES・INVALID_OBSERVED_AT・INVALID_VALID_DAYS・INVALID_MARKS で止めます。ドメインは 242 文字まで、時刻は UTC の Z の形で 2000〜9998 年、marks は 2000 個までです。
• isClaimCurrent・claimToAttestationAttributes に渡す claim の形が違うとき（余分なキー・期限が observed_at より後でない・90 日を超える）、INVALID_CLAIM で止めます。at の形が違うときは INVALID_AT です。claimToAttestationAttributes だけは OrgDomainClaimError を投げます。
• 入力がオブジェクトでないとき INVALID_INPUT、source が DNS_TXT・HTTPS_WELL_KNOWN のどちらでもないとき UNKNOWN_SOURCE で止めます。止めたときは { ok: false, errors: [{ code }] } を返します。

しないこと・既知の限界

• matched: true は、渡された答えの中にこの目的とこの鍵 ID の印があったという事実だけです。ドメインの持ち主の本人性、印がそのドメインから来たこと、attestation に署名してよいことは示しません。署名するかは呼ぶ側が決めます。
• DNS・HTTPS の照会はしません。外の境界・状態・乱数を持たず、時計も読みません（時刻はすべて入力）。
• 目的の表は持ちません。どの目的を許すか（allowed_purposes）は呼ぶ側が渡します。
• JSON の重なるキーは JSON.parse のとおり最後の値を使い、重なりを見つけて断ることはしません。
• { undecodable_base64 } の値は復号しません。正準の base64 か・本当に UTF-8 でないかは確かめず（受け取りの側で検めること）、その形の行を印として読みません。
• 記録（claim）ができたことは、承認ではありません（result_is_approval: false）。権限も作りません（derives_authority: false）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• DNS や HTTPS の照会の雛形ではありません。

つなぎ方

src/org-domain-claim.js の parseMarks・checkClaim・isClaimCurrent（投げない）と claimToAttestationAttributes（投げる）を呼びます。parseMarks は txt_records か body_base64・content_type を受け取り marks と ignored を返します。checkClaim は domain・purpose・key_id・allowed_purposes・marks・observed_at・valid_days を受け取り matched・reasons・claim を返します。答えの形は契約 org-domain-control/v1 に合わせています。副作用・状態・資格情報は無く、利用側が用意する port はありません。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

組織の確認の画面の裏で、照会の順と断る条件を決めておくための部品です。ほかの目的・ほかの鍵の印で通してしまうこと、別のドメイン・目的・鍵・確かめ方の答えを取り違えること、決められないのに「無い」と決めてしまうこと、期限の判断を自分で作ってしまうことを防ぎます。

使う場面

• 組織のドメインに、決めた目的と鍵 ID（16 桁の小文字 hex）の印があるかを、DNS を先に、次に HTTPS の順で 1 回の呼び出しで確かめたいとき。
• 照会してよい目的を設定の表（allowed_purposes、1〜64 個。今は `seat8`）に限り、表に無い目的では照会もしないようにしたいとき。
• 結果を MATCHED・NOT_FOUND・UNAVAILABLE の 3 つで受け取り、「両方が答えて一致が無い」と「決められなかった（後でやり直せる）」を分けて扱いたいとき。
• 印の期限の判断を、A-10 の isClaimCurrent に、照会の受け取りの後に読んだ時刻で任せたいとき（記録の有効日数は valid_days、1〜90）。
• MATCHED のとき、決めた照会の受け取りの request_id（receipt_ref）と照会を送る前の時刻（observed_at）を、後の記録に添えたいとき。

使わない場面

• MATCHED を、ドメインの管理権の判断・署名してよいことの根拠として使いたいとき。MATCHED は「この目的とこの鍵 ID の印が、照会の時点でこのドメインの DNS か well-known にあった」という事実だけです。
• 同じ端末・ドメインへの照会の回数の上限まで任せたいとき。回数の上限は呼ぶ側の規則と人の役目です。
• 答えない照会の port を直接つなぐとき。この部品は待ち時間を切らないので、check が終わりません（本物の A-09 のクライアントは limits.timeout_ms に 1 秒を足した時間で UNKNOWN を返します）。
• receipt_ref が指す受け取りを、再起動の後も引けることが要るとき。A-09 のクライアントの記録はプロセスの中だけで、再起動で消えます。呼ぶ側の記録に頼ります。
• attestation の属性まで作らせたいとき。A-10 の claimToAttestationAttributes は使いません。属性を作るのは呼ぶ側です。
• 本物の DNS・HTTPS で確かめた部品が要るとき。実の照会は 0 回です。
• Node.js v24.21.0 のほかの版で使うとき。ほかの版は確かめていません（NOT_VERIFIED）。

検査すること

• options が足りない・形が違うとき INVALID_OPTIONS で止めます。check の入力がオブジェクトでない・読めないとき INVALID_INPUT、domain が契約の DomainName（242 文字まで）でないとき INVALID_DOMAIN、purpose が表に無いとき PURPOSE_NOT_ALLOWED、key_id が 16 桁の小文字 hex でないとき INVALID_KEY_ID で断ります。断るときは照会 0 回・時計を読まず、state は null です。
• 時計が投げた・数でない・2000〜9998 年の外のとき、CLOCK_FAILED でそこで止めて UNAVAILABLE にします（それ以上照会しません）。
• A-09 の答えが REFUSED のとき LOOKUP_REFUSED、UNKNOWN のとき LOOKUP_UNKNOWN、RECEIPT_REJECTED か HALTED のとき LOOKUP_HALTED、DONE 以外（ALREADY_DONE を含む）のとき LOOKUP_NOT_DONE、下位の部品が例外を投げた・reject したとき PORT_FAILED で、MATCHED にしません。
• DONE でも、結果が聞いたドメイン・目的・鍵 ID・確かめ方を写していない・approval が false でない・result が無いとき、RESULT_MISMATCH で使いません。
• 照会が答えられなかったとき（TIMEOUT・FAILED・TLS_FAILED・REDIRECT_REFUSED・知らない状態）LOOKUP_FAILED にします。FAILED は理由（PRIVATE_ADDRESS・DNSSEC_BOGUS・CONTENT_TYPE_REFUSED など）によらず「答えられない」です。
• A-10 の parseMarks が印を読めないとき MARKS_UNREADABLE、checkClaim が真偽値の matched を返さない・聞いたものと違う claim を返すとき CLAIM_UNCHECKED、isClaimCurrent が current: true を返さないとき（NOT_YET_OBSERVED・EXPIRED など）CLAIM_NOT_CURRENT で、MATCHED にしません。
• 設定と目的の表は作るときに写し、A-10 へ渡す表も写します。後から options や表を書き換えられても、次の check は広がりません。

しないこと・既知の限界

• 組織のドメインの管理権の確かめの部品は継手ではありません。自分の Request/Receipt は無く、外への照会は、束ねた A-09 の継手が自分の契約（org-domain-control/v1）で行います。この部品自身は外へ触れず、照会も読むだけです（side effect NONE）。
• 照会の検め（受け取りの照合・転送・TLS・DNSSEC・つないだアドレス・content type）は A-09 の側に、印の読み取り・照合・期限は A-10 の側に残ります。印がそのドメインから来たことは A-09 と port の役目で、この部品は A-09 の DONE を信じます。
• MATCHED は、管理権の判断でも、権限でも承認でもありません（approval: false・authority: NOT_DERIVED、derives_authority: false）。
• 受け取りの queried_at（port の申告）と時計の食い違いは照らしません。照会の待ち時間も、この部品は切りません。
• 本物の DNS・HTTPS には一度も照会していません。試験とファズは代役で、結線の検めは本物の A-09・A-10 のコードと、A-09 の試験用の代役の port を相手に確かめました。
• 目的の表の置き場所と、今の目的のほかの名前は、この部品では決めていません（契約の残り）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 特定の DNS サービス・HTTP クライアントの使い方の雛形ではありません。

つなぎ方

src/org-domain-check.js の createOrgDomainCheck(options) で作り、{ ok, errors, instance } を返します。options は allowed_purposes・contract_schema_digest・resolver_profile_ref・limits・valid_days・request_prefix・clock・ports です。check は { ok, errors, state, method, observed_at, receipt_ref, approval: false, … } を返します。port は domainControl.submit（A-09 の継手のクライアント）と A-10 の parseMarks・checkClaim・isClaimCurrent。資格情報は不要です。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

成果物や記録に電子署名するとき、任意のバイト列に署名してしまうこと、採択していない形式や context に署名してしまうこと、署名の順番（sequence）や前とのつながり（previous_hash）が崩れたまま署名してしまうことを防ぎます。署名 API を、任意の入力を受けない fail-closed の部品にするための検めです。

使う場面

• 成果物・記録への電子署名を、採択した schema・context と正準化した payload に限って行いたいとき。
• 署名を context ごとの追記専用（append-only）の鎖（sequence の単調増加と previous_hash の連鎖）に並べたいとき。
• 返ってきた署名を、公開鍵を都度取りに行かず、pin した PEM でその場で検証してから使いたいとき。
• Cloud KMS の AsymmetricSign（EC_SIGN_P256_SHA256）を、JSON 鍵を置かない認証（attached SA / ADC）と鍵単位の最小権限で使う構成にしたいとき。

使わない場面

• 任意のバイト列やファイルにそのまま署名したいとき。canonical_payload は RFC 8785 で正準化した文字列に限り、任意の payload は拒否します。
• 正準化もこの継手にまかせたいとき。RFC 8785 の正準化は呼び出し側が行います。
• 実際の Cloud KMS・Firestore につないだ状態で試験済みの部品がほしいとき。この部品の試験は、ローカルの P-256 鍵と in-memory の store で行っており、本番の Cloud KMS・Firestore への接続は確かめていません。
• 署名を、承認や決裁として扱いたいとき。この継手は検めて署名を継ぐだけで、権限は与えません。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは融合核（Kernel）が担います。

検査すること

• schema と context を検めます。採択していない schema・context、誤った context（wrong-context）は、KMS を呼ばず 422 で拒否します。
• sequence を検めます。巻き戻し・重複・整数でない sequence は、KMS を呼ばず拒否します。
• previous_hash を検めます。直前の payload の SHA-256（または GENESIS）とつながらないもの、genesis の規則違反（approval の genesis が定まっていない場合を含む）は拒否します。
• payload を検めます。canonical_payload が無いもの、任意の payload は拒否します。
• payload の中身を依頼と照らします。payload の context・schema_version が依頼と同じときだけ署名し、違う payload には署名しません。
• 知らない鍵の指定は 400 で拒否します。鍵は erabazu_publisher か approval_checkpoint です。
• 署名を検証します。KMS が返した署名を pin した公開鍵（PEM）で検証できなければ、署名を返さず 500 とします。

しないこと・既知の限界

• この部品の試験（単体試験とファズ）では、本番の Cloud KMS・Firestore には接続していません。試験はローカルの P-256 鍵と in-memory の store で行いました。別に、2026-08-15 に本番の ERABAZU HSM 鍵で synthetic の context（erabazu.synthetic-test）に署名し、pin した PEM で検証できた記録があります。
• canonical_payload の正準化（RFC 8785）はしません。呼び出し側が行います。
• 任意の入力には署名しません。context・schema・正準化した payload に限ります。
• GET /latest が返す次の sequence・previous_hash は目安（ヒント）です。署名の可否は POST /sign の検めで決まります。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 署名 API の使い方の雛形ではありません。

つなぎ方

POST /sign に { key, context, schema_version, sequence, previous_hash, canonical_payload } を渡すと、200（signature_der_base64（ECDSA DER）・payload_sha256・verified_with_pinned_pem: true など）、400（知らない鍵）、422（fail-closed、reasons 付き）、500（pin した鍵で検証できない。署名なし）のどれかを返します。入口は src/server.js（handleSign）、設定は app_kms_config.json。利用側が用意するもの: signer の port（本番は Cloud KMS）と store の port（getLatest・commit。本番は Firestore）。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

受領物が「本物か」を誰も確かめない、という困りごとに対して、出所・完全性を手元で検証します。そのとき、要求が持ち込んだ鍵で照合してしまうこと、alg を取り違えること、秘密鍵の JWK を pinned に入れた設定の誤り、Node.js の取り込みが受け取ってしまう正準でない符号化を、先に止めます。

使う場面

• 受け取った bytes の署名を、使う側が決めて固定した（pinned）公開鍵だけで検証したいとき。
• alg が Ed25519（RFC 8032 の R||S）か ES256（P-256 の ECDSA・SHA-256、署名は IEEE P1363 の r||s の 64 bytes）の署名を検証したいとき。
• 例外を投げない検証が要るとき。verify は { ok, errors } を返し、例外を投げず、入力を書き換えません。
• JSON の値の署名を検証したいとき。I-08 の部品で正準の bytes にしてから、この部品に渡します。
• 時計・乱数・環境の locale に左右されず、外の境界・状態を持たない処理として、手元で呼びたいとき。依存パッケージはありません。

使わない場面

• 署名者が誰か（身元）を確かめたいとき。署名が正しいことは、pinned の鍵の持ち主がこの bytes に署名したことだけを示します。
• どの鍵を pin するか・鍵の更新と失効・key_id の割り当てを任せたいとき。これらはこの部品の外（使う側・trust の管理）で決めます。
• 署名の bytes を一意の識別子に使いたいとき。ES256 の署名は malleable（(r, n - s) も正しい）で、low-S を強制しません。
• Ed25519・ES256 のほかの alg（EdDSA・ES384・RS256・none など）や、DER の形の ES256 署名、事前にハッシュした値を検証したいとき。
• JWS の全体（ヘッダー・payload の組み立て・base64url の区切り）を扱いたいとき。この部品は署名の bytes の検証だけを受け持ちます。
• Ed25519 の厳密さ（小さい位数の点・正準でない点・RFC 8032 と ZIP-215 などの違い）を自分の決まりで揃えたいとき。OpenSSL の実装に従い、小さい位数の点の公開鍵も断りません。
• Node.js v24.21.0 のほかの版（OpenSSL の版の違いを含む）で使うとき。ほかの版は確かめていません（NOT_VERIFIED）。

検査すること

• 要求が素のオブジェクトでないとき NOT_A_REQUEST、alg・key_id・signature・bytes のほかのフィールド（鍵を持ち込む public_key_jwk・seed など）を持つとき UNKNOWN_FIELD で止めます。
• alg が "Ed25519" でも "ES256" でもないとき（大文字小文字の違い・none を含む）UNSUPPORTED_ALGORITHM、key_id が 1〜256 文字の文字列でないとき INVALID_KEY_ID で止めます。
• signature が正準の base64url でないとき（パディング・標準の base64 の文字・空白・余りの bit）MALFORMED_SIGNATURE、読むと 64 bytes でないとき（DER を含む）INVALID_SIGNATURE_LENGTH で止めます。
• bytes が Uint8Array でないとき（文字列・ほかの型付き配列・DataView・Proxy）、NOT_BYTES で止めます。
• pinned が素のオブジェクトでないとき INVALID_PINNED_SET、pinned のどこか（列挙しない項目を含む）に秘密のメンバーを持つ JWK があるとき、どの key_id でも PRIVATE_KEY_REFUSED で止めます。
• key_id が pinned の自分のメンバーに無いとき（__proto__ などのプロトタイプの名前を含む）UNKNOWN_KEY、pinned の項目・JWK の形が違うか曲線の上に無い点のとき INVALID_PINNED_KEY で止めます。
• 要求の alg と pinned の alg が違うとき ALG_MISMATCH、bytes・署名・鍵のどれかが違うとき（Ed25519 の S + L を含む）SIGNATURE_INVALID を返します。
• 入力を調べること自体が例外になるとき（getter・Proxy の罠など）、INSPECTION_FAILED を返し、例外を投げません。入力は一度だけ読み、取り込みにはこの関数が作り直した JWK を渡します。

しないこと・既知の限界

• 鍵の配布・pin の決定・更新と失効（trust の管理）、JWS・manifest の組み立ては含みません。
• 署名の作成はしません。秘密鍵を扱うのは KMS などの継手で、この部品は秘密のメンバーを持つ JWK を受け取りません。
• 楕円曲線の計算は Node.js の crypto（OpenSSL）に任せ、独立には確かめていません。ファズのオラクルも同じ crypto を別の取り込み方で呼ぶだけです。
• RFC 8032 の例は 1 つ（例 1）だけで確かめ、ES256 は公開の既知の答えの代わりに、実行時に作った鍵の署名で確かめました。
• 署名が正しいことは、署名者の身元・法的な受け入れ・権限・承認ではありません（result_is_approval: false）。権限も作りません（derives_authority: false）。
• ほかの部品・継手の中の署名の検証との互換は確かめていません。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 特定の署名のライブラリの使い方の雛形ではありません。

つなぎ方

src/signature-verify.js の verify(request, pinned) を呼びます（投げません）。受け取るのは、alg・key_id・signature・bytes（Uint8Array）だけの素のオブジェクト request と、key_id → { alg, public_key_jwk }（公開の JWK だけ）の素のオブジェクト pinned です。返すのは { ok: true, errors: [] } か { ok: false, errors: [{ code }] }（code は error_taxonomy）。鍵は pinned で受け取り、取りに行きません。副作用（NONE）・状態・外の接続・資格情報は無く、利用側が用意するものはありません。依存は Node.js の組み込みの crypto と util だけです。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

「暗号化されているはず」の裏で、平文の DEK が部品の結果や状態に残ること、包んだ鍵の参照や KMS の鍵の合わない封筒を KMS に送ってしまうこと、暗号化の文脈が違う封筒・改ざんされた封筒・違う aad の封筒を開いてしまうことを防ぎます。

使う場面

• データ（plaintext、Uint8Array）を、KMS で作らせた DEK で封筒にしたいとき（encrypt）。ports.kms に kms-envelope の継手のクライアント、ports.seal・open に envelope-encrypt の Primitive を注入します。
• 平文の DEK を、KMS の port の外に出さずに使いたいとき。port の中の keyAccess.withDataKey(handle, fn) が DEK を fn に渡し、この部品は fn の外へ DEK を出しません。
• 暗号化の文脈を object_ref と context_digest（64 桁の 16 進）に結び付け、違う文脈の封筒を開かないようにしたいとき。
• 封筒・包んだ鍵（wrapped_key）・暗号化の文脈の digest をまとめて保管し、decrypt で開きたいとき。開く前に、封筒の key_ref と包んだ鍵の参照、KMS の鍵が合うかを確かめます。

使わない場面

• 暗号化できた・開けたことを、データを使ってよいこと・権限・承認として使いたいとき。暗号化はアクセス制御ではなく、どの結果にも approval: false・authorization: NOT_DERIVED が付きます。
• 包んだ鍵・封筒の保管や鍵の回転も任せたいとき。保管は呼び出し側、鍵の回転は B-05 の継手の役目です。
• DEK がメモリーから確実に消えることを当てにしたいとき。DEK を port の中に閉じ込めること・ゼロで消すことは port の役目で、確かめていません。
• 同じ入力から同じ封筒を作りたいとき。IV は Primitive が乱数で作るので、封筒は毎回違います。
• 16 MiB を超える平文、64 KiB を超える aad を扱うとき。上限は Primitive のままです。
• 本物の KMS で確かめた部品が要るとき。本物の KMS には一度も接続していません。
• Node.js v24.21.0 のほかの版で使うとき。ほかの版は確かめていません（NOT_VERIFIED）。

検査すること

• options が足りない・形が違う・参照が不正・port の関数が無いとき INVALID_OPTIONS、入力の形が違うとき（bytes でない・context_digest が 64 桁の 16 進でない・wrapped_key の形など）INVALID_INPUT、getter が例外を投げたとき INSPECTION_FAILED で止めます。
• 封筒の key_ref と包んだ鍵の参照、または包んだ鍵の KMS の鍵と自分の kms_key_ref が合わないとき、KMS に送らずに WRAPPED_KEY_MISMATCH で止めます。
• 暗号化の文脈が違うとき、KMS が見つければ CONTEXT_MISMATCH、継手が自分の記録から見つければ送らずに KMS_REFUSED で、開きません。
• 封筒が改ざんされた・aad が違うなど Primitive の open が ok: true を返さないとき OPEN_REFUSED（認証の失敗を含む）、seal が ok: true を返さないとき SEAL_REFUSED で止めます。
• KMS の継手の結果が分からないとき KMS_UNKNOWN、送らなかったとき KMS_REFUSED、receipt を照合できず停止した・GENERATED に包んだ鍵の参照や版が無いとき KMS_HALTED、DENIED・KEY_DISABLED・FAILED など望んだ状態でないとき KMS_DENIED で止めます。
• handle が無い・継手が使えると true ちょうどで答えないとき HANDLE_NOT_USABLE、withDataKey が投げた・結果を返さない・32 bytes の DEK を渡さないとき KEY_ACCESS_FAILED で止めます。
• timestamp が date-time の文字列を返さない・投げたとき CLOCK_FAILED、前の操作が終わっていないとき BUSY で止めます（同時に 1 つの操作だけ）。
• 開いた平文がその封筒を作った平文と同じであること、何かが違うのに開いた回が 0 であることを、別に書いた手本と突き合わせるファズで毎回確かめました（不一致と fail-open は 0）。

しないこと・既知の限界

• 保管時暗号（envelope）の部品は継手ではありません。自分の Request/Receipt は無く、KMS とのやり取りは束ねた kms-envelope の継手が自分の契約（kms-envelope/v1）で行います。その要求はどれも intended_side_effect NONE で、この部品自身は外へ触れません。
• 束ねた部品の意味（包めた・開けた ≠ 使ってよい）は、それぞれの部品の側に残ります。
• 暗号化できた・開けたことは、承認でも権限でもありません（approval: false・authorization: NOT_DERIVED・plaintext_key_material: NOT_TRANSPORTED、derives_authority: false）。
• DEK も handle も持ち続けず、結果に鍵の中身は入りません。状態は通し番号だけで、再起動で消えます。
• 包んだ鍵・封筒の保管、鍵の回転（B-05）、データを使ってよいかの判断はしません。DEK を port の中に閉じ込めること・期限やプロセスの終わりにゼロで消すことは port の役目で、確かめていません。
• 本物の KMS には一度も接続していません。単体試験とファズは代役で、本物の 2 部品のコードとの結線は、DEK を中に持つ port の代役を相手に確かめました。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 特定の KMS の使い方の雛形ではありません。

つなぎ方

src/envelope-encryption.js の createEnvelopeEncryption(options) で作ります。受け取るのは kms_key_ref・request_prefix・ports・任意の timestamp で、{ ok, errors, instance } を返します。encrypt は envelope・wrapped_key・encryption_context_digest を、decrypt は plaintext を返し、どの結果にも approval: false が付きます。利用側が用意する port は kms（kms-envelope の継手のクライアント）、keyAccess.withDataKey、seal・open（envelope-encrypt）です。副作用は NONE で、資格情報は port が持ちます。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

「鍵マークだけ見て終わり」という困りごとに対して、TLS の構成そのものを版つきの規則で検めます。TLS 1.0/1.1・SSL、弱い cipher、相手の証明書やホスト名を確かめない設定、証明書や鍵の中身（PEM・base64 の塊）の混入を、黙って通しません。

使う場面

• TLS の構成（min_version・max_version・ciphers_tls12・reject_unauthorized・verify_hostname・ca_refs・client_auth・alpn）を、使う前に規則 R1〜R10 で検めたいとき。
• TLS 1.2 を許す構成で、cipher を ECDHE の AEAD 6 つの名前の一覧（allowlist）だけに限りたいとき。
• mTLS のサーバー側の設定として、相手の証明書を求めるとき（client_auth.required が true）に、信頼の起点の参照（client_auth.ca_refs）が揃っているかを検めたいとき。
• 違反を 1 つずつでなく、すべて決まった順（R1 → … → R10）で、コードと位置（JSON Pointer）付きで受け取りたいとき。
• 時計・乱数・環境の locale・外の状態に左右されず、外の境界を持たない処理として手元で呼びたいとき。verify は例外を投げず、入力を書き換えません。

使わない場面

• 経路の暗号化・相互認証そのもの（TLS の接続）をしてほしいとき。この部品は構成を検めるだけで、接続しません。
• 証明書そのもの（期限・鍵の長さ・署名のアルゴリズム・鎖）、失効（CRL・OCSP）、相手の名前の一致を確かめたいとき。
• 証明書の発行・更新や、構成をサーバー・ロードバランサー・クラウドの設定に当てはめることを求めるとき。発行・更新は B-09、当てはめは継手の側に残ります。
• OpenSSL の cipher 文字列（: で区切る・! で除く・HIGH などのまとまり）をそのまま検めたいとき。受け取るのは cipher の名前の配列だけです。
• TLS 1.3 の cipher suite・鍵交換のグループ（曲線）・署名のアルゴリズム・セッションの再開・0-RTT を決めたいとき。profile では決めていません。
• Node.js v24.21.0 のほかの版で使うとき。ほかの版は確かめていません（NOT_VERIFIED）。

検査すること

• 構成が素のオブジェクトでないとき NOT_A_CONFIG、決めていないキー（__proto__ を含む）があるとき UNKNOWN_KEY、必須のキーが無いとき（値が undefined を含む）MISSING_KEY で止めます。
• SSLv2・SSLv3・TLSv1・TLSv1.1 のとき VERSION_TOO_OLD、ほかの正しくない版の値のとき INVALID_VERSION、max_version が min_version より下のとき VERSION_RANGE_INVERTED で止めます。
• TLS 1.2 を許すのに ciphers_tls12 が無いとき CIPHERS_REQUIRED、空の配列や cipher 文字列のとき INVALID_CIPHER_LIST で止めます。
• 許した 6 つのほかの cipher（CBC・RC4・3DES・NULL・anon・export・静的 RSA・DHE・TLS 1.3 の名前・大文字小文字や空白の違い・配列の穴）のとき、CIPHER_NOT_ALLOWED で止めます。
• reject_unauthorized が true でないとき REJECT_UNAUTHORIZED_REQUIRED、verify_hostname が true でないとき VERIFY_HOSTNAME_REQUIRED で止めます（"true"・1 も違反です）。
• ca_refs が空のとき INVALID_CA_REFS、参照に PEM の印があるとき CA_REF_LOOKS_LIKE_PEM、128 文字超えや + = 改行を含むとき CA_REF_LOOKS_LIKE_BLOB、決めた文字の並びでないとき INVALID_CA_REF で止めます。
• client_auth の形が違うとき INVALID_CLIENT_AUTH、required が true なのに client_auth.ca_refs が無いか空のとき CLIENT_CA_REFS_REQUIRED、alpn が空のとき INVALID_ALPN、id が表示できる ASCII でないとき INVALID_ALPN_ID で止めます。
• 値を調べること自体が例外になるとき（Proxy の罠・例外を投げる getter）、INSPECTION_FAILED を返し、例外を投げません。getter は値ごとに 1 回だけ読み、その写しで検めます。

しないこと・既知の限界

• 経路の暗号化・相互認証を名前に持つ項目ですが、この部品は TLS の構成を検めるだけで、TLS の接続・証明書の読み込みは含みません。構成が規則に合うことは、接続を確かめたことではありません。
• 証明書そのもの（期限・鍵の長さ・署名のアルゴリズム・鎖）、失効（CRL・OCSP）、相手の名前の一致は確かめません。
• 実行環境（Node.js・OpenSSL・ロードバランサーなど）がこの構成を本当に守るか、名前の書き方を受け取るかは確かめていません（tls に渡していません）。
• ca_refs の参照が何を指すか・解決できるかは確かめません。見た目の検めなので、128 文字以内で決めた文字の並びに合う文字列は参照として受け取ります。
• 許す cipher の一覧は 2026-09-30 の判断です。後で弱くなった場合は profile の版を上げて直します。
• 構成が規則に合うことは、受け入れてよいことではありません（result_is_approval: false）。権限も作りません（derives_authority: false）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 特定のサーバーやクラウドの TLS 設定の雛形ではありません。

つなぎ方

src/tls-config.js の verify(config) を呼びます（投げません）。受け取るのは、min_version・max_version・ciphers_tls12・reject_unauthorized・verify_hostname・ca_refs・client_auth・alpn の 8 つのキーだけの素のオブジェクトです。返すのは { ok: true, errors: [] } か { ok: false, errors: [{ code, path }, ...] }（code は error_taxonomy、path は JSON Pointer。違反は規則の順にすべて並ぶ）。実際の設定の文字列にするのは使う側です。副作用（NONE）・状態・外の接続・資格情報は無く、利用側が用意するものはありません。依存は Node.js の組み込みだけです。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

鍵の版の無効化や破棄の予約を、人・組織の権限の証拠なしに送ってしまうこと、ENABLED でない版を primary にしてしまうこと、短すぎる猶予で破棄を予約してしまうこと、そして鍵の操作が通ったことを鍵を使う許可と取り違えることを防ぎます。

使う場面

• 外の KMS・HSM で鍵を作り、新しい版を作って（回転）primary を替える操作を、契約どおりに検めてから運びたいとき。
• 版の無効化と破棄の予約を、その鍵・版・op に結ばれた人・組織の権限の証拠を受け取ったときだけ送りたいとき。証拠は 1 回の変更で使い切ります。
• 破棄を、すぐにではなく猶予（1 日以上、設定の下限以上）を置いた予約としてだけ行い、CANCEL_DESTROY で DISABLED に戻せるようにしたいとき。
• primary にする版を、この継手が ENABLED と照合した版だけに限りたいとき。

使わない場面

• 鍵をすぐに破棄したいとき。すぐに破棄する op は契約にありません。
• 回転の方針（いつ回すか・何世代残すか）を検めたいとき。これは手元の Primitive の役目で、この継手には入っていません。rotation_policy_ref は運ぶだけです。
• 鍵を使って暗号化・署名したいとき。暗号化は KMS envelope の継手（B-03 では部品(Component) がこれを束ねます）、署名は B-01 KMS 署名の継手の役目です。
• 鍵の中身（公開鍵を含む）を受け渡したいとき。この継手は鍵の中身を運ばず、公開鍵も参照だけです。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。
• すぐに使える KMS・HSM への接続がほしいとき。実の KMS・HSM には一度も接続しておらず、port の実装・資格情報・設定の値は接続するときに別の関門で決めます。

検査すること

• 設定を検めます。設定が無い、一覧に無い KMS・鍵の仕様、下限（min_destroy_window_seconds）の無い破棄の予約、下限や 1 日より短い猶予は送りません。
• 権限の証拠を検めます。証拠の欄が無い、証拠を受け取っていない、出どころが違う（HUMAN・ORGANIZATION でないものを含む）、ほかの鍵・版・op の subject digest、使い切った証拠では、無効化・破棄の予約を送りません。
• primary の替え先を検めます。知らない版・ENABLED でない版、食い違う版の記録があれば SET_PRIMARY_VERSION を送りません。
• 参照と要求の形を検めます。ドライブ・..・制御文字・行区切り・空白や PEM を含む参照、Ref でない request_id、契約に無い op（DESTROY を含む）、op が使わない欄、op ごとの必須の欄の欠けは送りません。
• receipt を照合します。request_digest の偽り、別の request_id・KMS・鍵・版、op の食い違い、表の外の状態、効果を増やす・不明な効果、断ったのに効果がある receipt は受理せず、停止します（HALTED）。
• 鍵の中身・公開鍵そのものを載せた receipt、鍵を使う許可（authorization）を導いた receipt は受理しません。
• 破棄の時刻を検めます。猶予より手前・過去の破棄の時刻、時刻の無い予約、DESTROY_SCHEDULED でないのに時刻がある receipt、DISABLED に戻らない CANCEL_DESTROY は受理しません。
• 結果の分からない送信は同じ要求の再送（lookup）で解き、解けるまでほかは送りません。同じ request_id で別の中身の要求は送りません。

しないこと・既知の限界

• 権限の証拠を作りません。版の無効化と破棄の予約には、部品の外の人・組織の証拠が入力として要ります（HUMAN_OR_ORGANIZATION_EVIDENCE_FOR_KEY_DISABLE_AND_DESTROY）。証拠の中身（誰が出したか・期限・本物か）も読みません。
• 鍵の操作が通っても、鍵を使う許可でも業務の承認でもありません（authorization は NOT_DERIVED、approval: false）。
• 鍵の中身を保管しません。この継手は鍵の操作の要求を運ぶ継手で、鍵の中身は運ばず・持たず、回転の方針を決める機能も含みません。
• KMS 側の破棄の猶予が要求より短いか、予約どおりに破棄されたか、取り消しが効いたかは、KMS の答え（DESCRIBE）でしか知りません。
• 参照の欄が鍵の中身でないことは、形でしか確かめられません。短い符号化された鍵の文字列を参照と見分けることはできません。
• 版の状態の記録はこの継手の中だけにあり、再起動で消えます。ほかの者が KMS で版の状態を変えると記録は古くなります。資格情報は port 側が持ちます（HELD_BY_PORT）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。契約も変えません（schema authority は NOT_SPECIFIED）。
• 特定のクラウド KMS・HSM の鍵管理 API の使い方の雛形ではありません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/key-lifecycle/v1 でつなぎます。createKeyLifecycleClient({ cfg, port }) の submit(request) に KeyLifecycleRequest を渡すと、DONE・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED を返します（どれも approval: false）。無効化・破棄の予約の前に recordAuthorityEvidence で証拠を渡します。利用側が用意するもの: KMS・HSM への port（submit、任意で lookup）。副作用: 破棄の予約は EXTERNAL_IRREVERSIBLE、DESCRIBE は NONE、ほかは EXTERNAL_REVERSIBLE。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

契約や検査で「いつ存在したか」を示すとき、別のハッシュに差し替えられた時刻トークン、使い回し（リプレイ）されたトークン、pin していない TSA のトークン、ずれや精度が大きすぎる時刻を、そのまま信じてしまうことを防ぎます。返ってきた時刻を検めてから来歴へ継ぐための検めです。

使う場面

• TSA から受け取った時刻トークンが、こちらの送ったハッシュ（message_imprint）と nonce に一致するかを必ず確かめたいとき。
• 使う TSA を pin し、時刻のずれ（max_skew_seconds）と精度（max_accuracy_seconds）の上限を決めて検めたいとき。
• トークンの欄の署名を、pin した公開鍵（PEM）で検証したいとき（署名は DER 形式・sha256）。
• 「いつ存在したか」を来歴の核（provenance-facts）へ継ぎたいとき。

使わない場面

• TSA が返す RFC 3161 の DER（ASN.1）形式のトークンを、そのまま渡して検めたいとき。この継手は DER を解析しません。トークンは 6 つの欄を取り出した形で渡す必要があり、署名の検証の対象も、その 6 つの欄の JSON です。
• TSA へのタイムスタンプの依頼や、TSA の証明書の取得・pin までまかせたいとき。TSA への通信は含みません（port は無し）。
• 時刻トークンを発行したいとき。src/tsa.js の signToken は試験用の TSA の代役で、本物の TSA ではありません。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。

検査すること

• imprint を検めます。トークンの message_imprint が、こちらの送ったハッシュと一致しなければ（差し替え）信頼しません。
• nonce を検めます。こちらの nonce がそのまま返っていなければ（リプレイ）信頼しません。
• TSA を検めます。pin していない TSA（tsa_id）のトークンは信頼しません。
• 時刻を検めます。基準の時刻とのずれが上限を超えるもの、精度（accuracy_seconds）が上限を超えるもの、gen_time が整数でないものは信頼しません。
• ハッシュのアルゴリズムを検めます。採択していないアルゴリズムは信頼しません。
• 署名を検めます。verifyToken は、渡された signature_valid が真でなければ信頼しません。verifyTokenSignature は、改ざんされたトークンや別の鍵の署名を、pin した公開鍵で検証できないものとして偽を返します。

しないこと・既知の限界

• RFC 3161 の DER（ASN.1）形式の解析はしません。署名の対象は、トークンの 6 つの欄（message_imprint・hash_algo・tsa_id・nonce・gen_time・accuracy_seconds）の JSON です。
• 実 TSA への通信と、TSA の証明書の取得・pin はしません。配備のときに決めます。
• verifyToken は署名そのものを検証しません。signature_valid（真偽値）を受け取って判定します。署名の検証は verifyTokenSignature で別に行います。
• 試験では ECDSA P-256 の鍵と試験用の TSA の代役（signToken）を使っています。実 TSA は叩いていません。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• TSA API の使い方の雛形ではありません。

つなぎ方

src/guards.js の verifyToken(cfg, request, token, refTime) に、request { hash, nonce, hash_algo }、token { message_imprint, hash_algo, tsa_id, nonce, gen_time, accuracy_seconds, signature_valid }、基準の時刻（秒）を渡すと { ok, errors } を返します。src/tsa.js の verifyTokenSignature(pinnedPubPem, fields, derSignature) は 6 つの欄の署名を検証し真偽値を返します。含まないもの: RFC 3161 の DER の解析、TSA への通信、TSA の証明書の取得と pin（配備のときに決めます）。port は無し。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

provenance・reconcile の土台として内容から一意の指紋を作り、照合するときに、bytes と文字列を取り違えること、形の違う digest や別のアルゴリズムを受け取ってしまうこと、domain・target を取り違えて照合してしまうことを防ぎます。

使う場面

• bytes から sha256（小文字 64 桁の hex）や内容アドレス（sha256:<hex>）を作りたいとき。
• 契約で使う型つきの digest（{ domain, algorithm: "sha256", value, target }）を作り、照合したいとき。domain と target は名札で、ハッシュには混ぜません。
• digest を bytes と照合するときに、期待した domain・target を渡して取り違えを止めたいとき。
• 例外を投げない照合が要るとき。verifyDigest と parseContentAddress は { ok, errors } を返し、例外を投げません。
• JSON の値の digest を取りたいとき。I-08 の部品で正準の bytes にしてから、この部品に渡します。
• 時計・乱数・環境の locale に左右されず、外の境界・状態を持たない処理として、手元で呼びたいとき。

使わない場面

• 文字列をそのまま渡したいとき。この部品は文字列を受け取りません（NOT_BYTES）。文字列は、使う側が決まった文字コード（UTF-8 など）で bytes にしてから渡します。
• digest の一致で、出どころを証明したいとき。一致は出どころの証明ではありません。署名の検証は B-02 です。
• sha256 のほかのアルゴリズムが要るとき。
• bytes の大きさの上限が要るとき。上限は持たず、大きさの上限は I-06 の部品か使う側で決めます。
• Node.js v24.21.0 のほかの版で使うとき。ほかの版は確かめていません（NOT_VERIFIED）。

検査すること

• bytes（Uint8Array）でないとき（文字列・数・配列・ArrayBuffer・ほかの型付き配列）、NOT_BYTES で止めます。
• domain の形が違うとき INVALID_DOMAIN、target が空・文字列でない・1024 文字を超えるとき INVALID_TARGET で止めます。
• digest が 4 つのキーだけのオブジェクトでないとき（キーの余り・欠け・digest が無い）、NOT_A_DIGEST で止めます。
• algorithm が sha256 でないとき UNSUPPORTED_ALGORITHM、value が小文字 64 桁の hex でないとき（大文字・長さ違い）MALFORMED_VALUE で止めます。
• bytes の sha256 が value と違うとき、定数時間の比較（crypto.timingSafeEqual）で VALUE_MISMATCH を返します。
• 期待した domain・target と違うとき DOMAIN_MISMATCH・TARGET_MISMATCH、expect がオブジェクトでないとき INVALID_EXPECTATION で止めます。
• 内容アドレスが sha256:<小文字 64 桁の hex> でないとき、MALFORMED_CONTENT_ADDRESS で止めます。

しないこと・既知の限界

• 文字列の bytes 化・JSON の正準化はしません。文字列は使う側が bytes にし、JSON の値は I-08 の部品で正準の bytes にしてから渡します。
• digest の一致は出どころの証明ではありません。署名の検証（B-02）や鍵の管理は含みません。
• digest が一致したことは、中身が正しいことでも、受け入れてよいことでもありません（result_is_approval: false）。権限も作りません（derives_authority: false）。
• sha256 のほかのアルゴリズムは扱いません。
• 継手の中にある digests.js の写し（19 個）を、まだこの部品に置き換えていません。bytes では写しの sha256hex と byte 単位で同じ値ですが、写しは文字列も受け取って UTF-8 としてハッシュし、この部品は bytes だけを受け取ります。置き換えは互換表を確かめた後の別の作業です。
• 要求の正準化＋sha256（requestDigestValue）と、どのフィールドを digest に入れるかは決めません。使う側（各継手・契約）に残ります。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 特定のハッシュのライブラリの使い方の雛形ではありません。

つなぎ方

src/digest.js の verifyDigest(digest, bytes, expect) を呼びます（投げません）。受け取るのは、4 つのキーだけの digest、bytes（Uint8Array。Buffer を含む）、任意の expect（{ domain, target }）です。返すのは { ok: true, errors: [] } か { ok: false, errors: [{ code }] }（code は error_taxonomy）。sha256Hex・digest・contentAddress は受け取れない値で DigestError を投げ、parseContentAddress は投げません。副作用（NONE）・状態・外の接続・資格情報は無く、利用側が用意するものはありません。依存は Node.js の組み込みの crypto だけです。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

「弱いと全部崩れる裏方」である乱数の作り方を固定します。出どころを OS の CSPRNG に固定して差し替えられないようにし、使う側の seed を受け取らず、長さ・符号化・範囲を検め、randomInt は x mod m の偏りを作らない棄却法で一様にします。出どころが失敗したときは値を作らずに止めます（fail-closed）。

使う場面

• OS の CSPRNG から、決まった長さ（1〜1024 bytes）の bytes を引きたいとき。
• nonce を小文字の hex か、パディングなしの base64url（RFC 4648 の URL と名前に安全な字母）の文字列で作りたいとき。
• 0 以上 max_exclusive 未満の整数を、1〜2^48 の範囲（2^48 を含む）で偏りなく作りたいとき。
• 使う側の seed が混じらないことを入口で守りたいとき。seed のフィールドは UNKNOWN_FIELD で断ります。
• 例外を投げない呼び方が要るとき。generate(request) は { ok, errors, value } を返し、例外を投げません。

使わない場面

• 乱数の質（予測できないこと・偏りのなさ）の確かめを求めるとき。この部品は確かめておらず、OS と Node.js の crypto.randomBytes に任せています。
• 用途に足りる長さの判断を任せたいとき。長さは使う側が決め、1 byte の nonce も受け取ります。
• 再現できる（決定的な）値が要るとき。値は呼ぶたびに OS の CSPRNG から引き、再現できません（設計どおり）。
• 1 回に 1024 bytes を超える bytes や、2^48 を超える範囲の整数、bigint・文字列の数を扱いたいとき。
• fork したプロセス・仮想マシンの複製などで使うとき。そこでの OS の CSPRNG の振る舞いは確かめていません。
• Node.js v24.21.0 のほかの版で使うとき。ほかの版は確かめていません（NOT_VERIFIED）。

検査すること

• 要求が素のオブジェクトでないとき（配列・Map・クラスのインスタンスなど）、NOT_A_REQUEST で止めます。
• kind が "bytes"・"nonce"・"int" のどれでもないとき（プロトタイプの名前を含む）UNKNOWN_KIND、決まったフィールドのほか（seed を含む）を持つとき UNKNOWN_FIELD で止めます。
• length・bytes が 1〜1024 の整数（number）でないとき（0・1024 超え・小数・文字列・bigint）、INVALID_LENGTH で止めます。
• encoding が "hex" でも "base64url" でもないとき INVALID_ENCODING、max_exclusive が 1〜2^48 の整数（number）でないとき INVALID_BOUND で止めます。
• 乱数の出どころが投げた・長さの違う値や bytes でない値を返したとき、または randomInt で 64 回続けて捨てたとき、値を作らず ENTROPY_UNAVAILABLE で止めます。
• 要求を調べること自体が例外になるとき（getter・Proxy の罠など）、generate は INSPECTION_FAILED を返します。フィールドは一度だけ読み、検めた値だけを使います。

しないこと・既知の限界

• 「予測不能な値の生成」を名前に持つ項目ですが、この部品は乱数の質（予測できないこと・偏りのなさ）を確かめていません。OS と Node.js の crypto.randomBytes に任せています。統計の試験は大きな偏りを見る煙の試験で、NIST SP 800-22 などの正式な統計試験ではありません。
• どの用途に何 bytes 使うか（nonce の一意性・トークンの強さ）は判断しません。使う側が決めます。
• 出どころの失敗（ENTROPY_UNAVAILABLE）は、差し替えた出どころで確かめました。実際の OS の CSPRNG を失敗させては確かめていません。
• 使う側の seed や、出どころを差し替える手段は受け取りません。公開の入口の module.exports は凍結してあり、内部の makeRandom は出していません。
• 値ができたことは、使う側の目的に長さが足りることでも、乱数の質が正式な試験で確かめられたことでもありません（result_is_approval: false）。権限も作りません（derives_authority: false）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 特定の乱数のライブラリの使い方の雛形ではありません。

つなぎ方

src/random.js の generate(request) を呼びます（投げません）。受け取るのは { kind: "bytes", length }・{ kind: "nonce", bytes, encoding }・{ kind: "int", max_exclusive } のどれかです。返すのは { ok: true, errors: [], value }（Buffer・文字列・整数）か { ok: false, errors: [{ code }] }（code は error_taxonomy）。randomBytes・nonce・randomInt は受け取れないとき RandomError を投げます。副作用（NONE）・状態・外の接続・資格情報は無く、利用側が用意するものはありません。依存は Node.js の組み込みの crypto と util だけです。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

取り消せない発行（FINALIZE）を、注文と名前の合わない CSR や、人・組織の根拠なしに依頼してしまうこと、そして名前や公開鍵の違う証明書を受け取ったまま使ってしまうことを防ぎます。発行は Certificate Transparency に公に記録されるため、送る前と受け取った後の両方で検めます。

使う場面

• TLS 証明書を ACME の認証局から取得し、更新（renewal_of_ref つきの新しい注文）するときの要求を、契約どおりに検めてから運びたいとき。
• 発行の依頼を、この directory・注文・CSR・名前の主体（authority_subject_digest）に結ばれた人・組織の根拠を受け取ったときだけ送りたいとき。
• CSR の名前が注文の名前とちょうど同じで、CSR の中身と公開鍵の sha256 が要求の digest と同じことを確かめてから発行を依頼したいとき。
• 取り出した証明書の名前と公開鍵を、連鎖を読み戻して注文・CSR と照合してから受け取りたいとき。

使わない場面

• 証明書を失効させたいとき。失効（REVOKE）は v1 の契約に無く、別の判断が要ります。
• challenge の応答（HTTP のファイル・DNS の記録）を置きたいとき。それは別の port の役目で、この継手は challenge の参照と digest を返すだけです。
• 更新の時期や期限切れを判断させたいとき。この継手は有効期間の形と前後を検めるだけで、その判断はしません。
• TLS の構成を検めたいとき。それは手元の Primitive（B-04）の役目です。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。
• すぐに使える認証局への接続がほしいとき。実の認証局には一度も接続しておらず、port の実装・account 鍵の結び付け（JWS の署名）・nonce・設定の値は接続するときに別の関門で決めます。

検査すること

• 設定を検めます。設定が無い・一覧が空、一覧に無い directory・account 鍵・名前、名前を覆わないワイルドカード、DNS でない・大文字・重なる・空・昇順でない名前の注文は送りません。
• 発行の根拠を検めます。根拠を受け取っていない、出どころが違う（HUMAN・ORGANIZATION でないものを含む）、別の注文・CSR・名前・名前の順に結ばれた根拠では、FINALIZE を送りません。
• CSR を検めます。CSR を読めない、中身や公開鍵の sha256 が digest と違う、名前の欠け・余り・違い、注文の外の CN、SAN や extensionRequest が二つある CSR では、FINALIZE を送りません。
• 注文の順番を検めます。知らない注文、directory や account 鍵の変わった注文、pending でない注文・challenge への知らせ、ready でない注文の FINALIZE、valid でない・この継手が FINALIZE していない注文の取り出しは送りません。
• 参照と要求の形を検めます。..・ドライブ・制御文字・行区切りを含む参照、空白を含む account 鍵の参照、account 鍵の秘密鍵の欄、REVOKE、ほかの op の欄、Ref でない request_id は送りません。
• receipt を照合します。request_digest の偽り、別の op・directory・注文、名前の所有や信頼を導いた receipt、効果を増やす・小さく言う・不明な効果、注文や challenge の状態の後戻りは受理せず、停止します（HALTED）。
• 証明書を照合します。leaf_names の欠け・余り・違い、CSR と違う公開鍵、連鎖を読み戻せない・sha256 が違う、有効期間の違い、名乗りと読み戻した leaf の食い違いがあれば、照合済みにしません。
• DER の読み取りで、最小でない長さ・高いタグ番号・後ろに余るバイトを受け付けません。

しないこと・既知の限界

• 発行の根拠を作りません。FINALIZE には、部品の外の人・組織の根拠が入力として要ります（HUMAN_OR_ORGANIZATION_EVIDENCE_FOR_CERTIFICATE_ISSUANCE）。根拠の記録が本当に人・組織から来たかも確かめません。
• 発行できた・取り出せたことは、名前の正当な所有でも信頼でもありません（name_ownership・trust_decision は NOT_DERIVED、approval: false）。ドメインを持っていることは確かめません。
• 証明書の自動の取得・更新を自分で回しません。この継手は ACME の要求を運ぶ継手で、更新の時期の判断、challenge の応答を置くこと、失効（REVOKE）の機能は含みません。
• CSR の自己署名と、証明書の署名・連鎖・失効・信頼は検めません。leaf は連鎖の先頭の証明書とみなします。
• CSR と証明書は、要る DER だけを読む小さな読み取りで、試験は手元で組み立てた P-256 の CSR と証明書だけです。実の認証局が出した証明書では確かめていません。認証局が公開鍵の書き方を変えると、同じ鍵でも照合済みになりません。
• 注文の状態と受け取った根拠はこの継手の中だけにあり、再起動で消えます。名前は小文字の ASCII だけを扱います。account 鍵などの資格情報は port 側が持ちます（HELD_BY_PORT）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。契約も変えません（schema authority は NOT_SPECIFIED）。
• 特定の認証局の ACME クライアントの雛形ではありません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/acme-certificate/v1 でつなぎます。createAcmeClient({ cfg, port }) の submit(request, csr) に AcmeRequest を渡すと（csr は FINALIZE のときだけ）、DONE・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED を返します（どれも approval: false）。FINALIZE の前に recordAuthorityEvidence で根拠を渡します。利用側が用意するもの: 認証局への port（submit・readChain、任意で lookup）。副作用: FINALIZE は EXTERNAL_IRREVERSIBLE。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

「束ねて署名した」の中身を、後から照らす土台になります。束ねた木の根に署名しておけば、ある葉が含まれていることを包含証明で部分的に確かめられ、追記した後の木が前の木を先頭に持つことを一貫性証明で確かめられます。葉と節の前置き（0x00・0x01）で、葉と節を取り違えた偽の葉を防ぎます。

使う場面

• bytes の葉の並びから、RFC 9162 の木の根（小文字 64 桁の hex）を作りたいとき（merkleRoot）。
• ある葉が根に含まれることを示す包含証明（audit_path）を作り、検めたいとき（inclusionProof・verifyInclusion）。
• 追記で大きくなる記録について、古い木が新しい木の先頭であることを示す一貫性証明を作り、検めたいとき（consistencyProof・verifyConsistency）。
• 照合の不一致（証明・葉・番号・根の取り違え、足りない・余る証明）を、例外ではなく verified: false で受け取りたいとき。
• 時計・乱数・外の接続を持たない、決定的な処理として手元で呼びたいとき。依存パッケージはありません。

使わない場面

• 透明性ログが要るとき。この部品は木を保存・追記せず、署名つきの木の頭（STH）・ログの監視・gossip・ログの ID を扱いません。
• 証明だけで大きいほうの木の大きさを決めたいとき。証明の通り道で形が同じ別の大きさでも true になることがあります。大きさと根は、署名された記録から取ってください。
• SHA-256 のほかのハッシュが要るとき、または 1,048,576 葉より大きな木・ログの証明を検めたいとき（BAD_SIZE）。
• old_size が 0 の一貫性や、大きさの同じ木（old_size = new_size）の一貫性を確かめたいとき。BAD_SIZE で止めます。同じ大きさなら、使う側が根を直接比べます。
• 奇数のときに右端を複製する形（Bitcoin 型）の木が要るとき。この部品は複製せず、右端をそのまま上の段へ上げます。
• 大きな木で証明を何度も作る使い方の速さが要るとき。証明を作るたびに渡された葉から木を作り直し（O(n)）、その速さは測っていません。葉の合計の bytes の上限も持たず、メモリーと時間は呼ぶ側の持ち分です。
• Node.js v24.21.0 のほかの版で使うとき。ほかの版は確かめていません（NOT_VERIFIED）。

検査すること

• leaves が配列でない、要素が bytes（Uint8Array）でない（穴・getter・ほかの型付き配列・ArrayBuffer・DataView・Proxy で包んだ bytes を含む）、引数がオブジェクトでないとき、NOT_BYTES_LIST で止めます。
• 葉が 1,048,576 個を超えるときは要素を読む前に TOO_MANY_LEAVES、葉 1 つが 64 MiB を超えるときはハッシュの前に LEAF_TOO_LARGE で止めます。
• index・leaf_index が整数でない・負・木の大きさ以上のとき、INDEX_OUT_OF_RANGE で止めます。verifyInclusion でも、照合の失敗ではなくエラーとする厳しいほうの読みです。
• tree_size が 1〜1,048,576 の整数でないとき、old_size・new_size が 0 < old_size < new_size ≤ 1,048,576 の整数でないとき、BAD_SIZE で止めます。
• root・old_root・new_root と証明の要素が小文字 64 桁の hex の文字列でないとき BAD_HEX、audit_path・proof が配列でないとき BAD_PROOF_SHAPE で止めます。
• 証明の要素の書き換え・抜け・追加・入れ替え、葉・番号・根の取り違えは通しません（verified: false）。作った証明は、同じ根と大きさで必ず true になります。
• 止めるときは、決まった順で最初に見つけた 1 つのコードだけを返します。getter を呼ばず、調べると例外になる値（Proxy の罠など）でも投げません。

しないこと・既知の限界

• 署名はしません（根への署名は B-12）。時刻の証明もしません（B-06）。根が誰のものか・いつのものかは言いません。
• verified: true は、SHA-256 の衝突が無い限り、渡された葉が渡された根と大きさの木に含まれる（または古い木が新しい木の先頭である）と言えるというだけです。根が正しいこと、中身が正しいこと、受け入れてよいことは示しません。
• 木・証明・記録を保存しません。呼び出しの間に状態を持たず、記録の保存と追記の管理は使う側（H-11 など）に残ります。
• 比較は定数時間ではありません（根と証明は秘密ではない前提）。強さは SHA-256 の衝突・原像の困難さに頼ります。
• certificate-transparency の試験の 1〜8 葉の根は試験に書き写した値で、元のファイルを取り寄せて照合してはいません（定義から手で組んだ値と一致することで確かめました）。
• 根・証明・照合の結果は、承認ではありません（result_is_approval: false）。権限も作りません（derives_authority: false）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 特定の透明性ログ（CT のログ・Trillian など）の雛形ではありません。

つなぎ方

src/merkle.js の merkleRoot・inclusionProof・verifyInclusion・consistencyProof・verifyConsistency を呼びます（どれも投げません）。引数は leaves・index・leaf・leaf_index・tree_size・audit_path・root・old_size・new_size・old_root・new_root・proof を持つオブジェクトで、葉は Uint8Array、根と証明の要素は小文字 64 桁の hex です。返すのは { ok: true, errors: [], ... } か { ok: false, errors: [{ code }] }。副作用・状態・外の接続・資格情報は無く、利用側が用意する port はありません。依存は Node.js の組み込みだけです。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

記録への署名の裏で、鍵をどう扱うかは見えません。この部品は、bytes・PEM・JWK などで秘密鍵を持ち回る使い方を断り、秘密鍵を KeyObject でだけ受け取ります。形の違う鍵・署名は決まったコードで止め、止めるときは署名を返しません。

使う場面

• 呼ぶ側が持つ Ed25519 の秘密鍵で、bytes（16 MiB まで）に署名したいとき（sign）。何に署名するか（Merkle 木の根や正準の bytes など）は使う側が決めます。
• どの鍵で署名したかを、公開鍵の SPKI DER の sha256（public_key_spki_sha256）で示したいとき（sign・publicKeyFingerprint）。
• 署名した直後に往復の確かめをしたいとき（verify。違えば verified: false で、エラーではない）。
• 同じ鍵と同じ message から、いつも同じ署名が要るとき（RFC 8032 の Ed25519 の pure。時計・乱数を使わない）。
• KMS・HSM を使わず、手元の鍵で署名したいとき。この部品は KMS・HSM・鍵の保管庫とは話しません。

使わない場面

• 使う側が pin した鍵で署名を検証したいとき。verify は往復の確かめで、その代わりではありません。pin した鍵での検証は B-02 です。
• 鍵の保管・入れ替え・失効や、HSM・KMS での署名が要るとき。この部品は扱いません。
• 秘密鍵を bytes・文字列・PEM・JWK・WebCrypto の CryptoKey で渡したいとき。KEY_NOT_KEYOBJECT で止めます。
• Ed25519 のほかの種類の鍵（EC・RSA・X25519・Ed448・共通鍵）で署名したいとき。KEY_TYPE_UNSUPPORTED で止めます。
• 16 MiB を超える message に署名したいとき。MESSAGE_TOO_LARGE で止めます。
• サイドチャネル（時間・電力）への強さが要るとき。確かめていません。
• Node.js v24.21.0 のほかの版で使うとき。ほかの版は確かめていません（NOT_VERIFIED）。

検査すること

• 引数が素のオブジェクトでない、または決まった欄のほかを持つとき、INVALID_ARGUMENT で止めます。引数を読むこと自体が例外になるとき（getter や Proxy の罠）は INSPECTION_FAILED です。
• message が Uint8Array でないとき NOT_BYTES、16 MiB を超えるとき MESSAGE_TOO_LARGE で止めます。
• 鍵が KeyObject でないとき（PEM・DER・JWK・bytes・CryptoKey・KeyObject を装ったもの・KeyObject の Proxy・欄が無い）、KEY_NOT_KEYOBJECT で止めます。
• KeyObject でも種類が違うとき（sign に公開鍵、verify に秘密鍵、共通鍵・EC・RSA・X25519・Ed448）、KEY_TYPE_UNSUPPORTED で止めます。
• key_id が Ref（印字できる ASCII の空白を除く 1〜200 文字、".." を含まず、/ と \ で始まらない）でないとき、INVALID_KEY_ID で止めます。
• signature が詰め物なしの正準の base64url で 64 bytes の文字列でないとき（詰め物・標準の base64・余りの bits が 0 でない・長さ違い）、INVALID_SIGNATURE で止めます。
• 署名の 1 bit の反転、S + L の署名、ほかの message・ほかの鍵の署名は verified: false になります。
• 引数の欄はそれぞれ一度だけ読み、getter が違う値を返しても、検めた値だけを使います。

しないこと・既知の限界

• 署名は「この秘密鍵を持つ誰かがこの bytes に署名した」ことだけを示します。承認・中身が正しいこと・受け入れてよいこと・署名者が誰かの証明ではありません。誰が署名してよいかの判断は、この部品の外です。
• この部品は秘密鍵を書き出さず（export を呼ばない）、保管せず、ログに出さず、結果に入れません。ただし、呼ぶ側が渡した KeyObject を消すことはしません（消すのは GC 任せ）。
• key_id は呼ぶ側の名札で、鍵と結びついているかを確かめません。どの鍵かを確かめるには public_key_spki_sha256 を使います。
• Ed25519 の計算そのものは Node.js の crypto（OpenSSL）に任せています。確かめたのは RFC 8032 の 7.1 の TEST 1〜3 と、実行時に作った鍵での Node の crypto との突き合わせまでです。
• verify の厳しさ（小さい位数の公開鍵・正準でない点など）は OpenSSL に従い、S + L の署名のほかの境目は確かめていません。B-02 との突き合わせもしていません。
• 署名・指紋・照合の結果は、承認ではありません（result_is_approval: false）。権限も作りません（derives_authority: false）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 特定の署名ライブラリの使い方の雛形ではありません。

つなぎ方

src/local-sign.js の sign({ message, private_key, key_id })・publicKeyFingerprint({ public_key })・verify({ message, public_key, signature }) を呼びます（どれも投げません）。sign は { ok: true, errors: [], algorithm: "Ed25519", key_id, signature, public_key_spki_sha256 } を返します（signature は 86 文字の base64url）。止めるときは { ok: false, errors: [{ code }] }。KeyObject は呼ぶ側が作って持ちます。副作用・状態・外の接続は無く、利用側が用意する port はありません。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

「確かめ済み」の裏で、どの鍵と失効を見たかは見えません。この部品は、重ね署名が無い・正しくないものを REFUSE にして通さず（fail-closed）、本物の鍵・取得先・起点を部品の中に固定して引数で差し替えさせず、trust の巻き戻りや同じ generation の別の bytes を断ります。結果には、見た trust と目録の digest を facts として添えます。

使う場面

• .amupkg の bytes（Uint8Array）を Runtime に渡す前に、完全性・自分用の署名・重ね署名・trust・失効・結び付けを確かめ、verdict（PASS か REFUSE）・code・stage・facts を受け取りたいとき（verifyAmupkg。投げません）。
• PASS の後に Runtime で開いたとき、返った amupkg_digest が sha256: ＋ facts.manifest_digest と同じかを照らすための値を受け取りたいとき。この照らし合わせは使う側が行います。
• trust bundle を取りに行き、確かめに通ったものだけを store の port に保存したいとき（refreshTrust）。取れないときは、保存したものか、部品に焼き込んだ gen 10 で判定を続けます。
• trust の鮮度を区別したいとき。新しい受け入れは trust の next_update まで、受け入れ済みのものは next_update から 30 日まで動かし、過ぎれば COUNTERSIG_TRUST_STALE・COUNTERSIG_TRUST_EXPIRED で止めます。
• PASS したものだけを受け入れの記録に残し（recordAdmitted）、trust・受け入れた数・確かめの版を見たいとき（status）。
• どの元の版の bytes を受け入れたかを、元の commit（33f2b1c）と 36 本のファイルの sha256 で照らせる部品が要るとき。

使わない場面

• 利用者が持ち込む .amupkg を、固定した見本（pinnedDigests）で通したいとき。固定した見本を守るのは、使う側のプログラムのコード署名で、部品はそれを確かめません。利用者が持ち込む .amupkg には使えません。
• 本物の鍵で署名した重ね署名が PASS することを、工房で確かめた結果として扱いたいとき。工房はそれを確かめていません（工房の試験とファズは、使い捨ての起点と鍵だけを使います）。
• PASS を、承認・販売の許可・中身が正しいことの印として使いたいとき。PASS は「出所・完全性・確認の範囲を確かめた」ことだけです。
• ZIP のファイルの bytes をまるごと同じものに限りたいとき。PASS は目録と目録に載ったファイルと署名で決まるので、その用途では facts.archive_digest（ZIP 全体の sha256）を使います。
• 利用者に見せる文（display の title_ja・detail_ja）を、そのまま本番の文として使いたいとき。display は仮の文です。
• 元の版が直ったときに、自動で新しい版を使いたいとき。自動では追いません（auto_follow: false）。新しい版は写し直して検査し直します。trust の新しい generation（gen 11 以降）が出たときも検査し直します。
• Node.js v24.21.0 のほかの版で使うとき。元は Node.js 20 以上の ES module ですが、工房はほかの版を確かめていません（NOT_VERIFIED）。

検査すること

• 確かめる順は、完全性 → 署名のファイルが目録に無いこと → 自分用の署名 → 固定した見本 → 重ね署名のファイル → 重ね署名の形 → trust（起点・鮮度）→ 重ね署名の鍵と署名 → 失効 → 結び付け、です。止めたときは、code と stage（integrity・self_signature・countersignature・trust・pinned）を返します。
• ZIP が上限（96 MiB・2000 件・1 件 64 MiB・合計 192 MiB・倍率 100）を超える・安全でない名前・読めないとき PKG_ARCHIVE_UNSAFE、載ってよいファイル・区分の決まりに合わないとき AMUPKG_SECTION_INVALID、目録の sha256・区分の digest が合わないとき AMUPKG_DIGEST_MISMATCH、目録の profile が扱えないとき AMUPKG_PROFILE_UNSUPPORTED、署名のファイルが目録に載っているとき MANIFEST_LISTS_SIGNATURE_FILE で止めます。
• 自分用の署名が無いとき SELF_SIGNATURE_MISSING、目録に合わないとき SELF_SIGNATURE_INVALID、自分用の鍵が失効しているとき SELF_KEY_REVOKED で止めます。
• 重ね署名のファイルが無い（COUNTERSIG_MISSING）・読めない（COUNTERSIG_UNREADABLE）・schema や purpose が違う・期限がある（期限は持たない決まり）・確認の範囲（scope_id・scope_version）が無い・重ね署名者が wi-t.com でない・この .amupkg の自分用の鍵と署名に結び付いていない（COUNTERSIG_SELF_SIGNER_MISMATCH）とき、それぞれのコードで止めます。
• 重ね署名の鍵が trust bundle に無い（COUNTERSIGNER_KEY_UNKNOWN）・重ね署名専用でない・方式が違う・失効している、重ね署名の署名が合わない（COUNTERSIG_SIGNATURE_INVALID）、その重ね署名が失効している（COUNTERSIG_REVOKED）とき、REFUSE にします。
• trust bundle が確かめられない（取れない・保存も焼き込みも使えない）とき COUNTERSIG_TRUST_UNAVAILABLE で止めます。trust の取得は 1 ファイル 256 KiB・10 秒までで、redirect を追いません。trust の巻き戻りと、同じ generation の別の bytes は断ります。
• 正しい .amupkg を 1 回ごとに 1 つの壊し方（目録の対象のファイルの書き換え・消し・足し、重ね署名の差し替え、別の鍵での署名の作り直し、ランダムな bytes の書き換えなど）で変えて答えと突き合わせる 1,000,000 回のファズを工房の検査で走らせ、不一致と fail-open が 0 でした（Node.js v24.21.0）。

しないこと・既知の限界

• PASS は「出所・完全性・確認の範囲を確かめた」ことだけで、承認・販売の許可・中身の正しさではありません（result_is_approval: false）。権限も作りません（derives_authority: false）。
• 部品が確かめるのは、目録と、目録に載ったファイルと、署名だけです。ZIP の中のファイルの外にある bytes（末尾など）は確かめの対象外で、Runtime も使いません。ファイルの bytes をまるごと同じにしたいときは facts.archive_digest（末尾に足すと変わる）を使います。
• 固定した見本（pinnedDigests）を守るのは使う側のプログラムのコード署名で、部品はそれを確かめません。利用者が持ち込む .amupkg には使えません。
• 本物の trust（gen 10）には重ね署名の鍵 wi-t-countersigner-ed25519.v1 が載っていて、その鍵で署名されていない重ね署名は COUNTERSIG_SIGNATURE_INVALID になります。部品に焼き込んだ trust も gen 10 です。ただし、本物の鍵で署名した重ね署名が PASS することは、工房では確かめていません。工房の試験とファズは本物の秘密鍵を使わず、使い捨ての起点と鍵だけを使います。
• これは ERABAZU が作った確かめの実装ではありません。別の書き手が作った部品を、bytes を書き換えずに受け入れたものです（36 本の sha256 と元の出所の記録で照らします）。中身・確かめの順番・止めるコード・API は元の設計のままです。受け入れたファイルには LICENSE・LICENSES/CC0-1.0.md・NOTICE もあり、NOTICE は元の書き手が足したものです。
• Runtime の実行ファイルとの通し（flow）は、工房の検査では動かしていません（実行ファイルが無い）。元のリポジトリの CI（run 37588955237）で PASS しています。元の試験は 54 件（pass 53・skip 1）です。
• store の port に trust と受け入れの記録を書き、fetch の port で trust の 4 つのファイルを読みます（LOCAL_REVERSIBLE）。部品のメモリーには状態を持たず、資格情報も使いません。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。

つなぎ方

src/index.mjs（ES module）の createCountersignatureVerifier({ store, fetch?, now?, log?, pinnedDigests? }) で instance を作り、await instance.verifyAmupkg(bytes, { admit? }) を呼びます。store（read・write）は必須の port、fetch（null なら取りに行かない）・now・log は省けます。返すのは { verdict, code, stage, facts, display } です。factory の引数の形が違うときと、bytes が Uint8Array でないときだけ TypeError を投げます。依存は Node.js の組み込み（node:crypto・WebCrypto）だけです。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

「保存した」で終わらせてしまうこと、つまり backend の受領や申告をそのまま信じて、化けた中身や偽った保存物を正しいものとして扱ってしまうことを防ぎます。読み出した中身は backend の「一致した」という申告だけでは検証済みにせず、自分で digest を計算して突き合わせます。

使う場面

• ファイルや blob を外部の object backend に保存し、読み出したいとき。
• 読み出した中身を、backend の申告ではなく自分で計算した digest で確かめてから使いたいとき。
• 受け付ける content-type と大きさの上限を決め、中身の種類を偽ったもの（magic bytes と合わないもの）を通したくないとき。
• 同じ中身を二重に保存したくないとき、また一度書いたら上書きしない（WORM）対象を守りたいとき。受領が確定しないまま再送する場合は、照会（lookup）で解きます。
• 部分書込や偽の受領が出たら、人が確かめるまで保存を止めたいとき。

使わない場面

• application/pdf・image/png・image/jpeg・text/plain・application/json 以外の content-type を、中身の種類まで確かめて扱いたいとき。magic bytes で確かめられるのはこの 5 種だけで、確かめられない型は通しません。
• 保持期間・TTL（C-08）やアーカイブ（C-09）のための削除・ライフサイクルの操作が要るとき。この継手には含まれていません（後続）。
• put の成功を「中身が正しいと確かめた」と扱いたいとき。put の成功は中身の検証済みではありません（content_verified: false）。
• 保存の成功を、承認や決裁として扱いたいとき。どの成功も承認ではありません。
• すぐに使える保管先がほしいとき。実 backend は含まず、どの object store につなぐかはまだ決まっていません。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。

検査すること

• 要求の型を検めます。追加のフィールド、決まった値（const）と違う値、side effect の条件に反するものは送りません。
• pin した backend の版を検めます。pin していない backend の版（backend_profile_revision）への要求は送りません。
• 中身の種類と大きさを検めます。magic bytes と合わない content-type（種類の偽り）、上限を超える大きさは送りません。
• 二重保存と上書きを検めます。同じ object_ref・同じ digest は二重に保存せず（ALREADY_STORED）、WORM の対象への上書きは送りません。
• get で読み出した中身の digest を自分で計算し、期待値と合わなければ中身を渡しません（GET_REJECTED）。読み出し時の改ざんを拒否します。
• 受領（ObjectReceipt）を照合します。request_digest を偽った受領、部分書込（MISMATCH）があれば受理せず、以後は停止します（HALTED）。
• backend の障害（500 の応答、書いた後の失敗）は UNKNOWN とし、保存済みとして扱いません。再送は照会（lookup）で解きます。
• 秘密の渡し方を検めます。SecretRef は secret-ref/v2 の場所だけを受け付け、SecretRef の隣に置いた生の秘密や、HUMAN_CREDENTIAL の種類は拒否します。

しないこと・既知の限界

• 化けていないかを決めるのは核（integrity-facts）の役目です。この継手がするのは、送る前と受け取った後の検めだけです。
• put の成功は中身の検証済みではなく（content_verified: false）、どの成功も承認ではありません（approval: false）。
• 実 backend を含みません。どの object store につなぐか、port の実装、pin する対象（endpoint・受領の形式）は未定で、接続するときに別の関門で決めます。
• 保持期間・TTL（C-08）やアーカイブ（C-09）の削除・ライフサイクルの拡張は含みません。
• magic bytes で中身の種類を確かめられるのは、application/pdf・image/png・image/jpeg・text/plain・application/json だけです。
• 契約を変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• object store の使い方の雛形ではありません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/object-store/v1 でつなぎます。createObjectStoreClient({ cfg, port }) の put(ObjectPutRequest, bytes)・get(ObjectGetRequest) は、STORED・GET_VERIFIED・GET_REJECTED・REFUSED・UNKNOWN・HALTED などを返します（どれにも approval: false）。利用側が用意するもの: object backend への port（put・get、任意で lookup）。副作用は WORM が EXTERNAL_IRREVERSIBLE、OVERWRITE が EXTERNAL_REVERSIBLE、get は NONE。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

保管した物が、気づかないうちに化けてしまうこと（沈黙のビット腐敗）や、改ざん・すり替えを見逃して、そのまま使ってしまうことを防ぎます。大きさが一致しただけでは内容の一致とはみなさず、ハッシュの一致を別に求めます。

使う場面

• 保管先から読み戻した物が、書いたときと同じかを確かめたいとき（checksum や ETag で化けていないか）。
• ネットワークの中継（proxy）を置かずに、呼び出し側のライブラリとして完全性を確かめたいとき。
• 採択したハッシュアルゴリズムだけを受け付け、それ以外のアルゴリズムの結果を信頼したくないとき。
• ハッシュと大きさを、自分の側ですでに計算・取得していて、その突き合わせだけを任せたいとき。

使わない場面

• ハッシュの計算や、保管先への書き込み・読み戻しまでこの継手にさせたいとき。これらは含まれておらず、呼び出し側が行って結果を渡します。
• 記録（recorded）を残していない物を確かめたいとき。書いたときの hash・size・algo が無ければ、突き合わせられず、信頼しません。
• 特定の保管 API の ETag の形式に、今すぐ合わせて使いたいとき。実際の保管 API と ETag の形式は、配備するときに config で決めます。
• SHA-256 以外のハッシュで確かめたいとき。確かめた範囲は SHA-256 の内容ハッシュです。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。

検査すること

• ハッシュを突き合わせます。記録と観測のハッシュが合わなければ（ビット腐敗・改ざん）、信頼しません（ok: false）。
• 大きさを突き合わせます。記録と観測の大きさが合わなければ、信頼しません。
• 大きさが同じでも、内容のハッシュが違えば信頼しません（大きさだけの一致では通しません）。
• ハッシュアルゴリズムを検めます。記録と観測でアルゴリズムが違うもの、採択していないアルゴリズムは信頼しません。
• 欠落を検めます。ハッシュや大きさが欠けていれば、信頼しません。

しないこと・既知の限界

• ハッシュを計算しません。保管先への書き込みも読み戻しもしません。呼び出し側が行い、その結果（recorded と observed）を渡します。
• backend につなぐ port を持ちません。この継手は、渡された値を突き合わせる純粋な関数だけです。
• require_size を false にすると、大きさの一致を求めなくなります（既定は true）。
• 実際の保管 API と ETag の形式は決めていません。配備するときに config で決めます。
• 完全性の事実を核としてまとめ、署名の対象や来歴に継ぐのは核（integrity-facts・provenance-facts）の側です。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 保管 API の使い方の雛形ではありません。

つなぎ方

入口は src/guards.js の verifyIntegrity(cfg, recorded, observed)（純粋な関数）です。recorded に書いたときに記録した { hash, size, algo }、observed に読み戻したときに観測した { hash, size, algo } を渡すと、一致すれば { ok: true, errors: [] }、合わなければ { ok: false, errors: [...] } を返します。cfg は allowed_algos（採択したアルゴリズム）と require_size（既定 true）。port は無く、ハッシュの計算と保管先への読み書きは利用側が用意します。実行環境は Node.js（依存パッケージなし）。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

DB に「保存されたはず」と思い込んでしまうこと、つまり半分だけ書けた transaction を成功として扱ってしまうことを防ぎます。COMMITTED はすべての操作が入ったと照合できたとき、ABORTED は何も入っていないと照合できたときだけ受け取ります。

使う場面

• 複数の書き込みを、一貫性を保ったまま DB に書きたいとき（すべて入るか、何も入らないか）。
• DB が返す受領をそのまま信じず、要求（request_id・request_digest）と target の一致を照合してから、書けたと扱いたいとき。
• 書き込み先を、pin した backend と許可した論理の target に限りたいとき。ファイルシステムの路を target にさせたくないとき。
• 同じ要求を二度コミットしたくないとき。受領が確定しないまま再送する場合は、照会（lookup）で解きます。
• 部分コミットや偽の受領が出たら、人が確かめるまで書き込みを止めたいとき。

使わない場面

• 同じ契約 storage-persistence/v1 に属する C-05〜C-09 の機能が要るとき。この継手には含めていません。
• 書き込みの成功を、承認や決裁として扱いたいとき。書けたことは承認ではありません。
• すぐに使える DB がほしいとき。実 DB は含まず、どの backend につなぐかはまだ決まっていません。
• ファイルシステムの路（先頭の / や \、..）に書きたいとき。target にしません。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。

検査すること

• 送り先を検めます。pin していない backend、許可していない target、ファイルシステムの路の target への要求は送りません。
• 操作と本体を検めます。本体の改ざん（digest の不一致）、本体の過不足、同じ操作の重複、操作の数や本体の大きさが上限を超えるものは送りません。
• 部分コミットを受理しません。COMMITTED は全件、ABORTED は 0 件で外への効果が無いことを求め、外れれば受理せず、以後は停止します（HALTED）。
• side effect を検めます。受領の side effect は要求の宣言から減らすことだけを認め、増やした受領は受理しません。COMMITTED は意図した side effect と一致する必要があります。
• 受領（TransactionalWriteReceipt）を照合します。request_digest を偽った受領、別の target の受領は受理せず、以後は停止します（HALTED）。
• DB の障害は UNKNOWN とし、書けたとして扱いません。同じ request_id は二度コミットせず、再送は照会（lookup）で解きます。

しないこと・既知の限界

• 一貫性を決めるのは核（reconcile-facts・policy-facts）の役目です。この継手がするのは、送る前と受け取った後の検めだけです。
• 書けたことは承認ではありません（approval: false）。
• 実 DB を含みません。どの backend につなぐか、port の実装、pin する対象は未定で、接続するときに別の関門で決めます。
• 同じ契約 storage-persistence/v1 の C-05〜C-09 は含みません。優先順位の案では、継手を作らない（decision-only）か後回し（DEFER）です。
• 契約を変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• DB クライアントの雛形ではありません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/storage-persistence/v1 でつなぎます。createTxClient({ cfg, port }) の write(TransactionalWriteRequest, payloads)（payloads は { op_ref: bytes }）は、COMMITTED・ABORTED・REFUSED・UNKNOWN・HALTED などを返します（どれにも approval: false）。利用側が用意するもの: DB への port（commit と、任意で lookup）。副作用は要求で宣言する EXTERNAL_REVERSIBLE か EXTERNAL_IRREVERSIBLE（ABORTED は NONE か LOCAL_REVERSIBLE）。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

外部の追記専用の保管先にイベントを積み重ねるとき、手元の台帳の先頭と保管先の実際がずれること（通番の巻き戻し・飛び、同じイベントの二重の追記、障害で結果が分からない書き込み）を防ぎます。受領を照合できない追記では台帳の先頭を進めないので、台帳の続き方を信頼できる状態に保てます。

使う場面

• 改変不能なイベント履歴を、外部の追記専用 backend に 1 件ずつ積み重ねたいとき。
• 決まった 1 つの台帳（ledger_id・ledger_profile_revision・contract_revision で pin したもの）にだけ追記したいとき。
• 通番が巻き戻ったり飛んだりしない、一本の続き方を保ちたいとき。
• 同じイベントを二重に追記したくないとき。二重かどうかは event_id と封筒の digest で見分け、受領が確定しないまま再送する場合は照会（lookup）で解きます。
• 台帳の先頭・未解決の送信・停止の有無を、手元で確かめながら追記を進めたいとき（state() が { head, pending, halted } を返します）。

使わない場面

• 書き換えや削除ができる保管先として使いたいとき。この継手は追記だけを扱います。
• イベントの本文そのものを台帳に積みたいとき。封筒には契約のフィールドだけを載せ、本文の混入は拒否します。
• 透明性ログ（Merkle の包含証明）が要るとき。この継手の範囲外です。
• すぐに使える保管先がほしいとき。実 backend は含まず、どの追記専用サービスにつなぐかはまだ決まっていません。
• 追記の成功を、承認や決裁として扱いたいとき。追記の成功は承認ではありません。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。

検査すること

• pin した台帳を検めます。pin していない台帳への追記は送りません。
• 通番（sequence）を検めます。台帳の先頭から見て通番が巻き戻っている・飛んでいるときは、送らず、受理しません。
• 二重の追記を止めます。同じ event_id・同じ内容がもう追記済みなら backend に送らず ALREADY_APPENDED を返し、同じ event_id で内容が違うときは REFUSED を返します。
• 未解決の送信があるあいだは、次の封筒を送らず REFUSED を返します。結果が分からなかった送信は照会（lookup）で解きます。
• backend の障害（500 の応答や一部だけの書き込み）は UNKNOWN とし、台帳の先頭を進めません。
• 受領（AuditAppendReceipt）の台帳・通番・event_id・対象が、送った封筒と食い違うときは受理せず、台帳の先頭を進めません。
• 受領に不整合があれば停止します（HALTED）。人が確かめるまで追記しません。
• 本文が混じった封筒、封筒の大きさの上限（max_envelope_bytes）を超えるイベント、種類を偽った封筒（content-type の偽り）を拒否します。

しないこと・既知の限界

• 台帳が改変できないかどうかを決めるのは核（provenance-facts・integrity-facts）の役目です。この継手がするのは、送る前の検めと受領の照合だけです。
• 追記の成功は承認ではありません（approval: false）。
• 実 backend を含みません。どの追記専用サービスにつなぐか、port の実装、pin する対象（endpoint・受領の形式）は未定で、接続するときに別の関門で決めます。
• 透明性ログ（Merkle の包含証明）は扱いません。
• backend の認証に使う秘密（SecretRef）の解決はしません。port 側の責務です。
• C-04 専用の部品ではありません。H-01（改変不能監査ログ）・H-08（改ざん検知チェーン）・H-02（アクセスログ）と同じ 1 つの部品が担い、試験と検査も共通です。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 契約を変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。

つなぎ方

契約 erabazu.candidate/certified-tsugite/audit-ledger/v1 でつなぎます。createLedgerClient({ cfg, port }) の append(envelope) に AuditEventEnvelope を渡すと APPENDED_VERIFIED・ALREADY_APPENDED・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED のどれかを返します（どれにも approval: false）。cfg は pin する台帳と封筒の上限。state() は { head, pending, halted }。利用側は追記専用 backend への port（append、任意で lookup）を用意します。副作用は EXTERNAL_IRREVERSIBLE（取り消せない書き込み）。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

保管先への書き込みを再送したときに同じ内容を二重に書いてしまうこと、同じ冪等キーで別の中身を書いてしまうこと、そして backend の receipt を確かめないまま「書けた」と扱ってしまうことを防ぎます。

使う場面

• 再送があっても、保管 backend への書き込みの外への効果を高々 1 回にしたいとき。
• 重複で効果なし（DEDUP_HIT）と返ったときも、保管されている中身が送った中身と同じかを確かめてから受け取りたいとき。
• 書込の中身の digest を自分で確かめ、大きさの上限を超える中身を送りたくないとき。
• backend の障害で結果が分からないとき、同じ request_id を二度送らず、照会（lookup）で解きたいとき。

使わない場面

• トランザクション書込が要るとき。C-03 のトランザクション書込は別の部品（transactional-write-tsugite）です。
• 重複かどうかの決定をこの継手に任せたいとき。重複の検出は核（reconcile-facts）の役目です。
• ファイルシステム上の場所を書き先にしたいとき。target は論理の target だけで、ファイルシステムの target は拒否します。
• すぐに使える保管先がほしいとき。実 backend は含まず、どの保管サービスにつなぐかはまだ決まっていません。
• 書けたことを、承認や決裁として扱いたいとき。書けたことは承認ではありません。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。

検査すること

• 要求の型を検めます。追加のフィールド、決まった値（const）と違う値、ファイルシステムの target、pin していない backend・許可していない target への要求は送りません。
• 同じ冪等キーで別の中身を書く要求は送りません（REFUSED）。
• 書込の中身を検めます。大きさの上限を超える中身、digest と合わない（改ざんされた）中身は送りません。
• 重複（DEDUP_HIT）の receipt が新しい効果を伴っていれば受理しません。DEDUP_HIT は効果なし（NONE）でなければなりません。
• 保管された中身（stored_digest）が送った中身と違えば、DEDUP_HIT でも受理しません。同じキーで別の中身は異常として扱います。
• receipt を照合します。request_digest の偽り、別の target の receipt、外への効果を増やす receipt は受理せず、以後停止します（HALTED）。
• backend の障害は UNKNOWN とし、同じ request_id を二度送りません。未解決の送信があるときは REFUSED を返し、backend に送りません。
• FAILED・REFUSED・SIMULATED の receipt は、効果なし（NONE）でなければ受理しません。

しないこと・既知の限界

• 重複かどうかを決めるのは核（reconcile-facts）の役目です。この継手がするのは、送る前の検めと受け取った後の照合だけです。
• 書けたことは承認ではありません（approval: false）。
• 実 backend を含みません。どの保管サービスにつなぐか、port の実装、pin する対象は未定で、接続するときに別の関門で決めます。
• この項目だけの別の部品ではありません。C-05〜C-09 と H-06・F-04 は契約上 1 つの部品（tsugite/storage-persistence/lifecycle）で、この項目はその冪等書込の面で、F-04（冪等キー処理）も同じ面で担います。
• 契約を変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 保管サービスの使い方の雛形ではありません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/storage-persistence/v1 でつなぎます。createStorageLifecycleClient({ cfg, port }) の submit(request, bytes) に IdempotentWrite の要求と書込の中身 bytes（必須）を渡すと、DONE・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED のどれかを返し、DONE に dedup_result を添えます（どれにも approval: false）。利用側が用意するもの: 保管 backend の port（submit、任意で lookup）と、backend・target・上限の設定。副作用は EXTERNAL_*（DEDUP_HIT は NONE）。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

スナップショットの要求を送るとき、許可していない対象を送ってしまうこと、そして backend の receipt が本当にその対象のものかを確かめないまま「取れた」と扱ってしまうことを防ぎます。この継手が照合できたスナップショットだけが、模擬の復元（C-07）の元になります。

使う場面

• 保管の backend に論理の target のスナップショットの要求を送り、receipt を照合できてから、取れたことを事実として受け取りたいとき。
• スナップショットの receipt を、その snapshot_ref の中身の digest（content_digest）と対にして照合したいとき。
• 照合できたスナップショットだけを、模擬（SYNTHETIC）・dry-run の復元の元として扱いたいとき。
• backend の障害で結果が分からないとき、同じ request_id を二度送らず、照会（lookup）で解きたいとき。

使わない場面

• スナップショットから実際に戻すこと（本番の PITR）まで求めるとき。実際に壊す復元は範囲外で、復元は模擬・dry-run だけです。
• ファイルシステム上の場所の複製を取りたいとき。target は論理の target だけで、ファイルシステムの target は拒否します。
• すぐに使える保管先がほしいとき。実 backend は含まず、どの保管サービスにつなぐかはまだ決まっていません。
• 取れたことを、承認や決裁として扱いたいとき。取れたことは承認ではありません。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。

検査すること

• 要求の型を検めます。追加のフィールド、決まった値（const）と違う値、ファイルシステムの target、pin していない backend・許可していない target への要求は送りません。
• receipt を照合します。request_digest の偽り、別の target の receipt、外への効果を増やす receipt は受理せず、以後停止します（HALTED）。
• スナップショットの receipt の効果は、取り消せる外部への効果（EXTERNAL_REVERSIBLE）までです。それより効果を増やす receipt は受理しません。
• 照合できたスナップショットを state() の snapshots に残し、照合していないスナップショットからの復元の要求は送りません。
• FAILED・REFUSED・SIMULATED の receipt は、効果なし（NONE）でなければ受理しません。
• backend の障害は UNKNOWN とし、同じ request_id を二度送りません。未解決の送信があるときは REFUSED を返し、backend に送りません。

しないこと・既知の限界

• スナップショットが照合できたことは、そこから実際に戻せることを確かめたものではありません。実際に壊す復元（本番の PITR）は範囲外です。
• 何をいつ取るかの決定は核の役目です。この継手がするのは、送る前の検めと受け取った後の照合だけです。
• 取れたことは承認ではありません（approval: false）。
• 実 backend を含みません。どの保管サービスにつなぐか、port の実装、pin する対象は未定で、接続するときに別の関門で決めます。
• この項目だけの別の部品ではありません。C-05〜C-09 と H-06・F-04 は契約上 1 つの部品（tsugite/storage-persistence/lifecycle）で、この項目はそのスナップショットの面です。
• 契約を変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 保管サービスの使い方の雛形ではありません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/storage-persistence/v1 でつなぎます。createStorageLifecycleClient({ cfg, port }) の submit(request) に Snapshot の要求を渡すと、DONE・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED のどれかを返し、DONE に snapshot_ref・snapshot_state を添えます（どれにも approval: false）。利用側が用意するもの: 保管 backend の port（submit、任意で lookup）と、pin する backend・許可する target の設定。副作用は取り消せる外部への効果（EXTERNAL_REVERSIBLE）。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

復元の要求を送るとき、照合していないスナップショットから戻そうとすること、dry-run なのに「適用した」とする結果を信じてしまうこと、実際に壊す復元の要求が送られてしまうことを防ぎます。この継手が扱うのは模擬・dry-run の復元だけで、実際にある時点へ戻すことはしません。

使う場面

• 照合済みのスナップショットを元に、模擬（SYNTHETIC）または dry-run の復元の要求を送り、その receipt を照合したいとき。
• dry-run の復元の結果として、効果なし（NONE）の receipt だけを受け取りたいとき。
• 復元の元を、この継手が CREATED と照合したスナップショットに限りたいとき。

使わない場面

• 実際にある時点へ戻したいとき（本番の PITR）。実際に壊す復元は範囲外で、契約も模擬・dry-run だけを定めます。この継手はその要求を送りません。
• 事故のときに実際に復旧する手段として使いたいとき。この継手は実際の復旧をしません。
• この継手が照合していないスナップショットから戻したいとき。
• すぐに使える保管先がほしいとき。実 backend は含まず、どの保管サービスにつなぐかはまだ決まっていません。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。

検査すること

• 実際に壊す復元のモードの要求は送りません。
• この継手が CREATED と照合していないスナップショットからの復元の要求は送りません。
• dry-run の要求に「適用した」とする receipt は受理しません。APPLIED_SYNTHETIC は模擬（SYNTHETIC）の要求のときだけ受け取ります。
• 復元の receipt の効果は、効果なし（NONE）か手元で取り消せる効果（LOCAL_REVERSIBLE）までで、dry-run は NONE だけです。効果を増やす receipt は受理しません。
• request_digest の偽り、別の target の receipt は受理せず、以後停止します（HALTED）。
• 要求の型を検めます。追加のフィールド、決まった値（const）と違う値、ファイルシステムの target、pin していない backend・許可していない target への要求は送りません。
• FAILED・REFUSED・SIMULATED の receipt は、効果なし（NONE）でなければ受理しません。
• backend の障害は UNKNOWN とし、同じ request_id を二度送りません。未解決の送信があるときは REFUSED を返し、backend に送りません。

しないこと・既知の限界

• 実際の復旧はしません。実際に壊す復元（本番の PITR）は範囲外で、契約も模擬・dry-run だけを定めます。DONE に添える restore_state は、模擬・dry-run の復元の結果です。
• ファズは backend を叩かず、試験は保管 backend の代役を使っています。実際の backend である時点へ戻せることは確かめていません。
• 何をいつ戻すかの決定は核の役目です。この継手がするのは、送る前の検めと受け取った後の照合だけです。
• 模擬の復元が照合できたことは承認ではありません（approval: false）。
• 実 backend を含みません。どの保管サービスにつなぐか、port の実装、pin する対象は未定で、接続するときに別の関門で決めます。
• この項目だけの別の部品ではありません。C-05〜C-09 と H-06・F-04 は契約上 1 つの部品（tsugite/storage-persistence/lifecycle）で、この項目はその模擬の復元の面です。
• 契約を変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/storage-persistence/v1 でつなぎます。createStorageLifecycleClient({ cfg, port }) の submit(request) に Restore の要求（模擬か dry-run）を渡すと、DONE・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED のどれかを返し、DONE に restore_state を添えます（どれにも approval: false）。利用側が用意するもの: 保管 backend の port（submit、任意で lookup）。副作用は NONE か LOCAL_REVERSIBLE（dry-run は NONE）で、実際の復旧は含みません。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

保持期限による削除を backend へ送るとき、許していない削除やリーガルホールド中の対象の削除を送ってしまうこと、期限切れの判定だけのはずが削除されたと扱うこと、backend の receipt を確かめないまま「消せた」と扱うことを防ぎます。

使う場面

• 保持方針に沿った削除（EXPIRE）の要求を、設定で許したときだけ backend へ送りたいとき。
• リーガルホールドの事実（核・人の決定）を受け取り、以後その対象の EXPIRE を送らないようにしたいとき。
• 削除せずに、期限切れかどうかの判定（EVALUATE）だけを backend に求めたいとき。
• 消せたこと（deleted: true）を、EXPIRE の receipt が EXPIRED と照合できたときだけ事実として扱いたいとき。

使わない場面

• 保持期限やリーガルホールドをこの継手に決めさせたいとき。その決定は核と人の役目で、この継手は事実を受け取って守るだけです。
• 期限が来たら自動で消す仕組みそのものがほしいとき。この継手は渡された保持の要求を検めて送るだけで、EXPIRE は設定 allow_expire が true でなければ送りません。
• 期限で別の階層へ移したいとき。階層の移動は Archive の要求で、C-09 アーカイブ・階層化の面です。
• すぐに使える保管先がほしいとき。実 backend は含まず、どの保管サービスにつなぐかはまだ決まっていません。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。

検査すること

• 設定 allow_expire が true でないとき、EXPIRE を送りません。
• リーガルホールド中の対象には EXPIRE を送りません。
• EVALUATE の receipt が削除を伴っていれば受理しません。EVALUATE の EXPIRED は期限切れの判定だけで、削除ではありません。
• RETAIN に EXPIRED を返す receipt は、異常として受理しません。
• pin した一覧にない保持方針の要求は送りません。
• 要求の型を検めます。追加のフィールド、決まった値（const）と違う値、ファイルシステムの target、pin していない backend・許可していない target への要求は送りません。
• receipt を照合します。request_digest の偽り、別の target の receipt、外への効果を増やす receipt は受理せず、以後停止します（HALTED）。
• FAILED・REFUSED・SIMULATED の receipt は、効果なし（NONE）でなければ受理しません。backend の障害は UNKNOWN とし、同じ request_id を二度送りません。

しないこと・既知の限界

• 保持期限の決定・リーガルホールドの決定はしません。核（redact-facts・policy-facts）と人の役目で、この継手はその事実を受け取って守るだけです。
• 消せたことは承認ではありません（approval: false）。
• 実 backend を含みません。どの保管サービスにつなぐか、port の実装、pin する対象は未定で、接続するときに別の関門で決めます。
• この項目だけの別の部品ではありません。C-05〜C-09 と H-06・F-04 は契約上 1 つの部品（tsugite/storage-persistence/lifecycle）で、この項目はその保持の面で、H-06（保持強制）も同じ面で担います。
• 契約を変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 保管サービスの使い方の雛形ではありません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/storage-persistence/v1 でつなぎます。createStorageLifecycleClient({ cfg, port }) の submit(request) に Retention の要求を渡すと、DONE・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED のどれかを返し、DONE に decision・deleted・effect を添えます（どれにも approval: false）。利用側が用意するもの: 保管 backend の port（submit、任意で lookup）と、pin する保持方針・allow_expire の設定。副作用は EXPIRE が EXTERNAL_IRREVERSIBLE、ほかは NONE。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

データを別の階層へ移す要求を送るとき、pin していない階層や許可していない対象へ送ってしまうこと、そして backend の receipt を確かめないまま「移せた」と扱ってしまうことを防ぎます。

使う場面

• 古いデータを、pin した階層へ移す要求を backend へ送りたいとき。
• 移した結果（transition_state・archive_ref）を、receipt を照合できてから事実として受け取りたいとき。
• backend の障害で結果が分からないとき、同じ request_id を二度送らず、照会（lookup）で解きたいとき。

使わない場面

• どのデータをいつ移すかをこの継手に決めさせたいとき。決定は核の役目で、この継手は送る前と受け取った後の検めだけです。
• 取り消せない削除を伴わせたいとき。アーカイブの効果は取り消せる外部への効果（EXTERNAL_REVERSIBLE）までで、取り消せない削除は保持（C-08）の EXPIRE の扱いです。
• ファイルシステム上の場所へ移したいとき。target は論理の target だけで、ファイルシステムの target は拒否します。
• すぐに使える保管先がほしいとき。実 backend は含まず、どの保管サービスにつなぐかはまだ決まっていません。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。

検査すること

• pin していない階層への移動の要求は送りません。
• 要求の型を検めます。追加のフィールド、決まった値（const）と違う値、ファイルシステムの target、pin していない backend・許可していない target への要求は送りません。
• アーカイブの receipt の効果は、取り消せる外部への効果（EXTERNAL_REVERSIBLE）までです。それより効果を増やす receipt は受理しません。
• request_digest の偽り、別の target の receipt は受理せず、以後停止します（HALTED）。
• FAILED・REFUSED・SIMULATED の receipt は、効果なし（NONE）でなければ受理しません。
• backend の障害は UNKNOWN とし、同じ request_id を二度送りません。未解決の送信があるときは REFUSED を返し、backend に送りません。

しないこと・既知の限界

• 何をいつ移すかの決定は核の役目です。この継手がするのは、送る前の検めと受け取った後の照合だけです。
• 移せたことは承認ではありません（approval: false）。
• 実 backend を含みません。どの保管サービスにつなぐか、port の実装、pin する対象は未定で、接続するときに別の関門で決めます。
• この項目だけの別の部品ではありません。C-05〜C-09 と H-06・F-04 は契約上 1 つの部品（tsugite/storage-persistence/lifecycle）で、この項目はその階層の移動の面です。
• 契約を変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 保管サービスの使い方の雛形ではありません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/storage-persistence/v1 でつなぎます。createStorageLifecycleClient({ cfg, port }) の submit(request) に Archive の要求を渡すと、DONE・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED のどれかを返し、DONE に transition_state・archive_ref を添えます（どれにも approval: false）。利用側が用意するもの: 保管 backend の port（submit、任意で lookup）と、pin する backend・階層（tiers）・許可する target の設定。副作用は EXTERNAL_REVERSIBLE。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

「保存してある」の裏で、元のまま残っているかは誰も確かめません。この部品は、記録と合わない bytes を置くこと、一度置いたキーを別の中身で上書きすること、PII をほかの区画と混ぜること、読んだ bytes が置いたものと違うのに使ってしまうことを防ぎます。

使う場面

• 取得したファイル（1〜10000 個）と fetch.json を、raw/<source>/<folder_stamp>/payload/<name> と raw/<source>/<folder_stamp>/fetch.json のキーで、追記だけで 1 回だけ置きたいとき（store）。
• 保持区分ごとに保管先を分け、PII の区画には、ほかの区画と別の backend・別のクライアントを当てたいとき。どの書込も、その取得の retention_class の区画の target にだけ送ります。
• PARTIAL の取得も、取れた分をほかと同じに残したいとき。続きは次の取得で、別の fetched_at の別のフォルダーになります。
• 置いた raw を、期待する sha256 を添えて読み、継手の検めの後に自分でも sha256 を計算し直して、合ったときだけ bytes の写しを受け取りたいとき（read）。
• 結果の分からなかった書込を、同じ要求で送り直して残りの書込を続けたいとき（resolvePending）。同じ取得をもう一度 store すれば、書けた分は DEDUP_HIT で続きから書けます。

使わない場面

• 保持の期間を数える・期限で消す・PII の期間の決まりを守らせることまで任せたいとき。この部品は区画を分けて置くだけです。保持と削除は backend の方針（C-08 など）の側です。
• 取得した中身がプラットフォームの中身と同じかを確かめたいとき。確かめるのは、渡した bytes が N-09 の記録の name・byte_size・sha256 と合うことだけです。
• PII の区画が本当に別のストレージであることを確かめたいとき。確かめるのは backend_profile_ref の文字列とクライアントのオブジェクトが違うことまでで、2 つの名前が同じ物を指していても見分けられません。
• ファイルの大きさの上限をこの部品に任せたいとき。上限は C-05 の継手の max_payload_bytes で決めます。大きなファイルは送るたびに写しを作ります。
• ほかのプロセスや再起動の前に書いたキーまで、この部品に RAW_CONFLICT で見分けさせたいとき。控えはプロセスの中だけで、そのキーは継手と backend が断ります（どちらでも上書きはしません）。
• 同じ request_prefix の 2 つのインスタンスで、同じクライアントを使いたいとき。継手が同じ request_id を ALREADY_DONE で答え、別の要求が前の答えで返ります。request_prefix はクライアントごとに一意にします。
• Node.js v24.21.0 のほかの版で使うとき。ほかの版は確かめていません（NOT_VERIFIED）。

検査すること

• options が足りない・形が違う・区画が 3 つちょうどでない・2 つの区画が同じ保管先・pii がほかの区画と同じ backend かクライアント・port の関数が無いとき、INVALID_OPTIONS で止めます。
• 操作の入力の形が違うとき（欄の過不足、files が 1〜10000 個の素の配列でない、name の重なり、bytes が Uint8Array でない、read の key が raw/ で始まらない など）INVALID_INPUT、getter が例外を投げたとき INSPECTION_FAILED で止めます。
• N-09 が記録を作らないとき FETCH_RECORD_REFUSED（N-09 の errors を添える）、N-09 が例外を投げたとき FETCH_RECORD_PORT_FAILED、答えが食い違うとき（canonical の sha256・正準形・schema・入力の欄・folder_stamp・files の形）FETCH_RECORD_INVALID で、何も送りません。
• 渡した files が記録の files と合わないとき、FILE_MISMATCH で何も送りません。errors[0] に name と reason（MISSING・SIZE・DIGEST・EXTRA）を添えます。
• 書込の計画のキーに、この部品が前に別の sha256 を送っているとき、RAW_CONFLICT で何も送りません（追記だけ・上書きしない）。
• 書込の結果が分からないとき STORE_UNKNOWN で同じ要求を保ち、保留の間の store を STORE_PENDING で止めます。継手が送らなかったとき WRITE_REFUSED、停止・receipt の照合の失敗・結果が APPLIED か DEDUP_HIT でないとき WRITE_FAILED で、次へ進みません。
• read で、保管物が無いとき OBJECT_NOT_FOUND、digest が合わないとき（継手の GET_REJECTED か、自分で計算し直した sha256 の違い）DIGEST_MISMATCH、結果が分からないとき READ_UNKNOWN、送らなかったとき READ_REFUSED、停止・形の違いのとき READ_FAILED で、bytes を返しません。
• timestamp が RFC 3339 の UTC（Z）の実在する日時を返さない・投げたとき CLOCK_FAILED で何も送らず、前の操作が終わっていないとき BUSY で止めます。

しないこと・既知の限界

• raw の保管の部品は継手ではありません。自分の Request/Receipt は無く、書込と読出しという外への効果は、束ねた C-05・C-01 の継手がそれぞれの契約で起こします。この部品自身は外へ触れません。
• 束ねた部品の意味（記録できた ≠ 取得の正しさ・書けた ≠ 受け入れ・読めた ≠ 中身の正しさ）は、それぞれの部品の側に残ります。
• 削除・上書きの操作はありません。送るのは IdempotentWriteRequest と ObjectGetRequest だけです。保持の期間は数えず、消しません。
• 書けたこと・読めたことは、中身の正しさでも受け入れでも承認でもありません（approval: false・authority: NOT_DERIVED、derives_authority: false）。
• C-05 のキーと C-01 の object_ref が同じ保管物を指すか（書いた raw を read で読めるか）は backend profile の役目です。試験では同じ保管物を指す代役で確かめました。
• 本物の N-09・C-05・C-01 には、この部品の試験では接続していません。単体試験とファズは代役で、本物との結線は別の結線の検めで確かめます。状態（送ったキーの控え・保留）はプロセスの中だけで、再起動で消えます。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 特定のデータレイク・オブジェクトストレージの雛形ではありません。

つなぎ方

src/raw-store.js の createRawStore(options) で作ります。受け取るのは partitions { pii, business, evidence }・request_prefix・ports・任意の timestamp で、{ ok, errors, instance } を返します。操作は store・read・resolvePending・status で、どの結果にも approval: false が付きます。利用側が用意する port は fetchRecord（N-09）、区画ごとの write.<class>.submit（C-05 の継手のクライアント）と read.<class>.get（C-01 の継手のクライアント）です。副作用は束ねた継手が起こし（EXTERNAL_REVERSIBLE）、資格情報は port が持ちます。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

バックアップは戻すときまで試されません。この部品は、照合できないスナップショットを世代にすること、PII をほかの区画と混ぜること、世代を上書きすること、確かめていないバックアップを「復元できる」と扱うことを防ぎます。

使う場面

• 区画ごとにスナップショットを作らせ、照合できたものを次の世代として backup/<class>/<seq>.json に 1 回だけ記録したいとき（backup）。世代の番号は last_seq + 1 から、書けた世代だけで数えます。
• 記録した世代から SYNTHETIC の模擬の復元を送り、readRestored が返す復元した中身の digest を、世代の content_digest と照合したいとき（verifyRestore）。
• 世代が keep_generations を超えたことを、over_limit の事実として受け取りたいとき。古い世代は消しません。
• 区画ごとの世代と確かめの結果（restore_verified）・保留を一覧したいとき（status）。
• 結果の分からなかった送信を、その区画だけ保留にし、同じ要求で送り直したいとき（resolvePending）。保留の間も、ほかの区画は止まりません。

使わない場面

• 本番への復元（実際に壊す復元）をしたいとき。送るのは DRY_RUN か SYNTHETIC だけで、本番で復元できるかは確かめていません。
• 古い世代を期限で消したいとき。keep_generations は over_limit の事実を返すだけで、消すのは backend の保持（C-08 など）の役目です。
• 取ったばかりのバックアップを「復元できる」と扱いたいとき。verifyRestore の digest の照合（SYNTHETIC・readRestored あり）が済むまで restore_verified: false です。readRestored が無い・DRY_RUN のときは digest_verified: null です。
• スナップショットの content_digest が中身を正しく表しているか、readRestored が本当に復元した中身から digest を計算したかまで確かめたいとき。この部品は返った値どうしを照合するだけです。
• 再起動の前に取った世代を、そのまま verifyRestore したいとき。状態はプロセスの中だけで、再起動後は last_seq を渡して数え直し、前のプロセスの世代は verifyRestore の対象になりません。
• Node.js v24.21.0 のほかの版で使うとき。ほかの版は確かめていません（NOT_VERIFIED）。

検査すること

• options が足りない・形が違う・区画が 3 つちょうどでない・2 つの区画が同じ保管先・keep_generations や last_seq の形・port の関数が無いとき INVALID_OPTIONS、操作の入力の形が違うとき INVALID_INPUT、getter が例外を投げたとき INSPECTION_FAILED で止めます。
• スナップショットの結果が分からないとき SNAPSHOT_UNKNOWN（同じ要求を保つ）、送らなかったとき SNAPSHOT_REFUSED、CREATED でない・停止・結果や content_digest の形が違うとき SNAPSHOT_FAILED で、世代にしません。
• 世代の記録の書込の結果が分からないとき RECORD_UNKNOWN（同じ要求を保つ）、送らなかったとき（同じキーの別の中身を含む）RECORD_REFUSED、停止・結果が APPLIED か DEDUP_HIT でないとき RECORD_FAILED で、世代として数えません。
• verifyRestore で、この部品が記録した世代として無い snapshot_ref のとき UNKNOWN_GENERATION で止めます。
• 復元の結果が分からないとき RESTORE_UNKNOWN、継手が送らなかった・backend が復元を断ったとき RESTORE_REFUSED、停止・知らない restore_state・DRY_RUN なのに適用したと言ったとき RESTORE_FAILED で止めます。
• 復元した digest が世代の content_digest と合わないとき（C-02 が ok: true でない、sha256 でない、値が違う）RESTORE_DIGEST_MISMATCH（digest_verified: false）、readRestored が投げた・形が違うとき RESTORED_READ_FAILED、C-02 の関数が投げたとき INTEGRITY_PORT_FAILED（どちらも digest_verified: null）で、確かめにしません。
• その区画に結果の分からない送信があるとき CLASS_PENDING、保留が無いのに resolvePending を呼ぶと NOTHING_PENDING、timestamp が実在する日時を返さないとき CLOCK_FAILED、前の操作が終わっていないとき BUSY で止めます。

しないこと・既知の限界

• 区画ごとの世代バックアップと復元の検めの部品は継手ではありません。自分の Request/Receipt は無く、スナップショット・模擬の復元・世代の記録の書込という外への効果は、束ねた継手（C-05・C-06・C-07）がそれぞれの契約で起こします。この部品自身は外へ触れません。
• 束ねた部品の意味（作れた ≠ 中身の正しさ・模擬の復元 ≠ 本番の復元・照合できた ≠ 承認）は、それぞれの部品の側に残ります。
• 削除・保持・アーカイブの要求は送らず、古い世代を消しません。世代は上書きしません。
• 結果は承認ではありません（approval: false・authority: NOT_DERIVED、derives_authority: false）。
• 世代の記録が保存されたのに結果が崩れたときは、その seq のキーが backend に残り、次の backup の記録は断られ続けます（fail-closed）。直すのは呼び出し側で、last_seq を合わせます。
• 本物の storage-lifecycle・storage-integrity の継手と backend には、この部品の試験では接続していません。単体試験とファズは代役で、本物との結線は別の結線の検めで確かめます。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 特定のバックアップ製品の雛形ではありません。

つなぎ方

src/backup.js の createBackup(options) で作り、{ ok, errors, instance } を返します。options は policies { pii, business, evidence }（target・keep_generations・任意の last_seq）・request_prefix・ports・任意の timestamp です。操作は backup・verifyRestore・resolvePending・status で、結果に approval: false が付きます。port は区画ごとの storage.<class>.submit（storage-lifecycle の継手のクライアント）・verifyIntegrity（C-02）・任意の readRestored です。資格情報は port が持ちます。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

メールを「届いた」で終わらせてしまうこと、つまり宛先を偽ったメールや同意の無いメール、化けたメールを送ってしまうこと、そして送れたことを届いたことと取り違えることを防ぎます。送れた状態（REQUESTED）は到達ではなく、delivered: false として扱います。

使う場面

• 確認・領収・リマインドなどのメールを、外部のメール backend から送りたいとき。
• 送り先を、pin した宛先の表（recipient_ref とメールアドレス）に限りたいとき。
• 検証済みの同意が無い宛先や、bounce・苦情を記録した宛先には送りたくないとき。
• 同じメールを二重に送りたくないとき。受領が確定しないまま再送する場合は、照会（lookup）で解きます。
• 偽の受領が出たら、人が確かめるまで送信を止めたいとき。

使わない場面

• SMS・push・chat で送りたいとき。この継手は email だけで、ほかの channel は範囲外です。
• 到達の確認（D-05）や、bounce・苦情の判定（D-06）をこの継手にさせたいとき。これらは核の側で、この継手はその結果を受け取るだけです。
• Cc・Bcc で複数の相手に送りたいとき。To はちょうど 1 つで pin した宛先と一致する必要があり、Cc・Bcc・Resent-* は送りません。
• 送信の成功を、到達や承認として扱いたいとき。送れたことは到達ではなく、到達は承認ではありません。同意も Authority ではありません。
• すぐに使えるメール backend がほしいとき。実メール backend（SMTP・各社の API）は含まず、どれにつなぐかはまだ決まっていません。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。

検査すること

• 宛先の偽装を検めます。To が pin した宛先と合わない、To が 2 つある、Cc・Bcc がある、ヘッダーに CR/LF の注入があるメールは送りません。pin していない宛先にも送りません。
• 同意を検めます。同意の無い送信、検証されていない同意での送信は送りません。
• bounce・苦情を記録した宛先には送りません。
• 本文を検めます。digest と合わない本文（改ざん）や、上限を超える大きさの本文は送りません。
• 二重送信を検めます。同じ idempotency_key はもう一度送りません（ALREADY_SENT）。
• 受領（NotificationReceipt）を照合します。request_digest を偽った受領、証拠の無い delivered、UNKNOWN を送信に格上げした受領、side effect の食い違いは受理せず、以後は停止します（HALTED）。
• backend の障害は UNKNOWN とし、送信として扱いません。再送は照会（lookup）で解きます。
• 秘密の渡し方を検めます。SecretRef の隣に生の秘密を置いた要求は拒否します。

しないこと・既知の限界

• 宛先の許可・配信の同意・本文の最小化を決めるのは核（policy-facts・consent-facts・redact-facts）の役目です。この継手は、その結果を受け取って検めるだけです。
• 送れたことは到達ではありません（REQUESTED は delivered: false）。どの結果も承認ではありません（approval: false）。
• 実メール backend（SMTP・各社の API）を含みません。port の実装と pin する対象は未定で、接続するときに別の関門で決めます。
• email 以外の channel（SMS・push・chat）は扱いません。
• 到達の確認（D-05）と、bounce・苦情の判定（D-06）はしません。その結果を受け取るだけです。
• 契約を変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• メール API の使い方の雛形ではありません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/request-receipt-group/v1 でつなぎます。createMailClient({ cfg, port }) の send(NotificationRequest, bytes, verifiedConsents) は、SENT・ALREADY_SENT・FAILED・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED のどれかを返します（どれにも approval: false）。bounce・苦情は recordSuppression で渡します。利用側が用意するもの: メール backend への port（send と、任意で lookup）。副作用は取り消せない外部への送信（EXTERNAL_IRREVERSIBLE）。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

SMS を送るとき、pin していない番号や形の崩れた番号（E.164 でない番号）へ送ってしまうこと、同意や最小化の記録が無いまま送ること、同じ通知を二度送ること、そして「依頼した」を「届いた」「読まれた」と取り違えることを防ぎます。

使う場面

• 通知の SMS を、pin した宛先表の番号（E.164）にだけ送りたいとき。
• 送る前に、検証済みの同意と本文の最小化の記録があることを確かめたいとき（どちらも設定で必須にできます）。
• 同じ通知を二度送りたくないとき。冪等キーを必須にし、受領が確定しないまま再送する場合は照会（lookup）で解きます。
• 不達・苦情のあった宛先に、以後は送りたくないとき（recordSuppression）。
• 依頼した・届いた・読まれた・確認されたを、それぞれの証拠で分けて扱いたいとき。

使わない場面

• 本人確認に使いたいとき。この継手は SMS の通知要求を運ぶ継手で、本人確認の機能は含みません。SMS が届いた・読まれたことは、本人を確かめたことではありません。
• メール・Webhook の channel で送りたいとき。channel は sms・push だけです。D-01 は mail 継手、D-04 は notify 継手です。
• 送れたこと・届いたことを、承認や決裁として扱いたいとき。送れた・届いたは承認ではありません。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。
• すぐに使える送信基盤がほしいとき。実の送信基盤（どの SMS のサービスか）は含まず、まだ決まっていません。

検査すること

• 宛先を検めます。pin した宛先表に無い宛先、止めた宛先（不達・苦情）、要求の channel と宛先の channel が合わないもの、email・webhook の channel の要求は送りません。
• 宛先表の形を検めます。SMS の宛先は E.164（+ と国番号から 7〜15 桁）で、表に 1 件でも形の崩れた宛先（E.164 でない・空白を含む）があれば、表全体を使いません。
• SMS の本文を検めます。UTF-8 として正しくない本文、改行のほかの制御文字を含む本文は送りません。
• 本文の digest の改ざんと、上限（max_payload_bytes）を超える本文を送りません。
• 同意と最小化を検めます。設定で必須にしたとき、同意が無い・検証されていない要求、最小化の記録が無い要求は送りません。
• 冪等キーの無い要求は送りません。同じ冪等キーは二度送りません（ALREADY_SENT）。
• 送信基盤の認証は SecretRef の場所だけを運びます。SecretRef の欄に秘密そのものが入った要求は送りません。
• 受領（NotificationReceipt）を照合します。証拠の無い到達・既読・確認の状態、message_id の無い送信、side effect の食い違い、request_digest の偽りは受理せず、そのあとは停止します（HALTED）。送信基盤の障害は UNKNOWN とし、送信として扱いません。

しないこと・既知の限界

• 本人確認はしません。SMS の通知要求を運ぶ継手で、本人確認の機能は含みません。届いた・読まれたは、本人の確認ではありません。
• 送れたことは到達ではありません。SENT の delivered は、到達の証拠がある状態のときだけ true です。依頼しただけ（REQUESTED）は届いたではありません。
• SMS の文字数（分割・文字コードによる上限）は見ません。上限は bytes だけです。
• 同意が有効か・最小化が十分かを決めるのは核（consent-facts・redact-facts）の役目で、宛先の許可は policy-facts の役目です。この継手がするのは、送る前と受け取った後の検めだけです。
• 実の送信基盤を含みません。どのサービスにつなぐか、port の実装と宛先表は未定で、接続するときに別の関門で決めます。
• 送れた・届いたは承認ではありません（approval: false）。
• 契約を変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/request-receipt-group/v1（channel sms）でつなぎます。createSmsPushClient({ cfg, port }) の send(NotificationRequest, bytes, verifiedConsents) は、SENT・ALREADY_SENT・FAILED・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED のどれかを返します（どれにも approval: false）。利用側が用意するもの: 送信基盤への port（send と、任意で lookup）と、cfg の宛先表 recipients。副作用は取り消せない外部への送信（EXTERNAL_IRREVERSIBLE）。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

push 通知を送るとき、本文に送り先（token・to・topic など）を入れて pin していない端末へ差し替えてしまうこと、同意や最小化の記録が無いまま送ること、同じ通知を二度送ること、そして「依頼した」を「届いた」「読まれた」と取り違えることを防ぎます。

使う場面

• push 通知を、pin した宛先表の端末の参照（空白の無い参照）にだけ送りたいとき。
• 送り先は宛先表だけで決め、本文（JSON）から送り先を変えさせたくないとき。
• 送る前に、検証済みの同意と本文の最小化の記録があることを確かめたいとき（どちらも設定で必須にできます）。
• 同じ通知を二度送りたくないとき。冪等キーを必須にし、受領が確定しないまま再送する場合は照会（lookup）で解きます。
• 不達・苦情のあった宛先に、以後は送りたくないとき（recordSuppression）。
• 依頼した・届いた・読まれた・確認されたを、それぞれの証拠で分けて扱いたいとき。

使わない場面

• push の本文の中身の意味（通知として正しいか）を確かめたいとき。この継手が止めるのは送り先の差し替えだけです。
• メール・Webhook の channel で送りたいとき。channel は sms・push だけです。D-01 は mail 継手、D-04 は notify 継手です。
• 送れたこと・届いたことを、承認や決裁として扱いたいとき。送れた・届いたは承認ではありません。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。
• すぐに使える送信基盤がほしいとき。実の送信基盤（どの push のサービスか）は含まず、まだ決まっていません。

検査すること

• 宛先を検めます。pin した宛先表に無い宛先、止めた宛先（不達・苦情）、要求の channel と宛先の channel が合わないもの、email・webhook の channel の要求は送りません。
• 宛先表の形を検めます。push の宛先は空白の無い端末の参照で、表に 1 件でも形の崩れた宛先があれば、表全体を使いません。
• push の本文を検めます。UTF-8 の JSON オブジェクトでない本文と、token・to・topic・registration_ids・condition・target を持つ本文（送り先の差し替え）は送りません。
• 本文の digest の改ざんと、上限（max_payload_bytes）を超える本文を送りません。
• 同意と最小化を検めます。設定で必須にしたとき、同意が無い・検証されていない要求、最小化の記録が無い要求は送りません。
• 冪等キーの無い要求は送りません。同じ冪等キーは二度送りません（ALREADY_SENT）。
• 送信基盤の認証は SecretRef の場所だけを運びます。SecretRef の欄に秘密そのものが入った要求は送りません。
• 受領（NotificationReceipt）を照合します。証拠の無い到達・既読・確認の状態、message_id の無い送信、side effect の食い違い、request_digest の偽りは受理せず、そのあとは停止します（HALTED）。送信基盤の障害は UNKNOWN とし、送信として扱いません。

しないこと・既知の限界

• 送れたことは到達ではありません。SENT の delivered は、到達の証拠がある状態のときだけ true です。依頼しただけ（REQUESTED）は届いたではありません。
• push の本文の中身の意味（通知として正しいか）は見ません。止めるのは送り先の差し替えだけです。
• 同意が有効か・最小化が十分かを決めるのは核（consent-facts・redact-facts）の役目で、宛先の許可は policy-facts の役目です。この継手がするのは、送る前と受け取った後の検めだけです。
• 実の送信基盤を含みません。どのサービスにつなぐか、port の実装と宛先表は未定で、接続するときに別の関門で決めます。
• 送れた・届いたは承認ではありません（approval: false）。
• 契約を変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 特定の SMS・push サービスの使い方の雛形ではありません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/request-receipt-group/v1（channel push）でつなぎます。createSmsPushClient({ cfg, port }) の send(NotificationRequest, bytes, verifiedConsents) は、SENT・ALREADY_SENT・FAILED・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED のどれかを返します（どれにも approval: false）。利用側が用意するもの: 送信基盤への port（send と、任意で lookup）と、cfg の宛先表 recipients。副作用は取り消せない外部への送信（EXTERNAL_IRREVERSIBLE）。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

連携の裏配管として外部へ通知を送るとき、pin していない宛先（任意の URL）へ送ってしまうこと（SSRF）、許可していないイベントを送ってしまうこと、同じ通知を二重に送ってしまうこと、署名の無い payload を送ってしまうことを、送る前の判定で防ぎます。

使う場面

• 自分の送信処理の前に置いて、Webhook などの通知を送ってよいかを判定させたいとき。
• 送り先を pin した宛先の集合に限り、任意の URL への送出を拒否したいとき（anti-SSRF）。
• 送ってよいイベントの種別を、許可した一覧（allowlist）に限りたいとき。
• もう送った冪等キーの集合を自分で持っていて、同じ通知の二重送信を送る前に止めたいとき。

使わない場面

• Webhook を実際に送る部品、失敗したときに再送する部品、payload に署名する部品がほしいとき。この継手はどれもしません。送る前の判定だけです。
• 送った通知が届いたかを、受領（receipt）で確かめたいとき。到達の receipt の検めは含みません。
• payload の署名そのものを検めたいとき。署名済みかどうかは、呼び出し側が渡す真偽値（payload_signed）で判定します。
• 冪等キーや署名の要求を外したまま使うとき。require_idempotency_key・require_signed_payload を false にすると、その検めが外れます。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。

検査すること

• 宛先を検めます。pin した宛先の集合の外への通知は、送らないと判定します（任意の URL への送出を拒否。SSRF）。
• イベントを検めます。許可していないイベント種別の通知は、送らないと判定します。
• 冪等キーを検めます。冪等キーの無い通知は、送らないと判定します（require_idempotency_key が既定の true のとき）。
• 署名を検めます。payload_signed が真でない（未署名の）通知は、送らないと判定します（require_signed_payload が既定の true のとき）。
• 重複を検めます。渡された「もう送った冪等キーの集合」にあるキーの通知は、二重送信として送らないと判定します。

しないこと・既知の限界

• Webhook を送信しません。失敗したときの再送もしません。payload に署名もしません。これらは利用側が行います。
• 到達の受領（receipt）を検めません。この継手がするのは送る前の判定だけです。
• 冪等キーと署名の要求は設定で外せます。require_idempotency_key・require_signed_payload を false にすると、その検めが外れ、冪等キーの欠落・未署名を理由には止めなくなります（どちらも既定は true）。
• もう送った冪等キーの集合（delivered）を保持しません。呼び出し側が渡します。
• 実際の配信 API と署名の方式は決めていません。配備するときに config で決めます。
• 配信の同意や承認の経路、配信の来歴は核（consent-facts・provenance-facts）の側です。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 通知 API の使い方の雛形ではありません。

つなぎ方

入口は src/guards.js の evaluate(cfg, request, delivered)（純粋な関数。送る前の判定）です。request に { recipient, event_type, idempotency_key, payload_signed }、delivered にもう送った冪等キーの集合 { key: 1 } を渡すと、送ってよければ { ok: true, errors: [] }、だめなら { ok: false, errors: [...] } を返します。cfg は allowed_recipients・allowed_events・require_idempotency_key・require_signed_payload。port は無く、送信・再送・署名・receipt の検めは利用側が用意します。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

届いた・読まれたを事実として残すとき、問い合わせた段とは別の段の証拠を受け取ってしまうこと、そして配信の証拠から業務の受け入れを導いてしまうことを防ぎます。

使う場面

• 届いた・読まれた・確認されたを、段ごとの証拠として基盤に問い合わせ、照合してから記録したいとき。
• 上の段の確認から、下の段の確認や業務の受け入れを推し量らせたくないとき。
• 同意や監査のために、依頼しただけの状態と届いた状態を分けて残したいとき。
• 受領に不整合が出たら、そこで止めたいとき（HALTED）。
• 同じ問い合わせを二度送りたくないとき。受領が確定しないまま再送する場合は照会（lookup）で解きます。

使わない場面

• 受け取った側が処理したか（業務として受け入れたか）を確かめたいとき。この継手は確かめません。
• メッセージの本文を載せたいとき。この継手はメッセージの中身を扱わず、参照だけを運びます。
• 通知そのものを送りたいとき。送信は D-01 の mail 継手、D-02・D-03 の SMS と push の継手、D-04 の notify 継手が担います。
• 届いたことを、承認や決裁として扱いたいとき。届いたは承認ではありません。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。
• すぐに使える基盤がほしいとき。実の基盤（どの配信の証拠の仕組みか）は含まず、まだ決まっていません。

検査すること

• 問い合わせた段（evidence_kind）の証拠だけを受理します。別の段の証拠を返す受領は受理せず、停止します。
• 業務の受け入れを名乗る受領（配信の証拠から業務の受け入れを導くもの）は受理せず、停止します。
• 参照を検めます。空の参照、パス（.. を含む）の参照、追加のフィールドは拒否します。空の一覧は何も許しません。
• side effect を検めます。配信の証拠の問い合わせは side effect 無し（NONE）です。外への効果を増やす受領と、効果が不明（UNKNOWN）な受領は受理しません。
• 別の要求の受領（request_digest の偽り）は受理しません。照合できない受領のあとは停止します（HALTED）。
• 同じ request_id は二度送りません。基盤の障害は UNKNOWN とし、再送は照会（lookup）で解きます。

しないこと・既知の限界

• 配信の証拠を自ら作る仕組みは含みません。配信の証拠の問い合わせを基盤へ運び、戻った受領を照合するだけです。どの配信の証拠の仕組みにつなぐかは未定で、接続するときに別の関門で決めます。
• 届いた・読まれた・確認されたは、業務の受け入れではありません。受け取った側が処理したかは確かめません。
• 業務の受け入れの判断は核と人の役目です。この継手がするのは、送る前と受け取った後の検めだけです。
• 届いたは承認ではありません（approval: false）。
• 契約を変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 特定のキューやメッセージ基盤の使い方の雛形ではありません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/messaging-ext/v1 でつなぎます。createMessagingExtClient({ cfg, port }) の submit(request) に DeliveryEvidence の要求 を渡すと、DONE・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED のどれかを返します（どれにも approval: false）。DONE の result には evidence_kind・evidence_state・confirmed・business_acceptance が付きます。利用側が用意するもの: 基盤への port（submit と、任意で lookup）と、cfg で pin する一覧。副作用は 無し（NONE）。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

不達・スパム申告（苦情）を記録するとき、一時的な保留まで宛先を止める理由にしてしまうこと、効果が不明な受領や別の要求の受領を受け取ってしまうこと、同じ記録を二度送ることを防ぎます。

使う場面

• 不達・スパム申告（苦情）を基盤に記録し、止めた状態（suppression_state・suppressed）を受け取りたいとき。
• 一時的な保留（DEFERRAL）では宛先を止めたくないとき。
• 止めた宛先を、利用側で送信の継手（mail・SMS と push）へ渡したいとき。この継手は、渡すための状態を返します。
• 受領に不整合が出たら、そこで止めたいとき（HALTED）。

使わない場面

• 送信の停止まで任せたいとき。この継手は状態を返すだけで、止めた宛先を送信の継手（mail・SMS と push）へ渡すのは利用側の役目です。
• メッセージの本文を載せたいとき。この継手はメッセージの中身を扱わず、参照だけを運びます。
• 止めたことを、承認や決裁として扱いたいとき。どの結果も承認ではありません。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。
• すぐに使える基盤がほしいとき。実の基盤（どのキュー・発行購読・配信の証拠の仕組みか）は含まず、まだ決まっていません。

検査すること

• 一時的な保留（DEFERRAL）で宛先を止めようとする記録は拒否します。DEFERRAL と、止めない記録（NOT_SUPPRESSED）の side effect は無し（NONE）です。
• side effect を検めます。不達・苦情の記録の side effect は NONE か EXTERNAL_REVERSIBLE です。意図より外への効果を増やす受領と、効果が不明（UNKNOWN）な受領は受理しません。
• 参照を検めます。空の参照、パス（.. を含む）の参照、追加のフィールドは拒否します。空の一覧は何も許しません。
• 別の要求の受領（request_digest の偽り）は受理しません。照合できない受領のあとは停止します（HALTED）。
• 同じ request_id は二度送りません。基盤の障害は UNKNOWN とし、再送は照会（lookup）で解きます。

しないこと・既知の限界

• 止めた宛先を送信の継手（mail・SMS と push）へ渡しません。この継手は状態を返すだけです。
• 不達・苦情の記録を運ぶ継手で、苦情の中身の判断や送信の評価（レピュテーション）の管理の機能は含みません。
• 止める・再送するの方針を決めるのは核（policy-facts）と人の役目です。この継手がするのは、送る前と受け取った後の検めだけです。
• 実の基盤を含みません。port の実装と pin する一覧は未定で、接続するときに別の関門で決めます。
• どの結果も承認ではありません（approval: false）。
• 契約を変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 特定のキューやメッセージ基盤の使い方の雛形ではありません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/messaging-ext/v1 でつなぎます。createMessagingExtClient({ cfg, port }) の submit(request) に BounceComplaint の要求を渡すと、DONE・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED のどれかを返します（どれにも approval: false）。DONE の result には event・suppression_state・suppressed が付きます。利用側が用意するもの: 基盤への port（submit と、任意で lookup）と、cfg で pin する一覧。副作用は NONE か EXTERNAL_REVERSIBLE。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

非同期の受け渡しにキューを使うとき、pin していないキューへ積むこと、同じメッセージを二重に積むこと、同じ冪等キーで別の中身を積むこと、そして積んだことを受け取った側の処理と取り違えることを防ぎます。

使う場面

• 非同期の受け渡しで、pin したキューにだけ積み（ENQUEUE）・取り出し（DEQUEUE）・ACK を運びたいとき。
• 同じメッセージを二重に積みたくないとき。ENQUEUE には idempotency_key を必須にし、重複（DEDUP_HIT）は新しい効果なしとして扱います。
• 受領の状態が操作（op）に対応しているかを確かめてから受け取りたいとき。
• 受領に不整合が出たら、そこで止めたいとき（HALTED）。

使わない場面

• 取り出した側が処理したか（業務として受け入れたか）を確かめたいとき。この継手は確かめません。
• メッセージの本文を載せたいとき。この継手はメッセージの中身を扱わず、参照だけを運びます。
• 積んだことを、承認や決裁として扱いたいとき。積んだは承認ではありません。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。
• すぐに使える基盤がほしいとき。実の基盤（どのキューの仕組みか）は含まず、まだ決まっていません。

検査すること

• pin していないキューへの要求は送りません。
• 参照を検めます。空の参照、パス（.. を含む）の参照、追加のフィールドは拒否します。空の一覧は何も許しません。
• idempotency_key の無い ENQUEUE は送りません。同じ冪等キーで別の中身の要求は送りません（REFUSED）。
• 重複（DEDUP_HIT）なのに新しい効果が付いた受領と、DEQUEUE への DEDUP_HIT は受理しません。
• 操作に対応しない状態の受領は受理しません（ENQUEUE→ENQUEUED か DEDUP_HIT、DEQUEUE→DEQUEUED、ACK→ACKED、または FAILED だけ）。
• side effect を検めます。キューの操作は EXTERNAL_REVERSIBLE（DEDUP_HIT・FAILED は NONE）です。意図より外への効果を増やす受領と、効果が不明（UNKNOWN）な受領は受理しません。
• 別の要求の受領（request_digest の偽り）は受理しません。照合できない受領のあとは停止します（HALTED）。
• 同じ request_id は二度送りません。基盤の障害は UNKNOWN とし、再送は照会（lookup）で解きます。

しないこと・既知の限界

• キューそのものは含みません。キューへの出し入れの要求を運ぶ継手です。どの基盤につなぐか、port の実装と pin する一覧は未定で、接続するときに別の関門で決めます。
• 積んだこと・取り出したことは、受け取った側が処理したこと（業務として受け入れたこと）ではありません。確かめません。
• 重複の検出や、止める・再送するの方針を決めるのは核（reconcile-facts・policy-facts）と人の役目です。この継手がするのは、送る前と受け取った後の検めだけです。
• 積んだは承認ではありません（approval: false）。
• 契約を変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 特定のキューやメッセージ基盤の使い方の雛形ではありません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/messaging-ext/v1 でつなぎます。createMessagingExtClient({ cfg, port }) の submit(request) に Queue の要求 を渡すと、DONE・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED のどれかを返します（どれにも approval: false）。DONE の result には queue_state が付きます。利用側が用意するもの: 基盤への port（submit と、任意で lookup）と、cfg で pin する一覧。副作用は EXTERNAL_REVERSIBLE（DEDUP_HIT・FAILED は NONE）。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

1 対多の配信に発行と購読を使うとき、pin していない話題への発行・購読、スキーマを pin していないイベントの発行、そして発行したことを購読側が受け取ったことと取り違えることを防ぎます。

使う場面

• pin した話題にだけ、発行（PUBLISH）・購読（SUBSCRIBE）・購読の解除（UNSUBSCRIBE）を運びたいとき。
• 発行するイベントに、pin したイベントのスキーマ（event_schema_ref）を必ず付けたいとき。
• 発行したことと、受け取られたことを分けて扱いたいとき。
• 同じ発行を二度送りたくないとき。受領が確定しないまま再送する場合は照会（lookup）で解きます。
• 受領に不整合が出たら、そこで止めたいとき（HALTED）。

使わない場面

• 購読側が受け取ったか・処理したかを確かめたいとき。received は観測しておらず（NOT_OBSERVED）、業務として受け入れたかも確かめません。
• メッセージの本文を載せたいとき。この継手はメッセージの中身を扱わず、参照だけを運びます。
• 発行したことを、承認や決裁として扱いたいとき。発行したは承認ではありません。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。
• すぐに使える基盤がほしいとき。実の基盤（どの発行購読の仕組みか）は含まず、まだ決まっていません。

検査すること

• pin していない話題、pin していないイベントのスキーマへの要求は送りません。
• イベントのスキーマ（event_schema_ref）の無い PUBLISH は送りません。
• 参照を検めます。空の参照、パス（.. を含む）の参照、追加のフィールドは拒否します。空の一覧は何も許しません。
• 操作に対応しない状態の受領は受理しません（PUBLISH→PUBLISHED、SUBSCRIBE→SUBSCRIBED、UNSUBSCRIBE→UNSUBSCRIBED、または FAILED だけ）。
• side effect を検めます。発行と購読は EXTERNAL_REVERSIBLE（FAILED は NONE）です。意図より外への効果を増やす受領と、効果が不明（UNKNOWN）な受領は受理しません。
• 別の要求の受領（request_digest の偽り）は受理しません。照合できない受領のあとは停止します（HALTED）。
• 同じ request_id は二度送りません。基盤の障害は UNKNOWN とし、再送は照会（lookup）で解きます。

しないこと・既知の限界

• 発行と購読の要求を基盤へ運ぶ継手で、1 対多に配る（ファンアウト）機能そのものは含みません。
• 発行したことは、受け取られたことではありません（received: NOT_OBSERVED）。
• 実の基盤を含みません。どの発行購読の仕組みにつなぐか、port の実装と pin する一覧は未定で、接続するときに別の関門で決めます。
• 業務の受け入れの判断は核と人の役目です。この継手がするのは、送る前と受け取った後の検めだけです。
• 発行したは承認ではありません（approval: false）。
• 契約を変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 特定のキューやメッセージ基盤の使い方の雛形ではありません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/messaging-ext/v1 でつなぎます。createMessagingExtClient({ cfg, port }) の submit(request) に PubSub の要求 を渡すと、DONE・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED のどれかを返します（どれにも approval: false）。DONE の result には pubsub_state・received: NOT_OBSERVED が付きます。利用側が用意するもの: 基盤への port（submit と、任意で lookup）と、cfg で pin する一覧。副作用は EXTERNAL_REVERSIBLE（FAILED は NONE）。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

失敗したメッセージの退避にデッドレターを使うとき、pin していないデッドレターを操作すること、設定で許していないのに取り消せない消去（PURGE）をしてしまうこと、そして効果が意図より大きい受領を受け取ってしまうことを防ぎます。

使う場面

• 失敗したメッセージの退避のために、pin したデッドレターへの PARK・REDRIVE を運びたいとき。
• 取り消せない消去（PURGE）を、設定で明示して許したときだけ運びたいとき（allow_purge の既定は false）。
• 同じ操作を二度送りたくないとき。受領が確定しないまま再送する場合は照会（lookup）で解きます。
• 受領に不整合が出たら、そこで止めたいとき（HALTED）。

使わない場面

• 消してよいかの判断を任せたいとき。消してよいかの判断は核と人の役目です。
• メッセージの本文を載せたいとき。この継手はメッセージの中身を扱わず、参照だけを運びます。
• 退避・消去の成功を、承認や決裁として扱いたいとき。どの結果も承認ではありません。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。
• すぐに使える基盤がほしいとき。実の基盤（どのデッドレターの仕組みか）は含まず、まだ決まっていません。

検査すること

• pin していないデッドレターへの要求は送りません。
• 設定 allow_purge: true でないときの PURGE は送りません。
• 参照を検めます。空の参照、パス（.. を含む）の参照、追加のフィールドは拒否します。空の一覧は何も許しません。
• 操作に対応しない状態の受領は受理しません（PARK→PARKED、REDRIVE→REDRIVEN、PURGE→PURGED、または FAILED だけ）。
• side effect を検めます。PARK・REDRIVE は EXTERNAL_REVERSIBLE、PURGE は EXTERNAL_IRREVERSIBLE、FAILED は NONE です。意図より外への効果を増やす受領と、効果が不明（UNKNOWN）な受領は受理しません。
• 別の要求の受領（request_digest の偽り）は受理しません。照合できない受領のあとは停止します（HALTED）。
• 同じ request_id は二度送りません。基盤の障害は UNKNOWN とし、再送は照会（lookup）で解きます。

しないこと・既知の限界

• PURGE で消したものは取り消せません（EXTERNAL_IRREVERSIBLE）。この継手は、設定で許したかを検めるだけです。
• デッドレターの操作の要求を運ぶ継手で、失敗したメッセージを自ら見つけて退避する機能は含みません。
• 消してよいかの判断は核と人の役目です。この継手がするのは、送る前と受け取った後の検めだけです。
• 実の基盤を含みません。port の実装と pin する一覧は未定で、接続するときに別の関門で決めます。
• どの結果も承認ではありません（approval: false）。
• 契約を変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 特定のキューやメッセージ基盤の使い方の雛形ではありません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/messaging-ext/v1 でつなぎます。createMessagingExtClient({ cfg, port }) の submit(request) に DeadLetter の要求 を渡すと、DONE・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED のどれかを返します（どれにも approval: false）。DONE の result には dlq_state が付きます。利用側が用意するもの: 基盤への port（submit と、任意で lookup）と、cfg で pin する一覧。副作用は PARK・REDRIVE が EXTERNAL_REVERSIBLE、PURGE が EXTERNAL_IRREVERSIBLE。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

毎日・毎時の起動を外部のスケジューラに任せるとき、pin していない予定や起動の指定を登録してしまうこと、止めた予定に次の起動が残っていると読み違えること、受領を照合しないまま「登録できた」と扱うことを防ぎます。登録できたことを業務の許可と取り違えないための検めです。

使う場面

• 毎日・毎時の起動の予定を外部のスケジューラに登録・更新・停止するとき、要求を pin した予定（schedule_refs）と起動の指定（trigger_spec_refs）で検めてから送りたいとき。
• スケジューラの受領をそのまま信じず、受領の状態が要求（op）に対応するもの（REGISTER→REGISTERED、UPDATE→UPDATED、DISABLE→DISABLED）か、効果のない FAILED かを照合してから扱いたいとき。
• 同じ要求を二度送りたくないとき。結果が分からなかった送信は照会（lookup）で解きます。
• 受領が照合できないとき、以後の送信を止めたいとき（HALTED）。

使わない場面

• 予定どおりに起動したかを確かめたいとき。この継手が見るのは登録の受領だけで、起動したかどうかは見ません。
• スケジューラそのものがほしいとき。実の実行基盤は含まず、どのスケジューラにつなぐかはまだ決まっていません。
• 予定を登録できたことを、その仕事を実行してよいという業務の許可として扱いたいとき。何をいつ実行してよいかの決定は核（policy-facts）の役目です。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。

検査すること

• 参照を検めます。pin していない予定・起動の指定、空の参照、パスや .. を含む参照は送りません。空の一覧は何も許しません。
• 受領の状態は、要求（op）に対応するもの（REGISTER→REGISTERED、UPDATE→UPDATED、DISABLE→DISABLED）か、効果のない FAILED（副作用なし・次の起動なし）だけを受け取ります。それ以外は受理しません。
• 止めた・失敗した予定に次の起動（next_fire_ref）が付いた受領を受理しません。
• 受領の request_id・request_digest・参照が要求と一致しないとき（request_digest の偽り）、受理しません。
• 外への効果を増やす受領と、効果が分からない（UNKNOWN）受領を受理しません。効果は、どこまで及ぶかと取り消せるかの両方で、要求の意図以下でなければなりません。
• 受領が照合できなければ停止し（HALTED）、以後は送りません。同じ request_id は二度送らず、実行基盤の障害は UNKNOWN として照会（lookup）で解きます。

しないこと・既知の限界

• 予定どおりに起動したかは見ません（登録の受領だけを見ます）。起動そのものは実行基盤が行います。
• 何をいつ実行してよいかの決定（policy-facts）と重複の検出（reconcile-facts）は核の役目です。業務の許可・再試行の許可・補償の承認は核と人の役目で、この継手がするのは送る前と受け取った後の検めだけです。
• 積めた・実行できた・完了したは承認ではありません。どの結果にも approval: false が付きます。
• 実の実行基盤（どのスケジューラ・キュー・ロックの仕組みか）を含みません。port の実装と pin する一覧は未定で、接続するときに別の関門で決めます。
• 契約を変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 特定のスケジューラやキューの使い方の雛形ではありません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/workflow-jobs/v1 でつなぎます。createWorkflowClient({ cfg, port }) の submit(request) に ScheduleTrigger の要求を渡すと、DONE・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED のどれかを返します。DONE に schedule_state・next_fire_ref を添えます。利用側が用意するもの: 実行基盤への port（submit、任意で lookup）と cfg の schedule_refs・trigger_spec_refs。副作用は EXTERNAL_REVERSIBLE（重複・拒否・失敗は NONE）。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

リマインドのように後で実行する仕事を外部の実行基盤に預けるとき、pin していないジョブを積むこと、同じ仕事を二重に積むこと、失敗した積み込みに worker が割り当たったと読み違えることを防ぎます。積めたことを業務の許可と取り違えないための検めです。

使う場面

• N 分後に実行する仕事を外部の実行基盤に預けるとき、pin したジョブ（job_refs）だけを送りたいとき。
• 同じ仕事を二重に積みたくないとき。重複（DEDUP_HIT）は新しい効果なしとして受け取り、同じ冪等キーで別の中身は送りません。
• 実行基盤の受領をそのまま信じず、契約どおりに照合してから積めたとしたいとき。
• 結果が分からなかった送信を、二度送らずに照会（lookup）で解きたいとき。

使わない場面

• 積んだ仕事が予定の時刻に実行されたかを確かめたいとき。この継手が見るのは積み込みの受領だけで、実行されたかは見ません。
• 時間を待って実行する仕組みそのものがほしいとき。実の実行基盤は含まず、どの仕組みにつなぐかはまだ決まっていません。
• 積めたことを、その仕事を実行してよいという業務の許可として扱いたいとき。何をいつ実行してよいかの決定は核（policy-facts）の役目です。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。

検査すること

• 参照を検めます。pin していないジョブ、空の参照、パスや .. を含む参照は送りません。空の一覧は何も許しません。
• 同じ冪等キーで別の中身の要求は送りません。重複（DEDUP_HIT）に新しい効果が付いた受領は受理しません。
• 失敗した積み込みに worker の割当て（worker_assignment_ref）が付いた受領を受理しません。
• 受領の状態が要求に対応しないとき、受理しません。
• 受領の request_id・request_digest・参照が要求と一致しないとき（request_digest の偽り）、受理しません。
• 外への効果を増やす受領と、効果が分からない（UNKNOWN）受領を受理しません。効果は、どこまで及ぶかと取り消せるかの両方で、要求の意図以下でなければなりません。
• 受領が照合できなければ停止し（HALTED）、以後は送りません。同じ request_id は二度送らず、実行基盤の障害は UNKNOWN として照会（lookup）で解きます。

しないこと・既知の限界

• 積んだ仕事が実行されたかは見ません（積み込みの受領だけを見ます）。時間を待って実行するのは実行基盤です。
• 何をいつ実行してよいかの決定（policy-facts）と重複の検出（reconcile-facts）は核の役目です。業務の許可・再試行の許可・補償の承認は核と人の役目で、この継手がするのは送る前と受け取った後の検めだけです。
• 積めた・実行できた・完了したは承認ではありません。どの結果にも approval: false が付きます。
• 実の実行基盤（どのスケジューラ・キュー・ロックの仕組みか）を含みません。port の実装と pin する一覧は未定で、接続するときに別の関門で決めます。
• 契約を変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 特定のスケジューラやキューの使い方の雛形ではありません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/workflow-jobs/v1 でつなぎます。createWorkflowClient({ cfg, port }) の submit(request) に DelayedJob の要求を渡すと、DONE・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED のどれかを返します。DONE に enqueue_state・worker_assignment_ref を添えます。利用側が用意するもの: 実行基盤への port（submit、任意で lookup）と cfg の job_refs。副作用は EXTERNAL_REVERSIBLE（重複・拒否・失敗は NONE）。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

重い処理を後ろで回すためにキューへ積むとき、途中で改ざんされた中身や大きすぎる中身を積むこと、同じタスクを二重に積むこと、失敗した積み込みに worker が割り当たったと読み違えることを防ぎます。

使う場面

• 重い処理を後ろで回すため、pin したキュー（queue_refs）にだけタスクを積みたいとき。
• キューに積む中身（bytes）の digest と上限（max_payload_bytes）を、送る前に自分で確かめたいとき。
• 同じタスクを二重に積みたくないとき。重複（DEDUP_HIT）は新しい効果なしとして受け取り、同じ冪等キーで別の中身は送りません。
• 結果が分からなかった送信を、二度送らずに照会（lookup）で解きたいとき。

使わない場面

• 積んだタスクが実行されたかを確かめたいとき。この継手が見るのは積み込みの受領だけで、実行されたかは見ません。
• キューの仕組みそのものがほしいとき。実の実行基盤は含まず、どのキューにつなぐかはまだ決まっていません。
• 積めたことを、その処理を実行してよいという業務の許可として扱いたいとき。何をいつ実行してよいかの決定は核（policy-facts）の役目です。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。

検査すること

• 参照を検めます。pin していないキュー、空の参照、パスや .. を含む参照は送りません。空の一覧は何も許しません。
• 中身を検めます。要求の payload_digest（対象は task_ref）と中身の bytes が合わないとき（改ざん）は送りません。TaskEnqueue は bytes が必須です。
• 上限（max_payload_bytes）を超える中身は送りません。
• 同じ冪等キーで別の中身の要求は送りません。重複（DEDUP_HIT）に新しい効果が付いた受領は受理しません。
• 失敗した積み込みに worker の割当て（worker_assignment_ref）が付いた受領を受理しません。
• 受領の request_id・request_digest・参照が要求と一致しないとき（request_digest の偽り）、受理しません。
• 外への効果を増やす受領と、効果が分からない（UNKNOWN）受領を受理しません。効果は、どこまで及ぶかと取り消せるかの両方で、要求の意図以下でなければなりません。
• 受領が照合できなければ停止し（HALTED）、以後は送りません。同じ request_id は二度送らず、実行基盤の障害は UNKNOWN として照会（lookup）で解きます。

しないこと・既知の限界

• 積んだタスクが実行されたかは見ません（積み込みの受領だけを見ます）。タスクを実行するのは実行基盤です。
• 何をいつ実行してよいかの決定（policy-facts）と重複の検出（reconcile-facts）は核の役目です。業務の許可・再試行の許可・補償の承認は核と人の役目で、この継手がするのは送る前と受け取った後の検めだけです。
• 積めた・実行できた・完了したは承認ではありません。どの結果にも approval: false が付きます。
• 実の実行基盤（どのスケジューラ・キュー・ロックの仕組みか）を含みません。port の実装と pin する一覧は未定で、接続するときに別の関門で決めます。
• 契約を変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 特定のスケジューラやキューの使い方の雛形ではありません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/workflow-jobs/v1 でつなぎます。createWorkflowClient({ cfg, port }) の submit(request, bytes) に TaskEnqueue の要求と bytes（必須）を渡すと、DONE・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED のどれかを返します。DONE に enqueue_state・worker_assignment_ref を添えます。利用側が用意するもの: 実行基盤への port（submit、任意で lookup）と cfg の queue_refs・max_payload_bytes（必須）。副作用は EXTERNAL_REVERSIBLE（重複・拒否・失敗は NONE）。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

多段処理が途中で失敗して巻き戻すとき、補償の参照が無い補償を送ること、効果の分からない手順や取り消せない手順を許しなく送ること、補償できたことを人の取消しの承認として扱ってしまうことを防ぎます。

使う場面

• 多段処理の手順を、pin したサガ（saga_refs）と手順（step_refs。補償の手順も含む）だけで送りたいとき。
• 途中失敗の巻き戻しで、補償の要求（COMPENSATE）を補償の手順の参照つきでだけ送りたいとき。
• 受領の手順の状態が要求に対応するか（FORWARD→EXECUTED・FAILED・SKIPPED、COMPENSATE→COMPENSATED・FAILED・SKIPPED）を照合したいとき。
• 取り消せない効果の手順を、設定で明示したとき（allow_irreversible: true）だけ送りたいとき。既定は false です。

使わない場面

• 補償できたことを、人の取消しの承認として扱いたいとき。承認は核と人の役目で、受領からは NOT_DERIVED だけを受け取ります。
• 手順を実行できたことを、業務の許可として扱いたいとき。業務の許可を導く受領は受理しません。
• サガの調停（多段処理の状態機械）そのものがほしいとき。調停は実行基盤の側で、実の実行基盤は含まず、どれにつなぐかはまだ決まっていません。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。

検査すること

• 参照を検めます。pin していないサガや手順、空の参照、パスや .. を含む参照は送りません。空の一覧は何も許しません。
• 補償の手順の参照が無い補償（COMPENSATE）は送りません。
• 意図した効果が UNKNOWN の手順は送りません。取り消せない効果の手順は、設定 allow_irreversible: true のときだけ送ります。
• 受領の手順の状態が要求に対応しないとき、受理しません。
• 補償の承認や業務の許可を導く受領を受理しません（NOT_DERIVED だけを受け取ります）。
• 受領の request_id・request_digest・参照が要求と一致しないとき（request_digest の偽り）、受理しません。
• 外への効果を増やす受領と、効果が分からない（UNKNOWN）受領を受理しません。効果は、どこまで及ぶかと取り消せるかの両方で、要求の意図以下でなければなりません。
• 受領が照合できなければ停止し（HALTED）、以後は送りません。同じ request_id は二度送らず、実行基盤の障害は UNKNOWN として照会（lookup）で解きます。

しないこと・既知の限界

• サガの調停（多段処理の状態機械）は実行基盤の役目で、この継手は持ちません。巻き戻しそのものも行わず、補償の要求を検めて送り、受領を照合するだけです。
• 補償できても人の取消しの承認ではありません。成功はどれも承認ではなく、どの結果にも approval: false が付きます。
• 何をいつ実行してよいかの決定（policy-facts）と重複の検出（reconcile-facts）は核の役目です。業務の許可・再試行の許可・補償の承認は核と人の役目で、この継手がするのは送る前と受け取った後の検めだけです。
• 実の実行基盤（どのスケジューラ・キュー・ロックの仕組みか）を含みません。port の実装と pin する一覧は未定で、接続するときに別の関門で決めます。
• 契約を変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 特定のスケジューラやキューの使い方の雛形ではありません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/workflow-jobs/v1 でつなぎます。createWorkflowClient({ cfg, port }) の submit(request) に SagaStep の要求を渡すと、DONE・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED のどれかを返します。DONE に step_state・compensation_authorization・business_authorization を添えます。利用側が用意するもの: 実行基盤への port（submit、任意で lookup）と cfg の saga_refs・step_refs・allow_irreversible。副作用は手順ごとの意図どおり（SKIPPED は NONE）。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

同時実行の排他を外部のロックの仕組みに任せるとき、他の holder のロックに触ること、期限の無いロックや上限を超える期限のロックを取ること、結果が分からない（UNKNOWN）ときに「持っている」と読み違えることを防ぎます。持っていないロックを持っていると扱わないための検めです。

使う場面

• 同時実行の排他を外部のロックの仕組みに任せるとき、pin したロック（lock_refs）を、この継手の holder（holder_ref）だけで扱いたいとき。
• ロックに期限を付け、期限の上限（max_lock_ttl_seconds）を超えない ACQUIRE・RENEW だけを送りたいとき。
• 「持っている」（held: true）を、受領の状態が ACQUIRED・HELD のときだけにしたいとき。UNKNOWN からは導きません。
• fencing token（fencing_token_ref）を、持っているロック（ACQUIRED・HELD）の受領でだけ受け取りたいとき。

使わない場面

• この継手でリーダー選出（E-06）をしたいとき。この継手の契約にリーダー選出の種類は無く、選出の任期や他の持ち主の観測も持ちません。E-06 は、この継手の分散ロックを束ねる部品(Component)（リーダー選出の部品）が担います。
• 排他が正しく守られることを、この継手に頼りたいとき。ロックの排他の正しさは実行基盤の役目で、この継手は holder と期限と受領の整合だけを見ます。
• ロックの仕組みそのものがほしいとき。実の実行基盤は含まず、どのロックの仕組みにつなぐかはまだ決まっていません。
• ロックを持てたことを、その処理を実行してよいという業務の許可として扱いたいとき。何をいつ実行してよいかの決定は核（policy-facts）の役目です。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。

検査すること

• 参照を検めます。pin していないロック、空の参照、パスや .. を含む参照は送りません。空の一覧は何も許しません。
• この継手の holder ではない holder のロックの要求は送りません。他が持っていれば DENIED で、効果なしとして受け取ります。
• 期限の無い ACQUIRE・RENEW と、上限（max_lock_ttl_seconds）を超える期限の要求は送りません。
• 受領の状態が要求に対応しないとき（ACQUIRE→ACQUIRED・HELD・DENIED・UNKNOWN、RENEW→HELD・EXPIRED・DENIED・UNKNOWN、RELEASE→RELEASED・EXPIRED・DENIED・UNKNOWN 以外）、受理しません。
• 解放したロックなど、持っていないロックに fencing token が付いた受領を受理しません。UNKNOWN から「持っている」を導きません。
• リーダー選出（E-06）の種類の要求は、この継手の契約に種類が無いので受け付けません。
• 受領の request_id・request_digest・参照が要求と一致しないとき（request_digest の偽り）、受理しません。
• 外への効果を増やす受領と効果が分からない（UNKNOWN）受領を受理せず、照合できない受領で停止します（HALTED）。同じ request_id は二度送らず、実行基盤の障害は UNKNOWN として照会（lookup）で解きます。

しないこと・既知の限界

• リーダー選出はしません。E-06 は、この継手を束ねる部品(Component)（リーダー選出の部品）が担います。この継手自身には選出の種類はありません。
• ロックの排他の正しさは実行基盤の役目です。この継手は holder と期限と受領の整合だけを見ます。
• 何をいつ実行してよいかの決定（policy-facts）と重複の検出（reconcile-facts）は核の役目です。業務の許可・再試行の許可・補償の承認は核と人の役目で、この継手がするのは送る前と受け取った後の検めだけです。
• 積めた・実行できた・完了したは承認ではありません。どの結果にも approval: false が付きます。
• 実の実行基盤（どのスケジューラ・キュー・ロックの仕組みか）を含みません。port の実装と pin する一覧は未定で、接続するときに別の関門で決めます。
• 契約を変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 特定のスケジューラやキューの使い方の雛形ではありません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/workflow-jobs/v1 でつなぎます。createWorkflowClient({ cfg, port }) の submit(request) に Lock の要求を渡すと、DONE・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED のどれかを返します。DONE に lock_state・held・fencing_token_ref を添えます。利用側が用意するもの: 実行基盤への port（submit、任意で lookup）と cfg の lock_refs・holder_ref・max_lock_ttl_seconds。副作用は EXTERNAL_REVERSIBLE（重複・拒否・失敗は NONE）。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

可用性の裏で、同じロックを取り合う 2 つの参加者が同時にリーダーを名乗ること（ロックの基盤が正しいとき）、受領の遅れの分だけ期限を長く見てしまうこと、fencing token の無いままリーダーを名乗ることを防ぎます。

使う場面

• 冗長な構成で、処理を 1 つの参加者だけに動かしたいとき。E-05 分散ロックの継手のクライアント（submit(LockRequest) を持つもの）を lock として注入します。
• 立候補（campaign）・期限の前の更新（renew）・降りる（resign）・今リーダーかの確認（status）を、例外を投げない操作で行いたいとき。
• リーダーのときに fencing token（fencing_token_ref）を受け取り、書込み先に渡したいとき。leader が true のときは必ず fencing_token_ref があります。
• 期限を、ロックを頼む前に読んだ時刻 + ttl − 安全余裕で短く見積もりたいとき。時刻は注入した単調な時計（clock.now()）だけから取ります。
• 降りたら、ロックの解放の結果によらず、手元ではすぐリーダーでないことにしたいとき。

使わない場面

• リーダーであることを、権限や承認として使いたいとき。どの結果にも approval: false と authority: NOT_DERIVED が付きます。
• 古いリーダーの書込みを、この部品で止めたいとき。fencing token で古いリーダーの書込みを止めるのは書込み先の役目で、この部品は token を渡すだけです。
• 「リーダー」を、ロックの基盤の最新の状態そのものとして扱いたいとき。「リーダー」はこの参加者の手元の判定です。
• 再起動をまたいでリーダーを続けたいとき。状態はこのプロセスの中だけで、再起動の後は立候補し直すまでリーダーでありません。
• 本物のロックの基盤で確かめた部品が要るとき。本物の基盤には一度も接続しておらず、代役のロックだけで確かめました。
• Node.js v24.21.0 のほかの版で使うとき。ほかの版は確かめていません（NOT_VERIFIED）。

検査すること

• options が足りない・形が違うとき（ttl が 1〜3600 の外、安全余裕が ttl 以上、submit の無い lock、now の無い clock、.. を含む参照）、INVALID_OPTIONS で止めます。
• 前の操作が終わっていないとき、2 つ目を BUSY で止めます（同時に 1 つの操作だけ）。
• リーダーでないのに更新しようとしたとき NOT_LEADER、期限を過ぎてからの更新のとき LEASE_EXPIRED で、ロックへ送りません。ロックが基盤の側で切れていたときも LEASE_EXPIRED です。
• ほかの参加者がロックを握っているとき LOCK_DENIED、結果が DONE でないとき（UNKNOWN・REFUSED・ALREADY_DONE・HALTED など）や held が true でないとき LOCK_UNKNOWN で、リーダーでないとします。
• 握れたのに fencing token が無いとき NO_FENCING_TOKEN、ロックのクライアントが例外を投げたとき PORT_FAILED で、リーダーを名乗りません。
• 時計が戻ったとき、リースを捨てて CLOCK_WENT_BACKWARDS で止めます。
• 期限を延ばすのは、status が DONE で held が true、かつ fencing token があるときだけです。同じロックを取り合う 2 つの参加者が同時にリーダーを名乗らないことを、ファズで毎回確かめました。

しないこと・既知の限界

• リーダー選出の部品は継手ではありません。自分の Request/Receipt は無く、ロックの取得・更新・解放という外への効果は、束ねた E-05 の継手が自分の契約（workflow-jobs/v1）で起こします。この部品自身は外へ触れません。
• 束ねた E-05 の継手の意味（受領の照合・承認ではない）は、継手の側に残ります。
• リーダーであることは権限でも承認でもありません（approval: false・authority: NOT_DERIVED、derives_authority: false）。
• fencing token を使った書込みの守りはしません。古いリーダーの書込みを止めるのは書込み先の役目です。
• ロックの基盤の正しさ（線形化・時計のずれ・分断のときの振る舞い）は確かめません。安全性は、その正しさと、呼び出し側が決める安全余裕の見積もりに頼ります。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 特定の調整サービスの使い方の雛形ではありません。

つなぎ方

src/leader.js の createLeaderElection(options) で作ります。受け取るのは lock_ref・holder_ref・ttl_seconds・renew_margin_ms・lock・任意の clock と timestamp で、{ ok, errors, instance } を返します。campaign・renew・resign（Promise）と status は { ok, errors, leader, fencing_token_ref, approval: false, … } を返します。利用側が用意する port は lock.submit(request)（E-05 の継手のクライアント）です。副作用は束ねた継手が起こし（EXTERNAL_REVERSIBLE）、資格情報は port が持ちます。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

連打や多重起動を抑える判定を外部の実行基盤に任せるとき、pin していない方針で問い合わせること、許可（ALLOW）の判定に再試行の時刻（retry_after_ref）が付いた食い違った受領を受け取ること、受領を照合しないまま判定を使うことを防ぎます。

使う場面

• 連打・多重起動の抑制の判定を、pin した間引きの方針（throttle_policies）でだけ実行基盤に問い合わせたいとき。
• 実行基盤の判定をそのまま信じず、要求と受領の一致（request_id・request_digest）を照合してから使いたいとき。
• 間引きの問い合わせを、外への効果なし（NONE）として扱いたいとき。効果の付いた受領は受理しません。

使わない場面

• 間引きの判定そのものをこの継手に期待するとき。判定は実行基盤の役目で、実の実行基盤は含まず、どれにつなぐかはまだ決まっていません。
• デバウンス専用の要求の種類を求めるとき。契約の種類は間引き（Throttle）で、デバウンス専用の種類はありません。
• 判定の許可（allowed）を、その処理を実行してよいという業務の許可として扱いたいとき。何をいつ実行してよいかの決定は核（policy-facts）の役目です。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。

検査すること

• 参照を検めます。pin していない間引きの方針、空の参照、パスや .. を含む参照は送りません。空の一覧は何も許しません。
• 許可（ALLOW）の判定に再試行の時刻（retry_after_ref）が付いた受領を受理しません。
• 受領の状態が要求に対応しないとき、受理しません。
• 受領の request_id・request_digest・参照が要求と一致しないとき（request_digest の偽り）、受理しません。
• 外への効果を増やす受領と、効果が分からない（UNKNOWN）受領を受理しません。効果は、どこまで及ぶかと取り消せるかの両方で、要求の意図以下でなければなりません。
• 受領が照合できなければ停止し（HALTED）、以後は送りません。同じ request_id は二度送らず、実行基盤の障害は UNKNOWN として照会（lookup）で解きます。

しないこと・既知の限界

• 間引きの判定はしません。判定は実行基盤が行い、この継手は要求を検めて送り、受領の判定を照合するだけです。
• 何をいつ実行してよいかの決定（policy-facts）と重複の検出（reconcile-facts）は核の役目です。業務の許可・再試行の許可・補償の承認は核と人の役目で、この継手がするのは送る前と受け取った後の検めだけです。
• 積めた・実行できた・完了したは承認ではありません。どの結果にも approval: false が付きます。
• 実の実行基盤（どのスケジューラ・キュー・ロックの仕組みか）を含みません。port の実装と pin する一覧は未定で、接続するときに別の関門で決めます。
• 契約を変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 特定のスケジューラやキューの使い方の雛形ではありません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/workflow-jobs/v1 でつなぎます。createWorkflowClient({ cfg, port }) の submit(request) に Throttle の要求を渡すと、DONE・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED のどれかを返します。DONE に decision・allowed・retry_after_ref を添えます。利用側が用意するもの: 実行基盤への port（submit、任意で lookup）と cfg の throttle_policies。副作用は無し（NONE）。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

「終わった?」に答えるためにジョブの状態を実行基盤に尋ねるとき、完了を業務の受け入れと、再試行できるを再試行の許可と取り違えること、たどれない失敗の参照を受け取ることを防ぎます。

使う場面

• 進捗・完了の確認を、pin したジョブ（job_refs）でだけ実行基盤に問い合わせたいとき。
• 失敗の参照（failure_ref）を、ai-execution-error の記録へ解決できるときだけ受け取りたいとき。
• 完了や再試行できるを、業務の受け入れ・再試行の許可と分けて扱いたいとき。受領からは NOT_DERIVED だけを受け取ります。
• 照会を外への効果なし（NONE）として扱いたいとき。効果の付いた受領は受理しません。

使わない場面

• 失敗の記録の中身を検めたいとき。failure_ref が指す ai-execution-error の記録の中身は検めません（解決できるかだけを見ます）。
• 完了を業務の受け入れとして、再試行できるを再試行の許可として扱いたいとき。どちらも核と人の役目です。
• ジョブの状態を持つ仕組みそのものがほしいとき。実の実行基盤は含まず、どれにつなぐかはまだ決まっていません。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。

検査すること

• 参照を検めます。pin していないジョブ、空の参照、パスや .. を含む参照は送りません。空の一覧は何も許しません。
• failure_ref が解決できないとき、または解決の手段（port.resolveFailureRef）が無いときは受領を受理せず、以後は停止します（HALTED）。
• failure_ref は FAILED・CANCELLED のときだけ受け取ります。
• 再試行の許可や業務の受け入れを導く受領を受理しません（NOT_DERIVED だけを受け取ります）。
• 受領の状態が要求に対応しないとき、受理しません。UNKNOWN の状態から実行や許可を導きません。
• 受領の request_id・request_digest・参照が要求と一致しないとき（request_digest の偽り）、受理しません。
• 外への効果を増やす受領と、効果が分からない（UNKNOWN）受領を受理しません。効果は、どこまで及ぶかと取り消せるかの両方で、要求の意図以下でなければなりません。
• 受領が照合できなければ停止し（HALTED）、以後は送りません。同じ request_id は二度送らず、実行基盤の障害は UNKNOWN として照会（lookup）で解きます。

しないこと・既知の限界

• failure_ref が指す ai-execution-error の記録の中身は検めません（解決できるかだけを見ます）。
• 完了は業務の受け入れではなく、再試行できるは再試行の許可ではありません。成功はどれも承認ではなく、どの結果にも approval: false が付きます。
• 何をいつ実行してよいかの決定（policy-facts）と重複の検出（reconcile-facts）は核の役目です。業務の許可・再試行の許可・補償の承認は核と人の役目で、この継手がするのは送る前と受け取った後の検めだけです。
• 実の実行基盤（どのスケジューラ・キュー・ロックの仕組みか）を含みません。port の実装と pin する一覧は未定で、接続するときに別の関門で決めます。
• 契約を変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 特定のスケジューラやキューの使い方の雛形ではありません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/workflow-jobs/v1 でつなぎます。createWorkflowClient({ cfg, port }) の submit(request) に JobStatus の要求を渡すと、DONE・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED のどれかを返します。DONE に status・retryable・failure_ref・retry_authorization・business_acceptance を添えます。利用側が用意するもの: 実行基盤への port（submit、任意で lookup、failure_ref があるとき必須の resolveFailureRef）と cfg の job_refs。副作用は無し（NONE）。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

集計表の数字がどの入力から出たかは、表に出ません。この部品は、入力の集合・集計器の版・出力のハッシュを系譜として残します。あわせて、検めていない入力で集計すること、集計器に保管物を書き換えさせること、出力で入力の場所を上書きすることを防ぎます。

使う場面

• 1〜1000 個の入力（key と sha256）を検めて読み、信頼できる集計器 fn で集計し、出力を out/<tool ref>/<入力の集合の digest>/<出力の sha256>.json に 1 回だけ書きたいとき（run）。
• fn に、キーの順の凍った配列 [{ key, sha256, data }] だけを渡し、元の bytes や読んだ値そのものは渡したくないとき。
• 出力の隣に、入力の Ref（<key>@sha256:<hex>）・集計器の ref と version・出力のハッシュを結んだ系譜の記録を残したいとき。
• ほかの集計器の出力を、次の集計の入力にしたいとき。出力の場所は集計器ごとで、自分の出力の場所と重ならない入力は読めます。
• 結果の分からなかった書込を、同じ要求で送り直したいとき（resolvePending）。同じ run をもう一度すれば、出力は DEDUP_HIT になります。

使わない場面

• 信頼できない集計器を隔離して動かしたいとき。fn は同じプロセスで動き、process・require・グローバルの値・時計・乱数・ネットワークに触れられ、時間とメモリの上限もありません。この部品が守るのは「入力を書き換えさせない」ことだけです。
• 集計の正しさや、fn が決定的であることを確かめたいとき。系譜は使った入力・集計器の版・出力のハッシュの記録で、集計の正しさの証明ではありません。
• fn に小数を返させたいとき。出力は RFC 8785（rfc8785-restricted/v1）なので、小数は受け取りません。
• 入力・出力の大きさの上限をこの部品に任せたいとき。上限は読出しと書込の継手の設定で決めます。
• 入力の JSON の重複したキーや、安全な整数を超える数を検めたいとき。JSON.parse のとおりに読み、fn に渡る値として検めません。
• Node.js v24.21.0 のほかの版で使うとき。ほかの版は確かめていません（NOT_VERIFIED）。

検査すること

• options が足りない・形が違うとき INVALID_OPTIONS、run の入力の形が違うとき INVALID_INPUT、同じキーが 2 回以上あるとき DUPLICATE_INPUT、入力のキーが出力の場所 out/<tool ref> と同じかその下にあるとき INPUT_OUTPUT_OVERLAP で、何も読みません。
• C-01 の継手が NOT_FOUND を返したとき INPUT_NOT_FOUND、GET_REJECTED を返した・自分で計算し直した sha256 が違うとき INPUT_DIGEST_MISMATCH、結果が分からないとき READ_UNKNOWN、送らなかったとき READ_REFUSED、停止・形の違いのとき READ_FAILED で、fn を呼ばず何も書きません。
• 入力の bytes が UTF-8 の JSON でないとき（BOM を含む）、INPUT_NOT_JSON で fn を呼びません。
• fn が例外を投げたとき（凍った入力を strict mode で書き換えようとした場合を含む）AGGREGATOR_FAILED、fn の値が RFC 8785 で正準化できない・同期の値でないとき OUTPUT_NOT_JSON（reason を添える）で、何も書きません。
• H-10 が例外を投げたとき LINEAGE_FAILED、ok: true を返さないとき LINEAGE_REFUSED、記録の形や count・出力の digest と大きさ・tool・recorded_at・schema が今回の実行と合わないとき LINEAGE_INVALID で、何も書きません。
• 書込の結果が分からないとき WRITE_UNKNOWN で保留にし、保留の間の run を WRITE_PENDING で止めます。送らなかったとき WRITE_REFUSED、停止・結果が APPLIED か DEDUP_HIT でないとき WRITE_FAILED です。
• timestamp が RFC 3339 の UTC（Z）の実在する日時を返さないとき CLOCK_FAILED、前の操作が終わっていないとき BUSY、保留が無いのに resolvePending を呼ぶと NOTHING_PENDING です。

しないこと・既知の限界

• 読み取り専用の集計の実行の部品は継手ではありません。自分の Request/Receipt は無く、書込という外への効果は、束ねた C-05 の継手が自分の契約で起こします（読出しは NONE）。この部品自身は外へ触れません。
• 束ねた部品の意味（読めた ≠ 中身の正しさ・系譜は集計の正しさの証明ではない・書けた ≠ 受け入れ）は、それぞれの部品の側に残ります。集計器そのものと集計の正しさは、この部品に入りません。
• 書けたことは、集計の正しさでも承認でもありません（approval: false・authority: NOT_DERIVED・aggregation_correctness: NOT_VERIFIED、derives_authority: false）。
• fn を隔離しません（sandbox ではありません）。fn の時間とメモリにも上限を設けません。
• C-05 のキーと C-01 の object_ref が同じ保管物を指すか、出力を後で C-01 で読めるかは backend の設定の役目です。
• 本物の object-store・storage-lifecycle の backend と H-10 の本物のコードには、この部品の試験では接続していません。単体試験とファズは代役です。状態（保留の書込）はプロセスの中だけで、再起動で消えます。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 特定の集計ツール・BI の雛形ではありません。

つなぎ方

src/sandbox-run.js の createSandboxRun(options) で作り、{ ok, errors, instance } を返します。options は output_target・request_prefix・ports・任意の timestamp です。run({ inputs, aggregator: { ref, version, fn } }) は、書けたとき output_key・lineage_key・written などを添え、結果に approval: false が付きます。port は read.get（C-01 の継手のクライアント）・lineage（H-10 の recordLineage）・write.submit（C-05 の継手のクライアント）です。副作用は束ねた継手が起こし、資格情報は port が持ちます。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

予定が「入る」と出た裏で、楽観の長さ（min）で置いたかは見えません。P-05 は工程を duration.min の長さで置くので、この写しを通すと max の長さで置かれます。たとえば不可分の 10〜20 分の工程は 20 分として扱われ、10 分の枠には入りません。どちらの長さで判定したかは、projection_profile と projected_tasks_digest で記録できます。

使う場面

• 工程の並び（0〜200 件）の duration を、見積りの上限 max で置く形に写してから P-05 に渡したいとき（projectDurations）。どの工程も { min, max } なら { max, max } になり、min = max ならそのままです。
• どの工程の長さを変えたかを、元の値つきで残したいとき。projected に、変えた工程だけを { id, from: { min, max }, to: { min, max } } で並びの順に載せます。
• どの入力を P-05 に渡したかを後から照らしたいとき。写した tasks の正準の JSON（キーを UTF-16 の符号単位の順、余白なし）の UTF-8 の sha256 を projected_tasks_digest として返します。
• 長さの分からない工程（{ unknown: true }）を推し量らずにそのまま残し、その id を unknown に並べて受け取りたいとき。
• 工程のほかの欄（requires・resource・window など）を、値として同じまま新しいデータに写したいとき。入力は書き換えません。
• 例外を投げず、状態を持たない処理として、手元で呼びたいとき。時計・乱数・環境の locale を使わず、同じ入力には同じ答えを返します。

使わない場面

• 楽観の長さ（min のまま）で判定したいとき。その判定はこの部品を通しません。P-05 が自分で max を使うのではなく、使う側がこの写しを明示して通します。
• 配置の可否を知りたいとき。この部品は P-05 を呼ばず、配置の可否を言いません。P-05 の答え（feasible など）は P-05 の事実のままです。
• 工程の形（requires・resource・window など）を検めたいとき。そのまま写すだけで、検めるのは P-05 です。
• 見積りの max が正しいかを確かめたいとき。この部品は見ません。
• 200 件を超える工程、100,000,000 分を超える長さ、32 段を超える入れ子の欄を扱いたいとき。決まったコードで止めます。
• Node.js v24.21.0 のほかの版で使うとき。ほかの版は確かめていません（NOT_VERIFIED）。

検査すること

• tasks が素の配列でない（配列の派生クラスを含む）とき INVALID_TASKS、200 件を超えるとき TOO_MANY_TASKS で止めます。
• id が無い・getter・1〜128 の符号単位の文字列でない・単独のサロゲートがあるとき INVALID_ID、同じ id が 2 回あるとき DUPLICATE_ID（2 回目の位置）で止めます。
• duration が無い・getter、{ min, max }（ほかのキーなし）か { unknown: true } でない、min・max が整数でない・範囲の外、min が 1 より小さい、max が min より小さいとき、INVALID_DURATION で止めます。丸めず・詰めません。
• 要素が素のオブジェクトでない（穴・null・継いだもの）、symbol・単独のサロゲートのキー、ほかの欄に getter・関数・undefined・整数でない数・安全でない整数・Date などの素でないオブジェクト・穴、入れ子 32 段を超えるとき、MALFORMED_TASK で止めます。
• 値を調べること自体が例外になるとき（Proxy の罠など）、例外を出さずに INSPECTION_FAILED で止めます。getter は呼びません。
• 止めたときは、決まった順で最初に見つけた 1 件のコードと位置（path。JSON Pointer）を返し、写した tasks は返しません。
• 結果を、別の書き方の独立オラクル（isWellFormed、比較関数での並べ替え、配列の線形の探索）と突き合わせるファズ（1,000,000 回）で、写した tasks・projected・unknown・digest と止めるコード・path の不一致、fail-open が 0 であることを確かめました。
• 本物の P-05（solveSchedule）に不可分の 10〜20 分の工程と 15 分の枠を渡すと、そのままでは feasible、この部品で写した後は infeasible（INDIVISIBLE_TOO_LONG）になることを、手元で 1 例だけ確かめました。

しないこと・既知の限界

• P-05 との結線は手元で 1 例だけ確かめました。部品の束は P-05 を含まないので、単体試験には入っていません。
• 写すのは duration だけです。見積りの max が正しいかも、工程のほかの欄の形も検めません。
• 配置はしません。写した結果は配置の可否ではなく、承認でもなく（result_is_approval: false）、権限も作りません（derives_authority: false）。
• 外の境界・状態・時計・乱数を持ちません。副作用は NONE で、資格情報も使いません。
• 入出力の形は v1 で定めたもので、既存の実装はありません（新規）。P-05 の契約は変えていません。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 特定のスケジューラーの使い方の雛形ではありません。

つなぎ方

src/duration-projection.js の projectDurations(tasks) を呼びます（投げません。入力を書き換えません）。受け取るのは { id, duration, ... } の素のオブジェクトの素の配列（200 件まで）です。返すのは { ok: true, errors: [], projection_profile, tasks, projected, unknown, projected_tasks_digest } か { ok: false, errors: [{ code, path }] }。写した tasks を P-05 に渡すのは使う側です。副作用・状態・外の接続・資格情報は無く、依存は Node.js の組み込みの crypto だけで、利用側が用意する port はありません。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

「制限に達しました」を返す裏側で、1 つのプロセスの中の呼び出しの速さを抑えるときに、丸めで余計に通すこと、足りないのに量を減らしてしまうこと、知らないキーを無限に覚えてメモリーを使い切ることを防ぎます。

使う場面

• 1 つのプロセスの中で、キーごとに呼び出しの回数や量を抑えたいとき（take(key, n)）。
• 止めたときに、待てばちょうど通る最短のミリ秒（retry_after_ms）を返したいとき。1 ms 前では通りません。
• バケットを減らさずに残りを見たいとき（peek は新しいキーを作りません）。キーを忘れて満杯に戻したいとき（reset）、満杯のバケットだけを忘れたいとき（prune）。
• 時計を注入して、試験で結果を決定的にしたいとき。注入した時計の値の列が同じなら、同じ操作の列は同じ結果になります。
• 例外を投げない呼び方が要るとき。ファクトリーとインスタンスのメソッドは例外を投げません。

使わない場面

• 複数のプロセス・マシンで数を共有するレート制限が要るとき。状態はインスタンスごと・このプロセスのメモリーの中だけで、ほかのプロセス・インスタンス・マシンとは共有しません。分散したレート制限ではありません。
• 再起動をまたいで数を残したいとき。プロセスを再起動すると数は消え、すべてのキーが満杯に戻ります。
• プロバイダーのクォータ・上限を問い合わせたり変えたりしたいとき。それは外の境界で、別の継手の役目です。
• 時間の窓で数える方式（固定窓・スライド窓）や、キーごとに違う上限が要るとき。
• スレッド（worker_threads）の間で 1 つのインスタンスを共有したいとき。1 つのイベントループの中で使う前提です。
• Node.js v24.21.0 のほかの版で使うとき。ほかの版は確かめていません（NOT_VERIFIED）。

検査すること

• トークンが足りないとき、RATE_LIMITED と remaining・retry_after_ms を返し、バケットを変えません。
• options がオブジェクトでない・読むと例外が起きるとき INVALID_OPTIONS、知らないオプションのとき UNKNOWN_OPTION、型・範囲が違うとき INVALID_OPTION（field に名前）で止めます。書き間違いを黙って無視しません。
• 空から満杯までの時間が安全な整数のミリ秒を超えるとき、retry_after_ms を正確に返せないので REFILL_TOO_SLOW で止めます。
• key が 1〜256 文字の文字列でないとき INVALID_KEY、n が 1 以上の安全な整数でないとき INVALID_AMOUNT、n が capacity を超えるとき REQUEST_TOO_LARGE で止めます。
• 新しいキーが max_keys を超えるとき、状態を作らずに TOO_MANY_KEYS で止めます。
• 時計が受け取った一番新しい時刻より前に戻ったとき CLOCK_WENT_BACKWARDS、clock.now() が例外を投げたとき CLOCK_FAILED、安全な整数を返さないとき INVALID_CLOCK_VALUE で止めます。

しないこと・既知の限界

• 複数のプロセス・マシンの間で数を共有しません。状態はこのプロセスのメモリーの中だけで、再起動で消えます。分散したレート制限（共有の記憶が要るもの）はこの部品ではありません。
• 名前の「クォータ」のうち、プロバイダーのクォータ・上限の問い合わせや変更はしません。それは外の境界で、別の継手の役目です。この部品はプロセスの中の数え方だけです。
• プロバイダーの API のクォータ・レート制限の数え方と一致するとは確かめていません。
• 進みすぎた時計（未来の値）は見分けられません。既定の時計（process.hrtime.bigint）の単調さは Node.js に任せています。
• 誰にどれだけ許すかという業務の意味は決めません。それは Kernel と使う側の役目です。
• 通したことは、その呼び出しを行ってよいという許可でも、プロバイダーの側のクォータが残っていることの証明でもありません（result_is_approval: false）。権限も作りません（derives_authority: false）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 特定のレート制限のライブラリやサービスの使い方の雛形ではありません。

つなぎ方

src/rate-limit.js の createRateLimiter(options) を呼びます（投げません）。options は { capacity, refill_tokens, refill_interval_ms, max_keys, clock } だけで、clock は任意。返すのは { ok, errors, instance }。instance の take(key, n) は { ok, errors, remaining, retry_after_ms }、peek・reset・prune は remaining・removed・keys を返します。止めたときは errors の code（error_taxonomy）です。副作用（NONE）・外の接続・資格情報・port は無く、状態はプロセスのメモリー、依存は Node.js の組み込みだけです。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

1 つのプロセスの中で、失敗の続く相手への呼び出しを一時止めるときに、前の呼び出しの遅れた結果や前の回の試しで HALF_OPEN が勝手に閉じてしまうこと、止めたときに状態が変わってしまうことを防ぎます。

使う場面

• 1 つのプロセスの中で、失敗の続く相手への呼び出しを一時止めたいとき。呼ぶ前に allow() で聞き、結果を record で渡します。
• 直近 window_size 件の中の FAILURE の件数（failure_threshold 件以上）で OPEN にしたいとき。
• OPEN の間に、次に試せるまでのちょうどのミリ秒（retry_after_ms）を返したいとき。
• HALF_OPEN の試しを trial_id で結びつけ、どの結果がどの試しのものかを取り違えたくないとき。
• 時計を注入して、試験で結果を決定的にしたいとき。乱数を使いません（trial_id は通し番号）。
• 例外を投げない呼び方が要るとき。ファクトリーとインスタンスのメソッドは例外を投げません。

使わない場面

• 複数のプロセス・マシンで状態を共有するブレーカが要るとき。状態はインスタンスごと・このプロセスのメモリーの中だけで、ほかのプロセス・インスタンス・マシンとは共有しません。
• 再起動をまたいで OPEN を保ちたいとき。プロセスを再起動すると CLOSED の空の窓に戻り、相手がまだ落ちていても数え直します。
• 時間の窓（直近 N 秒）・失敗の率・遅い呼び出しで数えたいとき。件数の窓だけです。
• HALF_OPEN で複数の試しの成功を待ってから閉じたいとき。最初に届いた試しの結果で決めます。
• 試しの結果を必ず record できないとき。試しの期限は持たず、結果が来ないと HALF_OPEN_BUSY のまま次の試しを出しません。
• スレッド（worker_threads）の間で 1 つのインスタンスを共有したいとき、または Node.js v24.21.0 のほかの版で使うとき（NOT_VERIFIED）。

検査すること

• OPEN の間、allow() は CIRCUIT_OPEN と retry_after_ms を返します。1 ms 前では試しを出しません。
• 対応する allow の無い結果（HALF_OPEN・OPEN で trial_id が無い、知らない trial_id、前の回や無効になった試しの trial_id、CLOSED で trial_id がある）のとき、数えずに UNKNOWN_TRIAL で止め、状態を変えません。
• この回の試しを half_open_max_trials 件出し終えて結果がまだ来ていないとき、HALF_OPEN_BUSY で止めます。
• record の引数が { outcome, trial_id? } だけのオブジェクトでない・trial_id が文字列でないとき INVALID_RECORD、outcome が "SUCCESS"・"FAILURE" でない（大文字小文字も区別）とき INVALID_OUTCOME で止めます。
• options がオブジェクトでないとき INVALID_OPTIONS、知らないオプションのとき UNKNOWN_OPTION、型・範囲が違うとき（failure_threshold が window_size を超えるものを含む）INVALID_OPTION で止めます。
• 時計が受け取った一番新しい時刻より前に戻ったとき CLOCK_WENT_BACKWARDS、clock.now() が例外を投げたとき CLOCK_FAILED、安全な整数を返さないとき INVALID_CLOCK_VALUE で止めます。

しないこと・既知の限界

• 複数のプロセス・マシンの間で状態を共有しません。状態はこのプロセスのメモリーの中だけで、再起動で消えます。共有するブレーカはこの部品ではありません。
• 名前の「障害の連鎖を止める」のうち、どの結果を失敗とみなすか（例外・応答を見た分類）はしません。呼ぶ側が決めた SUCCESS／FAILURE だけを数えます。
• 止めたときに何をするか（F-07 の代わりの候補・F-03 の再試行など）は決めず、呼び出しそのものもしません。使う側の役目です。
• state() は時計を読みません。open_ms たった後も、allow() を呼ぶまで OPEN を返します。
• 進みすぎた時計（未来の値）は見分けられません。既定の時計（process.hrtime.bigint）の単調さは Node.js に任せています。ほかのサーキットブレーカのライブラリの移り方・既定値と同じだとは言いません。
• allow() が通したことは、その呼び出しを行ってよいという許可でも、相手が回復したことの証明でもありません（result_is_approval: false）。権限も作りません（derives_authority: false）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 特定のサーキットブレーカのライブラリの使い方の雛形ではありません。

つなぎ方

src/circuit-breaker.js の createCircuitBreaker(options) を呼びます（投げません）。options は failure_threshold・window_size・open_ms・half_open_max_trials・clock（任意）だけ。返す instance の allow() は state・trial_id?・retry_after_ms?、record({ outcome, trial_id? }) は state、state() は窓の件数・opened_at などを返します。どれも { ok, errors } を持ち、止めたときは errors の code（error_taxonomy）です。副作用（NONE）・外の接続・資格情報・port は無く、状態はプロセスのメモリーです。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

「たまに直る」一時失敗を再試行するときに、冪等でない操作を再試行してしまうこと、idempotent の言い忘れを通してしまうこと、無限の再試行や遅延の桁あふれを起こすこと、知らないキーを黙って無視することを防ぎます。

使う場面

• 1 つの操作の再試行の回数（max_attempts。最初の試行を含む）と、次の試行の時刻（not_before_ms）を、1 つのプロセスの中で管理したいとき。
• 上限つきの指数バックオフの遅延 min(max_ms, base_ms × multiplier^(attempt-1)) を、整数の ms で計算したいとき（computeDelay は状態を持たない純関数です）。
• jitter "full" で、[0, 遅延] の整数の遅延を注入した乱数で選びたいとき。
• 冪等でない操作は、最初の試行だけを許し、再試行を止めたいとき（idempotent: false）。
• 時計と乱数を注入して、試験で結果を再現したいとき。
• 例外を投げない呼び方が要るとき。工場・computeDelay・インスタンスの操作は例外を投げません。

使わない場面

• 複数のプロセス・インスタンスの再試行の合計を数えたいとき。状態はインスタンスごと・このプロセスのメモリーの中だけで、プロセスやインスタンスをまたいで共有しません。
• 再起動をまたいで試行の回数を残したいとき。状態はプロセスが終われば消えます。
• 操作の実行や、not_before_ms までの待ち（タイマー）を部品に任せたいとき。どちらも呼ぶ側の役目です。
• Equal Jitter・Decorrelated Jitter や、整数でない multiplier（1.5 など）が要るとき。jitter は none と full だけ、multiplier は整数だけです。
• 予測できない乱数の質が要るとき。注入した乱数は、戻り値が範囲の整数かだけを検めます。
• Node.js v24.21.0 のほかの版で使うとき。ほかの版は確かめていません（NOT_VERIFIED）。

検査すること

• idempotent: false の操作で RETRYABLE_FAILURE を記録した後は HALTED になり、次の試行を NOT_IDEMPOTENT で止めます（回数が残っていても）。idempotent が無い・真偽値でないときは INVALID_IDEMPOTENT で止めます（既定値を置きません）。
• not_before_ms より前の試行のとき TOO_EARLY（not_before_ms と retry_after_ms を付けて）、試行の回数が max_attempts に達したとき RETRIES_EXHAUSTED で止めます。
• 試行と記録が交互でないとき（試行中の nextAttempt は ATTEMPT_IN_FLIGHT、試行の無い record は NO_ATTEMPT_IN_FLIGHT）、終わった後の試行・記録は RUN_FINISHED で止めます。
• record の input が { outcome } だけでない、または outcome が SUCCESS・RETRYABLE_FAILURE・FINAL_FAILURE でないとき、INVALID_OUTCOME で止めます。
• options・policy が素のオブジェクトでないとき INVALID_OPTIONS、知らないキーのとき UNKNOWN_OPTION（key を付けて）、attempt・base_ms・max_ms・multiplier・jitter・max_attempts が範囲の外のとき、それぞれの INVALID_* で止めます。
• random が関数でないとき INVALID_RANDOM、[0, 遅延] の整数を返さない・例外を投げたとき RANDOM_OUT_OF_RANGE で止めます。
• clock が now() を持たないとき INVALID_CLOCK、clock.now() が 0 以上の安全な整数を返さない・例外を投げたとき CLOCK_INVALID、前に読んだ値より戻ったとき CLOCK_WENT_BACKWARDS で止めます。
• 止めた操作（ok: false）は、試行の回数・段階・not_before_ms を変えません。

しないこと・既知の限界

• 状態はこのプロセスのメモリーの中だけで、プロセスやインスタンスの間で共有せず、再起動で消えます。複数のプロセスにまたがる再試行の数え方には使えません。
• 名前の「一時失敗の再試行」のうち、再試行の実行はしません。操作の実行と not_before_ms までの待ち（タイマー）は呼ぶ側です。
• 失敗が一時的か（RETRYABLE か FINAL か）、業務として再試行してよいかは決めません。idempotent と outcome は呼ぶ側の申告をそのまま使い、正しいかを確かめません。
• 相手の Retry-After やレート制限の応答は読みません（継手の側）。全体の待ち時間の制限は F-06、呼ぶこと自体を止めるのは F-02 の役目です。
• 時計の単調さは、戻ったときに止めるだけで、保つのは注入した側です。ファズの手本は実装と同じ書き手が同じ仕様から別に書いたもので、仕様の読み違いが両方にあれば見つかりません。
• nextAttempt が ok でも、操作を実行してよいという許可ではありません。retry_allowed: true は業務として再試行すべきかの判断ではありません（result_is_approval: false、derives_authority: false）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 特定のリトライのライブラリの使い方の雛形ではありません。

つなぎ方

src/retry.js の createRetryRun(options) を呼びます（投げない工場）。options は max_attempts・base_ms・max_ms・multiplier・jitter・idempotent（必須）・clock・random だけ。返す instance の nextAttempt() は attempt・not_before_ms、record({ outcome }) は state・retry_allowed、snapshot() は状態を返します。computeDelay(policy, random) は delay_ms を返す純関数です。どれも { ok, errors } を持ち、止めたときは code（error_taxonomy）です。副作用（NONE）・外の接続・資格情報・port は無く、状態はプロセスのメモリーです。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

再送で同じ処理が二重に動くことを防ぐための見分けです。同じ ID で中身の違う要求を、同じものの送り直しとして通すこと、結果の分からない送り直しを新しい実行として扱うこと、形の違う台帳の行を黙って読み飛ばすことを防ぎます。

使う場面

• 新しい要求が、渡された台帳にある要求の送り直しかどうかを、冪等の鍵（段・op_id）と中身の digest（payload_digest）の完全一致で見分けたいとき（classify）。
• 同じものの送り直しに、前の結果の digest を返したいとき。DUPLICATE_SAME の result_digest は、台帳のその行の result_digest そのものです。
• 結果がまだ無い行（result_digest が null）への送り直しを、もう一度動かさない印 DUPLICATE_PENDING として受け取りたいとき。もう一度動かす判断にはせず、照合を待つための印です。
• 同じ ID で中身が違う要求を CONFLICT として見分けたいとき。同じ ID の中身の違いを見ずに、ID だけで重複を決める見分けとは違います。
• 要求の受付（REQUEST）・試行（ATTEMPT）・届け（DELIVERY）を段ごとに別に数えたいとき。段が違えば、同じ op_id でも比べません。counts に段ごとの別々の op_id の数を返します。
• 例外を投げず、入力を書き換えず、状態を持たない処理として、手元で呼びたいとき。同じ入力には同じ答えを返します。

使わない場面

• 台帳の保存・読み出しや、ほかの呼び出し・保存済みの台帳との重複を見たいとき。比べるのは引数の中だけで、台帳を保存・読み出すのは Host など、この部品の外の側です。
• 同時に来た 2 つの要求の競り合いを決めたいとき。どちらを先にするかは、台帳を書く側（Host）が決めます。
• 要求を断る・記録する・知らせる、または送り直しを実行したいとき。CONFLICT は断る要求の印を返すだけで、断る・記録する・知らせるのは使う側の仕事です。送り直しの実行・時計・保存もしません。
• 見た目が同じ op_id（é と e + 結合文字、A と a、前後の空白の違い）を同じものとして扱いたいとき。op_id は UTF-16 の符号単位の完全一致だけで比べます。
• digest を大文字・sha256: の接頭辞つきで渡したいとき。digest は変換せず、小文字 16 進 64 桁のほかは INVALID_DIGEST で止めます。中身から digest を作る規則（正準化 I-08、ハッシュ B-07 など）は使う側が決め、台帳と要求の両方を同じ規則で作ります。
• 100,000 行を超える台帳を 1 回で扱いたいとき。使う側で分けます。分けると、分けた先の行との重複は見分けません。
• Node.js v24.21.0 のほかの版で使うとき。ほかの版は確かめていません（NOT_VERIFIED）。

検査すること

• request が素のオブジェクトでない（継いだもの・クラスのもの・null の原型を含む）、stage・op_id・payload_digest が自分のデータのプロパティでない（無い・getter）とき、MALFORMED_REQUEST で止めます。
• ledger が素の配列でないとき INVALID_LEDGER、100,000 行を超えるとき TOO_MANY_ENTRIES、行が素のオブジェクトでない（穴・getter の行を含む）か 4 つの欄が自分のデータのプロパティでないとき MALFORMED_ENTRY で止めます。
• stage が REQUEST・ATTEMPT・DELIVERY のどれでもない（小文字・箱の文字列を含む）とき INVALID_STAGE、op_id が文字列でない・空のとき INVALID_OP_ID、256 の UTF-16 の符号単位を超えるとき OP_ID_TOO_LONG で止めます。
• payload_digest が小文字 16 進 64 桁の文字列でない（大文字・接頭辞・桁違い・16 進でない・箱の文字列・配列・null）、result_digest がその形の文字列でも null でもないとき、INVALID_DIGEST で止めます。
• 台帳に同じ（段・op_id）の行が 2 回あるとき、中身が同じでも DUPLICATE_LEDGER_ENTRY（2 回目の位置）で止めます。値を調べること自体が例外になるとき（Proxy の罠など）は INSPECTION_FAILED です。
• __proto__・constructor などの名前も、ただの op_id として比べます（Map で比べ、オブジェクトの名前に使いません）。getter は呼びません。
• 止めたときは、決まった順で最初に見つけた 1 件のコードと位置（path。JSON Pointer）を返し、decision などは返しません。
• 結果を、Map も Set も使わずに台帳を前から順に探す書き方の独立オラクルと突き合わせるファズ（1,000,000 回）で、不一致と fail-open が 0 であることを確かめました。

しないこと・既知の限界

• NEW は「渡された台帳に無い」だけで、実行してよいという意味ではありません。渡されていない台帳（ほかの場所・保存前のもの）との重複は分かりません。
• 中身の digest が本当に中身から作られたかは見ません（渡された digest を比べるだけ）。DUPLICATE_SAME の結果の digest が正しいかも見ません。
• 上限ちょうどの 100,000 行を受け取ることは、単体試験だけで確かめました（ファズは上限を超えるものだけ）。
• 外の境界・状態・時計・乱数を持たず、保存もしません。副作用は NONE で、資格情報も使いません。
• 見分けの結果は承認ではなく（result_is_approval: false）、権限も作りません（derives_authority: false）。
• 入出力の形は v1 で定めたもので、既存の実装はありません（新規）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 特定の冪等キーのライブラリの使い方の雛形ではありません。

つなぎ方

src/idempotency-ledger.js の classify(request, ledger) を呼びます（投げません。入力を書き換えません）。受け取るのは { stage, op_id, payload_digest } の素のオブジェクトと、{ stage, op_id, payload_digest, result_digest } の行の素の配列（100,000 行まで）です。返すのは { ok: true, errors: [], decision, matched_index, result_digest, counts } か { ok: false, errors: [{ code, path }] }。副作用・状態・外の接続・資格情報は無く、依存は Node.js の組み込みだけで、利用側が用意する port はありません。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

1 つのプロセスの中で、一部の仕事の暴走が同じプロセスのほかの仕事を巻き添えにしないように区画を分けるときに、上限を超えて枠を渡すこと、二重の release や偽の token で枠を余計に空けてしまうことを防ぎます。

使う場面

• 1 つのプロセスの中で、名前で区切った区画ごとに同時に動かす数と待ち行列の長さを制限したいとき。区画どうしは独立で、ある区画が満杯でもほかの区画に影響しません。
• 満員のときに、待ち行列に入れて FIFO で繰り上げたいとき。release の結果の promoted に繰り上がった token が入り、待っている側は poll で知ります。
• 待たずにすぐ断りたい区画があるとき（max_queue 0）。
• 待ち行列から外したいとき（cancel）。cancel した ticket は繰り上がりません。
• 例外を投げない呼び方が要るとき。工場とインスタンスの操作は例外を投げません。

使わない場面

• 複数のプロセス・マシンをまたぐ同時実行の制限（分散のセマフォ・共有の数え上げ）が要るとき。状態はインスタンスごと・このプロセスのメモリーの中だけで、プロセスやインスタンスをまたいで共有しません。
• 再起動をまたいで枠の数を残したいとき。状態は再起動で消えます。
• 待ちの期限（タイムアウト）が要るとき。待ちすぎを止めるのは F-06 か呼ぶ側です。
• 待っている側を通知・Promise で起こしたいとき。この部品は待っている側を起こしません。
• release を忘れた token の枠を自動で回収したいとき。期限による回収・漏れの検出はありません。
• 優先度・重み・公平さの調整が要るとき。区画の中は FIFO だけです。
• Node.js v24.21.0 のほかの版で使うとき。ほかの版は確かめていません（NOT_VERIFIED）。

検査すること

• 区画の枠も待ち行列も満杯のとき、BULKHEAD_FULL（compartment に名前）で止めます。上限を超えて枠を渡しません。
• このインスタンスが渡した token そのものでないとき（同じ形の偽物・別のインスタンスの物・ticket との取り違え）UNKNOWN_TOKEN、もう release した token のとき TOKEN_ALREADY_RELEASED で止め、枠を空けません。
• このインスタンスが渡した ticket でないとき UNKNOWN_TICKET、cancel 済みのとき TICKET_CANCELLED、繰り上がった後の cancel のとき TICKET_ALREADY_GRANTED で止めます。
• acquire の区画名が作った時の区画に無いとき（constructor・toString などのプロトタイプの名前を含む）、UNKNOWN_COMPARTMENT で止めます。
• options が素のオブジェクトでないとき INVALID_OPTIONS、知らないキーのとき UNKNOWN_OPTION、区画が 0 個か 257 個以上のとき INVALID_COMPARTMENTS、区画名・区画の値・max_concurrent・max_queue の形や範囲が違うとき、それぞれの INVALID_* で止めます。
• clock が now() を持たないとき INVALID_CLOCK、clock.now() が 0 以上の安全な整数を返さない・例外を投げたとき CLOCK_INVALID、前に読んだ値より戻ったとき CLOCK_WENT_BACKWARDS で止めます。
• 止めた操作（ok: false）は、枠・待ち行列・token・ticket を変えません。

しないこと・既知の限界

• 複数のプロセス・マシンの合計は制限しません。状態はこのプロセスのメモリーの中だけで、再起動で消えます。分散の制限は外の境界を持つので、この部品ではなく継手の側です。
• 名前の「一部の暴走を隔離」のうち、暴走の検出や停止はしません。区画ごとに同時に動かす数と待ち行列の長さを制限するだけです。
• 待ちの期限・待っている側の起こし方・release を忘れた枠の回収は持ちません。
• token は同じプロセスの中の取っ手で、所有の証明・権限・実行の許可ではありません。受け取った側がほかへ渡すことは止めません（result_is_approval: false、derives_authority: false）。
• ファズの手本は実装と同じ書き手が同じ仕様から別に書いたもので、仕様の読み違いが両方にあれば見つかりません。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 特定のセマフォ・プールのライブラリの使い方の雛形ではありません。

つなぎ方

src/bulkhead.js の createBulkhead({ compartments, clock? }) を呼びます（投げない工場）。返す instance の acquire(name) は token（queued: false）か ticket（queued: true）、release(token) は compartment・promoted、poll(ticket) は granted と token、cancel(ticket) は compartment、snapshot() は区画ごとの active・queued を返します。どれも { ok, errors } を持ち、止めたときは errors の code（error_taxonomy）です。副作用（NONE）・外の接続・資格情報・port は無く、状態はプロセスのメモリーです。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

1 つのプロセスの中で処理を重ねて呼ぶときに、子の期限が親より延びてしまうこと、時計が戻って期限切れが取り消されてしまうこと、取消しが子孫に伝わらないことを防ぎ、待ちすぎ（ハング）を読み取れるようにします。

使う場面

• 1 つのプロセスの中で、処理の期限を作り、呼び出しの先へ残り時間（remaining_ms）を渡したいとき。外の API を呼ぶ継手に残り時間を渡す側の共通の部品になる候補です。
• 子の期限を min(親の期限, 今 + 自分の timeout) にして、伝播で期限が広がらないようにしたいとき（child）。
• 自分と子孫すべてに取消しの印をつけたいとき（cancel）。cancel は時計を読まないので、時計が壊れていても取消しはできます。
• 期限の状態（ACTIVE・EXPIRED・CANCELLED）と、取消しの理由・由来（SELF・ANCESTOR）を読みたいとき（status・expired）。
• 時計を注入して、試験で結果を決定的にしたいとき。壁時計（Date）・タイマー・乱数は使いません。
• 例外を投げない呼び方が要るとき。工場も instance のメソッドも例外を投げません。

使わない場面

• プロセスをまたぐ・分散した期限の伝播（ヘッダーで送るなど）が要るとき。状態はこのプロセスのメモリーの中だけで、プロセス間・分散の共有も永続化もしません。
• 再起動をまたいで期限を残したいとき。プロセスを終えると状態は消えます。
• 外の処理（相手先の API など）を取り消したいとき。取消しはこのプロセスの中の印だけで、外の取消しは使う側か継手がそれぞれの契約で行います。
• 期限の時刻に知らせ（タイマー）が要るとき。使う側が読んだときに分かるだけです。
• 1 つの木を長く持ち、期限を 10,000 個を超えて作るとき。期限を手放す操作は無く、終わった期限もメモリーに残って数に入ります。
• Node.js v24.21.0 のほかの版で使うとき。ほかの版は確かめていません（NOT_VERIFIED）。

検査すること

• 時計の読みが、その木で読んだ一番大きな値より小さいとき、記録を変えずに CLOCK_WENT_BACKWARDS で止めます。一度 EXPIRED になった期限は ACTIVE に戻りません。
• 期限切れか取消し済みの期限に子を作ろうとしたとき、DEADLINE_ALREADY_OVER で止めます。
• timeout_ms が 1〜2,147,483,647 の安全な整数でないとき（0・負・小数・NaN・文字列・上限超え）、INVALID_TIMEOUT で止めます。
• clock が now() を持たないとき INVALID_CLOCK、clock.now() が投げた・0〜MAX_CLOCK_MS の有限の数を返さないとき INVALID_CLOCK_READING、parent の木と別の clock を渡したとき CLOCK_MISMATCH で止めます。
• parent がこの部品が作った期限の instance でないとき（写しを含む）、INVALID_PARENT で止めます。
• 選択肢がオブジェクトでない・許されないキーがある・読むと投げるとき INVALID_OPTIONS、reason_code が英大文字で始まる英大文字・数字・_ の 1〜64 文字でないとき INVALID_REASON で止めます。
• 木の期限の数が 10,000 個（MAX_DEADLINES_PER_TREE）に達したとき、TOO_MANY_DEADLINES で止めます。

しないこと・既知の限界

• 状態はこのプロセスのメモリーの中だけで、プロセス間・分散で共有せず、プロセスを終えると消えます。名前の「期限伝播」は、このプロセスの中の親から子への伝播だけで、プロセスをまたぐ伝播（ヘッダーで送るなど）はしません。
• 名前の「タイムアウト」のうち、処理を止めることはしません。取消しはこのプロセスの中の印（local_only: true）で、外の処理の取消しや、その成否は扱いません。外の取消しは各継手とその契約の側です。
• 期限の時刻に知らせることはしません（タイマーを持ちません）。
• 注入した時計が本当に単調かは確かめられません（戻った読みを止めるだけ）。既定の時計の単調さは Node.js の process.hrtime.bigint に依ります。どの継手・ライブラリの期限の形とも互換を確かめていません。
• 残り時間・期限切れ・取消しは、この部品の時計と印の上の事実だけで、外の処理が止まったこと・終わったこと・やり直してよいことではありません（result_is_approval: false、derives_authority: false）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 特定のライブラリ（AbortController など）の使い方の雛形ではありません。

つなぎ方

src/deadline.js の createDeadline({ timeout_ms, clock?, parent? }) を呼びます（投げない工場）。返す instance の remaining() は remaining_ms・state、expired() は expired・cancelled・over、child({ timeout_ms }) は子の instance、cancel({ reason_code }) は newly_cancelled・local_only: true、status() は state・deadline_at・cancelled を返します。どれも { ok, errors } を持ち、止めたときは code（error_taxonomy）です。副作用（NONE）・外の接続・資格情報・port は無く、状態はプロセスのメモリーです。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

「一部使えるが動く」ように次の候補へ切り替えるときに、決めていない候補へ移ること、並びを飛ばすこと、許されない失敗のあとで切り替えること、断られた後に別のコードで試し直すこと、作った後に許可リストを書き換えられることを防ぎます。

使う場面

• AI の provider・model、保存先などの切り替えを、外で決めた並びの通りにだけ行わせたいとき。
• 失敗のコードごとに、次の候補へ進んでよいかを決めたいとき。next は、失敗したのが今の候補で、そのコードがすぐ次の候補の allowed_after にあるときだけ、次の候補の id を返します。
• 切り替えの歩数に上限（max_steps、0〜31）を置きたいとき。
• 時計・乱数・環境を使わない、決定的な判定が要るとき。
• 例外を投げない呼び方が要るとき。工場も instance のメソッドも例外を投げません。

使わない場面

• 複数のプロセス・マシンで実行の状態を共有したいとき。状態は実行 1 回分・このプロセスのメモリーの中の instance だけで、プロセス間の共有も永続化もしません。
• 再起動をまたいで今の候補・歩数を残したいとき。プロセスを終えると状態は消えます。
• どの候補を並べるか・どの失敗で切り替えてよいかを部品に決めさせたいとき。それは外（方針・Owner・使う側）で決めます。
• 候補の呼び出し・待ち時間・再試行・遮断まで任せたいとき。期限は F-06、再試行は F-03、遮断は F-02 です。
• Node.js v24.21.0 のほかの版で使うとき。ほかの版は確かめていません（NOT_VERIFIED）。

検査すること

• error_code が、すぐ次の候補の allowed_after に無いとき、FALLBACK_NOT_ALLOWED で止め、その回の実行を終えます。断られた後に別のコードで試し直せません。
• failed_id が今の候補でないとき（前の候補・後の候補・知らない id）、状態を変えずに OUT_OF_ORDER で止めます。
• 今の候補が最後のとき NO_MORE_CANDIDATES、歩数が max_steps に達したとき MAX_STEPS_REACHED で止め、その回の実行を終えます。終わった後の next は RUN_ENDED です。
• first を 2 回呼んだとき ALREADY_STARTED、first の前に next を呼んだとき NOT_STARTED、next の報告が failed_id と error_code だけのオブジェクトでないとき INVALID_REQUEST で止めます。
• candidates が配列でない・空・32 個を超えるとき INVALID_CANDIDATES、id の形が違うとき INVALID_CANDIDATE_ID、同じ id が 2 つあるとき DUPLICATE_CANDIDATE_ID で止めます。
• allowed_after の形が違うとき（形の違うコード・重なるコード・64 個超え・最初の候補で空でない・2 番目からの候補で空）INVALID_ALLOWED_AFTER、max_steps が 0〜31 の安全な整数でないとき INVALID_MAX_STEPS、選択肢の形が違うとき INVALID_OPTIONS で止めます。
• 作った後に呼び出し側が許可リストの配列を書き換えても、結果は変わりません（写しを持ちます）。

しないこと・既知の限界

• 状態は実行 1 回分・このプロセスのメモリーの中だけで、プロセスやマシンの間で共有せず、プロセスを終えると消えます。プロセスをまたぐ・分散した実行の状態は扱いません。
• 名前の「縮退運転」のうち、縮退した動作そのものはしません。provider や model を選ばず・切り替えず・呼び出さず、外で決めた並びの次の id を返すだけです。候補を呼ぶのは使う側と各継手です。
• 許可リストの中身が正しいか（その候補に切り替えてよいか・費用や扱うデータの範囲が同じか）は判断しません。外で決めたものを守るだけです。
• 失敗のコードが本当かは確かめられません。コードの意味も解釈せず、文字列の完全一致だけを見ます。
• 次の候補の id は「外で決めた許可リストの上で次へ進んでよい」ことだけで、その候補を呼んでよい権限・費用の承認・結果の正しさではありません（result_is_approval: false、derives_authority: false）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• どの継手・ライブラリのフォールバックの形とも、互換を確かめていません。

つなぎ方

src/fallback.js の createFallback({ candidates, max_steps }) を呼びます（投げない工場）。candidates は { id, allowed_after } の並び（1〜32 個）です。返す instance の first() は最初の候補 { id }、next({ failed_id, error_code }) は次の候補 { id }・index・step・allowed_by、status() は state（READY・ACTIVE・ENDED）・current・steps・end_code を返します。止めたときは errors の code（error_taxonomy）です。副作用（NONE）・時計・外の接続・資格情報・port は無く、候補を呼び出すのは使う側です。依存は無い純 JS です。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

決済オーソリを外の決済基盤へ運ぶとき、許していないのにお金が動く操作を送ってしまうこと、pin していない支払い方法を使ってしまうこと、そしてお金が動いたか分からない receipt や業務の承認を名乗る receipt を信じてしまうことを防ぎます。決済の成功を業務の承認と取り違えないための検めです。

使う場面

• 決済オーソリ（AUTHORIZE）の要求を外の決済基盤へ運び、戻った receipt が op に合う状態（AUTHORIZED）かを照合してから結果として扱いたいとき。
• お金が動く操作を、設定 allow_money_movement: true で明示的に許したときだけ送りたいとき（既定は送りません）。
• 使ってよい支払い方法を、pin した一覧（method_refs。カード番号ではない参照）に限りたいとき。
• 同じオーソリを二度動かしたくないとき。冪等キーを必須にし、同じ request_id は二度送らず、障害のあとの再送は照会（lookup）で解きます。

使わない場面

• 決済できたことを、業務の承認として扱いたいとき。決済の成功は業務の承認ではありません（business_approval は運びから導きません）。
• 額・通貨・税・手数料の正しさを確かめたいとき。この継手は確かめません（外の判断と人・組織の役目です）。
• オーソリ済みの記録を再起動の後も持ち続けたいとき。記録はこの継手の中だけで、再起動で消えます（永続化は接続するときに別の関門で決めます）。
• すぐに実の決済基盤につなぎたいとき。実の決済基盤・PSP・銀行には一度も接続しておらず、port の実装も含みません。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。

検査すること

• お金を動かす許可を検めます。allow_money_movement が true でないとき、または真偽値でないとき、お金が動く操作は送りません（REFUSED）。
• pin した一覧を検めます。pin していない支払い方法、空・パス・.. を含む参照は送りません。空の一覧は何も許しません。
• 冪等キーを検めます。冪等キーの無いオーソリ、同じキーで別の中身の要求は送りません。
• オーソリの記録を検めます。この継手が AUTHORIZED と照合していない支払いの確定、取消の後の確定、二度目の確定は送りません。
• receipt を照合します。op と合わない状態、辞退なのに効果を名乗る receipt、外への効果を増やす receipt、別の要求の receipt（request_digest の偽り）は受理せず、以後は停止します（HALTED）。
• お金が動いたか分からない receipt（効果 UNKNOWN）は受け取らず、以後は停止します（HALTED）。人の確認へ回します。
• 業務の承認を名乗る receipt は受理しません。
• 同じ request_id は二度送りません。決済基盤の障害は UNKNOWN とし、再送は照会（lookup）で解いて、二度動かしません。

しないこと・既知の限界

• 決済の成功は業務の承認ではありません。どの結果にも approval: false が付きます。業務の承認は核（approval-facts）と人・組織の役目です。
• 実の決済基盤・PSP・銀行には一度も接続していません。実の課金・送金は 0 回です。port の実装、pin する一覧、お金を動かす許可は、接続するときに別の関門で決めます。
• 額・通貨・税・手数料の正しさは確かめません（外の判断と人・組織の役目です）。
• 決済基盤の認証に使う秘密は持ちません。秘密は port 側が持ちます（HELD_BY_PORT）。
• 契約を変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 特定の決済サービスの使い方の雛形ではありません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/payment-rails/v1 でつなぎます。createPaymentRailsClient({ cfg, port }) の submit(request) に PaymentAuthRequest を渡すと、DONE（result に op・auth_state・business_approval）・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED のどれかを返します（どれも approval: false）。利用側が用意するもの: 決済基盤への port（submit、任意で lookup）。副作用: オーソリの操作は EXTERNAL_IRREVERSIBLE、辞退・保留・失敗などは NONE。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

オーソリした支払いを確定・取消するとき、オーソリしていない支払いを確定してしまうこと、取消した支払いを確定してしまうこと、同じ支払いを二度確定してしまうこと、そしてお金が動いたか分からない receipt や業務の承認を名乗る receipt を信じてしまうことを防ぎます。確定できたことを業務の承認と取り違えないための検めです。

使う場面

• この継手でオーソリ（AUTHORIZED と照合済み）した支払いを、確定（CAPTURE→CAPTURED）または取消（VOID→VOIDED）として外の決済基盤へ運び、戻った receipt が op に合う状態かを照合してから結果として扱いたいとき。
• 確定を、設定 allow_money_movement: true で明示的に許したときだけ送りたいとき（既定は送りません）。
• 確定・取消の後に、同じ支払いを二度確定しないようにしたいとき。
• 決済基盤の障害のあとに再送するとき、照会（lookup）で解いて二度動かさないようにしたいとき。

使わない場面

• ほかの経路でオーソリした支払いを確定・取消したいとき。確定・取消は、この継手が AUTHORIZED と照合した支払いだけです。
• オーソリ済みの記録を再起動の後も持ち続けたいとき。記録はこの継手の中だけで、再起動で消えます（永続化は接続するときに別の関門で決めます）。
• 確定できたことを、業務の承認として扱いたいとき。決済の成功は業務の承認ではありません（business_approval は運びから導きません）。
• 額・通貨・税・手数料の正しさを確かめたいとき。この継手は確かめません（外の判断と人・組織の役目です）。
• すぐに実の決済基盤につなぎたいとき。実の決済基盤・PSP・銀行には一度も接続しておらず、port の実装も含みません。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。

検査すること

• オーソリの記録を検めます。この継手が AUTHORIZED と照合していない支払いの確定・取消、取消の後の確定、二度目の確定は送りません（REFUSED）。
• お金を動かす許可を検めます。allow_money_movement が true でないとき、または真偽値でないとき、確定を含むお金が動く操作は送りません（REFUSED）。
• 参照を検めます。空・パス・.. を含む参照は送りません。空の一覧は何も許しません。
• receipt を照合します。op と合わない状態（CAPTURE なら CAPTURED、VOID なら VOIDED でないもの）、辞退なのに効果を名乗る receipt、外への効果を増やす receipt、別の要求の receipt（request_digest の偽り）は受理せず、以後は停止します（HALTED）。
• お金が動いたか分からない receipt（効果 UNKNOWN）は受け取らず、以後は停止します（HALTED）。人の確認へ回します。
• 業務の承認を名乗る receipt は受理しません。
• 同じ request_id は二度送りません。決済基盤の障害は UNKNOWN とし、再送は照会（lookup）で解いて、二度動かしません。

しないこと・既知の限界

• 確定の成功は業務の承認ではありません。どの結果にも approval: false が付きます。業務の承認は核（approval-facts）と人・組織の役目です。
• 実の決済基盤・PSP・銀行には一度も接続していません。実の課金・送金は 0 回です。port の実装、pin する一覧、お金を動かす許可は、接続するときに別の関門で決めます。
• オーソリ済みの支払いの記録は、この継手の中だけに持ちます（再起動で消えます）。永続化はしません（接続するときに別の関門で決めます）。
• 額・通貨・税・手数料の正しさは確かめません（外の判断と人・組織の役目です）。
• 決済基盤の認証に使う秘密は持ちません。秘密は port 側が持ちます（HELD_BY_PORT）。
• 契約を変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 特定の決済サービスの使い方の雛形ではありません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/payment-rails/v1 でつなぎます。createPaymentRailsClient({ cfg, port }) の submit(request) に、op が CAPTURE か VOID の PaymentAuthRequest を渡すと、DONE（result に op・auth_state・business_approval）・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED のどれかを返します（どれも approval: false）。利用側が用意するもの: 決済基盤への port（submit、任意で lookup）。副作用: 確定・取消は EXTERNAL_IRREVERSIBLE、辞退・保留・失敗などは NONE。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

課金を外の決済基盤へ運ぶとき、再送や重複で二度課金してしまうこと、同じキーで別の中身を送ってしまうこと、重複なのに効果を名乗る receipt を信じてしまうことを防ぎます。課金の成功を業務の承認と取り違えないための検めでもあります。

使う場面

• 二重課金を防ぐために、課金の要求に冪等キーを必須にし、同じキーの要求を重複（DEDUP_HIT、新しい効果なし）として扱いたいとき。
• 課金を、設定 allow_money_movement: true で明示的に許したときだけ送りたいとき（既定は送りません）。
• 戻った receipt が要求に合う課金の状態かを照合してから、結果（charge_state・charged）として扱いたいとき。
• 決済基盤の障害のあとに再送するとき、照会（lookup）で解いて二度動かさないようにしたいとき。

使わない場面

• 課金できたことを、業務の承認として扱いたいとき。課金の成功は業務の承認ではありません（business_approval は運びから導きません）。
• 課金と入金の突き合わせをしたいとき。突き合わせは外の判断と人・組織の役目で、この継手はしません（対になる核は reconcile-facts です）。
• 額・通貨・税・手数料の正しさを確かめたいとき。この継手は確かめません。
• すぐに実の決済基盤につなぎたいとき。実の決済基盤・PSP・銀行には一度も接続しておらず、port の実装も含みません。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。

検査すること

• お金を動かす許可を検めます。allow_money_movement が true でないとき、または真偽値でないとき、お金が動く操作は送りません（REFUSED）。
• 冪等キーを検めます。冪等キーの無い課金、同じキーで別の中身の要求は送りません。
• 重複なのに効果を名乗る receipt は受理しません。重複（DEDUP_HIT）の効果は NONE です。
• pin した一覧を検めます。pin していない支払い方法、空・パス・.. を含む参照は送りません。空の一覧は何も許しません。
• receipt を照合します。op と合わない状態、辞退なのに効果を名乗る receipt、外への効果を増やす receipt、別の要求の receipt（request_digest の偽り）は受理せず、以後は停止します（HALTED）。
• お金が動いたか分からない receipt（効果 UNKNOWN）は受け取らず、以後は停止します（HALTED）。人の確認へ回します。
• 業務の承認を名乗る receipt は受理しません。
• 同じ request_id は二度送りません。決済基盤の障害は UNKNOWN とし、再送は照会（lookup）で解いて、二度動かしません。

しないこと・既知の限界

• 課金の成功は業務の承認ではありません。どの結果にも approval: false が付きます。業務の承認は核（approval-facts）と人・組織の役目です。
• 額・通貨・税・手数料の正しさ、明細の突き合わせは確かめません（外の判断と人・組織の役目です）。
• 実の決済基盤・PSP・銀行には一度も接続していません。実の課金・送金は 0 回です。port の実装、pin する一覧、お金を動かす許可は、接続するときに別の関門で決めます。
• 決済基盤の認証に使う秘密は持ちません。秘密は port 側が持ちます（HELD_BY_PORT）。
• 契約を変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 特定の決済サービスの使い方の雛形ではありません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/payment-rails/v1 でつなぎます。createPaymentRailsClient({ cfg, port }) の submit(request) に IdempotentChargeRequest を渡すと、DONE（result に charge_state・charged・business_approval）・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED のどれかを返します（どれも approval: false）。利用側が用意するもの: 決済基盤への port（submit、任意で lookup）。副作用: 課金は EXTERNAL_IRREVERSIBLE、重複・辞退・失敗などは NONE。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

会計の裏で、記載事項の欠けや足りない入力のある請求書が文書・保存・台帳に進んでしまうこと、同じ番号で別の中身の請求書を発行してしまうこと、保存を二重にしてしまうこと、請求書の中身を台帳へ渡してしまうことを防ぎます。

使う場面

• 1 枚の請求書を、計算 → 文書 → 保存 → 記録 の順で、前の段が済んでから次の段へ進めて発行したいとき（issue）。
• 税の事実を G-07 の computeInvoiceTax で出させ、need_input や記載事項の欠けがあれば、文書を作らずにそのまま need_input・missing に添えて受け取りたいとき。invoice・tax_table・taxpayer_profile は G-07 の入力そのままです。
• PDF を、請求書番号を冪等キー（invoice/<番号>）にして、C-05 の継手で 1 回だけ保存したいとき。結果が APPLIED か DEDUP_HIT のときだけ保存済みです。
• 発行の事実を、H-01 の継手で追記専用（append-only）の台帳に AuditEventEnvelope として記録したいとき。台帳へ渡すのは digest だけで、請求書の中身は渡しません。
• 結果の分からなかった段を、同じ番号・同じ中身の issue で、同じ要求・同じ封筒のまま送り直したいとき。
• 請求書番号ごとの段と digest を確かめたいとき（status）。

使わない場面

• 発行できたこと（ISSUED）を、請求の承認・相手への送付・債権の成立・記載事項の法的な十分さとして使いたいとき。
• 発行できたことを、税額が税務上正しいことを示すものとして使いたいとき。発行できたことは税務上正しいことを示すものではありません。税の事実は G-07 のままで、事実の正本は税率の表と事業者の選択です。
• 請求書番号の採番・一意性・連番を任せたいとき。呼び出し側の役目です。
• 相手への送付・受領、入金・債権の管理まで任せたいとき。外部の電子請求の送付・受領の継手は、この部品に入りません。
• PDF のレイアウトや、記載事項が PDF に実際に載っていることを確かめたいとき。G-07 の記載事項の検めは、入力の申告に対するものです。
• 再起動をまたいで途中の段を続けたいとき。状態はこのプロセスの中だけで、再起動で途中の段と保った要求は消えます（保存は冪等キーで二重になりませんが、台帳の封筒は作り直されます）。
• 本物の文書生成・保存・台帳の backend で確かめた部品が要るとき。本物の backend には一度も接続していません。
• Node.js v24.21.0 のほかの版で使うとき。ほかの版は確かめていません（NOT_VERIFIED）。

検査すること

• options が足りない・形が違う・参照が不正・port の関数が無いとき INVALID_OPTIONS、入力の形が違うとき（欄の過不足・請求書番号の形など）INVALID_INPUT、getter が例外を投げたとき INSPECTION_FAILED で止めます。
• G-07 が ok: true を返さないとき TAX_INPUT_INVALID（tax_errors を添える）、G-07 の関数が投げたとき PORT_FAILED、事実の形が違う・inference か advice が null でないとき TAX_FACTS_INVALID で、文書を作りません。
• G-07 の事実に need_input があるとき NEEDS_INPUT（推測で埋めない）、記載事項の欠けがあるとき REQUIRED_ITEMS_MISSING（直し方は言わない）で、書類を作る前に止め、保存も記録もしません。
• 同じ請求書番号で別の中身（請求書・税率の表・事業者の選択のどれか）のとき INVOICE_NUMBER_REUSED で止めます。発行済みの番号へのもう一度の issue は already_issued: true を返します。
• 文書の継手の結果が分からないとき RENDER_UNKNOWN、送らなかったとき RENDER_REFUSED、変換できなかった・部分だけ・停止・空の PDF のとき RENDER_FAILED で、保存へ進みません。
• 保存の継手の結果が分からないとき STORE_UNKNOWN（同じ要求を保つ）、送らなかったとき STORE_REFUSED（同じ冪等キーで別の中身を含む）、停止した・結果が APPLIED・DEDUP_HIT でないとき STORE_FAILED で、記録へ進みません。
• 台帳の継手の結果が分からないとき（state() が投げた場合を含む）LEDGER_UNKNOWN（同じ封筒を保つ）、台帳が断った・先頭が進んで封筒がつながらない・先頭の形が不正なとき LEDGER_REFUSED で、発行済みにしません。
• timestamp が date-time の文字列を返さない・投げたとき CLOCK_FAILED、前の操作が終わっていないとき BUSY で止めます（同時に 1 つの操作だけ）。

しないこと・既知の限界

• 請求書生成の部品は継手ではありません。自分の Request/Receipt は無く、文書の変換・保存・台帳への追記という外への効果は、束ねた J-01・C-05・H-01 の継手がそれぞれの契約で起こします。この部品自身は外へ触れません。
• 束ねた部品の意味（事実だけ・変換できた ≠ 中身の確認・保存できた ≠ 受け入れ・記録できた ≠ 承認）は、それぞれの部品の側に残ります。
• 発行できたことは、請求の承認・債権の成立・記載事項の法的な十分さではありません（approval: false・claim: NOT_DERIVED・legal_sufficiency: NOT_VERIFIED、derives_authority: false）。
• 発行できたことは、税務上正しいことを示すものではありません。税務の判断はせず、事実だけを返し、直し方を返しません（税務相談は税理士の独占業務です）。
• 請求書番号の採番・一意性・連番、相手への送付・受領、請求の承認、入金・債権の管理はしません。
• 本物の文書生成・保存・台帳の backend には一度も接続していません。単体試験とファズは代役で、本物の 4 部品のコードとの結線は、各継手の試験用の代役を相手に確かめました。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 特定の請求書ソフトの使い方の雛形ではありません。

つなぎ方

src/invoice.js の createInvoiceIssuance(options) で作ります。受け取るのは参照・store_target・ledger・ports・任意の timestamp で、{ ok, errors, instance } を返します。issue と status の結果には approval: false が付き、段に進んだ請求書は stage と digest を添えます。利用側が用意する port は taxFacts（G-07）・render.transform（J-01）・store.submit（C-05）・ledger.append と state（H-01）です。副作用は束ねた継手が起こし（EXTERNAL_IRREVERSIBLE）、資格情報は port が持ちます。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

定期課金を外の決済基盤へ運ぶとき、許していない請求や再開を送ってしまうこと、同じ請求を二度送ってしまうこと、op と合わない状態の receipt やお金が動いたか分からない receipt を信じてしまうことを防ぎます。

使う場面

• 定期課金の請求（BILL_CYCLE→BILLED）・一時停止（PAUSE→PAUSED）・再開（RESUME→RESUMED）・解約（CANCEL→CANCELLED）を外の決済基盤へ運び、receipt が op に合う状態かを照合したいとき。
• お金が動く操作（請求・再開）を、設定 allow_money_movement: true で明示的に許したときだけ送りたいとき（既定は送りません）。
• 請求に冪等キーを必須にし、同じキーの請求を重複（DEDUP_HIT、新しい効果なし）として扱いたいとき。
• 決済基盤の障害のあとに再送するとき、照会（lookup）で解いて二度動かさないようにしたいとき。

使わない場面

• 請求できたことを、業務の承認として扱いたいとき。定期課金の成功は業務の承認ではありません（business_approval は運びから導きません）。
• 額・通貨・税・手数料の正しさを確かめたいとき。この継手は確かめません（外の判断と人・組織の役目です）。
• すぐに実の決済基盤につなぎたいとき。実の決済基盤・PSP・銀行には一度も接続しておらず、port の実装も含みません。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。

検査すること

• お金を動かす許可を検めます。allow_money_movement が true でないとき、または真偽値でないとき、お金が動く操作は送りません（REFUSED）。
• 冪等キーを検めます。冪等キーの無い請求（BILL_CYCLE）、同じキーで別の中身の要求は送りません。
• 重複なのに効果を名乗る receipt は受理しません。重複（DEDUP_HIT）の効果は NONE です。
• pin した一覧を検めます。pin していない支払い方法、空・パス・.. を含む参照は送りません。空の一覧は何も許しません。
• receipt を照合します。op と合わない状態、辞退なのに効果を名乗る receipt、外への効果を増やす receipt、別の要求の receipt（request_digest の偽り）は受理せず、以後は停止します（HALTED）。
• お金が動いたか分からない receipt（効果 UNKNOWN）は受け取らず、以後は停止します（HALTED）。人の確認へ回します。
• 業務の承認を名乗る receipt は受理しません。
• 同じ request_id は二度送りません。決済基盤の障害は UNKNOWN とし、再送は照会（lookup）で解いて、二度動かしません。

しないこと・既知の限界

• 定期課金の成功は業務の承認ではありません。どの結果にも approval: false が付きます。業務の承認は核（approval-facts）と人・組織の役目です。
• 額・通貨・税・手数料の正しさは確かめません（外の判断と人・組織の役目です）。
• 実の決済基盤・PSP・銀行には一度も接続していません。実の課金・送金は 0 回です。port の実装、pin する一覧、お金を動かす許可は、接続するときに別の関門で決めます。
• 決済基盤の認証に使う秘密は持ちません。秘密は port 側が持ちます（HELD_BY_PORT）。
• 契約を変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 特定の決済サービスの使い方の雛形ではありません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/payment-rails/v1 でつなぎます。createPaymentRailsClient({ cfg, port }) の submit(request) に SubscriptionBillingRequest を渡すと、DONE（result に billing_state・business_approval）・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED のどれかを返します（どれも approval: false）。利用側が用意するもの: 決済基盤への port（submit、任意で lookup）。副作用: 定期課金の操作は EXTERNAL_IRREVERSIBLE、重複・辞退・失敗などは NONE。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

事業者への支払いを外の決済基盤へ運ぶとき、人・組織の根拠が無いまま送ってしまうこと、pin していない支払い先へ送ってしまうこと、支払いの許可を名乗る receipt を信じてしまうことを防ぎます。支払えることを支払いの許可と取り違えないための検めです。

使う場面

• 事業者への支払いを、人・組織が出した根拠を recordAuthorityEvidence(evidence_ref, origin) で受け取った後だけ運びたいとき（origin は HUMAN か ORGANIZATION だけ。この操作はチャージバックの受け入れの根拠も受け取ります）。
• 支払い先を、pin した一覧（payout_destinations）に限りたいとき。
• 支払いを、設定 allow_money_movement: true で明示的に許したときだけ送りたいとき（既定は送りません）。
• 同じ支払いを二度動かしたくないとき。冪等キーを必須にし、同じ request_id は二度送らず、障害のあとの再送は照会（lookup）で解きます。

使わない場面

• この継手に支払いの許可を出させたいとき。ERABAZU は支払いの許可を作りません。支払いの実行は人の役目です（Kernel と同じ承認の境界）。
• 根拠が本物か、額・通貨・税・手数料が正しいかを確かめたいとき。この継手はどちらも確かめません（外の判断と人・組織の役目です）。
• すぐに実の決済基盤につなぎたいとき。実の決済基盤・PSP・銀行には一度も接続しておらず、port の実装も含みません。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。

検査すること

• 根拠を検めます。根拠の参照が無い支払い、recordAuthorityEvidence で受け取っていない根拠を使う支払い、origin が ERABAZU の根拠は送りません。
• 支払いの許可を名乗る receipt は受理しません。
• お金を動かす許可を検めます。allow_money_movement が true でないとき、または真偽値でないとき、お金が動く操作は送りません（REFUSED）。
• pin した一覧を検めます。pin していない支払い先、空・パス・.. を含む参照は送りません。空の一覧は何も許しません。
• 冪等キーを検めます。冪等キーの無い支払い、同じキーで別の中身の要求は送りません。
• receipt を照合します。op と合わない状態、辞退なのに効果を名乗る receipt、外への効果を増やす receipt、別の要求の receipt（request_digest の偽り）は受理せず、以後は停止します（HALTED）。
• お金が動いたか分からない receipt（効果 UNKNOWN）は受け取らず、以後は停止します（HALTED）。人の確認へ回します。
• 同じ request_id は二度送りません。決済基盤の障害は UNKNOWN とし、再送は照会（lookup）で解いて、二度動かしません。

しないこと・既知の限界

• 支払えたことは支払いの許可ではありません。result の payout_authorization も運びから導かず、どの結果にも approval: false が付きます。
• 支払いの許可の中身（本物の根拠か）、額・通貨・税・手数料の正しさは確かめません（外の判断と人・組織の役目です）。
• 実の決済基盤・PSP・銀行には一度も接続していません。実の課金・送金は 0 回です。port の実装、pin する一覧、お金を動かす許可は、接続するときに別の関門で決めます。
• 決済基盤の認証に使う秘密は持ちません。秘密は port 側が持ちます（HELD_BY_PORT）。
• 契約を変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 特定の決済サービスの使い方の雛形ではありません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/payment-rails/v1 でつなぎます。createPaymentRailsClient({ cfg, port }) の recordAuthorityEvidence(evidence_ref, origin) で根拠を受けた後、submit(request) に PayoutRequest を渡すと、DONE（result に payout_state・payout_authorization）・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED を返します（どれも approval: false）。利用側が用意するもの: 決済基盤への port（submit、任意で lookup）。副作用: EXTERNAL_IRREVERSIBLE。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

「税込」の裏で、税額を明細ごとに丸めてしまうこと、浮動小数点の誤差が税額に入ること、コードに持った税率で計算してしまうこと、表や設定で決まらない入力を推測で埋めてしまうことを防ぎます。税額の端数処理は、1 枚につき税率ごとに 1 回だけです。

使う場面

• 適格請求書（QUALIFIED）か適格簡易請求書（SIMPLIFIED）1 枚の明細（1〜1000 件）から、税率ごとの対価の合計と消費税額等を事実として出したいとき。
• 税額の端数処理を、1 枚につき税率（率の内訳 rate・national_rate・local_rate の組）ごとに 1 回だけ、事業者の設定の方法（FLOOR 切捨て・CEIL 切上げ・HALF_UP 四捨五入）で行いたいとき。明細ごと・表の行ごとには丸めません。
• 税抜（TAX_EXCLUDED）か税込（TAX_INCLUDED）か（1 枚に 1 つ）に応じて、税額を浮動小数点を使わず正確な分数で出したいとき。金額と率は 10 進の文字列で渡します。
• 税率を、使う側が渡す税率の表（行ごとの期間・国と地方の内訳・出典つき）から選びたいとき。同梱の表は bundledTaxTable() が写しを返し、ほかの表を tax_table として渡すこともできます。
• 記載事項の欠け（氏名又は名称・登録番号・取引年月日・取引の内容・軽減税率の対象である旨など）を、計算と同じ呼び出しで一覧にしたいとき。欠けがあっても計算は止めません。
• 同じ請求書から、キーの並びに関係なく同じ invoice_digest（RFC 8785 の正準 JSON の sha256）と、byte 単位で同じ出力が要るとき。時計・乱数・環境の locale を使いません。

使わない場面

• 期間の集計（売上税額・仕入税額の積上げ計算、割戻し計算との選択）、簡易課税のみなし仕入率、2割特例、輸入消費税が要るとき。この部品は請求書 1 枚の中で閉じる計算だけです。
• 非課税・不課税・免税の判定、源泉徴収、ほかの国の税が要るとき。カタログの一言「消費税・源泉等」のうち、源泉徴収は含みません。
• 品目が軽減税率の対象かどうか、経過措置が当たるかどうかを判定させたいとき。呼び出し側が rate_class と rate_id の名指しで決めて渡します。
• 登録番号が国税庁の公表サイトの登録簿にあるかを確かめたいとき。T と 13 桁の数字の形だけを検め、登録簿には照会しません。
• 負の金額（値引き・返品・対価の返還等）を含む請求書を扱うとき。v1 は負の金額を受け取らず、NEGATIVE_AMOUNT で止めます。
• ほかの国の通貨の金額を扱うとき。UNSUPPORTED_CURRENCY で止めます。
• 税額の国・地方への分け方が要るとき。国と地方の内訳は率だけを出します。
• Node.js v24.21.0 のほかの版で使うとき。ほかの版は確かめていません（NOT_VERIFIED）。

検査すること

• 引数が { invoice, tax_table, taxpayer_profile } の 3 つだけを持つ素のオブジェクトでないとき INVALID_ARGUMENT、値を調べること自体が例外になるとき（Proxy の罠など）INSPECTION_FAILED で止めます。getter・クラスのインスタンス・穴のある配列・__proto__ のキーは受け取らず、素のデータに写してから検めます。
• 請求書の形が違うとき（知らないキー・足りないキー・語彙の外の値・単独のサロゲート・明細が 0 件か 1000 件を超える・reduced_marker が true 以外）INVALID_INVOICE、日付が実在する暦の日でないとき INVALID_DATE、同じ line_id の明細が 2 つあるとき DUPLICATE_LINE_ID で止めます。
• 金額が { value, scale, currency } の決まった形でないとき（scale が 0〜6 の整数でない・小数の桁数が scale と違う）MALFORMED_AMOUNT、金額が負のとき NEGATIVE_AMOUNT、通貨が違うとき UNSUPPORTED_CURRENCY で止めます。
• 税率の表の形が違うとき（出典の url が https でない場合を含む）INVALID_TAX_TABLE、行に出典が無いとき MISSING_SOURCE、率が決まった形でない・0 のとき MALFORMED_RATE、national_rate + local_rate が rate と等しくないとき RATE_SPLIT_MISMATCH で止めます。
• 期間の終わりが始まりより前のとき INVALID_PERIOD、同じ rate_id の行が 2 つあるとき DUPLICATE_RATE_ID、同じ区分の行の期間が重なるとき OVERLAPPING_RATE_ROWS、事業者の設定の形が違うとき（端数処理の方法が FLOOR・CEIL・HALF_UP 以外など）INVALID_PROFILE で止めます。
• 取引の日が無いとき、取引の日に当たる行が表に無いとき、名指しの rate_id が表に無い・区分が違う・日が合わないとき、請求書の日付に当たる端数処理の設定が 0 件か 2 件以上のときは、推測せず need_input にし、groups を空、invoice_totals を null にします（途中までの計算を出しません）。
• 記載事項（消法57の4①②、インボイスQ&A 問54・問58）のうち、氏名又は名称・登録番号（形だけ）・取引年月日・取引の内容と軽減税率の対象である旨・交付を受ける事業者の名称（適格請求書だけ）を入力の欄から、税率ごとの合計・適用税率・税額を載せるかを presentation の申告から検め、無いものを required_items の missing に並べます。
• 結果を、src の補助関数を使わずに規則から書き直した独立オラクルと突き合わせるファズで、不一致と fail-open が 0 であることを確かめました。

しないこと・既知の限界

• 返すのは税の事実だけです。inference と advice はいつも null で、出力のどの文字列にも直し方や判断の語を入れません。approval は false、authority は NOT_DERIVED です（derives_authority: false）。
• 結果は事実の提示であって、税務上の判断ではなく、申告が正しいことを示すものでもなく、税務の判断や申告の代行でもありません。税務相談は税理士の独占業務です。経過措置の当否・品目の区分・登録番号が登録簿にあるかは、この部品の外で確かめます。
• 期間の集計（積上げ計算・割戻し計算の選択の当否）、簡易課税、2割特例、輸入消費税、非課税・不課税・免税の判定、源泉徴収、ほかの国の税は扱いません。
• 標準税率の明細に reduced_marker が付いていることは検めません（記載事項の欠けとしても出しません）。sales_tax_method・taxation_method は形を検めて写すだけで、計算には使いません。
• 税込で通貨の最小単位未満を含む金額を渡し、切上げ・四捨五入で税額が合計を超えると、税抜の合計は負の値になります。そのまま事実として出し、直しません。
• 同梱の表は 2026-10-01 時点の国税庁の資料による 3 行だけです。2014-04-01 より前の税率と、成立していない改正案は入っていません。表に行の無い期間の取引の日は need_input になります。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。

つなぎ方

src/tax-facts.js の computeInvoiceTax({ invoice, tax_table, taxpayer_profile }) を呼びます（例外を投げません）。受け取るのは請求書（明細 lines・presentation など）、税率の表（行ごとの率の内訳・期間・出典）、事業者の設定（rounding）です。返すのは { ok: true, errors: [], facts }（groups・invoice_totals・required_items・need_input、inference: null・advice: null）か { ok: false, errors: [{ code, where }] }（where は JSON Pointer）です。副作用（NONE）・状態・外の接続・資格情報は無く、利用側が用意する port はありません。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

為替レートを外から取ってくるとき、pin していない通貨の組や出どころのレートを使ってしまうこと、観測したレートを権威として扱ってしまうことを防ぎます。

使う場面

• pin した通貨の組と出どころに限って為替レートを観測して運び、結果（rate_state・rate_ref）として受け取りたいとき。
• 受け取ったレートを、権威ではない観測値として扱う前提で使いたいとき（rate_authority は運びから導きません）。

使わない場面

• 通貨の変換（換算）をしたいとき。この継手は為替レートの取得（観測したレートの運搬）の継手で、換算の機能は含みません。
• 観測したレートを、権威のあるレートとして扱いたいとき。観測したレートは権威ではありません。
• すぐに実の決済基盤につなぎたいとき。実の決済基盤・PSP・銀行には一度も接続しておらず、port の実装も含みません。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。

検査すること

• pin した一覧を検めます。pin していない通貨の組、pin していないレートの出どころ、空・パス・.. を含む参照は送りません。空の一覧は何も許しません。
• 権威を名乗るレートの receipt は受理しません。
• 外への効果を増やす receipt は受理しません。為替レートの要求の効果は NONE です。
• op と合わない状態の receipt、別の要求の receipt（request_digest の偽り）は受理せず、以後は停止します（HALTED）。
• 効果が分からない receipt（効果 UNKNOWN）は受け取らず、以後は停止します（HALTED）。
• 同じ request_id は二度送りません。決済基盤の障害は UNKNOWN とし、再送は照会（lookup）で解いて、二度動かしません。

しないこと・既知の限界

• 為替レートの要求を運ぶ継手で、換算（通貨の変換）の機能は含みません。
• 観測したレートは権威ではありません。どの結果にも approval: false が付きます。
• 額・通貨・税・手数料の正しさは確かめません（外の判断と人・組織の役目です）。
• 実の決済基盤・PSP・銀行には一度も接続していません。実の課金・送金は 0 回です。port の実装、pin する一覧、お金を動かす許可は、接続するときに別の関門で決めます。
• 契約を変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 特定の決済サービスの使い方の雛形ではありません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/payment-rails/v1 でつなぎます。createPaymentRailsClient({ cfg, port }) の submit(request) に FxRateRequest を渡すと、DONE（result に rate_state・rate_ref・rate_authority）・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED のどれかを返します（どれも approval: false）。利用側が用意するもの: 決済基盤への port（submit、任意で lookup）。副作用: NONE。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

決済の明細を外から取り込むとき、pin していない出し手の明細を取り込んでしまうこと、明細を運んだことを明細と入金の突き合わせが済んだことと取り違えることを防ぎます。

使う場面

• pin した明細の出し手に限って明細を取り込んで結果（intake_state）として受け取り、突き合わせは核（reconcile-facts）や人・組織に任せたいとき。
• 取り込みと突き合わせを分けて扱いたいとき。突き合わせを名乗る receipt は受理せず、reconciliation は運びから導きません。

使わない場面

• 明細と入金の突き合わせをしたいとき。この継手は突き合わせをしません。明細の突き合わせは外の判断と人・組織の役目です。
• 明細の額・通貨・税・手数料の正しさを確かめたいとき。この継手は確かめません。
• すぐに実の決済基盤につなぎたいとき。実の決済基盤・PSP・銀行には一度も接続しておらず、port の実装も含みません。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。

検査すること

• pin した一覧を検めます。pin していない明細の出し手、空・パス・.. を含む参照は送りません。空の一覧は何も許しません。
• 突き合わせを名乗る receipt は受理しません。
• 外への効果を増やす receipt は受理しません。明細の取り込みの効果は NONE か EXTERNAL_REVERSIBLE（FAILED は NONE）です。
• op と合わない状態の receipt、別の要求の receipt（request_digest の偽り）は受理せず、以後は停止します（HALTED）。
• 効果が分からない receipt（効果 UNKNOWN）は受け取らず、以後は停止します（HALTED）。
• 同じ request_id は二度送りません。決済基盤の障害は UNKNOWN とし、再送は照会（lookup）で解いて、二度動かしません。

しないこと・既知の限界

• 明細の突き合わせはしません。明細を運んでも突き合わせではなく、result の reconciliation も運びから導きません。
• 取り込めたことは承認ではありません。どの結果にも approval: false が付きます。
• 額・通貨・税・手数料の正しさは確かめません（外の判断と人・組織の役目です）。
• 実の決済基盤・PSP・銀行には一度も接続していません。実の課金・送金は 0 回です。port の実装、pin する一覧、お金を動かす許可は、接続するときに別の関門で決めます。
• 契約を変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 特定の決済サービスの使い方の雛形ではありません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/payment-rails/v1 でつなぎます。createPaymentRailsClient({ cfg, port }) の submit(request) に StatementIntakeRequest を渡すと、DONE（result に intake_state・reconciliation）・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED のどれかを返します（どれも approval: false）。利用側が用意するもの: 決済基盤への port（submit、任意で lookup）。副作用: NONE か EXTERNAL_REVERSIBLE（FAILED は NONE）。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

チャージバックを外の決済基盤へ運ぶとき、証拠の参照の無い提出を送ってしまうこと、人・組織の根拠の無いまま受け入れ（ACCEPT）を送ってしまうこと、解決の権限を名乗る receipt を信じてしまうことを防ぎます。受け入れは取り消せない業務の判断なので、根拠があるときだけ運びます。

使う場面

• チャージバックの申し立て（OPEN→OPENED）・証拠の提出（SUBMIT_EVIDENCE→EVIDENCE_SUBMITTED）・観測（OBSERVE→OBSERVED）・受け入れ（ACCEPT→ACCEPTED）を運び、receipt が op に合う状態かを照合したいとき。
• チャージバックの解決を人・組織の判断に残し、運びからは解決の権限（resolution_authority）を導かないようにしたいとき。
• チャージバックの受け入れ（ACCEPT）を、人・組織が出した根拠を recordAuthorityEvidence で受け取った後だけ、設定 allow_money_movement: true で許したときだけ運びたいとき。

使わない場面

• 人・組織の根拠が無いまま、または設定 allow_money_movement が true でないまま、チャージバックを受け入れたい（ACCEPT）とき。この継手は送りません（REFUSED）。
• チャージバックを解決したいとき、または返金をしたいとき。この継手はチャージバックの申し立て・証拠の提出・観測・受け入れを運ぶ継手で、解決の権限は無く、返金の機能は含みません。受け入れを運んでも解決ではありません。
• 受け入れの根拠が本物の判断かを確かめたいとき。この継手は、人・組織から受け取った参照かだけを見ます。
• すぐに実の決済基盤につなぎたいとき。実の決済基盤・PSP・銀行には一度も接続しておらず、port の実装も含みません。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。

検査すること

• 受け入れの根拠を検めます。根拠の参照が無い受け入れ（ACCEPT）、recordAuthorityEvidence で受け取っていない根拠を使う受け入れ、origin が ERABAZU の根拠の受け入れは送りません。受け入れ以外の op に根拠の欄を付けた要求も送りません。
• お金を動かす許可を検めます。allow_money_movement が true でないとき、または真偽値でないとき、受け入れ（ACCEPT）は送りません（REFUSED）。
• 証拠の参照の無い証拠の提出は送りません。参照が空・パス・.. を含むものも送りません。
• 解決の権限を名乗る receipt は受理しません。
• 外への効果を増やす receipt は受理しません。効果は、観測は NONE、申し立て・証拠の提出は EXTERNAL_REVERSIBLE、受け入れは EXTERNAL_IRREVERSIBLE（FAILED は NONE）です。
• op と合わない状態の receipt、別の要求の receipt（request_digest の偽り）は受理せず、以後は停止します（HALTED）。
• 効果が分からない receipt（効果 UNKNOWN）は受け取らず、以後は停止します（HALTED）。
• 同じ request_id は二度送りません。決済基盤の障害は UNKNOWN とし、再送は照会（lookup）で解いて、二度動かしません。

しないこと・既知の限界

• チャージバックの解決はしません。受け入れ（ACCEPT）を運んでも解決の権限ではなく、どの結果にも approval: false が付きます。解決は外の判断と人・組織の役目です。
• 受け入れの根拠の中身（本物の判断か）は確かめません。人・組織から受け取った参照かだけを見ます。ERABAZU は争いを認める判断を作りません。
• 実の決済基盤・PSP・銀行には一度も接続していません。実の課金・送金は 0 回です。port の実装、pin する一覧、お金を動かす許可は、接続するときに別の関門で決めます。
• 決済基盤の認証に使う秘密は持ちません。秘密は port 側が持ちます（HELD_BY_PORT）。
• 契約を変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 特定の決済サービスの使い方の雛形ではありません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/payment-rails/v1 でつなぎます。createPaymentRailsClient({ cfg, port }) の recordAuthorityEvidence で根拠を受けた後、submit(request) に DisputeRequest を渡すと、DONE（result に dispute_state・resolution_authority）・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED を返します（どれも approval: false）。利用側が用意するもの: port。副作用: 観測は NONE、申し立て・証拠の提出は EXTERNAL_REVERSIBLE、受け入れは EXTERNAL_IRREVERSIBLE。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

小数の誤差で、金額が端数の分だけずれる事故を防ぎます。浮動小数点を使わないので誤差が入らず、38 桁に収まらない結果は黙って丸めずに止めます。受け取れない値は、決まったコードと位置で止めます。

使う場面

• 10 進の文字列（-?[0-9]+(.[0-9]+)?、ASCII の数字だけ）を、通貨のコードとあわせて金額に読みたいとき（parseDecimal）。scale は書かれた小数の桁数のままで、正規化しません。
• 末尾の 0 を削り、scale を最小にした金額にそろえたいとき（normalize。0 は { value: "0", scale: 0 }）。
• 同じ通貨の 2 つの金額を、丸めずに足したいとき（add。結果は正規化した金額）。
• scale によらず、数の大小（compare の -1・0・1）や等しさ（equal）を知りたいとき。equal は通貨が違えば false で、エラーではありません。
• 金額を、小数の桁数がちょうど scale の 10 進の文字列に書き出したいとき（toText）。parseDecimal(toText(a)) は同じ value・scale に戻ります。
• 時計・乱数・環境の locale・外の接続を持たない、決定的な処理として手元で呼びたいとき。

使わない場面

• 丸め・掛け算・割り算・為替の換算が要るとき。この部品は扱いません。
• 記号や桁区切りの付いた表示用の文字列が要るとき。表示用の整形は L-03 の部品の役目です。
• 通貨のコードが ISO 4217 の表にあるか、通貨ごとの小数の桁数に合うかを確かめたいとき。この部品は形（英大文字 3 字）だけを検めます。
• 38 桁・scale 18 を超える金額を扱うとき。表せないので止めます（TOO_MANY_DIGITS・INVALID_SCALE）。
• 整数部の先頭の 0 を断りたいとき。parseDecimal は先頭の 0 を受け取って捨てます。より狭い形が要るときは、使う側で検めます。
• text の長さの上限が要るとき。上限は持たず、大きさの上限は I-06 の部品か使う側で決めます。
• Node.js v24.21.0 のほかの版で使うとき。ほかの版は確かめていません（NOT_VERIFIED）。

検査すること

• 引数が素のオブジェクトでない、決めたキーの外を持つ、getter・列挙しないプロパティ・symbol のキーを持つ、値を調べること自体が例外になるとき（Proxy の罠など）、INVALID_ARGUMENT で止めます。getter は呼びません。
• text・value が文字列でないとき（数として渡された値・NaN・Infinity・bigint・無いキー）、NOT_A_STRING で止めます。
• text が -?[0-9]+(.[0-9]+)? の形でないとき（指数・+・空白・桁区切り・"1."・".5"・全角の数字・改行）、INVALID_DECIMAL_TEXT で止めます。
• value が -?[0-9]+ の形でない・先頭に余分な 0 があるとき INVALID_VALUE、"-0" などの負の 0 のとき NEGATIVE_ZERO で止めます。
• 桁が 38 を超えるとき（足し算の結果を含む）TOO_MANY_DIGITS、scale が 0〜18 の整数でないとき（-0・小数・文字列）や小数の桁数が 18 を超えるとき INVALID_SCALE で止めます。
• currency が英大文字 3 字の文字列でないとき INVALID_CURRENCY、add・compare の 2 つの金額の通貨が違うとき CURRENCY_MISMATCH で止めます。
• 止めたときは、決まった順で最初の 1 つだけを、コード（code）と位置（where。JSON Pointer で、2 つの金額の操作では /a・/b から始まる）で返します。

しないこと・既知の限界

• 丸め・掛け算・割り算・為替の換算・表示用の整形はしません。
• 計算できたことは、金額が業務として正しいことでも、受け入れてよいことでもありません。
• 通貨ごとの小数の桁数には照らしません。ISO 4217 の表に無いコードでも、形が合えば受け取ります。
• 全角・ほかの文字体系の数字は受け取りません。数字は ASCII の 0〜9 だけです。
• 計算の結果は、承認ではありません（result_is_approval: false）。権限も作りません（derives_authority: false）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 特定の 10 進数のライブラリの使い方の雛形ではありません。

つなぎ方

src/decimal-amount.js の parseDecimal({ text, currency })・normalize(amount)・add(a, b)・compare(a, b)・equal(a, b)・toText(amount) を呼びます（どれも投げません）。金額は { value, scale, currency }（value は符号を除いて 38 桁までの整数の文字列、scale は 0〜18 の整数、currency は英大文字 3 字）です。返すのは { ok: true, errors: [], amount | result | equal | text } か { ok: false, errors: [{ code, where }] }。副作用・状態・外の接続・資格情報は無く、利用側が用意する port はありません。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

二重計上を防ぐ照合の鍵には、同じ事実からいつも同じ値が要ります。金額の末尾の 0 と scale の書き方の違い、入力のキーの順、浮動小数点の誤差、raw_refs のような出どころの参照によって、同じ事実の ID が変わってしまうことを防ぎます。

使う場面

• 取引・証憑の事実から、二重計上を防ぐ照合の鍵として、同じ事実から同じ値になる事象の ID（txn_id）を作りたいとき。
• 同じ値の金額を、scale の書き方によらず同じ ID にしたいとき。金額は BigInt で末尾の 0 を削って scale を最小にし、浮動小数点を使いません。通貨・符号・値が違えば別の ID です。
• 取引先を、出どころの ID（id_in_source）か名前で表したいとき。id_in_source があって空でなければそれだけを使い、無ければ名前を NFKC にして前後の空白を削ったものを使います。
• 必要な事実が欠けているときに、推測で埋めず、無い事実の位置（JSON Pointer）の一覧 missing を受け取りたいとき。state は need_input で、エラーではありません。
• ID と一緒に、ハッシュした形（hashed）と、その正準 JSON の文字列（canonical）も受け取り、ID の元を確かめたいとき。
• 時計・乱数・環境の locale を使わず、入力のキーの順によらない、決定的な出力が要るとき。外の境界・状態はありません。

使わない場面

• 2 つの記録が同じ取引かどうかを判断させたいとき。同じ欄の値を持つ別々の取引（同じ日・同じ金額・同じ取引先の 2 回の買い物など）は同じ txn_id になります。区別は source_key の役目で、G-13・G-14 の部品が扱います。
• 表記のゆれを寄せたいとき。大文字と小文字、(株) と 株式会社、ゼロ幅の文字、空白の数の違いは別の ID になります。別名の候補を出すことは、この部品に含みません。
• kind（evidence か transaction か）・source・id_in_source を決めさせたいとき。どれも呼び出し側が決めて渡します。kind は申告されたものを使い、判定しません。
• 記録の形の検め・supersedes の扱い・重複のまとまり分けが要るとき。記録の形と supersedes は G-13、同一性の基準は G-14 の部品の範囲です。
• ID が衝突しないことを前提にしたいとき。txn_id は 128 bit に切り詰めたハッシュで、衝突しないことは約束しません。
• Node.js v24.21.0 のほかの版で使うとき。ほかの版は確かめていません（NOT_VERIFIED）。NFKC は Node.js（ICU）の String.prototype.normalize によるため、Unicode の版が変わると結果が変わりえます。

検査すること

• 引数が 6 つのキー（kind・source・occurred_on・amount・counterparty・raw_refs）だけを持つ素のオブジェクトでないとき、getter・列挙しないプロパティ・symbol のキーを持つとき（raw_refs を除く）、値を調べること自体が例外になるとき（Proxy の罠など）は INVALID_ARGUMENT で止めます。
• kind が evidence・transaction でないとき INVALID_KIND、source が ^[a-z0-9][a-z0-9_-]{0,62}$ の文字列でないとき INVALID_SOURCE、occurred_on が YYYY-MM-DD の実在する暦の日（0001〜9999 年）でないとき INVALID_DATE で止めます。
• amount が { value, scale, currency } だけを持つ素のオブジェクトでないとき、value が -?[0-9]+ の形でない（先頭の 0・"-0"・符号を除いて 38 桁を超える）とき、scale が 0〜18 の整数でない（-0 を含む）とき、currency が英大文字 3 字でないときは INVALID_AMOUNT で止めます。
• counterparty が { id_in_source, name } のうちだけを持つ素のオブジェクトでないとき、どちらかが文字列か null でないとき、単独のサロゲートを含むときは INVALID_COUNTERPARTY で止めます。id_in_source があるときも、名前の形は検めます。
• 形の違う欄が 1 つでもあれば、無い欄があってもエラー（{ ok: false }）にし、最初に見つけた 1 つだけを返します。検める順は 引数の形 → kind → source → occurred_on → amount → counterparty です。
• raw_refs は読まず（形も検めず、getter も呼ばず）、ID に入れません。検めた値とハッシュする値は同じです。
• 結果を、src の補助関数も src/canonical.js も crypto も使わずに規則から書き直した独立オラクル（SHA-256 も純 JS）と突き合わせるファズで、不一致と fail-open が 0 であることを確かめました。NFKC だけはオラクルも同じ関数を使います。
• 15 件の既知の答え（test/known-answers.json）で試験しています。正準の文字列は規則から手で書き、txn_id は src を使わない純 JS の SHA-256 で求めたものです。G-13 の部品と同じ答えを共有します。

しないこと・既知の限界

• 返すのは事実だけです。inference と advice はいつも null で、出力のどの文字列にも判断の語を入れません。結果は承認ではなく（result_is_approval: false）、権限も作りません（derives_authority: false）。
• 事象 ID は決まった欄から決まった規則で作った値で、記帳や突合の判断ではありません。2 つの記録が同じ取引かどうかは決めません。
• id_in_source は正規化しません（前後の空白も含めてそのまま使います）。名前は NFKC と前後の空白の削りだけで、それ以上は寄せません。
• 通貨のコードは形（英大文字 3 字）だけを検め、ISO 4217 の表とは照らしません。
• id_in_source と name の長さの上限は持ちません。NFKC・正準化・ハッシュには長さに比例する時間がかかります。大きさの上限は I-06 の部品か使う側で決めます。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。

つなぎ方

src/txn-id.js の computeTxnId(input) を呼びます（例外を投げません）。受け取るのは { kind, source, occurred_on, amount: { value, scale, currency }, counterparty: { id_in_source?, name? }, raw_refs? } です。返すのは { ok: true, errors: [], facts }（state・txn_id・hashed・canonical・missing、inference: null・advice: null）か { ok: false, errors: [{ code, where }] }（where は JSON Pointer）です。副作用（NONE）・状態・外の接続・資格情報は無く、利用側が用意する port はありません。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

帳簿の元になる記録の形は、誰も見ないまま使われがちです。記録に書かれた txn_id を言い分のまま信じること、突合の情報を取引の記録に書き込んでしまうこと、supersedes の鎖の切れ・循環・枝分かれに気づかないことを防ぎます。

使う場面

• 共通形の取引 1 件を、閉じた形（schema・txn_id・kind・occurred_on・amount・counterparty・lines・source・raw_refs・probe_version・extracted_at と、任意の supersedes・source_key）として検めたいとき（checkTxn）。
• 記録の txn_id が、kind・source・occurred_on・amount・counterparty から G-12 の規則で計算した値と同じかを確かめたいとき。違えば TXN_ID_MISMATCH と、計算し直した値 recomputed_txn_id を返します。
• 突合の記録（evidence_txn・transaction_txn・basis・matcher_version・confidence）を、取引とは別の記録として検めたいとき（checkMatch）。取引の欄を持つ突合の記録は受け取りません。
• 取引の集合（10,000 件まで）について、supersedes の鎖を古い順に並べ、相手が無い・同じ id・別の source・循環・枝分かれを problems として受け取りたいとき（checkSupersedesChain）。
• 時計・乱数・環境の locale を使わない、決定的な出力が要るとき。checkSupersedesChain の結果は入力の並びにもよりません。外の境界・状態はありません。

使わない場面

• どの版が正しいか・どれを使うかを決めさせたいとき。supersedes の鎖の事実を並べるだけです。
• 評価（為替の換算など）や、重複のまとまり分けが要るとき。まとまり分けは G-14 の部品の範囲です。
• 突合の evidence_txn・transaction_txn が実在する取引か、それぞれの kind が合っているかを確かめたいとき。id の形と 2 つが違うことだけを検めます。
• 明細の金額の合計が取引の金額と合うか、明細の通貨が取引の通貨と同じかを確かめたいとき。どちらも検めません。
• 欠けた事実を集めたいとき。記録の欄が足りなければ need_input ではなく INVALID_RECORD で止めます。この部品は保存された記録の検めで、無い事実の一覧を出す G-12 とは役割が違います。
• 中身を直しても txn_id が変わらない訂正を、同じ集合で扱いたいとき。同じ txn_id が 2 件ある集合は DUPLICATE_TXN_ID で止まります。
• Node.js v24.21.0 のほかの版で使うとき。ほかの版は確かめていません（NOT_VERIFIED）。NFKC は実行環境の ICU によるため、Unicode の版が変わると名前の正規化の結果が変わることがあります。

検査すること

• 記録が素のデータでないとき（getter・クラスのインスタンス・穴のある配列・symbol のキー・__proto__ のキー・入れ子 8 段や配列 10,000 要素を超える）、知らないキー・足りないキーがあるとき INVALID_RECORD、値を調べること自体が例外になるとき INSPECTION_FAILED で止めます。
• schema が違うとき INVALID_SCHEMA、txn_id・supersedes などが小文字の hex 32 文字でないとき INVALID_TXN_ID、kind が語彙の外のとき INVALID_KIND、日付が実在する暦の日でないとき INVALID_DATE、金額の形が違うとき INVALID_AMOUNT で止めます。
• 取引先が空（id_in_source が空で、NFKC と trim の後の name も空）か形が違うとき INVALID_COUNTERPARTY、明細・数量の形が違うとき INVALID_LINES、source の形が違うとき INVALID_SOURCE、raw_refs が 1〜1024 件の重複のない Ref の配列でないとき INVALID_RAW_REFS で止めます。
• probe_version の形が違うとき INVALID_PROBE_VERSION、extracted_at が RFC 3339 の日時でない（うるう秒・小文字の t と z を含む）とき INVALID_TIME、source_key の形が違うとき INVALID_SOURCE_KEY で止めます。検めは決まった順で、最初に当たった 1 つだけを返します。
• txn_id を記録の言い分のまま信じず、G-12 の規則で計算し直して比べます。違えば TXN_ID_MISMATCH で止めます。
• 突合の記録が素のデータでない・知らないキー（取引の欄を含む）・足りないキーがあるとき、basis・matcher_version・confidence（exact・probable・manual）の形が違うとき INVALID_MATCH、2 つの id が同じとき SAME_TXN_MATCHED で止めます。
• 鎖の引数が { txns } だけの素のオブジェクトでないとき INVALID_ARGUMENT、同じ txn_id が 2 件あるとき DUPLICATE_TXN_ID で止めます。問題のある辺（相手が無い・同じ id・別の source・枝分かれ・循環）は鎖につながず、SUPERSEDES_ で始まるコードの事実として problems に出します。
• 結果を、src の補助関数を使わずに規則から書き直した独立オラクルと突き合わせるファズで、不一致と fail-open が 0 であることを確かめました。NFKC と SHA-256 は、オラクルも Node.js の同じ関数を使います。

しないこと・既知の限界

• 返すのは記録の形と規則との一致の事実だけです。inference と advice はいつも null、approval は false で、権限も作りません（derives_authority: false）。入力の名前・説明の文字列はそのまま写します。
• 結果は、取引の中身が正しいこと・どの版が正しいことの判断ではありません。会計の判断や記帳の代行でもありません。突合の当否・kind の当否・金額の評価（為替など）は、この部品の外です。
• kind（evidence か transaction か）は宣言をそのまま受け取り、判定しません。
• raw_refs が指す取得物が実在するか、probe_version が実在する版かは検めません（形だけ）。通貨の英大文字 3 字も形だけを検め、ISO 4217 の一覧とは照らしません。
• G-12 の部品そのものは読み込まず、規則の写しを中に持ちます。写しが同じことは、両方の既知の答えを試験で照らすことと、一度だけの突き合わせで確かめました。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。

つなぎ方

src/txn-record.js の checkTxn(record)・checkMatch(record)・checkSupersedesChain({ txns }) を呼びます（例外を投げません。入力を書き換えません）。返すのは { ok: true, errors: [], facts } か { ok: false, errors: [{ code, where }] }（where は JSON Pointer。TXN_ID_MISMATCH は recomputed_txn_id も持つ）です。checkTxn の facts は txn_id・hashed・canonical・supersedes・source_key、鎖では chains と problems です。副作用（NONE）・状態・外の接続・資格情報は無く、利用側が用意する port はありません。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

「同じ取引か」の判断の土台として、宣言した基準で同じ鍵になる記録をまとめます。鍵の無い記録を推測で埋めること、似た名前・近い日付・近い金額を同じものとして寄せてしまうこと、まとめるときに記録の違いを捨ててしまうことを防ぎます。

使う場面

• 記録にプラットフォームの取引 id（source_key）があり、それだけを鍵にまとめたいとき（basis: source_key）。identity_key は "sk:" と source_key をつないだ文字列です。
• id が無く、日付（occurred_on）・金額（amount）・取引先（counterparty）から 1〜3 個を選んで鍵にしたいとき（basis: composite_key）。鍵は選んだ欄だけの RFC 8785 の正準 JSON の SHA-256（小文字の hex 64 文字）です。
• 金額の scale の違いや取引先の名前の全角と半角の違いを、G-12 の事象 ID と同じ正規化で同じ鍵にしたいとき。金額は末尾の 0 を削って scale を最小にし、取引先は id_in_source が空でなければそれだけ、無ければ名前を NFKC にして前後の空白を削ります。
• 宣言した鍵が無い記録を、推測で鍵を作らず need_input として受け取りたいとき。各記録は groups か need_input のどちらかにちょうど 1 回入ります。
• 同じ鍵のまとまりの中で記録の欄の有無や値が違うことを、differing として知りたいとき。書いたままの値で比べるので、scale・全角と半角のような表現の違いも違いとして数えます。
• 時計・乱数・環境の locale を使わない、決定的な出力が要るとき。groups は identity_key の順、refs と need_input は入力の順です。

使わない場面

• 似た名前・近い日付・近い金額の候補を出したいとき。曖昧一致はしません。取引先の名前は NFKC と前後の空白の除去だけで、それ以上は寄せません。
• 記録の統合・削除や、どれを残すか（supersedes）を決めさせたいとき。まとまりを出すだけです。
• ほかの source の記録を混ぜて、source_key でまとめたいとき。記録に source の欄が無いので、source_key が偶然同じでも区別しません。呼び出し側が source ごとに渡します。
• 宣言が composite_key のときに source_key も鍵に使いたいとき。宣言に従い、source_key は鍵に使いません（differing には数えます）。
• 基準を部品に選ばせたいとき。どの基準を使うかは呼び出し側が宣言します。
• Node.js v24.21.0 のほかの版で使うとき。ほかの版は確かめていません（NOT_VERIFIED）。NFKC は実行環境の ICU によるため、Unicode の版が変わると名前の正規化の結果が変わることがあります。

検査すること

• 引数が { declaration, records } の 2 つのデータプロパティだけの素のオブジェクトでないとき INVALID_ARGUMENT、値を調べること自体が例外になるとき（Proxy の罠など）INSPECTION_FAILED で止めます。getter・クラスのインスタンス・穴のある配列・__proto__ のキーは受け取りません。
• 宣言の basis が source_key・composite_key でないとき、知らないキーがあるとき（source_key に fields を付けたものを含む）、fields が occurred_on・amount・counterparty から 1〜3 個の重なりのない配列でないとき INVALID_DECLARATION で止めます。
• records が素のデータの配列（10,000 件まで・入れ子 8 段まで）でないとき、記録に知らないキーがある・ref が無いか Ref の形でないとき INVALID_RECORDS、同じ ref の記録が 2 つあるとき DUPLICATE_REF で止めます。
• 与えられた欄（source_key・occurred_on・amount・counterparty）の形が違うときは、宣言で使わない欄でも INVALID_FIELD で止めます。source_key の空文字も止めます。取引先が { } や空の文字列だけのときは、形の誤りではなく欄が無いもの（need_input）とします。
• 検めは決まった順（引数 → declaration → 記録ごとの形 → ref の重なり）で、最初に当たった 1 つだけを返します。
• 結果を、src の補助関数を使わずに規則から書き直した独立オラクルと突き合わせるファズで、不一致と fail-open が 0 であることを確かめました。NFKC と SHA-256 は、オラクルも Node.js の同じ関数を使います。

しないこと・既知の限界

• 返すのは事実だけです。inference と advice はいつも null、approval は false で、権限も作りません（derives_authority: false）。入力の ref・source_key はそのまま写します。
• 結果は、宣言した基準で同じ鍵になるかの事実で、同じ取引だという判断・どれを残すかの判断ではありません。重複の判断や記帳の代行でもありません。
• 曖昧な重複の候補出し（suggest-dup）・別名の寄せ（suggest-alias）・統合・削除・supersedes の決定は含みません。
• 通貨の英大文字 3 字は形だけを検め、ISO 4217 の一覧とは照らしません。
• G-12 の部品そのものは読み込まず、正規化の規則の写しを中に持ちます。写しは、Node.js の外の sha256sum で求めた既知の答え 4 件で確かめました。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。

つなぎ方

src/identity-rule.js の groupByIdentity({ declaration, records }) を呼びます（例外を投げません）。declaration は { basis: "source_key" | "composite_key", fields? }、records は { ref, source_key?, occurred_on?, amount?, counterparty? } の配列です。返すのは { ok: true, errors: [], facts }（groups・need_input など、inference: null・advice: null）か { ok: false, errors: [{ code, where }] } です。副作用・状態・外の接続・資格情報は無く、利用側が用意する port はありません。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

監査の記録を外部の追記専用の保管先へ送るとき、型の崩れた封筒や本文の混じった封筒を送ってしまうこと、そして保管先の受領が正しいかを確かめないまま「記録できた」と扱ってしまうことを防ぎます。照合できない追記を信頼しないための検めです。

使う場面

• 誰が何をしたかを、後から消せない形で残す監査ログを、外部の追記専用 backend に記録したいとき。
• backend から返る受領をそのまま信じず、契約の式（連鎖のハッシュ・通番・digest）で照合してから記録済みとしたいとき。
• 同じイベントを二重に追記したくないとき。受領が確定しないまま再送する場合は、照会（lookup）で解きます。
• 受領に不整合が出たら、人が確かめるまで追記を止めたいとき。

使わない場面

• 監査イベントの本文そのものを保管したいとき。封筒には契約のフィールドだけを載せ、本文の混入は拒否します。
• 透明性ログ（Merkle の包含証明）が要るとき。この継手の範囲外です。
• 追記の成功を、承認や決裁として扱いたいとき。追記の成功は承認ではありません。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。
• すぐに使える保管先がほしいとき。実 backend は含まず、どの追記専用サービスにつなぐかはまだ決まっていません。

検査すること

• 封筒の型を検めます。追加のフィールド、決まった値（const）と違う値、genesis の規則に反するものは送りません。
• pin した台帳を検めます。pin していない台帳への追記は送りません。
• 連鎖（previous_hash）と通番（sequence）を検めます。前のハッシュの改ざん、通番の巻き戻し・飛びがあれば、送らず、受理しません。
• digest を検めます。ハッシュは契約の式（RFC 8785 に制限した正準化と sha256。genesis の previous_hash_value は空文字）で計算し、式と違うものは受理しません。
• 受領（AuditAppendReceipt）を照合します。event_digest の偽り、連鎖のハッシュの誤り、台帳・通番・event_id・対象の食い違いがあれば、受理しません。
• 受領に不整合があれば停止します（HALTED）。人が確かめるまで追記しません。
• backend の障害（500 の応答や一部だけの書き込み）は UNKNOWN とし、台帳の先頭を進めません。
• 本文が混じった封筒、大きすぎるイベント、種類を偽った封筒（content-type の偽り）、同じイベントの二重の追記を拒否します。

しないこと・既知の限界

• 改変できないかどうかを決めるのは核（provenance-facts・integrity-facts）の役目です。この継手がするのは、送る前の検めと受領の照合だけです。
• 追記の成功は承認ではありません（approval: false）。
• 実 backend を含みません。どの追記専用サービスにつなぐか、port の実装、pin する対象（endpoint・受領の形式）は未定で、接続するときに別の関門で決めます。
• 透明性ログ（Merkle の包含証明）は扱いません。
• backend の認証に使う秘密（SecretRef）の解決はしません。port 側の責務です。
• 契約を変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 監査 backend の使い方の雛形ではありません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/audit-ledger/v1 でつなぎます。createLedgerClient({ cfg, port }) の append(envelope) に AuditEventEnvelope を渡すと、APPENDED_VERIFIED・ALREADY_APPENDED・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED のどれかを返します（どれにも approval: false が付きます）。利用側が用意するもの: 追記専用 backend への port（append と、任意で lookup）。pin する endpoint と受領の形式、認証の SecretRef の解決も port 側。副作用は取り消せない外部への書き込み（EXTERNAL_IRREVERSIBLE）。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

閲覧の記録を外部の追記専用の保管先へ積むとき、型の崩れた封筒や本文の混じった封筒を送ってしまうこと、同じ記録の二重の追記、通番の巻き戻り・飛び、そして保管先の受領が正しいかを確かめないまま「記録できた」と扱ってしまうことを防ぎます。

使う場面

• 閲覧の記録（誰が何を見たか）を、監査の出来事として、外部の追記専用 backend に 1 件ずつ追記したいとき。
• 閲覧を捉えて AuditEventEnvelope にする側（利用側）を自分で用意でき、その封筒の追記と照合だけをこの継手に任せたいとき。
• backend から返る受領を、契約の式（連鎖のハッシュ・通番・digest）で照合してから、記録済みとしたいとき。
• 同じ閲覧の記録を二重に追記したくないとき。受領が確定しないまま再送する場合は、照会（lookup）で解きます。
• 受領に不整合が出たら、人が確かめるまで追記を止めたいとき。

使わない場面

• 閲覧そのものを検知・収集したいとき。閲覧を捉えて出来事にするのは利用側の役目で、この継手は追記を運んで照合するだけです。
• 閲覧した内容そのもの（本文）を台帳に積みたいとき。封筒には契約のフィールドだけを載せ、本文の混入は拒否します。
• 記録を書き換えたり削除したりしたいとき。この継手は追記だけを扱います。
• 透明性ログ（Merkle の包含証明）が要るとき。この継手の範囲外です。
• すぐに使える保管先がほしいとき。実 backend は含まず、どの追記専用サービスにつなぐかはまだ決まっていません。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。

検査すること

• 封筒の型を検めます。追加のフィールド、決まった値（const）と違う値、genesis の規則に反するもの、種類を偽った封筒（content-type の偽り）は送りません。
• pin した台帳を検めます。pin していない台帳への追記は送りません。
• 連鎖（previous_hash）と通番（sequence）を検めます。前のハッシュの改ざん、通番の巻き戻し・飛びがあれば、送らず、受理しません。
• 同じ event_id・同じ内容がもう追記済みなら backend に送らず ALREADY_APPENDED を返し、同じ event_id で内容が違うときは REFUSED を返します。
• 受領（AuditAppendReceipt）を照合します。event_digest の偽り、連鎖のハッシュの誤り、台帳・通番・event_id・対象の食い違いがあれば、受理しません。
• 受領に不整合があれば停止します（HALTED）。人が確かめるまで追記しません。
• backend の障害（500 の応答や一部だけの書き込み）は UNKNOWN とし、台帳の先頭を進めません。
• 本文が混じった封筒と、大きさの上限（max_envelope_bytes）を超えるイベントを拒否します。

しないこと・既知の限界

• 閲覧を捉えることも、閲覧の出来事を作ることもしません。それは利用側の役目で、この継手は追記を運んで照合するだけです。
• 追記の成功は承認ではありません（approval: false）。
• 実 backend を含みません。どの追記専用サービスにつなぐか、port の実装、pin する対象（endpoint・受領の形式）は未定で、接続するときに別の関門で決めます。
• 透明性ログ（Merkle の包含証明）は扱いません。backend の認証に使う秘密（SecretRef）の解決もしません（port 側の責務です）。
• H-02 専用の部品ではありません。H-01（改変不能監査ログ）・C-04（追記専用台帳）・H-08（改ざん検知チェーン）と同じ 1 つの部品が担い、試験と検査も共通です。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 契約を変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。

つなぎ方

契約 erabazu.candidate/certified-tsugite/audit-ledger/v1 でつなぎます。createLedgerClient({ cfg, port }) の append(envelope) に、閲覧の記録を表す AuditEventEnvelope を渡すと、APPENDED_VERIFIED・ALREADY_APPENDED・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED のどれかを返します（どれにも approval: false）。利用側が用意するもの: 閲覧を封筒にする処理と、追記専用 backend への port（append、任意で lookup）。副作用は EXTERNAL_IRREVERSIBLE。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

同意の取得・撤回を外部の同意台帳へ記録するとき、pin していない目的・範囲での記録、本人のメールアドレスや電話番号をそのまま送ってしまうこと、そして記録できたことを同意の権限（consent authority）と取り違えることを防ぎます。同意の記録は事実で、権限ではありません。

使う場面

• 同意の取得（RECORD_GRANT）と撤回（RECORD_WITHDRAWAL）の履歴を、外部の同意台帳の基盤に追記したいとき。
• 記録した同意の状態を問い合わせ（QUERY）で確かめたいとき。問い合わせの副作用は NONE です。
• 本人を仮名の参照だけで運び、メールアドレス・電話番号の形を基盤へ送りたくないとき。
• 同意の目的と範囲を、pin した一覧（purpose_refs・scope_refs）に限りたいとき。空の一覧は何も許しません。
• 基盤から返る receipt をそのまま信じず、request_id・request_digest・record_digest で照合してから記録済みとしたいとき。

使わない場面

• 同意が有効かどうかを判断させたいとき。法的な判断はせず、人・組織と核の役目です。
• 記録できたことを同意の権限として使いたいとき。consent_authority は NOT_DERIVED か人・組織に固定され、継手は導きません。
• 記録した同意を消したり書き換えたりしたいとき。同意の記録は追記だけで、取り消せない外部への書き込み（EXTERNAL_IRREVERSIBLE）です。撤回は RECORD_WITHDRAWAL として記録します。
• すぐに使える同意台帳がほしいとき。実の基盤（同意台帳）は含まず、port の実装と pin する一覧は接続するときに別の関門（gate）で決めます。
• 個人情報を網羅的に見分けたいとき。直接の識別子の検出は、メールアドレスと電話番号の代表的な形だけです。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。
• H-03 だけの部品を求めるとき、またはほかの H の項目を担わせたいとき。この継手は H-03・H-04・H-05・H-07・H-09 を契約上 1 つの部品として担い、試験と検査も共通です。H-01・H-08 は監査台帳継手、H-06 は保管ライフサイクル継手（C-08）、H-02 は監査台帳か observability の sink が担います。

検査すること

• 本人の参照と参照の形を検めます。メールアドレス・電話番号の形の本人の参照、空の参照、パスや .. を含む参照（path traversal）、追加のフィールドは送りません。
• 目的と範囲を検めます。pin していない目的（purpose）・範囲（scope）の要求は送りません。
• op と副作用の対応を検めます。QUERY は NONE、RECORD_GRANT・RECORD_WITHDRAWAL は EXTERNAL_IRREVERSIBLE で、対応しない要求・receipt は送らず、受理しません。
• receipt の状態と record_digest を検めます。op に答えていない状態（RECORD_GRANT なら GRANTED か UNKNOWN、RECORD_WITHDRAWAL なら WITHDRAWN か UNKNOWN 以外）、ほかの同意の record_digest（target が consent_ref と違う）は受理しません。
• 同意の権限を導いたと名乗る receipt は受理しません。
• 外への効果を増やす receipt、効果が UNKNOWN の receipt、request_digest を偽った receipt は受理しません。受理できない receipt が来たら停止します（HALTED）。
• 同じ request_id は二度送りません。基盤の障害は UNKNOWN とし、再送は lookup で解きます。

しないこと・既知の限界

• 同意が有効か、同意の権限があるかは判断しません。同意の記録は事実で、権限ではありません。
• 要る同意・足りない同意・承認経路の事実を扱うのは核（consent-facts。同意を与えません）、保持の事実を扱うのは核（policy-facts）の役目で、法的な権利は人・組織の役目です。この継手がするのは、送る前と受け取った後の検めだけです。
• 実の基盤（同意台帳）を含みません。port の実装と pin する一覧は未定で、接続するときに別の関門で決めます。
• 個人情報のすべてを見分けるものではありません。直接の識別子の検出は、メールアドレスと電話番号の代表的な形だけを見る網です。
• 記録できたことは承認ではありません（approval: false）。
• プライバシー法令への適合を約束するものではありません。契約も変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/audit-privacy/v1 でつなぎます。createAuditPrivacyClient({ cfg, port }) の submit(request) に ConsentRecord の Request を渡すと、DONE・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED のどれかを返します（どれも approval: false）。利用側が用意するもの: 基盤への port（submit、任意で lookup）と cfg の purpose_refs・scope_refs。副作用は記録が EXTERNAL_IRREVERSIBLE、QUERY が NONE。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

DSAR を外部の DSAR の窓口へ運ぶとき、本人のメールアドレスや電話番号をそのまま送ってしまうこと、取り消せない効果や不明な効果を運搬の意図にしてしまうこと、そして運べたことを法的な権利（legal entitlement）の判断と取り違えることを防ぎます。

使う場面

• DSAR の要求を、本人の仮名の参照だけで DSAR の窓口の基盤へ運びたいとき。
• 運んだ結果を、request_id・request_digest・参照の一致で照合してから確かめたいとき。DONE の result には transport_state・dsar_type・legal_entitlement が添えられます。
• 運搬の副作用を NONE〜EXTERNAL_REVERSIBLE の範囲にとどめたいとき。取り消せない効果・不明な効果は意図にできません。
• 基盤の障害で結果が不明になっても、同じ request_id を二度送らず、lookup で解きたいとき。

使わない場面

• 請求に応じる権利があるか、何を開示してよいかを判断させたいとき。法的な判断はせず、人・組織と核の役目です。
• 開示・削除の請求に応じる窓口そのもの、あるいは開示・削除を実行する仕組みがほしいとき。この継手は DSAR の要求を基盤へ運ぶだけで、削除するかどうかは人・組織が決めます。実の基盤（DSAR の窓口）も含みません。
• 運べたことを法的な権利の判断として使いたいとき。legal_entitlement は NOT_DERIVED か人・組織に固定され、継手は導きません。
• 取り消せない効果を DSAR の運搬の意図にしたいとき。その要求は送りません。
• 個人情報を網羅的に見分けたいとき。直接の識別子の検出は、メールアドレスと電話番号の代表的な形だけです。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。
• H-04 だけの部品を求めるとき、またはほかの H の項目を担わせたいとき。この継手は H-03・H-04・H-05・H-07・H-09 を契約上 1 つの部品として担い、試験と検査も共通です。H-01・H-08 は監査台帳継手、H-06 は保管ライフサイクル継手（C-08）、H-02 は監査台帳か observability の sink が担います。

検査すること

• 本人の参照と参照の形を検めます。メールアドレス・電話番号の形の本人の参照、空の参照、パスや .. を含む参照（path traversal）、追加のフィールドは送りません。
• DSAR の意図を検めます。取り消せない効果・不明な効果を意図にした要求は送りません。
• 法的な権利を判断したと名乗る receipt は受理しません。
• receipt の request_id・request_digest・参照が要求と一致しなければ受理しません。
• 外への効果を増やす receipt、効果が UNKNOWN の receipt、request_digest を偽った receipt は受理しません。受理できない receipt が来たら停止します（HALTED）。
• 同じ request_id は二度送りません。基盤の障害は UNKNOWN とし、再送は lookup で解きます。

しないこと・既知の限界

• 法的な判断をしません。請求に応じる権利があるか、何を開示してよいかは、人・組織と核の役目です。要る同意・足りない同意の事実は核（consent-facts）が扱い、同意を与えません。
• 開示・削除を決めず、実行もしません。DSAR は運ぶだけで、削除するかどうかは人・組織が決めます。DSAR の運搬は法的な権利の判断ではありません。
• 実の基盤（DSAR の窓口）を含みません。port の実装と pin する一覧は未定で、接続するときに別の関門で決めます。
• 個人情報のすべてを見分けるものではありません。直接の識別子の検出は、メールアドレスと電話番号の代表的な形だけを見る網です。
• 運べたことは承認ではありません（approval: false）。
• プライバシー法令への適合を約束するものではありません。契約も変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/audit-privacy/v1 でつなぎます。createAuditPrivacyClient({ cfg, port }) の submit(request) に DSAR の Request を渡すと、DONE・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED のどれかを返します（どれも approval: false）。DONE の result: transport_state・dsar_type・legal_entitlement。利用側が用意するもの: DSAR の窓口の基盤への port（submit、任意で lookup）。副作用は NONE〜EXTERNAL_REVERSIBLE。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

黒塗りの処理を外部の基盤へ任せるとき、pin していない定義での処理、入力を上書きした結果や外への効果を持つ黒塗りを受け取ること、一部だけ塗れた結果（PARTIAL）を「全部塗れた」と扱うこと、そして黒塗りを開示の許可と取り違えることを防ぎます。

使う場面

• 黒塗りの処理を、pin した黒塗りの定義（redaction_manifests）に限って基盤へ運びたいとき。
• 黒塗りの結果を入力と別の参照（output_ref）で受け取り、入力を上書きさせたくないとき。
• 一部だけ塗れた結果（PARTIAL）を、全部塗れた結果と区別したいとき。PARTIAL では fully_redacted: false です。
• 黒塗りの副作用を NONE か手元で取り消せるもの（LOCAL_REVERSIBLE）にとどめたいとき。DONE の result には redaction_state・fully_redacted・output_ref・disclosure_authorization が添えられます。

使わない場面

• 何を黒塗りにするかを決めさせたいとき。その決定は核（redact-facts）の役目です。
• 黒塗りが正しく塗れているか（見落とし）を確かめたいとき。この継手は receipt の状態と出力の参照だけを見ます。
• 機微な情報を網羅的に検出する機能がほしいとき。直接の識別子の検出は、本人の参照に置かれたメールアドレスと電話番号の代表的な形だけを見る網で、すべての個人情報を見分けるものではありません。
• 黒塗りを開示の許可として使いたいとき。disclosure_authorization は NOT_DERIVED か人・組織に固定され、継手は導きません。
• すぐに使える黒塗りの処理の基盤がほしいとき。実の基盤は含まず、port の実装と pin する一覧は接続するときに別の関門（gate）で決めます。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。
• H-05 だけの部品を求めるとき、またはほかの H の項目を担わせたいとき。この継手は H-03・H-04・H-05・H-07・H-09 を契約上 1 つの部品として担い、試験と検査も共通です。H-01・H-08 は監査台帳継手、H-06 は保管ライフサイクル継手（C-08）、H-02 は監査台帳か observability の sink が担います。

検査すること

• 黒塗りの定義を検めます。pin していない定義（redaction manifest）の要求は送りません。
• 入力を上書きした receipt（出力が入力と同じ参照）は受理しません。
• 外への効果を持つ黒塗りの receipt は受理しません。黒塗りの副作用は NONE か LOCAL_REVERSIBLE で、FAILED は NONE です。
• 開示の許可を導いたと名乗る receipt は受理しません。
• PARTIAL を「全部塗れた」と扱いません（fully_redacted: false）。
• 本人の参照と参照の形を検めます。メールアドレス・電話番号の形の本人の参照、空の参照、パスや .. を含む参照（path traversal）、追加のフィールドは送りません。
• 外への効果を増やす receipt、効果が UNKNOWN の receipt、request_digest を偽った receipt は受理しません。受理できない receipt が来たら停止します（HALTED）。
• 同じ request_id は二度送りません。基盤の障害は UNKNOWN とし、再送は lookup で解きます。

しないこと・既知の限界

• 塗る処理そのものはしません。黒塗りの処理は基盤の役目で、継手は要求を検めて運び、receipt を照合するだけです。実の基盤（黒塗りの処理）は含まず、port の実装と pin する一覧は接続するときに別の関門で決めます。
• 何を黒塗りにするかは決めません。核（redact-facts）の役目です。
• 黒塗りが正しく塗れているか（見落とし）は確かめません。receipt の状態と出力の参照だけを見ます。
• 個人情報のすべてを見分けるものではありません。直接の識別子の検出は、メールアドレスと電話番号の代表的な形だけを見る網です。
• 黒塗りは開示の許可ではありません。塗れたことも承認ではありません（approval: false）。
• プライバシー法令への適合を約束するものではありません。契約も変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/audit-privacy/v1 でつなぎます。createAuditPrivacyClient({ cfg, port }) の submit(request) に RedactionPipeline の Request を渡すと、DONE・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED のどれかを返します（どれも approval: false）。利用側が用意するもの: 基盤への port（submit、任意で lookup）と cfg の redaction_manifests。副作用は NONE か LOCAL_REVERSIBLE。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

期限での削除・保全の要求を backend へ送るとき、許していない削除やリーガルホールド中の対象の削除を送ってしまうこと、期限切れの判定だけのはずが削除されたと扱うこと、backend の receipt を確かめないまま「消せた」と扱うことを防ぎます。

使う場面

• 保持方針に沿った保持の要求（RetentionRequest）を、検めてから保管の backend へ運びたいとき。
• 削除（EXPIRE）の要求を、設定 allow_expire で許したときだけ送りたいとき。
• リーガルホールドの事実（核・人の決定）を受け取り、以後その対象の EXPIRE を送らないようにしたいとき。
• 削除せずに、期限切れかどうかの判定（EVALUATE）だけを backend に求めたいとき。
• 消せたこと（deleted: true）を、EXPIRE の receipt が EXPIRED と照合できたときだけ事実として扱いたいとき。

使わない場面

• 期限が来たら自動で削除・保全する仕組みそのものがほしいとき。期限での削除・保全の実行は基盤の役目で、この継手は渡された保持の要求を運んで照合するだけです。
• 保持期限やリーガルホールドをこの継手に決めさせたいとき。その決定は核と人の役目で、この継手は事実を受け取って守るだけです。
• 期限で別の階層へ移したいとき。階層の移動は Archive の要求で、C-09 の面です。
• すぐに使える保管先がほしいとき。実 backend は含まず、どの保管サービスにつなぐかはまだ決まっていません。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。

検査すること

• 設定 allow_expire が true でないとき、EXPIRE を送りません。
• リーガルホールド中の対象には EXPIRE を送りません。
• EVALUATE の receipt が削除を伴っていれば受理しません。EVALUATE の EXPIRED は期限切れの判定だけで、削除ではありません。
• RETAIN に EXPIRED を返す receipt は、異常として受理しません。
• pin した一覧にない保持方針の要求は送りません。
• 要求の型を検めます。追加のフィールド、決まった値（const）と違う値、ファイルシステムの target、pin していない backend・許可していない target への要求は送りません。
• receipt を照合します。request_digest の偽り、別の target の receipt、外への効果を増やす receipt は受理せず、以後停止します（HALTED）。
• FAILED・REFUSED・SIMULATED の receipt は、効果なし（NONE）でなければ受理しません。backend の障害は UNKNOWN とし、同じ request_id を二度送りません。

しないこと・既知の限界

• 期限での削除・保全を実行しません。実行は基盤の役目で、この継手は保持の要求を運んで照合するだけです。
• 保持期限の決定・リーガルホールドの決定はしません。核（redact-facts・policy-facts）と人の役目で、この継手はその事実を受け取って守るだけです。
• 消せたことは承認ではありません（approval: false）。
• 実 backend を含みません。どの保管サービスにつなぐか、port の実装、pin する対象は未定で、接続するときに別の関門で決めます。
• H-06 専用の部品ではありません。C-05〜C-09 と F-04 と同じ 1 つの部品が担い、H-06 は C-08 の保持（RetentionRequest）の面です。試験と検査も共通です。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 契約を変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。

つなぎ方

契約 erabazu.candidate/certified-tsugite/storage-persistence/v1 でつなぎます。createStorageLifecycleClient({ cfg, port }) の submit(request) に RetentionRequest を渡すと、DONE・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED のどれかを返し、DONE に decision・deleted・effect を添えます（どれにも approval: false）。利用側が用意するもの: 保管 backend の port（submit、任意で lookup）と、保持方針・allow_expire の設定。副作用は EXPIRE が EXTERNAL_IRREVERSIBLE、ほかは NONE。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

リーガルホールドを外部の仕組みへ運ぶとき、人・組織の根拠が無いまま運んでしまうこと、人・組織以外や ERABAZU 自身を出どころとする根拠で運んでしまうこと、そして運べたことをリーガルホールドの権限と取り違えることを防ぎます。

使う場面

• 人・組織が出したリーガルホールドの根拠の参照を添えて、設定・解除の要求を基盤へ運びたいとき。根拠は recordAuthorityEvidence(evidence_ref, origin) で受け取ります（origin は HUMAN か ORGANIZATION だけ）。
• リーガルホールドの範囲を、pin した一覧（scope_refs）に限りたいとき。
• receipt の状態が op に答えている（PLACE→PLACED、RELEASE→RELEASED）か FAILED であることを照合してから、運べたとしたいとき。DONE の result には hold_state・legal_hold_authority が添えられます。
• 基盤の障害で結果が不明になっても、同じ request_id を二度送らず、lookup で解きたいとき。

使わない場面

• リーガルホールドが必要かを判断させたいとき。法的な判断はせず、人・組織と核の役目です。
• 根拠が本物の決定かを確かめたいとき。根拠の中身は検めず、人・組織から受け取った参照かどうかだけを見ます。
• 運べたことをリーガルホールドの権限として使いたいとき。legal_hold_authority は NOT_DERIVED か人・組織に固定され、継手は導きません。
• 削除の凍結を行う仕組みそのものがほしいとき。この継手は要求を運ぶだけで、実の基盤（リーガルホールドの仕組み）は含まず、port の実装と pin する一覧は接続するときに別の関門（gate）で決めます。
• 人・組織の根拠がまだ無いとき。根拠の無い要求は送りません（REFUSED）。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。
• H-07 だけの部品を求めるとき、またはほかの H の項目を担わせたいとき。この継手は H-03・H-04・H-05・H-07・H-09 を契約上 1 つの部品として担い、試験と検査も共通です。H-01・H-08 は監査台帳継手、H-06 は保管ライフサイクル継手（C-08）、H-02 は監査台帳か observability の sink が担います。

検査すること

• 根拠の有無を検めます。人・組織の根拠が無い要求は送りません（REFUSED）。
• 根拠の出どころを検めます。人・組織（HUMAN・ORGANIZATION）以外からの根拠、ERABAZU を出どころとする根拠では運びません。
• 範囲を検めます。pin していない範囲の要求は送りません。
• リーガルホールドの権限を名乗る receipt は受理しません。
• receipt の状態を検めます。op に答えていない状態（PLACE→PLACED、RELEASE→RELEASED、FAILED のどれでもないもの）は受理しません。
• 本人の参照と参照の形を検めます。メールアドレス・電話番号の形の本人の参照、空の参照、パスや .. を含む参照（path traversal）、追加のフィールドは送りません。
• 外への効果を増やす receipt、効果が UNKNOWN の receipt、request_digest を偽った receipt は受理しません。受理できない receipt が来たら停止します（HALTED）。
• 同じ request_id は二度送りません。基盤の障害は UNKNOWN とし、再送は lookup で解きます。

しないこと・既知の限界

• リーガルホールドが必要かを判断しません。法的な判断は人・組織と核の役目です。
• リーガルホールドの根拠を作りません（ERABAZU は根拠を作りません）。根拠の中身（本物の決定か）も検めず、人・組織から受け取った参照かどうかだけを見ます。
• 削除の凍結（保全）を自分では行いません。要求を基盤へ運び、receipt を照合するだけです。実の基盤は含みません。
• 保持・リーガルホールドの方針の事実を扱うのは核（policy-facts）、権限は人・組織の役目です。この継手がするのは、送る前と受け取った後の検めだけです。
• 運べたことはリーガルホールドの権限ではなく、承認でもありません（approval: false）。
• プライバシー法令への適合を約束するものではありません。契約も変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/audit-privacy/v1 でつなぎます。createAuditPrivacyClient({ cfg, port }) の recordAuthorityEvidence(evidence_ref, origin) で根拠を受け取った後、submit(request) に LegalHold の Request を渡すと、DONE・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED のどれかを返します（どれも approval: false）。利用側が用意するもの: 基盤への port（submit、任意で lookup）と cfg の scope_refs。副作用は EXTERNAL_REVERSIBLE。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

ハッシュでつないだ監査の連鎖は、どこかで前のハッシュが書き換えられたり、digest の計算の仕方が食い違ったりすると、改ざんを見つける力を失います。この継手は、送る前の封筒と保管先の受領の両方を同じ契約の式で検め、式と合わない連鎖を送らず、受理しないことで、照合できない連鎖を信頼しないようにします。

使う場面

• 監査イベントを、前のハッシュでつないだ改ざん検知の連鎖として外部の追記専用 backend に残したいとき。
• 連鎖のハッシュを、決まった式（RFC 8785 に制限した正準化と sha256）でそろえて計算・照合したいとき。
• 保管先が返す受領の event_digest や連鎖のハッシュをそのまま信じず、送った封筒から計算し直して照合してから記録済みとしたいとき。
• 連鎖の食い違いが見つかったら、人が確かめるまで追記を止めたいとき。
• 封筒の検めと受領の照合だけを、backend を呼ばずに試したいとき。純粋な関数 checkEnvelope と checkReceipt が { ok, errors } を返します。

使わない場面

• 透明性ログ（Merkle の包含証明）が要るとき。この継手が扱うのは前のハッシュでつなぐ連鎖で、包含証明は範囲外です。
• 改ざんがあったかどうかの最終の判断を、この継手に任せたいとき。改変不能かの決定は核（provenance-facts・integrity-facts）の役目です。
• RFC 8785 に制限した正準化と sha256 ではない、別のハッシュの式を使いたいとき。式の違うハッシュは受理しません。
• 監査イベントの本文そのものを連鎖に載せたいとき。封筒には契約のフィールドだけを載せ、本文の混入は拒否します。
• すぐに使える保管先がほしいとき。実 backend は含まず、どの追記専用サービスにつなぐかはまだ決まっていません。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。

検査すること

• 前のハッシュ（previous_hash）を、台帳の先頭（head）と照らして検めます。previous_hash が書き換えられた封筒は、送らず、受理しません。
• 連鎖のハッシュを契約の式で計算し直します。RFC 8785 に制限した正準化と sha256 で求め、正準化していない形で計算したハッシュは受理しません。
• 連鎖の始まり（genesis）の規則を検めます。genesis の previous_hash_value は空文字として計算し、genesis の規則に反する封筒は送りません。
• digest を検めます。digest の対象（domain）を取り違えて計算したものは受理しません。
• 受領（AuditAppendReceipt）を照合します。event_digest の偽り、連鎖のハッシュの誤り、台帳・通番・event_id・対象の食い違いがあれば、受理しません（RECEIPT_REJECTED）。
• 受領に不整合があれば停止します（HALTED）。人が確かめるまで追記しません。
• 通番（sequence）の巻き戻し・飛びがあれば、送らず、受理しません。連鎖の順番が崩れた追記を通しません。

しないこと・既知の限界

• 改変不能かどうか、改ざんがあったかどうかを決めるのは核（provenance-facts・integrity-facts）の役目です。この継手がするのは、送る前の検めと受領の照合だけです。
• 透明性ログ（Merkle の包含証明）は扱いません。
• 実 backend を含みません。どの追記専用サービスにつなぐか、port の実装、pin する対象（endpoint・受領の形式）は未定で、接続するときに別の関門で決めます。
• backend の認証に使う秘密（SecretRef）の解決はしません。port 側の責務です。
• 追記の成功は承認ではありません（approval: false）。
• 契約とハッシュの式を変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• H-08 専用の部品ではありません。H-01（改変不能監査ログ）・C-04（追記専用台帳）・H-02（アクセスログ）と同じ 1 つの部品が担い、試験と検査も共通です。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/audit-ledger/v1 でつなぎます。createLedgerClient({ cfg, port }) の append(envelope) に AuditEventEnvelope を渡すと APPENDED_VERIFIED・ALREADY_APPENDED・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED のどれかを返します（どれにも approval: false）。検めだけなら checkEnvelope と checkReceipt が { ok, errors } を返します。利用側は追記専用 backend への port（append、任意で lookup）を用意します。副作用は EXTERNAL_IRREVERSIBLE（取り消せない書き込み）。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

規制報告を外部の提出窓口へ運ぶとき、pin していない形式や提出先へ送ること、書き換わった中身や大きすぎる中身を送ること、許していない取り消せない提出をしてしまうこと、そして届けたことを規制当局の受理と取り違えることを防ぎます。

使う場面

• 規制報告の形式と提出先を、pin した一覧（report_profiles・report_destinations）に限りたいとき。
• 報告の中身（bytes）の digest と上限（max_report_bytes）を確かめてから運びたいとき。max_report_bytes は報告を使うとき必須です。
• 取り消せない提出を、設定 allow_irreversible: true のときだけに限りたいとき（既定は false）。
• 生成（GENERATED）と届けた（DELIVERED）を副作用と照らして区別したいとき。GENERATED は NONE か LOCAL_REVERSIBLE、DELIVERED は EXTERNAL_* です。DONE の result には delivery_state・delivered・regulatory_acceptance が添えられます。

使わない場面

• 規制当局が受理したかを知りたいとき。届けた報告は規制当局の受理ではなく、regulatory_acceptance は NOT_DERIVED か人・組織に固定され、継手は導きません。
• 届いた先が pin した提出先かを receipt で確かめたいとき。規制報告の receipt には提出先の欄が無く、確かめられるのは送る前の pin だけです。
• 報告の中身を作らせたいとき。中身は利用側が submit(request, bytes) の bytes として渡し、継手が確かめるのは digest と上限です。
• 法的な判断をさせたいとき。この継手は法的な判断をせず、人・組織と核の役目です。
• すぐに使える提出の窓口がほしいとき。実の基盤（規制当局の窓口）は含まず、port の実装と pin する一覧は接続するときに別の関門（gate）で決めます。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。
• H-09 だけの部品を求めるとき、またはほかの H の項目を担わせたいとき。この継手は H-03・H-04・H-05・H-07・H-09 を契約上 1 つの部品として担い、試験と検査も共通です。H-01・H-08 は監査台帳継手、H-06 は保管ライフサイクル継手（C-08）、H-02 は監査台帳か observability の sink が担います。

検査すること

• 報告の形式と提出先を検めます。pin していない形式（report profile）・提出先（report destination）の要求は送りません。
• 報告の中身を検めます。bytes の digest が合わないもの、上限を超えるものは送りません。
• 取り消せない提出を検めます。allow_irreversible: true でなければ送りません。
• 状態と副作用の対応を検めます。GENERATED なのに外への効果を名乗る receipt、DELIVERED なのに効果の無い receipt は受理しません。
• 規制当局の受理を導いたと名乗る receipt は受理しません。
• 本人の参照と参照の形を検めます。メールアドレス・電話番号の形の本人の参照、空の参照、パスや .. を含む参照（path traversal）、追加のフィールドは送りません。
• 外への効果を増やす receipt、効果が UNKNOWN の receipt、request_digest を偽った receipt は受理しません。受理できない receipt が来たら停止します（HALTED）。
• 同じ request_id は二度送りません。基盤の障害は UNKNOWN とし、再送は lookup で解きます。

しないこと・既知の限界

• 規制当局の受理を導きません。届けたことは受理ではなく、承認でもありません（approval: false）。
• 届いた先を receipt で確かめません。規制報告の receipt には提出先の欄が無く、送る前の pin だけで検めます。
• 報告の中身について継手が確かめるのは digest と上限だけです。法的な判断はしません（人・組織と核の役目）。
• 法的な権利・開示の許可は人・組織の役目です。この継手がするのは、送る前と受け取った後の検めだけです。
• 実の基盤（規制当局の窓口）を含みません。port の実装と pin する一覧は未定で、接続するときに別の関門で決めます。
• プライバシー法令への適合を約束するものではありません。契約も変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/audit-privacy/v1 でつなぎます。createAuditPrivacyClient({ cfg, port }) の submit(request, bytes) に RegulatoryReport の Request と中身の bytes を渡すと、DONE・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED のどれかを返します（どれも approval: false）。利用側が用意するもの: 基盤への port（submit、任意で lookup）と cfg（pin する形式・提出先、max_report_bytes、allow_irreversible）。副作用は NONE〜EXTERNAL_*。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

数字の出どころを後で問われたときの裏付けになります。どの入力を使い、どの集計器の版で、どの出力ができたかを、入力の集合のハッシュ・集計器の版・出力のハッシュとして残します。重複した入力を黙って除かないので、どの入力を使ったかの数え違いを隠しません。

使う場面

• 集計の入力の集合・集計器の参照と版・出力の bytes・記録の時刻から、系譜の記録を作りたいとき（recordLineage）。
• 入力の集合を、並べ順に左右されない digest にしたいとき。inputs を UTF-16 の符号単位の順に並べた配列の、RFC 8785 の正準 JSON の sha256 です。
• あとで入力と出力から計算し直し、記録と同じかを確かめたいとき（checkLineage。違いは matches: false と mismatched の一覧で、エラーではない）。
• どの欄が違ったか（input_set.count・input_set.digest・output.digest・output.size）を知りたいとき。
• 時計・乱数・外の接続を持たない、決定的な処理として手元で呼びたいとき。recorded_at は呼ぶ側が渡します。

使わない場面

• 集計器が正しいこと・出力が正しいことの証明が要るとき。この部品は集計器を動かさず、系譜は使ったものの記録です。
• 本当にその版で動かしたか・その時刻かを確かめたいとき。tool の ref・version と recorded_at は渡された値をそのまま記録し、照合では形だけを検めて値は比べません。
• inputs の Ref が実在する入力を指すか、その中身を確かめたいとき。Ref の形だけを検め、中身が変わっても Ref が同じなら digest は同じです。
• 記録そのものの改ざんを止めたいとき。それは署名（B-12）や封（H-11）の側の役目です。
• 時差の付いた時刻（+09:00 など）やうるう秒で記録したいとき。recorded_at は UTC の Z だけで、ほかは INVALID_TIME で止めます。
• 入力を 1,048,576 個より多く扱うとき。INVALID_INPUTS で止めます。
• Node.js v24.21.0 のほかの版で使うとき。ほかの版は確かめていません（NOT_VERIFIED）。

検査すること

• inputs に同じ文字列が 2 回以上あるとき、黙って除かずに DUPLICATE_INPUT で止めます（文字列の完全一致で比べ、大文字と小文字は別の入力）。
• inputs が素の配列でない、穴・余分なプロパティ・getter の要素を持つ、Ref でない要素を持つ、1,048,576 個を超えるとき、INVALID_INPUTS で止めます。
• tool_ref が Ref でない、tool_version が 1〜200 文字でない・制御文字や対になっていないサロゲートを含むとき INVALID_TOOL、output_bytes が Uint8Array でないとき NOT_BYTES で止めます。
• recorded_at が RFC 3339 の UTC（Z）の形でない、または実在しない日時（2 月 30 日・24 時・60 秒など）のとき、INVALID_TIME で止めます。
• checkLineage の record の形が違うとき（欄の過不足・schema の違い・負の count・小文字 64 桁の hex でない digest など）、INVALID_RECORD と最初に見つけた欄の名前（field）で止めます。
• 引数が素のオブジェクトでない・決まった欄のほかを持つとき INVALID_ARGUMENT、引数を読むこと自体が例外になるとき INSPECTION_FAILED で止めます。欄はそれぞれ一度だけ読みます。

しないこと・既知の限界

• 系譜は「何を使って何ができたか」の記録で、集計器が正しいこと・出力が正しいこと・記録が改ざんされていないことの証明ではありません。matches: true は、渡した入力と出力が記録と同じだったことだけを示します。
• 記録を保管しません。状態・時計・外の接続を持ちません。
• inputs が 0 個でも記録を作ります（count 0、digest は "[]" の sha256）。0 個を断ることはしません。
• SHA-256 の計算そのものは Node.js の crypto に任せていて、ファズのオラクルも同じ crypto を使います。
• 正準化は I-08 の部品のコードの写し（src/canonical.js）を使います。写しの中の分岐そのものは、この部品の試験では通りません（写しの試験は I-08 の側）。
• 記録・照合の結果は、承認ではありません（result_is_approval: false）。権限も作りません（derives_authority: false）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 特定の来歴（provenance）の仕様の実装ではありません。

つなぎ方

src/lineage.js の recordLineage({ inputs, tool_ref, tool_version, output_bytes, recorded_at }) と checkLineage({ record, inputs, output_bytes }) を呼びます（投げません）。record は schema（erabazu.lineage/1）・input_set（count・digest）・tool（ref・version）・output（digest・size）・recorded_at です。返すのは record か matches・mismatched で、止めるときは { ok: false, errors: [{ code }] } です。副作用・状態・外の接続・資格情報は無く、利用側が用意する port はありません。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

生データが後から書き換えられていないことの裏付けのための部品です。署名し直さない書き換えや信頼しない鍵の記録に続けて書くこと、証明や呼ぶ側の言う木の大きさを信じること、記録を上書きすること、固定できていないのに固定したと言うことを防ぎます。

使う場面

• 区画（folder_ref）に足したファイル（name と sha256、1〜10000 個）ごとに、前の記録の鎖に続く署名した封印の記録を <folder_ref>/seal/<seq>.json に 1 回だけ書きたいとき（appendSeal）。
• 日ごとに、区画の根を folder_ref の順に束ねた日の根を作り、canonical({ seal_date, root }) の形のファイルと、署名した日の記録を書きたいとき（finalizeDay）。日の記録は時計を含まないので、同じ鎖からは同じ bytes になります。
• 日の根を、注入した固定の port（H-01 の append と同じ形）で外へ固定し、その receipt を seal/roots/<date>.anchor.json に残したいとき。固定の port は根のファイルと日の記録が書けた後にだけ呼びます。
• 署名した 1 件の記録に対して、ファイルの包含の証明を検めたいとき（verifyFile）。証明を鎖から作りたいとき（proveFile）。
• 署名を、秘密鍵を閉じ込めた sign の port に任せ、この部品に秘密鍵を渡したくないとき。署名するのは keys の最初の鍵だけで、ほかの鍵は前の記録の検めにだけ使います。
• 結果の分からなかった書込・固定を、同じ要求・同じ bytes・同じ envelope で送り直したいとき（resolvePending）。

使わない場面

• 固定の port を付けずに、「この日時に存在した」ことの裏付けとして使いたいとき。固定の port が無ければ anchored: false で、記録は「これが署名した内容」だけです。sealed_at は注入した時計の値で、時刻の権威ではありません（信頼できる時刻は B-06）。
• 署名を、ファイルの中身や取得の正しさ・業務の判断・承認として使いたいとき。署名は「keys の鍵の持ち主がこの bytes に署名した」ことだけです。
• 鍵の置き場所・保管・入れ替え・失効まで任せたいとき。この部品の外で、どの鍵をいつまで信じるかは決めていません。
• verifyFile だけで鎖まで確かめたいとき。verifyFile は記録 1 件の署名と包含だけを検め、信頼する鍵で誤った tree_size に署名された記録は見分けられません。鎖の検めは appendSeal・finalizeDay・proveFile で行います。
• この部品に保管を読ませたいとき。この部品は保管を読みません。鎖は呼ぶ側が保管から読んで渡します。保管に無い版の記録を渡されると、それに続く記録を書き、以後その区画は SEAL_CHAIN_BROKEN で止まります（直すのは人）。
• 固定の port 付きの finalizeDay のやり直しを、成功として受け取りたいとき。固定の記録は anchor_status を含むので中身が変わり、保管が断って WRITE_REFUSED で終わります。
• Node.js v24.21.0 のほかの版で使うとき。ほかの版は確かめていません（NOT_VERIFIED）。

検査すること

• options が足りない・形が違う・keys が 1〜16 個でない・key_id や指紋が重なる・port の関数が無いとき INVALID_OPTIONS、操作の入力の形が違うとき INVALID_INPUT、getter が例外を投げたとき INSPECTION_FAILED で止めます。
• 渡した鎖が検めを通らないとき（正準化・欄・schema・folder_ref・seq・名前の重なり・tree_size・prev_entry_sha256・信頼する鍵の署名・前の根との一貫性・ファイルから計算し直した根）、SEAL_CHAIN_BROKEN で何も書きません。errors[0] に folder_ref・at・reason を添えます。
• tree_size と根は、署名した記録とファイルの数から取り直します。一貫性・包含の証明や呼ぶ側の言う大きさは使いません（RFC 9162 の証明は木の大きさを縛りません）。
• 足すファイルの名前が重なる・鎖に既にあるとき DUPLICATE_NAME、finalizeDay で同じ folder_ref が 2 回あるとき DUPLICATE_FOLDER、区画の記録が 10000 件かファイルが 100000 個を超えるとき SEAL_LIMIT_EXCEEDED で止めます。
• sign の port が投げた・ok でないとき SIGN_FAILED、結果が Ed25519・最初の鍵の key_id と指紋でない・最初の鍵の公開鍵での往復の検めが通らないとき SIGNER_MISMATCH、B-11・B-12 の port の故障や形の違いのとき MERKLE_PORT_FAILED・VERIFY_PORT_FAILED で、書きません。
• 書込の結果が分からないとき WRITE_UNKNOWN、送らなかったとき WRITE_REFUSED、停止・結果が APPLIED か DEDUP_HIT でないとき WRITE_FAILED です。固定の port の結果が分からないとき ANCHOR_UNKNOWN、断ったとき ANCHOR_REFUSED、停止・receipt の照合の失敗・形の違いのとき ANCHOR_FAILED で、anchored: true にしません。保留の間の appendSeal・finalizeDay は SEAL_PENDING です。
• verifyFile で、記録が正準化できない・形が違う・信頼する鍵の署名でないとき ENTRY_UNVERIFIED、証明の tree_size が記録と違う・leaf_index が大きすぎるとき PROOF_NOT_FOR_ENTRY、proveFile で名前が鎖に無いとき NAME_NOT_SEALED です。
• timestamp が RFC 3339 の UTC（Z）の実在する日時を返さないとき CLOCK_FAILED、前の操作が終わっていないとき BUSY、保留が無いのに resolvePending を呼ぶと NOTHING_PENDING です。

しないこと・既知の限界

• 封印の部品は継手ではありません。自分の Request/Receipt は無く、書込は束ねた C-05 の継手が自分の契約で、固定は注入した port がその契約で起こします（台帳への追記・Git の push は取り消せない効果です）。この部品自身は外へ触れません。
• 束ねた部品の意味（根が正しい ≠ 中身が正しい・署名 ≠ 承認・固定した ≠ 権威ある時刻で刻んだ）は、それぞれの部品の側に残ります。
• どの結果も、承認でも権限でも時刻の権威でもありません（approval: false・authority: NOT_DERIVED・timestamp_authority: NOT_DERIVED、derives_authority: false）。
• 外への固定の強さは、注入した固定の port とその先の強さまでです。この部品は port が固定したと言ったことと receipt を記録するだけで、固定先を自分では確かめません。
• 上書き・削除の要求は送りません。秘密鍵を見ません（sign の port の中だけ）。
• 単体試験とファズは代役です（ファズの署名の代役は Ed25519 ではなく、速さのための SHA-512 の代役）。本物の B-11・B-12・C-05・H-01 との結線は、別の結線の検めで確かめました。Git の固定は、成功する経路だけを結線で確かめ、断り・衝突・non-fast-forward の経路は試していません。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 特定の透明性ログや署名の製品の雛形ではありません。

つなぎ方

src/seal.js の createSeal(options) で作り、{ ok, errors, instance } を返します。options は target・request_prefix・keys・ports・任意の timestamp です。操作は appendSeal・finalizeDay・verifyFile・proveFile・resolvePending・status で、結果に approval: false が付きます。port は merkle（B-11 の 5 つの関数）・sign（秘密鍵を閉じ込めた closure）・verify と publicKeyFingerprint（B-12）・write.submit（C-05 の継手のクライアント）・任意の anchor.append です。資格情報は port が持ちます。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

「いつの時点の根か」を外から照らせるようにします。そのとき、根を上書きしてしまうこと、同じ日付に別の根を固定してしまうこと、push の結果が見えないまま二重に commit してしまうこと、commit の日時を時刻の権威と取り違えることを防ぎます。

使う場面

• 封印の部品が書いた日次の根のファイルを、Git のリポジトリへ追記だけで固定したいとき。
• 送る前に、要求の root_digest からファイルの中身 canonical({seal_date, root}) を作り直し、その sha256 が file_digest と同じことを確かめたいとき。
• 1 つの日付に 1 つの根を守りたいとき。食い違い（CONFLICT）の日付は、人の判断まで送りません。
• push の結果が見えないとき、相手の側（branch の先頭と path のファイル）を読んで解いてから送り直したいとき（port.inspect と SealInspectRequest / SealInspectReceipt）。

使わない場面

• 根そのもの（Merkle の計算・署名）を作りたい・確かめたいとき。それは封印の部品の役目で、この継手は根の digest からファイルの digest を作り直して照らすだけです。
• 信頼できる時刻で刻みたいとき。commit の日時もホストの push の時刻も観測です。信頼できる時刻は B-06（RFC 3161）の継手で別に刻みます。
• 履歴の書き換え（上書き・force-push・amend・削除）をしたいとき。要求にも設定にもその欄はありません。
• 特定の Git ホスティング（GitHub など）の API や git コマンドの使い方の雛形がほしいとき。この継手はその雛形ではありません。
• すぐに使える固定先がほしいとき。実の Git・remote への commit・push は 0 回で、port の実装・資格情報・ブランチ保護の設定は、接続するときに別の関門で決めます。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。

検査すること

• 設定と要求を検めます。repository・branch・committer は設定の一覧（repositories・branches・committer_refs）の中だけです。branch_ref は git check-ref-format に合うものだけで、暦に無い seal_date は送りません。空の一覧は何も許しません。
• ファイルの digest を照らします。作り直した sha256 と file_digest が違う要求は送りません。committed_file_digest が違う receipt、ANCHORED の parent_commit が依頼と違う receipt、changed_paths がちょうど [path] でない receipt は受理しません。
• 追記だけを守ります。history_rewrite が NOT_PERFORMED でない receipt は受理しません。設定に知らないキー（force_push など）があれば、何も送りません。
• 日付の状態を照合します。知っている日付に別の根は送りません。知っている日付への 2 度目の ANCHORED、知っている根と違う ALREADY_ANCHORED は受理せず、停止します（HALTED）。
• commit の桁を照合します。commit_id は依頼の parent_commit と同じ桁（40 桁か 64 桁、リポジトリの形式）のときだけ受け取ります。
• 効果を増やす receipt、FAILED のほかで効果の不明な receipt、状態の表の外の receipt、別の要求の receipt は受理せず、停止します。ANCHORED の効果は EXTERNAL_IRREVERSIBLE、ほかは NONE（FAILED は NONE か UNKNOWN）です。
• 結果の見えない push（port の障害、FAILED・UNKNOWN の receipt）は UNKNOWN（未解決）とし、成功にも失敗の確定にもしません。相手の側を読めないときは送り直さず、解けるまでほかの要求も送りません。
• push の資格情報は参照（committer_ref）だけです。committer_refs に封印の署名の鍵の参照（seal_signing_key_refs）が入っている設定は、誤りとして拒否します。

しないこと・既知の限界

• commit の中身が本当にその親とその変更か、push が fast-forward だったか、読んだ答えが本当の Git の状態かは確かめません（port の申告。この継手は git のオブジェクトを読みません）。
• 日付の状態はこの継手の中だけで、再起動で消えます。この継手が知らない日付の上書きは見分けられません。上書き・force-push の禁止は、repository のブランチ保護で別に守ります。
• commit の日時・host_time の正しさも順序も確かめません。どちらも時刻の権威ではありません（commit_date_authority・timestamp_authority は NOT_DERIVED）。
• 根そのものの正しさは確かめません。CONFLICT の解決は人の判断です。
• 固定できたことは承認ではなく、権威ある時刻で刻んだことでも、根が正しいことでもありません（どの結果にも approval: false が付きます）。
• 契約を変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/seal-anchor-git/v1（SealAnchorRequest / SealAnchorReceipt、読む口 SealInspectRequest / SealInspectReceipt）でつなぎます。createSealAnchorClient({ cfg, port, clock }) の submit(request) は DONE・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED を返します（常に approval: false）。利用側の用意: Git の port（submit、任意の lookup・inspect）と cfg の一覧。副作用: ANCHORED だけ EXTERNAL_IRREVERSIBLE。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

入力の形の妥当性を検めるときに、知らないキーワード・外の $ref・壊れた値を黙って読み飛ばして「通った」ことにしてしまうことを防ぎます。使えるキーワードを固定し、一部の外のものはスキーマごと断ります。

使う場面

• JSON の値の形（type・required・properties・additionalProperties・長さ・範囲・pattern・enum・const など）を、決まった一部のキーワードで検めたいとき（validate）。
• スキーマそのものが一部の中に収まっているかを、インスタンスなしで先に確かめたいとき（checkSchema）。
• 止めた理由を、コード・instance_path・schema_path（JSON Pointer）の最初の 1 件として、決まった順で受け取りたいとき。
• getter を呼ばず、スキーマとインスタンスを 1 回だけ読んだ写しで検めたいとき（途中で中身が変わらない）。
• 時計・乱数・環境の locale に左右されず、外の境界・状態を持たない処理として手元で呼びたいとき。validate と checkSchema は例外を投げません。

使わない場面

• JSON Schema 2020-12 の全体が要るとき。使えるのは決まった 28 のキーワードだけで、format は検めずに断ります。
• いまの実物の契約のスキーマ（00a の 17 本）をそのまま検めたいとき。17 本はどれも一部の外（format・runtime_validator_contract・uniqueItems・hash_computation・外の $ref）を使うので、スキーマごと断られます。
• 外の文書・$id による基底の URI・$anchor・$dynamicRef を使う $ref が要るとき。$ref は "#" と "#/$defs/<名前>" だけです。
• 信頼できないスキーマの pattern をそのまま使うとき。正規表現の爆発（ReDoS）は止めず、評価の回数の上限は正規表現の中の時間を数えません。
• 文字列・配列の長さや const・enum の比較の大きさに上限が要るとき。上限は持たず、I-06 の部品か使う側で決めます。
• 2^53 以上の整数を integer として扱いたいときや、見た目が同じ文字列を同じとして扱いたいとき。integer は安全な整数だけで、Unicode の正規化はしません。
• Node.js v24.21.0 のほかの版で使うとき。ほかの版は確かめていません（NOT_VERIFIED。RegExp の u フラグの Unicode の版はエンジンに依ります）。

検査すること

• 一部の外のキーワード（format を含む）が、どこにあっても（使われない $defs の中でも）あるとき、根でない $schema・$id・$defs があるとき、スキーマごと UNSUPPORTED_KEYWORD で止めます。
• $schema が 2020-12 でないとき UNSUPPORTED_DIALECT、$ref の形が違うとき（外の文書・アンカー・% ・~ の書き方）UNSUPPORTED_REF、名前が $defs に無いとき UNRESOLVED_REF で止めます。
• インスタンスを進めずに回る $ref があるとき、たどり着くかどうかに関わらず REF_CYCLE で止めます。
• キーワードの値の形が違うとき（空の enum・重なる required や type・負の数・配列の形の items・if の無い then）INVALID_SCHEMA、pattern が作れないとき INVALID_PATTERN で止めます。
• スキーマが JSON の値でないとき（getter を含む）SCHEMA_NOT_JSON、インスタンスが JSON の値でないとき（undefined・関数・NaN・bigint・Date・穴のある配列・symbol のキー・getter など）INSTANCE_NOT_JSON で止めます。
• 入れ子が 256 段を超えるとき SCHEMA_TOO_DEEP・INSTANCE_TOO_DEEP、評価の深さが 512 に届くとき EVALUATION_TOO_DEEP、評価の回数が 1,000,000 を超えるとき EVALUATION_LIMIT で止めます。not・anyOf・oneOf・if の中で届いても「通らない」に化けません。
• インスタンスがスキーマに合わないとき、TYPE_MISMATCH・REQUIRED_MISSING・ADDITIONAL_PROPERTY・PATTERN_MISMATCH・ONE_OF_MANY_MATCHED など、キーワードごとの決まったコードで止めます。2^53 以上の整数は integer に当てはまりません。
• 値を調べること自体が例外になるとき（Proxy の罠など）、INSPECTION_FAILED を返し、例外を投げません。Proxy が答えを変えても、1 回だけ読んだ写しを検めるので途中で結果が変わりません。

しないこと・既知の限界

• JSON Schema の全体ではなく一部だけを扱います（決まった 28 のキーワード）。format は検めずに断り、外の文書・$anchor・$dynamicRef の $ref も断ります。
• 実物の契約のスキーマ（00a の 17 本）は、どれも一部の外として断られます。一部は黙って広げておらず、一部を広げるか、契約の側を一部に合わせるかは別の決定です。
• 公式の JSON-Schema-Test-Suite にはかけていません。既知の答えは、この部品の試験に書いたものです。
• pattern の正規表現の爆発（ReDoS）は止めません。信頼できないスキーマの pattern は使う側で制限します。
• スキーマに合うことは形の検めで、値の中身が正しいことでも、受け入れてよいことでも、許可でもありません（意味の判断は Kernel、承認は人。result_is_approval: false）。権限も作りません（derives_authority: false）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 特定の JSON Schema のライブラリの使い方の雛形ではありません。

つなぎ方

src/schema-validate.js の validate(schema, instance) を呼びます（投げません）。checkSchema(schema) はスキーマだけを検め（投げません）、assertValid は合わなければ SchemaValidateError を投げます。受け取るのは、決まったキーワードだけのスキーマと、JSON の値のインスタンスです。返すのは { ok: true, errors: [] } か { ok: false, errors: [{ code, instance_path, schema_path }] }（最初の 1 件。code は error_taxonomy）。外の $ref は読みに行きません。副作用（NONE）・状態・外の接続・資格情報は無く、利用側が用意するものはありません。依存は Node.js の組み込みだけです。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

文字列を HTML・URL・<script> の中に書き出すときに、context を決めずに推測で符号化してしまうことや、壊れた文字列（単独のサロゲート）を黙って置き換えてしまうことを防ぎます。context は名前で明示させ、既定の context はありません。

使う場面

• 文字列を HTML の要素の中身（テキスト）に入れたいとき（html_text。& < > " ' を実体参照にします）。
• 文字列を二重引用符で囲んだ HTML の属性の値に入れたいとき（html_attribute_quoted。html_text の 5 つに加えて ` も符号化します）。
• 文字列を URL の 1 つの部分（パスの 1 区切り・クエリの名前や値）に入れたいとき（url_component。RFC 3986 の unreserved のほかを %XX にします）。
• 文字列を HTML の <script> 要素の中に、JSON の文字列リテラルとして置きたいとき（json_in_html_script。< > & U+2028 U+2029 を \u の形にし、</script> や <!-- で要素が閉じられません）。
• 時計・乱数・環境の locale に左右されず、外の境界・状態を持たない処理として手元で呼びたいとき。encode は例外を投げず、逆向きに戻すと元の text になります。

使わない場面

• タグや属性を残したい HTML の入力を無害化したいとき。この部品は HTML の無害化（sanitize）ではなく、すべてを文字として書きます。
• 引用符で囲まない属性・イベント属性（onclick など）・style 属性・URL を取る属性（href・src の javascript: など）の値の意味を防ぎたいとき。html_attribute_quoted はそれを防ぎません。
• URL 全体の検め（スキームの許可・ホストの検め）が要るとき。url_component は URL の 1 つの部分のためです。
• HTML の属性の中・JavaScript の文字列やテンプレートリテラルの中・style などの生テキストの要素に書くとき。json_in_html_script は <script> 要素の中のためです。
• CSS・JavaScript の識別子・XML・SQL・シェル・ヘッダーなどの context に書くとき。これらは扱いません。
• 1,048,576 UTF-16 符号単位より長い文字列を扱うとき。INPUT_TOO_LARGE で止めます。
• Node.js v24.21.0 のほかの版で使うとき。ほかの版は確かめていません（NOT_VERIFIED）。

検査すること

• context が決めた 4 つのどれでもないとき（大文字や空白の違い・Object.prototype の名前・文字列でない値を含む）、UNKNOWN_CONTEXT で止めます。
• text がプリミティブの文字列でないとき（数・null・undefined・String オブジェクト・配列・Symbol・bigint・Proxy）、NOT_A_STRING で止めます。
• text が 1,048,576 UTF-16 符号単位より長いとき、INPUT_TOO_LARGE で止めます。
• text に単独のサロゲート（対になっていない U+D800〜U+DFFF、逆順の対・末尾の単独を含む）があるとき、どの context でも INVALID_UNICODE で止めます。U+FFFD に置き換えません。
• 止める順は context → 文字列か → 長さ → 単独のサロゲートで、最初に当たった 1 つだけを返します。

しないこと・既知の限界

• 「injection 防止」を名前に持つ項目ですが、この部品は決めた 1 つの context の中で文字を文字として書く符号化だけで、HTML の無害化（許すタグを残す処理）は含みません。
• どの値をどの context に入れるか（テンプレートの組み立て）は決めません。使う側、または別の部品に残ります。
• ある context のための符号化は、別の context での安全ではありません。
• ブラウザの実際の読み方（parse）は実機で確かめていません。HTML・URL・JSON の仕様の規則から決め、Node.js v24.21.0 の組み込みの関数と独立オラクルで確かめました。
• Unicode の正規化はしません。見た目が同じでも、符号単位が違えば別の出力です。
• 符号化できたことは、その文字列を別の context に入れてよいことでも、HTML として無害にしたことでも、内容を受け入れてよいことでもありません（result_is_approval: false）。権限も作りません（derives_authority: false）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 特定のテンプレートエンジンやエスケープのライブラリの使い方の雛形ではありません。

つなぎ方

src/encode.js の encode(text, context) を呼びます（投げません）。受け取るのは、プリミティブの文字列 text（1,048,576 UTF-16 符号単位まで）と、html_text・html_attribute_quoted・url_component・json_in_html_script のどれかの context です。返すのは { ok: true, errors: [], text }（符号化した文字列）か { ok: false, errors: [{ code }] }（code は error_taxonomy。text は無い）です。副作用（NONE）・状態・外の接続・資格情報は無く、利用側が用意するものはありません。依存は Node.js の組み込みだけです。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

アップロードの検疫で、偽った・古い・すり替えた検査結果を通してしまうこと、そして「検出なし」を「安全」と取り違えて検疫を外してしまうことを防ぎます。検出が無くても安全は導かず（safety: NOT_DERIVED_FROM_SCAN）、検疫の解除は Policy・人の決定に残します。

使う場面

• アップロードされた添付などを、外部の scan engine に検査させ、その結果を検めてから扱いたいとき。
• 検査の受領を、対象の digest・pin した scanner と engine と版・提出からの時間枠で照合し、偽った・古い・すり替えた結果を通したくないとき。
• 検査の結果にかかわらず検疫を保ち、解除は Policy・人の決定に任せたいとき。
• 判定の無い・不明な検査結果を、clean 扱いにしたくないとき。

使わない場面

• マルウェアを検査する engine そのものがほしいとき。この継手は scan engine を含みません。検査は外部の engine が行い、どの engine につなぐかはまだ決まっていません。
• 「検出なし」を「安全」として使いたいとき。NOT_DETECTED でも安全とは言わず（safety: NOT_DERIVED_FROM_SCAN）、検疫を保ちます。
• 検疫の解除をこの継手にさせたいとき。解除は Policy・人の決定で、この継手は扱いません。
• モデレーション（I-04）が要るとき。別の部品です。
• 検査の結果を、承認や信頼・認可の根拠として扱いたいとき。どの結果も承認ではなく、trust・authorization は導きません（NOT_DERIVED）。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。

検査すること

• 提出を検めます。許可していない content-type、大きさの上限を超えるもの、中身の改ざん（digest と合わない bytes）は提出しません（REFUSED）。
• scanner と engine を検めます。pin していない scanner は受け付けず、pin した一覧に無い engine や版の受領は受理しません。pin していない engine の受領が来れば、以後は停止します（HALTED）。
• 受領の対象を照合します。request_digest を偽った受領、対象の digest をすり替えた受領は受理せず、以後は停止します（HALTED）。
• 時間枠を検めます。提出より前の受領と、提出から max_scan_seconds を過ぎた受領は、古い受領として受理しません。
• 語彙と証拠を検めます。知らない判定、証拠の無い DETECTED、safe・trusted・authorized を主張する受領は受理しません。
• INCONCLUSIVE・UNKNOWN の判定は SCAN_INCONCLUSIVE とし、clean 扱いにしません。
• scanner の障害は UNKNOWN とします。同じ提出は二重に出さず、再送は照会（lookup）で解きます。

しないこと・既知の限界

• マルウェアを検査しません。scan engine を含まず、検査そのものは外部の engine が行います。実 scan engine は未定で、port の実装と pin する対象（engine・版・受領の形式）は、接続するときに別の関門で決めます。
• 検出を受けた後の案件の整理はしません。核（case-support）の役目です。検疫の解除は Policy・人の決定です。
• 安全を導きません。どの結果にも safety: NOT_DERIVED_FROM_SCAN、quarantine: KEEP_UNTIL_POLICY_DECISION、approval: false が付きます。
• 検疫を解除しません。解除は Policy・人の決定です。
• モデレーション（I-04）は扱いません。別の部品です。
• 契約を変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• ウイルス対策の使い方の雛形ではありません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/request-receipt-group/v1 でつなぎます。createScanClient({ cfg, port }) の scan(ScanSubmitRequest, bytes) は、DETECTED_QUARANTINE_KEPT・NOT_DETECTED_QUARANTINE_KEPT・SCAN_INCONCLUSIVE・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED のどれかを返します（どれにも approval: false）。利用側が用意するもの: 外部の scan engine への port（submit と、任意で lookup）。副作用は外部への提出（EXTERNAL_REVERSIBLE）。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

外の事業者へ中身を渡すことは取り消せない開示（EXTERNAL_IRREVERSIBLE）です。確かめていないバイト列や、開示の根拠が覆わない事業者・中身の種類へ渡してしまうこと、そして返ったラベルを削除・公開の拒否・人の判断と取り違えることを防ぎます。

使う場面

• 投稿・画像などの中身を、外のモデレーションの事業者・AI に見てもらい、その観察（ラベル）を判定の素材として受け取りたいとき。
• 事業者・方針の版・モデルの版を設定で固定し、固定の外の版で観察させたくないとき。版がずれた receipt も受け取りません。
• 開示の根拠（disclosure_basis_ref）が、その事業者と content_type を覆うときだけ中身を外へ渡したいとき。
• 送る中身のバイト列が、要求に載せた content_digest と同じものだと確かめてから渡したいとき。

使わない場面

• 観察の結果から、削除・公開停止などの処置を自動で行いたいとき。この継手の結果は事実の観測で、処置ではありません（enforcement_action は NOT_DERIVED）。
• 手元でモデルを動かして観察したいとき。外の事業者・AI に頼む継手で、手元の観察は別の Primitive の範囲です。
• 中身を外へ渡してはいけない場面。送れば取り消せない開示（EXTERNAL_IRREVERSIBLE）になり、結果の分からない要求（UNKNOWN）でも開示はすでに起きたかもしれません。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。
• すぐに使える事業者への接続がほしいとき。実の事業者・AI には一度も接続しておらず、port の実装・資格情報・設定の値は接続するときに別の関門で決めます。

検査すること

• 設定の固定を検めます。設定が無い・一覧が空・表が欠ける、または事業者・方針・方針の版・モデル・モデルの版が固定の外、ほかの事業者のモデルなら、送りません。
• 開示の根拠を検めます。設定に無い根拠、その事業者または content_type を覆わない根拠、Ref の形でない根拠では、送りません。
• 中身のバイト列を検めます。バイト列が無い、sha256 が content_digest と違う、確かめた後に変えられた場合は送りません。要求に中身そのものを載せた要求も拒否します。
• 参照と要求の形を検めます。空・ドライブの絶対パス・..・先頭の /・制御文字・U+2028/2029 を含む参照、Ref でない request_id、media type でない content_type、追加の欄は送りません。設定が形の悪い参照を固定していても通しません。
• receipt を照合します。request_digest の偽り、別の要求・別の事業者の receipt、content_digest の写しの違い、受け取った中身の digest が違うのに CONTENT_MISMATCH でない receipt、方針・モデルの版のずれは受理しません。
• ラベルの形を検めます。語彙の外の verdict_state・level、ラベルの無い OBSERVED、OBSERVED でないのにラベルがある receipt、category の重なり、0〜10000 の整数でない score_bp は受理しません。
• 処置・人の判断・公開の判断を導いた receipt（enforcement_action・human_judgement・publication_decision が NOT_DERIVED でないもの）、状態の許さない効果や UNKNOWN の効果を持つ receipt は受理せず、停止します（HALTED）。
• 結果の分からない要求は同じ要求の再送（lookup）で解き、解けるまでほかの要求は送りません。同じ request_id の別の要求、未解決の要求のすり替え、送る間に変えられた要求は送りません。

しないこと・既知の限界

• モデレーションの処置をしません。この継手は観察の依頼を運ぶ継手で、削除・公開停止・違反の判断の機能は含みません。結果は事実の観測で、どの結果にも enforcement_action・human_judgement・publication_decision の NOT_DERIVED と approval: false が付きます。
• ラベルの正しさ、方針への当てはまり、score_bp の意味は確かめません。観察の中身は事業者の答えです。違反と判断するのは、別の人の判断と核の役目です。
• 開示の根拠（同意・承認の記録）を作らず、それが有効か・期限内か・撤回されていないかも確かめません。設定に載っていることだけを見ます。根拠は部品の外の人・組織の役目です（APPROVAL_OUTSIDE_PART）。
• 事業者が実際に受け取ったバイト列は、事業者が received_content_digest を返したときだけ確かめられます。返さなければ、確かめたバイト列を port に渡したところまでです。
• 時刻（observed_timestamp）は形だけを検め、receipt が古い・使い回しかは見ません。照合の記録と未解決の要求はこの継手の中だけにあり、再起動で消えます。
• 事業者の認証に使う資格情報は持ちません。資格情報は port 側が持ちます（HELD_BY_PORT）。契約も変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 特定のモデレーション API の使い方の雛形ではありません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/content-moderation/v1 でつなぎます。createModerationClient({ cfg, port }) の submit(request, bytes) に ModerationRequest と中身のバイト列を渡すと、DONE（result に verdict_state・labels ほか）・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED を返します（どれも approval: false）。cfg には固定の一覧 4 つ（allowed_providers ほか）が要ります。利用側が用意するもの: 事業者への port（submit、任意で lookup）と資格情報。副作用: EXTERNAL_IRREVERSIBLE。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

偽装した拡張子や申告の Content-Type を信じて、実体の違うファイルを受け取ってしまうことを防ぎます。bytes から判った型と申告を突き合わせ、許す一覧を必須にして、表に無い MIME を一覧に書いた設定の誤りも止めます。

使う場面

• 受け取ったファイルの bytes から、先頭の magic bytes で型と MIME を判りたいとき（detect）。
• 申告の MIME（declared_mime）が bytes の実体と完全に一致し、許す MIME の一覧（allowed_mimes）にあるときだけ受け取りたいとき（check）。
• 大きなファイルでも一定の手間で検めたいとき。読むのは先頭の 12 bytes までです。
• 例外を投げない呼び方が要るとき。check は { ok, errors, detected } を返し、例外を投げず、options の getter を呼びません。
• 時計・乱数・環境の locale に左右されず、外の境界・状態を持たない処理として手元で呼びたいとき。

使わない場面

• 中身の安全（マルウェア・悪意のある PDF の JavaScript・zip bomb など）を検めたいとき。それは I-03 の範囲です。
• ファイルの残りが正しい形か（壊れていないか・開けるか）を確かめたいとき。判るのは先頭の magic bytes だけです。
• docx・xlsx など zip を土台にした形式の中の形式を判りたいとき。application/zip とだけ判り、中の形式の MIME を申告すると TYPE_MISMATCH になります。
• 表の 7 つのほかの型（text・json・svg・mp4・webm・tiff・bmp・heic・7z・rar など）を扱いたいとき。UNKNOWN_TYPE で止めます。
• 申告の MIME の大文字・引数（; charset= など）・別名（image/jpg など）の読み替えを任せたいとき。読み替えはしないので、呼ぶ側が外して小文字にしてから渡します。
• bytes の大きさの上限が要るとき。上限は持たず、I-06 の部品か使う側で決めます。
• Node.js v24.21.0 のほかの版で使うとき。ほかの版は確かめていません（NOT_VERIFIED）。

検査すること

• bytes（Uint8Array）でないとき（文字列・数の配列・ArrayBuffer・ほかの型付き配列）、check は NOT_BYTES で止めます（detect は FileTypeError を投げます）。
• 表のどの型の magic bytes とも合わないとき（途中で切れた頭・1 byte 違い・GIF88a・小文字の %pdf-・zip の空の書庫や分割の印・gzip の別の方式・RIFF の WAVE・位置のずれ）、UNKNOWN_TYPE で止めます。
• 判った MIME が declared_mime と完全には一致しないとき（別名・引数付き・大文字・zip に Office の MIME を申告）、TYPE_MISMATCH で止めます。
• 判った MIME が allowed_mimes に無いとき、NOT_ALLOWED で止めます。
• allowed_mimes が無い・空・穴がある・配列に似たオブジェクト・表に無い MIME を含むとき、INVALID_OPTIONS で止めます。
• declared_mime が文字列でないとき、opts に知らないキー（symbol を含む）・getter があるとき、Proxy の罠・クラスのインスタンスのとき、INVALID_OPTIONS で止め、例外を投げません。
• 止めるときのエラーはいつも 1 つで、検める順番は bytes・options・型が判るか・申告・許す一覧です。

しないこと・既知の限界

• 型が判ることは、中身の安全の検めではありません。マルウェアの検査（I-03）・大きさの上限（I-06）・中の構造の検め（画像の復号など）は別の部品で、組み合わせるのは使う側です。
• magic bytes が合っても、ファイルの残りが正しい形である証明ではありません。PDF の xref・PNG の chunk・zip の中央ディレクトリなどは読みません。
• 継手の中にある magic bytes の写し（content.js 2 つ）を、まだこの部品に置き換えていません。pdf・png・jpeg の検めは作業場で 1 回突き合わせて違いは無かったものの、写しは text/plain・application/json も扱い Buffer だけを受け取る点が違い、置き換えは別の作業です。
• zip を土台にした形式の中の形式、空の zip・分割の zip は判りません。
• 型が判ったことは、受け入れてよいことではありません（result_is_approval: false）。権限も作りません（derives_authority: false）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 特定のファイル型判定ライブラリ（file-type・libmagic など）の写しや使い方の雛形ではありません。

つなぎ方

src/filetype.js の check(bytes, opts) を呼びます（投げません）。受け取るのは bytes（Uint8Array。Buffer を含む）と、allowed_mimes（必須）と declared_mime（任意）だけの素のオブジェクト opts です。返すのは { ok: true, errors: [], detected: { type, mime } } か { ok: false, errors: [{ code }], detected }（code は error_taxonomy）。detect(bytes) は { type, mime } か null を返します（bytes でなければ投げます）。副作用（NONE）・状態・外の接続・資格情報は無く、利用側が用意するものはありません。依存は Node.js の組み込みだけです。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

過大な入力を断る上限の検めで、数えられない値を 0 と数えてしまうこと、文字列を bytes として・配列に似たオブジェクトを配列として数えてしまうこと、単独のサロゲートを含む文字列を UTF-8 の長さで黙って数えてしまうこと、上限の無い・空の範囲を受け取ってしまうことを防ぎます。

使う場面

• 本文・名前・配列・オブジェクトの大きさに、使う側が決めた単位と上限を当てたいとき（例: 本文は utf8_bytes で 1 MiB、名前は code_points で 64）。
• 同じ文字列でも単位によって数が違うことを、単位を明示して扱いたいとき（絵文字 1 つは utf8_bytes で 4、utf16_units で 2、code_points で 1）。
• 上限・下限の境目を決めて検めたいとき。上限は既定で含み（max_inclusive）、下限は既定 0 で常に含みます。
• I-08 の正準化・B-07 のハッシュ・I-05 のファイル型の部品に渡す前に、大きさの上限を当てたいとき。それらの部品は大きさの上限を持ちません。
• 例外を投げない呼び方が要るとき。check は例外を投げず、値と options を書き換えず、getter を呼びません。
• 時計・乱数・環境の locale に左右されず、状態を持たない処理として、手元で呼びたいとき。

使わない場面

• 見た目の 1 文字（書記素。👨‍👩‍👧 や 🇯🇵）の数で制限したいとき。書記素は数えません。
• 見た目が同じ文字列を同じ長さとして扱いたいとき。Unicode の正規化はしないため、é と e + 結合文字は数が違います。
• 入れ子の中（配列の中の配列、オブジェクトの中のキー）まで含めた大きさで制限したいとき。items・keys は一段目だけを数えます。
• 値をメモリーに読み込む前に、大きすぎる入力を止めたいとき。この部品は、すでにメモリーにある値を数えます。
• Node.js v24.21.0 のほかの版で使うとき。ほかの版は確かめていません（NOT_VERIFIED）。

検査すること

• 大きさが上限を超えるとき（max_inclusive が false なら上限と等しいときも）TOO_LARGE、下限より小さいとき TOO_SMALL で止め、数えた大きさ（size）を返します。
• 値の型が単位に合わないとき（bytes に文字列・ArrayBuffer・ほかの型付き配列、文字列の単位に bytes・String オブジェクト、items に配列に似たオブジェクト・Set、keys に配列・Map・Date・クラスのインスタンスなど）、VALUE_TYPE_MISMATCH で止めます。
• utf8_bytes で、文字列に単独のサロゲート（対になっていない U+D800〜U+DFFF）があるとき、INVALID_UNICODE で止めます。
• unit が 6 つの単位のどれでもないとき（大文字・別名を含む）、UNKNOWN_UNIT で止めます。
• max が無い、max・min が 0 以上の安全な整数でない、min > max、または受け取れる大きさが 1 つも無い範囲のとき、INVALID_LIMITS で止めます。
• opts が素のオブジェクトでない、知らないキー・getter がある、max_inclusive が真偽値でないとき INVALID_OPTIONS、値を調べること自体が例外になるとき（Proxy の罠など）INSPECTION_FAILED で止めます。

しないこと・既知の限界

• 名前の「過大入力の遮断」のうち、大きすぎる値の読み込みそのものは止められません。値を渡す前にメモリーに載せる手間は、この部品の外の話です。
• どの単位で何を上限にするかは決めません。使う側（各継手・契約・Kernel の方針）が決めます。
• 書記素の数・Unicode の正規化・入れ子の中の大きさは扱いません。
• 継手の中の大きさの上限の検めと、工房の台帳の I-06 の記録を、この部品に置き換えてはいません。置き換えは別の作業です。utf8_bytes は、単独のサロゲートのある文字列では Buffer.byteLength と違い、止めます。
• Proxy の罠は単体試験の数件だけで確かめました（ファズには入れていません）。
• 範囲の中に収まったことは、値の中身が正しいことでも、受け入れてよいことでもありません（result_is_approval: false）。権限も作りません（derives_authority: false）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 特定の検証ライブラリの使い方の雛形ではありません。

つなぎ方

src/size.js の check(value, opts) を呼びます（投げません）。opts は { unit, max, min?, max_inclusive? } だけの素のオブジェクトで、unit は 6 つの単位のどれか、max は必須の 0 以上の安全な整数です。返すのは { ok: true, errors: [], size } か { ok: false, errors: [{ code }], size }（code は error_taxonomy、size は TOO_LARGE・TOO_SMALL のときだけ数、ほかは null）。measure(value, unit) は 0 以上の整数を返し、受け取れない値で SizeError を投げます。副作用（NONE）・状態・外の接続・資格情報・port は無く、依存は Node.js の組み込みだけです。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

reconcile と対になる重複の見分けで、形の違う entry を黙って読み飛ばすこと、__proto__・constructor などの名前の key を取り違えること、件数や key の長さに上限の無い入力を受け取ることを防ぎます。同じ入力からは、いつでも同じ答えになります。

使う場面

• 1 回の呼び出しで渡す一覧の中で、同じ key の重複を見分けたいとき。どの番号も kept と duplicates のどちらか一方にだけ、1 回入ります。
• 前に見た key を known_keys として渡し、それとの重複も of: "known" として見分けたいとき。
• I-08 の正準化や B-07 のハッシュで作った key を、符号単位の完全一致で比べたいとき。どの値から key を作るかは使う側が決めます。
• 受け取れない入力を、黙って読み飛ばさずに、コードと位置（JSON Pointer）で止めたいとき。
• 例外を投げず、入力を書き換えず、状態を持たない処理として、手元で呼びたいとき。

使わない場面

• 保存済みの索引や、ほかの呼び出しとの重複を見たいとき。比べるのは引数の中だけで、持続する索引・大域の索引は読まず書きません（保管の継手の側）。
• 見た目が同じ key（é と e + 結合文字、A と a、前後の空白の違い）を同じものとして扱いたいとき。正規化・大文字小文字の同一視・空白の除去はしません。同じにしたいなら、使う側が決まった規則で key を作ってから渡します。
• 100,000 件を超える一覧を 1 回で扱いたいとき。使う側で分けます。分けた呼び出しの間の重複は、前の key を known_keys に渡さない限り見分けません。
• entry の中身（key のほかのプロパティ）で重複を判断したいとき。重複の判断は key だけです。
• Node.js v24.21.0 のほかの版で使うとき。ほかの版は確かめていません（NOT_VERIFIED）。

検査すること

• entries が素の配列でないとき（配列の派生クラスを含む）INVALID_ENTRIES、100,000 件を超えるとき TOO_MANY_ENTRIES で止めます。
• 要素が素のオブジェクトでない（穴・getter・クラスのインスタンス・null prototype を含む）、自分のデータのプロパティ key が無い（getter・継いだもの）とき、MALFORMED_ENTRY で止めます。
• key が文字列でない・空のとき INVALID_KEY、4096 の UTF-16 の符号単位を超えるとき KEY_TOO_LONG で止めます。
• known_keys が素の配列でないとき INVALID_KNOWN_KEYS、100,000 件を超えるとき TOO_MANY_KNOWN_KEYS、同じ key が 2 回あるとき DUPLICATE_KNOWN_KEY（2 回目の位置）で止めます。
• options が素のオブジェクトでない、known_keys のほかの名前がある、known_keys が getter のとき INVALID_OPTIONS、値を調べること自体が例外になるとき（Proxy の罠など）INSPECTION_FAILED で止めます。
• 止めたときは、最初に見つけた 1 件のコードと位置（path。JSON Pointer）を返し、kept・duplicates は返しません。

しないこと・既知の限界

• 名前の「重複排除」のうち、保存されたデータから重複を消すことはしません。引数の一覧の番号を kept と duplicates に分けるだけです。保存済みの索引を引く・書くのは保管の継手の側です。
• 名前の「同一物の検出」のうち、中身が同じかどうかは見ません。key の符号単位の完全一致だけで、正規化・大文字小文字の同一視もしません。
• 渡されていない索引（ほかの呼び出し・保存済みのもの）との重複は分かりません。
• 上限ちょうどの 100,000 件を受け取ることは、単体試験だけで確かめました（ファズは上限を超えるものだけ）。
• 重複でないことは、中身が正しいことでも、受け入れてよいことでもありません（result_is_approval: false）。権限も作りません（derives_authority: false）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 特定の重複排除のライブラリの使い方の雛形ではありません。

つなぎ方

src/dedupe.js の dedupe(entries, options) を呼びます（投げません）。受け取るのは、{ key } の素のオブジェクトの素の配列（100,000 件まで）と、省略か { known_keys } だけの options です。返すのは { ok: true, errors: [], kept, duplicates }（kept は番号の小さい順、duplicates は { index, of } で of は番号か "known"）か { ok: false, errors: [{ code, path }] }（code は error_taxonomy、path は JSON Pointer）。副作用（NONE）・状態・外の接続・資格情報は無く、利用側が用意するもの（port）はありません。依存は Node.js の組み込みだけです。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

署名・突合の前処理で、キーの順・空白・数の書き方のゆれや、受け取れない値を黙って読み飛ばすことによって、digest の元になる bytes が変わってしまうことを防ぎます。同じ値からは、いつでも同じ文字列ができます。

使う場面

• 署名・突合の前処理として、JSON の値から digest の元になる正準の bytes を作りたいとき（canonicalBytes）。
• 受け取れない値（小数・undefined・関数・素でないオブジェクト・穴のある配列など）を、黙って読み飛ばさずに、コードと位置（JSON Pointer）で止めたいとき。
• 例外を投げない呼び方が要るとき。tryCanonicalize は { ok, errors, text } を返し、例外を投げません。
• 時計・乱数・環境の locale に左右されない、決定的な出力が要るとき。
• 外の境界・状態を持たない処理として、手元で呼びたいとき。依存パッケージはありません。

使わない場面

• 小数・指数の数を含む値を正準化したいとき。数は安全な整数（-(2^53-1)〜2^53-1）だけで、RFC 8785 の全体ではありません。
• 見た目が同じ文字列を同じものとして扱いたいとき。Unicode の正規化はしないため、é と e + 結合文字は別の文字列です。
• カタログの一言「表現ゆれの統一（RFC8785 等）」のような広い統一を求めるとき。この部品がするのは、RFC 8785（JCS）のうち数を安全な整数に限った profile の範囲です。
• 1000 段を超える入れ子の値を扱うとき。TOO_DEEP で止めます。
• 値の大きさの上限が要るとき。文字列・配列・キーの長さの上限は持たず、大きさの上限は I-06 の部品か使う側で決めます。
• Node.js v24.21.0 のほかの版・エンジンで使うとき。ほかの版は確かめていません（NOT_VERIFIED）。

検査すること

• 小数・安全な範囲の外の整数・NaN・Infinity のとき、NOT_A_SAFE_INTEGER で止めます。
• undefined（値そのもの・配列の要素・オブジェクトのメンバー）のとき UNDEFINED_VALUE、関数・symbol・bigint のとき UNSUPPORTED_TYPE で止めます。
• 配列の派生クラス、穴のある配列、要素のほかのプロパティを持つ配列のとき、NOT_A_PLAIN_ARRAY・SPARSE_ARRAY・EXTRA_ARRAY_PROPERTY で止めます。
• 素でないオブジェクト（Date・Map・Buffer・null prototype・クラスのインスタンスなど）、symbol のキー、列挙できないプロパティを持つオブジェクトのとき、NOT_A_PLAIN_OBJECT・SYMBOL_KEY・NON_ENUMERABLE_PROPERTY で止めます。
• getter・setter のプロパティがあるとき、呼ばずに ACCESSOR_PROPERTY で止めます。値を調べる間に中身が変わりません。
• 入れ子が 1000 段を超えるとき、スタックを溢れさせずに TOO_DEEP で止めます。
• 値を調べること自体が例外になるとき（Proxy の罠など）、tryCanonicalize は INSPECTION_FAILED を返し、例外を投げません。
• 止めたときは、コード（code）と止めた位置（path。JSON Pointer（RFC 6901）で、根は空文字）を返します。

しないこと・既知の限界

• RFC 8785 の全体（小数・指数の数の書き方）は扱いません。数は安全な整数だけです。
• Unicode の正規化はしません。見た目が同じでも、符号単位が違えば別の文字列です。
• どのフィールドを digest に入れるか・どの値を除くかは決めません。使う側（各継手・契約）に残ります。
• 継手の中にある正準化の写し（20 個）を、まだこの部品に置き換えていません。写しが正しく扱う値では byte 単位で同じ出力（または同じく止める）ですが、写しが壊れた JSON や欠けた出力を作る値（穴のある配列・symbol のキーなど）は、この部品は止めます。写しの側の扱いはそのままで、置き換えは互換表を確かめた後の別の作業です。
• 正準の文字列ができたことは、値の中身が正しいことでも、受け入れてよいことでもありません（result_is_approval: false）。権限も作りません（derives_authority: false）。
• Node.js v24.21.0 のほかのエンジンでの、JSON.stringify の文字列の書き方は確かめていません。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 特定の JSON ライブラリの使い方の雛形ではありません。

つなぎ方

src/canonical.js の tryCanonicalize(value) を呼びます（投げません）。canonicalize・canonicalBytes は正準の文字列・UTF-8 の Buffer を返し、受け取れない値で CanonicalizationError を投げます。受け取るのは JavaScript の値 1 つ（null・真偽値・文字列・安全な整数・密な配列・素のオブジェクトの入れ子）。返すのは { ok: true, errors: [], text } か { ok: false, errors: [{ code, path }] }（code は error_taxonomy、path は JSON Pointer）。副作用（NONE）・状態・外の接続・資格情報は無く、利用側が用意するものはありません。依存は Node.js の組み込みだけです。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

読めないファイルは、開くまで気づきません。この部品は、壊れた gzip・不正な UTF-8・壊れた JSON でも例外を投げずに事実として返し、解凍した後の大きさを 1 GiB で止めて、gzip の爆弾で際限なくメモリーを使わないようにします。format を中身から推し量らないので、宣言と違う中身を別の型として読み替えません。

使う場面

• 取得した bytes が、宣言された型として開けるかを事実として残したいとき（probeReadability）。
• gzip で圧縮された bytes を、解凍してから検めたいとき（compression: "gzip"。解凍できなければ GUNZIP_FAILED）。
• JSON の最上位の型（top_type）や、TSV の行の数と列の数（rows・columns）を事実として知りたいとき。
• PDF・PNG・JPEG に印があるか（PNG は IHDR の width・height・bit_depth・color_type も）を浅く確かめたいとき。
• 読めないことをエラーにせず、なぜ読めなかったか（reason と、TSV_RAGGED のときの行番号など）を受け取りたいとき。
• 時計・乱数・外の接続を持たない、決定的な処理として手元で呼びたいとき。ファイルは開かず、bytes は呼ぶ側が渡します。

使わない場面

• PDF・画像が描けること、ページ・画像のデータが壊れていないこと、暗号化されていないことを確かめたいとき。readable: true は印があることだけです（markers_only: true）。
• UTF-8 のほかの文字コード（Shift_JIS など）を読みたいとき。charset が utf-8 でなければ CHARSET_NOT_SUPPORTED で、変換も推測もしません。charset を宣言しない Shift_JIS は NOT_UTF8 になります。
• 中身の先頭の bytes から型を当ててほしいとき。format は宣言された media type の type/subtype だけで決めます。
• TSV の引用符（"…" の中の \t や改行）を扱いたいとき。\t は常に区切りとして数えます。
• PDF の前に bytes がある、%%EOF の後に 1024 bytes を超える bytes が続く、JPEG の EOI の後に bytes が続くファイルを、開けるものとして扱いたいとき。印が無いという事実になります。
• 256 MiB を超える入力や、解凍して 1 GiB を超える入力を検めたいとき。INPUT_TOO_LARGE（limit 付き）で止めます。これは読めないという事実ではなく、検めなかったという意味です。
• Node.js v24.21.0 のほかの版で使うとき。ほかの版は確かめていません（NOT_VERIFIED）。

検査すること

• 入力がオブジェクトでない、bytes が Uint8Array でない（文字列・数の配列・ArrayBuffer・ほかの型付き配列）、プロパティを読むこと自体が例外になるとき、NOT_BYTES で止めます。
• declared_media_type が契約 raw-fetch/v1 の形の文字列でない・255 文字を超えるとき INVALID_MEDIA_TYPE、compression が "gzip" でも "none" でもないとき（省略を含む）INVALID_COMPRESSION で止めます。
• 宣言の引数が RFC 9110 の parameter として読めない・charset が 2 つ以上あるとき MEDIA_TYPE_PARAMETERS_UNREADABLE、json・tsv・text で charset が utf-8 でないとき CHARSET_NOT_SUPPORTED を、bytes を読む前に返します。
• UTF-8 は fatal に復号し、過長・サロゲート・U+10FFFF 超・途中で切れた並びは NOT_UTF8 です。先頭の BOM は外さず、BOM 付きの JSON は JSON_PARSE_FAILED です。
• 空でない行の列の数がそろわない TSV は TSV_RAGGED で、最初にそろわなかった行の番号と列の数を facts に返します。
• PDF は先頭の %PDF- と最後の 1024 bytes の中の %%EOF、PNG は 8 bytes の署名・長さ 13 の IHDR・その CRC-32、JPEG は先頭の FFD8（SOI）と末尾の FFD9（EOI）を検めます。無ければ PDF_MARKERS_MISSING・PNG_SIGNATURE_OR_IHDR_BAD・JPEG_MARKERS_MISSING です。
• 入力が 256 MiB を超える、解凍した後が 1 GiB を超える、JSON の本文が 256 MiB を超えるときは、検めずに INPUT_TOO_LARGE と limit（input・gunzip_output・json_text）を返します。
• 宣言された media type が対応の表に無いときは FORMAT_UNKNOWN です。bytes は渡された view の範囲だけを読みます。

しないこと・既知の限界

• readable は開けるかどうかの事実だけで、中身が正しいこと・完全なこと・安全なこと・受け入れてよいことを意味しません。pdf・png・jpeg では印があることだけを意味します。
• 開けないものを止める判断（門番）はしません。止めるかは使う側が決めます。
• ファイルを開く・取得する・保存することはしません。
• gzip の解凍は zlib に任せ、ファズのオラクルも zlib を使います。zlib そのものの正しさは、この部品の試験の範囲の外です。
• メモリーが足りない環境での振る舞いは確かめていません。JSON.parse が文法以外の理由で失敗した場合も JSON_PARSE_FAILED になります。
• 可読性の結果は、承認ではありません（result_is_approval: false）。権限も作りません（derives_authority: false）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 特定のファイル形式のライブラリの使い方の雛形ではありません。

つなぎ方

src/decode-probe.js の probeReadability({ bytes, declared_media_type, compression }) を呼びます（投げません）。bytes は Uint8Array（256 MiB まで）、declared_media_type は解凍した後の中身の型の宣言（契約 raw-fetch/v1 の形、255 文字まで）、compression は "gzip" か "none"。返すのは { ok: true, errors: [], readable, format, facts, reason } か { ok: false, errors: [{ code }] }。副作用・状態・外の接続・資格情報は無く、利用側が用意する port はありません。依存は Node.js の組み込みの zlib だけです。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

取り込みの成否は、後から見返せません。この部品は、検査の結果を検査器の版つきの別の記録に残します。あわせて、検査が raw を止めてしまうこと、port の障害なのに嘘の done を書くこと、認定の一覧に無い継手の取得を読むこと、取り出した値（PII を含みうる）を結果に移すことを防ぎます。

使う場面

• 取得の直後に、fetch.json の記録（fetch_record）とフォルダー（folder_ref = raw/<source>/<YYYYMMDDTHHMMSSZ>）を渡し、検査の結果を probe/<source>/<folder_stamp>/<probe_version>.json に 1 回だけ書きたいとき（probeFetch）。
• 取得の失敗・記録が無い・N-09 が記録を受け取らないときは failed、tsugite_id が認定の一覧（certified_tsugite）に完全一致しないときは need_consent として、raw を読まずに記録したいとき。
• 完全性を期待する sha256 と大きさで、可読性を I-09 で、実用性を source ごとの抽出器で 3 項目（取引年月日 occurred_on・金額 amount・相手先 counterparty）が取り出せたかで検め、足りない段を need_input と理由で知りたいとき。
• 検査器を新しい版にして過去の取得に当て直し、古い記録を残したまま新しい記録を作りたいとき。結果のキーは probe_version を含みます。
• need_input の山から、次に作る継手と検査器を見つけたいとき（抽出器が無い source は need_input / NO_EXTRACTOR）。
• 結果の分からなかった書込を、同じ要求で送り直したいとき（resolvePending）。

使わない場面

• done を、取り出した値が正しいこと・形が正しいこと（日付・金額の書き方）として使いたいとき。done は 3 項目が取り出せたことだけです。
• 検査を門番にして、合わない raw を止めたり消したりしたいとき。この部品は raw を書かず・消さず・止めません。結果は別の記録です。
• ファイルが描けること・壊れていないことまで確かめたいとき。可読性は I-09 の浅い検め（pdf・png・jpeg は印があるか）で、I-09 の上限を超えたファイルは検めていません（READABILITY_NOT_CHECKED）。
• 抽出器が正しく読んでいるか、認定の一覧が正しいかまで任せたいとき。どちらもこの部品の外で、この部品は tsugite_id の文字列の完全一致だけを見ます。
• application/gzip の中身の型を確かに当てたいとき。中身の型は名前の拡張子の表から引くので、表に無い・名前が嘘のときは違う型で検め、need_input になることがあります。
• 信頼できない抽出器を隔離して動かしたいとき。抽出器は同じプロセスで動き、時間とメモリに上限はありません。
• Node.js v24.21.0 のほかの版で使うとき。ほかの版は確かめていません（NOT_VERIFIED）。

検査すること

• options が足りない・形が違うとき INVALID_OPTIONS、probeFetch の入力の形が違うとき（folder_ref の形・fetch_failed が真偽値でない など）INVALID_INPUT、getter が例外を投げたとき INSPECTION_FAILED で止めます。
• N-09 の port が投げた・答えが食い違うとき（この記録についての答えでない、schema・区画・files の形が違う）CHECK_PORT_FAILED、記録の source と folder_stamp が folder_ref と違うとき FOLDER_MISMATCH で、結果を書きません。
• 完全性の段で、保管物が無いとき INTEGRITY_MISSING、GET_REJECTED か自分で計算し直した sha256 が違うとき INTEGRITY_DIGEST_MISMATCH、大きさが byte_size と違うとき INTEGRITY_SIZE_MISMATCH として、全ファイルを並べて need_input にします。
• 完全性の段の読出しの結果が分からないとき READ_UNKNOWN、断り・停止・形の違い・bytes でない値のとき READ_FAILED、I-09 の port が投げた・答えの形が違うとき READABILITY_PORT_FAILED で止め、結果を書きません（errors[0].name にそのファイル）。
• 可読性の段で、読めないファイルがあれば need_input / UNREADABLE、検めていないものがあれば need_input / READABILITY_NOT_CHECKED です。実用性の段で、抽出器が投げた・配列でない答えなら EXTRACTOR_FAILED、記録が 0 件なら NO_RECORDS、3 項目の欠けがあれば MISSING_FACTS（件数と欠けた項目の名前）です。
• 同じ版の結果のキーに、このインスタンスが前に別の中身を送っているとき PROBE_RESULT_EXISTS で送りません。書込の結果が分からないとき PROBE_WRITE_UNKNOWN（保留の間は PROBE_PENDING）、送らなかったとき WRITE_REFUSED、停止・結果が APPLIED か DEDUP_HIT でないとき WRITE_FAILED です。
• timestamp が RFC 3339 の UTC（Z）の実在する日時を返さないとき CLOCK_FAILED で何も読まず書かず、前の操作が終わっていないとき BUSY、保留が無いのに resolvePending を呼ぶと NOTHING_PENDING です。

しないこと・既知の限界

• 取得データの検査の部品は継手ではありません。自分の Request/Receipt は無く、結果の書込という外への効果は、束ねた C-05 の継手が自分の契約で起こします（raw の読出しは NONE）。この部品自身は外へ触れません。
• 束ねた部品の意味（記録を受け取れた ≠ 取得の正しさ・読めた ≠ 中身の正しさ・開けた ≠ 壊れていない・書けた ≠ 受け入れ）は、それぞれの部品の側に残ります。抽出器そのものと取り出した値の正しさは、この部品に入りません。
• 結果は承認ではなく、正しいことも示しません（approval: false・authority: NOT_DERIVED、derives_authority: false）。
• 取り出した値は結果の記録に書きません。書くのは件数と欠けた項目の名前とファイル名・番号だけです。
• raw のキーがその区画の保管物を指すかは backend の設定の役目です。ほかのプロセスが書いた同じ版の結果は、この部品ではなく継手と backend が断ります（どちらでも上書きはしません）。
• 本物の N-09・I-09・C-01・C-05 には、この部品の試験では接続していません。単体試験とファズは代役です。状態（送った結果のキーの控え・保留）はプロセスの中だけで、再起動で消えます。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 特定のデータ品質ツールの雛形ではありません。

つなぎ方

src/probe.js の createProbe(options) で作り、{ ok, errors, instance } を返します。options は probe_version・certified_tsugite・result_target・request_prefix・ports・任意の timestamp です。probeFetch は state・reason・result・result_key などを返し、結果に approval: false が付きます。port は checkFetchRecord（N-09）・probeReadability（I-09）・区画ごとの read.<class>.get（C-01 の継手のクライアント）・write.submit（C-05 の継手のクライアント）・任意の extractors です。資格情報は port が持ちます。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

送った文が何から組み立てられ、上限に入ったかは、後から見えません。この部品は、選んでいない項目を足すこと、古い版の選択を使うこと、上限を超えた文を黙って切る・縮める・分けることを防ぎ、選んだもの・除いたもの・版・digest の一覧を返します。

使う場面

• 明示して選んだ項目（id と revision を名指し）だけを、選んだ順に separator でつなぎ、前後に prefix・suffix を付けた request を組み立てたいとき（assemble）。選んでいない項目は入りません。
• 組み立てた request の UTF-8 の bytes を、使う側が渡す上限 limit_bytes（1〜1,073,741,824）と比べたいとき。上限ちょうどは WITHIN_LIMIT です。上限の既定値は持たず、使う側が渡します。
• 項目の一部だけを、単位を名指しした範囲 { unit, start, end } で選びたいとき。unit は UTF16 か CODE_POINT で、同じ数でも別の文字を指しうるので、単位を推し量りません。
• 何を組み立てたかを後から照らしたいとき。request_digest（request の UTF-8 の sha256）と、版・中身・範囲・区切りのどれかが変われば変わる selection_digest、選んだ順の included と、選ばなかった excluded を返します。
• 役ごとの投影（P-12）の後に、送る文字列を固定したいとき。値 1 つの大きさを数える I-06 とは違い、選んだものだけを組み立てて版と digest を固定します。
• 例外を投げず、入力を書き換えず、状態を持たない処理として、手元で呼びたいとき。同じ入力には同じ答えを返します。

使わない場面

• 上限を超えた文を切ったり縮めたり分けたりして収めたいとき。OVER_LIMIT のとき request_text は null で、どの部分も切らず除きません。選び直しは使う側です。
• どれを選ぶか（選ぶ権限・同意・目的）を部品に確かめさせたいとき。選ばれたものを組み立てるだけで、選ぶ権限・同意・目的が正しいかは見ません。
• JSON などの外の包みやフレームを含めた大きさを数えたいとき。数えるのは prefix + 部分.join(separator) + suffix だけで、外の包みは使う側が別に検めます。
• 組み立てた文を送ったり保存したりしたいとき。この部品は送信・保存をしません。外の包みの組み立てと送信は使う側に残ります。
• items・selection が 10,000 件を超える、text・区切りが 4,194,304 の UTF-16 の符号単位を超える入力を扱いたいとき。上限を超えると決まったコードで止めます。
• Node.js v24.21.0 のほかの版で使うとき。ほかの版は確かめていません（NOT_VERIFIED）。

検査すること

• options が素のオブジェクトでない、知らない名前・getter がある、limit_bytes か separator が無いとき INVALID_OPTIONS、limit_bytes が 1〜1,073,741,824 の整数でないとき INVALID_LIMIT、separator・prefix・suffix が文字列でない（箱の文字列を含む）か長すぎるとき INVALID_FRAMING で止めます。
• items が素の配列でないとき INVALID_ITEMS、10,000 件を超えるとき TOO_MANY_ITEMS、要素の形が違うとき MALFORMED_ITEM、id・revision・text の形が違うとき INVALID_ID・INVALID_REVISION・INVALID_TEXT、text が長すぎるとき TEXT_TOO_LONG、同じ id が 2 回あるとき DUPLICATE_ITEM で止めます。
• selection の形が違うとき INVALID_SELECTION・TOO_MANY_SELECTED・MALFORMED_SELECTION、選んだ id が items に無いとき UNKNOWN_ITEM、選んだ版が items の版と違うとき REVISION_MISMATCH（古い選択を使いません）、同じ id を 2 回選んだとき DUPLICATE_SELECTION で止めます。
• range が { unit, start, end } でない、unit が UTF16・CODE_POINT でない（小文字を含む）、0 ≤ start < end の安全な整数でないとき INVALID_RANGE、end が text の長さを超えるとき RANGE_OUT_OF_BOUNDS、UTF16 の範囲の端がサロゲートの対の間にあるとき RANGE_SPLITS_SURROGATE で止めます。
• 選んだ部分か separator・prefix・suffix に単独のサロゲートがあるとき（UTF-8 にできない）INVALID_UNICODE、組み立てた request が空か空白（改行・全角の空白を含む）だけのとき BLANK_REQUEST、値を調べること自体が例外になるとき（Proxy の罠など）INSPECTION_FAILED で止めます。
• 止めたときは、決まった順で最初に見つけた 1 件のコードと位置（path。JSON Pointer）を返し、組み立てた結果は返しません。
• 結果を、別の書き方の独立オラクル（bytes は TextEncoder、符号位置は Array.from、単独のサロゲートは isWellFormed、項目は Map を使わず前から探す）と突き合わせるファズ（1,000,000 回）で、不一致と fail-open が 0 であることを確かめました。

しないこと・既知の限界

• WITHIN_LIMIT は「渡された上限に入る」だけで、送ってよい・同意があるという意味ではありません。外の包み（JSON・フレーム）の大きさは数えていません。
• 中身の digest（content_digest）は渡された text の digest で、元の資料と同じかは見ません。
• 上限ちょうどの 10,000 件・4,194,304 の符号単位を受け取ることは、単体試験だけで確かめました（ファズは小さな入力だけ）。
• 外の境界・状態・時計・乱数を持たず、送信・保存をしません。副作用は NONE で、資格情報も使いません。
• 組み立てと数えの結果は承認ではなく（result_is_approval: false）、権限も作りません（derives_authority: false）。
• 入出力の形は v1 で定めたもので、既存の実装はありません（新規）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 特定のプロンプト組み立てのライブラリの使い方の雛形ではありません。

つなぎ方

src/selected-input.js の assemble(items, selection, options) を呼びます（投げません）。items は { id, revision, text }、selection は { id, revision, range? } の配列、options は { limit_bytes, separator, prefix?, suffix? } です。返すのは { ok: true, errors: [], status, request_text, request_digest, selection_digest, included, excluded など } か { ok: false, errors: [{ code, path }] } です。副作用・状態・外の接続・資格情報・依存パッケージ・port は無しです。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

帳票・証憑を PDF で出すために外の変換 backend を使うとき、偽装した入力や pin していない出力 profile で送ってしまうこと、そして戻った PDF が要求したものか確かめないまま渡してしまうこと（すり替え）を防ぎます。出力の bytes の digest を自分で計算して receipt と突き合わせます。

使う場面

• 帳票・証憑を PDF で出す処理を外の変換 backend に任せ、その手前と後ろの検めがほしいとき。
• PDF の出力 profile と params を pin して、決めた形でしか作らせたくないとき。
• backend が返した PDF の bytes が、receipt の digest と一致したときだけ受け取りたいとき。
• 同じ要求を二重に送りたくないとき。障害のあとの再送は照会（lookup）で解きます。

使わない場面

• PDF を作る仕組みそのものがほしいとき。この継手は PDF を作らず、実 backend も含みません。
• できた PDF の見た目が元と同じか（忠実さ）や、PDF として壊れていないかを確かめたいとき。どちらも確かめません。
• できた PDF を保管したいとき。保存は object store 継手（C-01）の役目です。
• 電子契約が要るとき。電子契約（J-06）は作っておらず、この部品は J-06 を担いません。電子契約の操作を求める要求は送りません。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。

検査すること

• 入力を検めます。入力の bytes の digest が要求と合わないもの、上限（max_input_bytes）を超えるもの、許可していない content-type のもの、先頭の magic bytes が content-type と合わないもの（偽装した入力）は、変換 backend へ送りません。
• 操作・出力 profile・params を検めます。許可していない操作、電子契約（J-06）の操作、pin していない出力 profile・params を求める要求は送りません。
• 出力の bytes の digest を自分で計算し、receipt と違えば受理せず（OUTPUT_REJECTED）、以後は停止します（すり替えた出力は受け取りません）。
• receipt（MediaTransformReceipt）を照合します。request_digest の偽り、別の要求の receipt、操作のすり替え、外への効果を増やす receipt は受理せず、以後は停止します（HALTED）。
• receipt が検証済み・開示の許可あり・信頼できると名乗るもの（content_verification NOT_VERIFIED・fidelity_assertion NOT_ASSERTED・disclosure_authorization NOT_DERIVED・trust_assertion NOT_DERIVED 以外の値）は受理しません。
• 結果の形を検めます。出力の digest の無い SUCCEEDED、extracted_ref の無い OCR_EXTRACT・QR_DECODE の SUCCEEDED、出力や効果を伴う FAILED は受理しません。PARTIAL は成功として扱いません。
• 同じ request_id は二度送りません。backend の障害は UNKNOWN とし、再送は照会（lookup）で解きます。

しないこと・既知の限界

• PDF の生成そのものはしません。PDF を作るのは外の変換 backend で、この継手がするのは送る前の検めと、受け取った後の照合だけです。
• 変換の見た目の忠実さは確かめません。変換の成功は意味の同一ではありません。
• 実 backend を含みません。どの変換エンジン・OCR サービスにつなぐか、port の実装、pin する profile は未定で、接続するときに別の関門（gate）で決めます。
• magic bytes は先頭の数 bytes だけを見ます。ファイル全体の構造の検査（壊れた PDF など）はしません。
• どの結果も承認ではありません（approval: false）。どの結果にも content_verification: NOT_VERIFIED・trust: NOT_DERIVED が付きます。
• 契約を変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 変換エンジンの使い方の雛形ではありません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/document-media/v1 でつなぎます。createMediaTransformClient({ cfg, port }) の transform(request, bytes) は、TRANSFORMED・PARTIAL・FAILED・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・OUTPUT_REJECTED・HALTED のどれかを返します（どれも approval: false）。利用側が用意するもの: 変換 backend への port（transform、任意で lookup）と cfg（許可リスト・pin・上限）。副作用は NONE か LOCAL_REVERSIBLE。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

画像や紙から文字を取り出して検索・照合の前処理に使うとき、偽装した入力を送ってしまうこと、抽出の結果（extracted_ref）が無いのに成功と扱ってしまうこと、読めた文字を確かめた事実のように扱ってしまうことを防ぎます。

使う場面

• 画像や PDF の文字の読み取りを外の OCR サービスに任せ、その手前と後ろで検めたいとき。
• OCR_EXTRACT の成功には extracted_ref が必ず付いていてほしいとき。付いていない成功は受理しません。
• 読めた文字を検索・照合の前処理の材料として受け取り、事実として扱うかの判断は核（evidence 系）に任せたいとき。
• 同じ要求を二重に送りたくないとき。障害のあとの再送は照会（lookup）で解きます。

使わない場面

• 読み取った文字が正しいことを確かめたいとき。OCR で読めた内容の正しさは確かめず、検証済みの事実とも信頼とも扱いません。
• OCR エンジンそのものがほしいとき。この継手は OCR をせず、実 backend も含みません。どの OCR サービスにつなぐかは未定です。
• 許可リストに無い形式の入力を送りたいとき。magic bytes で確かめられる型は application/pdf・image/png・image/jpeg・text/plain・application/json だけで、一覧に無い型は送りません。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。

検査すること

• 結果の形を検めます。出力の digest の無い SUCCEEDED、extracted_ref の無い OCR_EXTRACT・QR_DECODE の SUCCEEDED、出力や効果を伴う FAILED は受理しません。PARTIAL は成功として扱いません。
• receipt が検証済み・開示の許可あり・信頼できると名乗るもの（content_verification NOT_VERIFIED・fidelity_assertion NOT_ASSERTED・disclosure_authorization NOT_DERIVED・trust_assertion NOT_DERIVED 以外の値）は受理しません。
• 入力を検めます。入力の bytes の digest が要求と合わないもの、上限（max_input_bytes）を超えるもの、許可していない content-type のもの、先頭の magic bytes が content-type と合わないもの（偽装した入力）は、変換 backend へ送りません。
• 操作・出力 profile・params を検めます。許可していない操作、電子契約（J-06）の操作、pin していない出力 profile・params を求める要求は送りません。
• receipt（MediaTransformReceipt）を照合します。request_digest の偽り、別の要求の receipt、操作のすり替え、外への効果を増やす receipt は受理せず、以後は停止します（HALTED）。
• 出力の bytes の digest を自分で計算し、receipt と違えば受理せず（OUTPUT_REJECTED）、以後は停止します（すり替えた出力は受け取りません）。
• 同じ request_id は二度送りません。backend の障害は UNKNOWN とし、再送は照会（lookup）で解きます。

しないこと・既知の限界

• OCR そのものはしません。文字を読み取るのは外の変換 backend で、この継手がするのは送る前の検めと、受け取った後の照合だけです。
• OCR で読めた内容の正しさは確かめません（契約の const のとおり、主張しません）。読めた文字を事実として扱うかは evidence 系の核の判断です。
• 実 backend を含みません。どの変換エンジン・OCR サービスにつなぐか、port の実装、pin する profile は未定で、接続するときに別の関門（gate）で決めます。
• magic bytes は先頭の数 bytes だけを見ます。ファイル全体の構造の検査（壊れた PDF など）はしません。
• どの結果も承認ではありません（approval: false）。どの結果にも content_verification: NOT_VERIFIED・trust: NOT_DERIVED が付きます。
• 契約を変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 変換エンジンの使い方の雛形ではありません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/document-media/v1 でつなぎます。createMediaTransformClient({ cfg, port }) の transform(request, bytes) は、TRANSFORMED（OCR では extracted_ref 付き）・PARTIAL・FAILED・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・OUTPUT_REJECTED・HALTED のどれかを返します（どれも approval: false）。利用側が用意するもの: 変換 backend への port（transform、任意で lookup）と cfg（許可リスト・pin・上限）。副作用は NONE か LOCAL_REVERSIBLE。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

互換のために外の変換 backend で文書の形式を変えるとき、偽装した入力や pin していない変換先（出力 profile）で送ってしまうこと、そして戻った bytes が要求したものか確かめないまま渡してしまうこと（すり替え）を防ぎます。

使う場面

• 文書の形式変換を外の変換 backend に任せ、その手前と後ろで検めたいとき。
• 入力が application/pdf・image/png・image/jpeg・text/plain・application/json のどれかで、先頭の magic bytes で型を確かめてから送りたいとき。
• 変換先の出力 profile と params を pin したいとき。
• 変換後の bytes が receipt の digest と一致したときだけ受け取りたいとき。

使わない場面

• docx など、一覧に無い形式を入力として送りたいとき。magic bytes で確かめられる型は application/pdf・image/png・image/jpeg・text/plain・application/json だけで、一覧に無い型は送りません（カタログの一言の「docx→pdf」の docx は、この一覧に入っていません）。
• 変換の前後で意味や見た目が同じことを確かめたいとき。変換の成功は意味の同一ではなく、見た目の忠実さも確かめません。
• 変換エンジンそのものがほしいとき。この継手は変換をせず、実 backend も含みません。
• 変換した結果を保管したいとき。保存は object store 継手（C-01）の役目です。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。

検査すること

• 入力を検めます。入力の bytes の digest が要求と合わないもの、上限（max_input_bytes）を超えるもの、許可していない content-type のもの、先頭の magic bytes が content-type と合わないもの（偽装した入力）は、変換 backend へ送りません。
• 操作・出力 profile・params を検めます。許可していない操作、電子契約（J-06）の操作、pin していない出力 profile・params を求める要求は送りません。
• 出力の bytes の digest を自分で計算し、receipt と違えば受理せず（OUTPUT_REJECTED）、以後は停止します（すり替えた出力は受け取りません）。
• receipt（MediaTransformReceipt）を照合します。request_digest の偽り、別の要求の receipt、操作のすり替え、外への効果を増やす receipt は受理せず、以後は停止します（HALTED）。
• receipt が検証済み・開示の許可あり・信頼できると名乗るもの（content_verification NOT_VERIFIED・fidelity_assertion NOT_ASSERTED・disclosure_authorization NOT_DERIVED・trust_assertion NOT_DERIVED 以外の値）は受理しません。
• 結果の形を検めます。出力の digest の無い SUCCEEDED、extracted_ref の無い OCR_EXTRACT・QR_DECODE の SUCCEEDED、出力や効果を伴う FAILED は受理しません。PARTIAL は成功として扱いません。
• 同じ request_id は二度送りません。backend の障害は UNKNOWN とし、再送は照会（lookup）で解きます。

しないこと・既知の限界

• 形式変換そのものはしません。形式を変えるのは外の変換 backend で、この継手がするのは送る前の検めと、受け取った後の照合だけです。
• 変換の見た目の忠実さは確かめません。変換の成功は意味の同一ではありません。
• 実 backend を含みません。どの変換エンジン・OCR サービスにつなぐか、port の実装、pin する profile は未定で、接続するときに別の関門（gate）で決めます。
• magic bytes は先頭の数 bytes だけを見ます。ファイル全体の構造の検査（壊れた PDF など）はしません。
• どの結果も承認ではありません（approval: false）。どの結果にも content_verification: NOT_VERIFIED・trust: NOT_DERIVED が付きます。
• 契約を変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 変換エンジンの使い方の雛形ではありません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/document-media/v1 でつなぎます。createMediaTransformClient({ cfg, port }) の transform(request, bytes) は、TRANSFORMED・PARTIAL・FAILED・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・OUTPUT_REJECTED・HALTED のどれかを返します（どれも approval: false）。利用側が用意するもの: 変換 backend への port（transform、任意で lookup）と cfg（許可リスト・pin・上限）。副作用は NONE か LOCAL_REVERSIBLE。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

一覧の見た目に使うサムネイルやプレビューを外の変換 backend で作るとき、偽装した入力や大きすぎる入力を送ってしまうこと、そして戻った画像が要求したものか確かめないまま表示に回してしまうこと（すり替え）を防ぎます。

使う場面

• 一覧に出すサムネイルやプレビューの作成を外の変換 backend に任せ、その手前と後ろで検めたいとき。
• 出力 profile と params を pin して、決めた形でしか作らせたくないとき。
• 入力の大きさに上限（max_input_bytes）を設け、超えるものは送りたくないとき。
• backend が返した画像の bytes が、receipt の digest と一致したときだけ受け取りたいとき。

使わない場面

• サムネイルを作る仕組みそのものがほしいとき。この継手はサムネイルを作らず、実 backend も含みません。
• サムネイルの見た目が元と合っているか（忠実さ）を確かめたいとき。確かめません。
• 作ったサムネイルを保管したいとき。保存は object store 継手（C-01）の役目です。
• 許可リストに無い形式の入力を送りたいとき。magic bytes で確かめられる型は application/pdf・image/png・image/jpeg・text/plain・application/json だけで、一覧に無い型は送りません。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。

検査すること

• 入力を検めます。入力の bytes の digest が要求と合わないもの、上限（max_input_bytes）を超えるもの、許可していない content-type のもの、先頭の magic bytes が content-type と合わないもの（偽装した入力）は、変換 backend へ送りません。
• 操作・出力 profile・params を検めます。許可していない操作、電子契約（J-06）の操作、pin していない出力 profile・params を求める要求は送りません。
• 出力の bytes の digest を自分で計算し、receipt と違えば受理せず（OUTPUT_REJECTED）、以後は停止します（すり替えた出力は受け取りません）。
• receipt（MediaTransformReceipt）を照合します。request_digest の偽り、別の要求の receipt、操作のすり替え、外への効果を増やす receipt は受理せず、以後は停止します（HALTED）。
• receipt が検証済み・開示の許可あり・信頼できると名乗るもの（content_verification NOT_VERIFIED・fidelity_assertion NOT_ASSERTED・disclosure_authorization NOT_DERIVED・trust_assertion NOT_DERIVED 以外の値）は受理しません。
• 結果の形を検めます。出力の digest の無い SUCCEEDED、extracted_ref の無い OCR_EXTRACT・QR_DECODE の SUCCEEDED、出力や効果を伴う FAILED は受理しません。PARTIAL は成功として扱いません。
• 同じ request_id は二度送りません。backend の障害は UNKNOWN とし、再送は照会（lookup）で解きます。

しないこと・既知の限界

• サムネイル・プレビューの作成そのものはしません。作るのは外の変換 backend で、この継手がするのは送る前の検めと、受け取った後の照合だけです。
• 変換の見た目の忠実さは確かめません。変換の成功は意味の同一ではありません。
• 実 backend を含みません。どの変換エンジン・OCR サービスにつなぐか、port の実装、pin する profile は未定で、接続するときに別の関門（gate）で決めます。
• magic bytes は先頭の数 bytes だけを見ます。ファイル全体の構造の検査（壊れた PDF など）はしません。
• どの結果も承認ではありません（approval: false）。どの結果にも content_verification: NOT_VERIFIED・trust: NOT_DERIVED が付きます。
• 契約を変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 変換エンジンの使い方の雛形ではありません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/document-media/v1 でつなぎます。createMediaTransformClient({ cfg, port }) の transform(request, bytes) は、TRANSFORMED・PARTIAL・FAILED・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・OUTPUT_REJECTED・HALTED のどれかを返します（どれも approval: false）。利用側が用意するもの: 変換 backend への port（transform、任意で lookup）と cfg（許可リスト・pin・上限）。副作用は NONE か LOCAL_REVERSIBLE。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

表示速度のために外の変換 backend で画像を縮小・軽量化するとき、偽装した入力や pin していない設定で送ってしまうこと、そして戻った画像が要求したものか確かめないまま使ってしまうこと（すり替え）を防ぎます。

使う場面

• 画像の縮小・軽量化を外の変換 backend に任せ、その手前と後ろで検めたいとき。
• 入力が image/png・image/jpeg などの許可した型で、先頭の magic bytes で型を確かめてから送りたいとき。
• 最適化の出力 profile と params を pin したいとき。
• backend が返した画像の bytes が、receipt の digest と一致したときだけ受け取りたいとき。

使わない場面

• 画像を縮小・軽量化する仕組みそのものがほしいとき。この継手は画像を変えず、実 backend も含みません。
• 最適化した画像の見た目が元と合っているか（忠実さ）を確かめたいとき。確かめません。
• 最適化した画像を保管したいとき。保存は object store 継手（C-01）の役目です。
• 許可リストに無い形式の入力を送りたいとき。magic bytes で確かめられる型は application/pdf・image/png・image/jpeg・text/plain・application/json だけで、一覧に無い型は送りません。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。

検査すること

• 入力を検めます。入力の bytes の digest が要求と合わないもの、上限（max_input_bytes）を超えるもの、許可していない content-type のもの、先頭の magic bytes が content-type と合わないもの（偽装した入力）は、変換 backend へ送りません。
• 操作・出力 profile・params を検めます。許可していない操作、電子契約（J-06）の操作、pin していない出力 profile・params を求める要求は送りません。
• 出力の bytes の digest を自分で計算し、receipt と違えば受理せず（OUTPUT_REJECTED）、以後は停止します（すり替えた出力は受け取りません）。
• receipt（MediaTransformReceipt）を照合します。request_digest の偽り、別の要求の receipt、操作のすり替え、外への効果を増やす receipt は受理せず、以後は停止します（HALTED）。
• receipt が検証済み・開示の許可あり・信頼できると名乗るもの（content_verification NOT_VERIFIED・fidelity_assertion NOT_ASSERTED・disclosure_authorization NOT_DERIVED・trust_assertion NOT_DERIVED 以外の値）は受理しません。
• 結果の形を検めます。出力の digest の無い SUCCEEDED、extracted_ref の無い OCR_EXTRACT・QR_DECODE の SUCCEEDED、出力や効果を伴う FAILED は受理しません。PARTIAL は成功として扱いません。
• 同じ request_id は二度送りません。backend の障害は UNKNOWN とし、再送は照会（lookup）で解きます。

しないこと・既知の限界

• 画像最適化そのものはしません。縮小・軽量化するのは外の変換 backend で、この継手がするのは送る前の検めと、受け取った後の照合だけです。
• 変換の見た目の忠実さは確かめません。変換の成功は意味の同一ではありません。
• 実 backend を含みません。どの変換エンジン・OCR サービスにつなぐか、port の実装、pin する profile は未定で、接続するときに別の関門（gate）で決めます。
• magic bytes は先頭の数 bytes だけを見ます。ファイル全体の構造の検査（壊れた PDF など）はしません。
• どの結果も承認ではありません（approval: false）。どの結果にも content_verification: NOT_VERIFIED・trust: NOT_DERIVED が付きます。
• 契約を変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 変換エンジンの使い方の雛形ではありません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/document-media/v1 でつなぎます。createMediaTransformClient({ cfg, port }) の transform(request, bytes) は、TRANSFORMED・PARTIAL・FAILED・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・OUTPUT_REJECTED・HALTED のどれかを返します（どれも approval: false）。利用側が用意するもの: 変換 backend への port（transform、任意で lookup）と cfg（許可リスト・pin・上限）。副作用は NONE か LOCAL_REVERSIBLE。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

B 署名と別の層として、署名フローで、台帳に記録の無い状態を名乗ること、ほかの envelope・文書・署名者のための署名を流用されること、台帳の結果が分からないまま状態を進めてしまうこと、文書の本文を台帳へ渡してしまうことを防ぎます。

使う場面

• 1 つの文書に、決めた署名者（1〜20 人）の署名を集め、全員の署名が検めを通って記録されたときだけ COMPLETED にしたいとき。
• 署名者ごとの署名を、使う側が固定した公開鍵（pinned_keys）で B-02 の部品に検めさせたいとき。署名者は signingBytes(signer_ref) が返す bytes（envelope_ref・文書の digest・signer_ref を含む）に署名します。
• 状態の遷移を、H-01 の監査台帳の継手に AuditEventEnvelope として追記し、記録できた遷移（APPENDED_VERIFIED か ALREADY_APPENDED）だけを状態にしたいとき。台帳へ渡すのは遷移の payload の digest だけです。
• 完了の後に、完了の digest に付けた時刻トークンを、B-06 の verifyToken を束ねた関数で 1 回だけ検めて記録したいとき（任意）。
• 台帳の結果が分からなかった記録を、同じ封筒で送り直したいとき（resolvePending）。

使わない場面

• 署名が揃ったこと・時刻が付いたことを、法的な受け入れ・権限・委任・承認として使いたいとき。「署名済み」は、pin した鍵の持ち主がこの envelope・この文書・この署名者の bytes に署名したことだけを示します。
• 署名者の本人確認が要るとき。この部品は本人確認・権限・委任、署名の法的な効力を扱いません。
• 署名の依頼の送付（通知）まで任せたいとき。通知は束ねません。送るなら呼び出し側が D-01 の継手で送ります。
• 時刻トークンの取得（TSA への依頼）まで任せたいとき。取得は含まず、B-06 も検めだけです。
• 外部の電子署名サービスへつなぎたいとき。その場合は別の継手の契約が要り、今は作りません。
• 再起動をまたいでフローを続けたいとき。状態はこのプロセスの中だけで、台帳の記録から状態を組み立て直す機能は v1 にありません。
• 同じ envelope_ref で 2 つのフローを作りたいとき。event_id が重なり、台帳が断ります（v1 は envelope_ref ごとに 1 つのフロー）。
• Node.js v24.21.0 のほかの版で使うとき。ほかの版は確かめていません（NOT_VERIFIED）。

検査すること

• options が足りない・形が違うとき（参照が不正、署名者や鍵の重複、pin に無い鍵、21 人以上、台帳の設定の余分なキー、getter）、INVALID_OPTIONS で止めます。
• その状態ではできない操作のとき（開く前・取り消しの後の署名、完了の後の取り消し、完了の前・2 回目の時刻）WRONG_STATE、前の操作が終わっていないとき BUSY で止めます。
• 決めた署名者でないとき UNKNOWN_SIGNER、すでに署名したとき ALREADY_SIGNED、署名が B-02 の検めを通らないとき（ほかの envelope・文書・署名者の bytes、ほかの鍵）SIGNATURE_REJECTED で止めます。
• 台帳の結果が分からないとき（UNKNOWN・例外・返事が無い）、状態を進めずに LEDGER_UNKNOWN で保留にし、保留の間は resolvePending のほかを RECORD_PENDING で止めます。保留が無いのに resolvePending を呼ぶと NOTHING_PENDING です。
• 台帳が断ったとき（REFUSED・RECEIPT_REJECTED・HALTED など）や台帳の先頭の形が不正なとき、状態を進めず保留も残さずに LEDGER_REFUSED で止めます（先頭が不正なら送りません）。
• 時刻の依頼が完了の digest でない・hash_algo が "SHA256" でない・B-06 の検めを通らないとき TIMESTAMP_REJECTED、verifyTimestamp の port が無いとき NOT_CONFIGURED で止めます。
• 台帳の state() や検めの port が例外を投げたとき PORT_FAILED、port の結果の getter が投げたとき INSPECTION_FAILED、contentAddress の結果が不正なとき DIGEST_FAILED、timestamp が不正なとき CLOCK_FAILED で止めます。

しないこと・既知の限界

• 電子契約（envelope）の部品は継手ではありません。自分の Request/Receipt は無く、台帳への記録という外への効果は、束ねた H-01 の継手が自分の契約（audit-ledger/v1）で起こします。この部品自身は外へ触れません。
• 束ねた部品の意味（digest の同一性・pin した鍵での検め・台帳の受領の照合・時刻トークンの検め、どれも承認ではない）は、それぞれの部品の側に残ります。
• 署名が揃ったこと・時刻が付いたことは、法的な受け入れ・権限・委任・承認ではありません（approval: false・authority: NOT_DERIVED、derives_authority: false）。
• 署名者の本人確認・権限・委任、署名の法的な効力は扱いません。
• 通知（署名の依頼の送付）と、時刻トークンの取得（TSA への依頼）は含みません。
• 本物の台帳・TSA には一度も接続していません。単体試験とファズは代役で、署名の検証も代役です（暗号の正しさは B-02 の役目）。本物の 4 部品のコードとの結線は、手元の代役の backend を相手に確かめました。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 特定の電子署名サービスの使い方の雛形ではありません。

つなぎ方

src/envelope.js の createEnvelopeFlow(options) で作ります。受け取るのは envelope_ref・signers・pinned_keys・ledger・ports などで、{ ok, errors, instance } を返します。各操作は { ok, errors, approval: false, phase, signed, … } を返します。利用側が用意する port は contentAddress（B-07）・verifySignature（B-02）・ledger.append と state（H-01 の継手のクライアント）・任意の verifyTimestamp（B-06）です。副作用は束ねた継手が起こし（EXTERNAL_IRREVERSIBLE）、資格情報は port が持ちます。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

現場の入出力で QR を読むとき、偽装した画像を送ってしまうこと、抽出の結果（extracted_ref）が無いのに成功と扱ってしまうこと、読めた内容を確かめた事実のように扱ってしまうことを防ぎます。

使う場面

• QR の読取を外の変換 backend に任せ、その手前と後ろで検めたいとき。
• QR_DECODE の成功には extracted_ref が必ず付いていてほしいとき。付いていない成功は受理しません。
• 読めた内容を受け取り、事実として扱うかの判断は核（evidence 系）に任せたいとき。
• 同じ要求を二重に送りたくないとき。障害のあとの再送は照会（lookup）で解きます。

使わない場面

• QR を生成したいとき。QR の生成は契約に無く、この継手が扱うのは読取（QR_DECODE）だけです。
• バーコードを扱いたいとき。この部品の操作に挙がっているのは QR 読取で、バーコードは挙がっていません。
• 読めた内容が正しいことを確かめたいとき。QR で読めた内容の正しさは確かめず、検証済みの事実とも信頼とも扱いません。
• QR を読む仕組みそのものがほしいとき。この継手は読取をせず、実 backend も含みません。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。

検査すること

• 結果の形を検めます。出力の digest の無い SUCCEEDED、extracted_ref の無い OCR_EXTRACT・QR_DECODE の SUCCEEDED、出力や効果を伴う FAILED は受理しません。PARTIAL は成功として扱いません。
• receipt が検証済み・開示の許可あり・信頼できると名乗るもの（content_verification NOT_VERIFIED・fidelity_assertion NOT_ASSERTED・disclosure_authorization NOT_DERIVED・trust_assertion NOT_DERIVED 以外の値）は受理しません。
• 入力を検めます。入力の bytes の digest が要求と合わないもの、上限（max_input_bytes）を超えるもの、許可していない content-type のもの、先頭の magic bytes が content-type と合わないもの（偽装した入力）は、変換 backend へ送りません。
• 操作・出力 profile・params を検めます。許可していない操作、電子契約（J-06）の操作、pin していない出力 profile・params を求める要求は送りません。
• receipt（MediaTransformReceipt）を照合します。request_digest の偽り、別の要求の receipt、操作のすり替え、外への効果を増やす receipt は受理せず、以後は停止します（HALTED）。
• 出力の bytes の digest を自分で計算し、receipt と違えば受理せず（OUTPUT_REJECTED）、以後は停止します（すり替えた出力は受け取りません）。
• 同じ request_id は二度送りません。backend の障害は UNKNOWN とし、再送は照会（lookup）で解きます。

しないこと・既知の限界

• QR の生成はしません。契約に無く、扱うのは QR_DECODE の読取の要求だけです。
• QR の読取そのものもしません。読むのは外の変換 backend で、この継手がするのは送る前の検めと、受け取った後の照合だけです。
• QR で読めた内容の正しさは確かめません（契約の const のとおり、主張しません）。
• 実 backend を含みません。どの変換エンジン・OCR サービスにつなぐか、port の実装、pin する profile は未定で、接続するときに別の関門（gate）で決めます。
• magic bytes は先頭の数 bytes だけを見ます。ファイル全体の構造の検査（壊れた PDF など）はしません。
• どの結果も承認ではありません（approval: false）。どの結果にも content_verification: NOT_VERIFIED・trust: NOT_DERIVED が付きます。
• 契約を変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/document-media/v1 でつなぎます。createMediaTransformClient({ cfg, port }) の transform(request, bytes) は、TRANSFORMED（QR では extracted_ref 付き）・PARTIAL・FAILED・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・OUTPUT_REJECTED・HALTED のどれかを返します（どれも approval: false）。利用側が用意するもの: 変換 backend への port（transform、任意で lookup）と cfg（許可リスト・pin・上限）。副作用は NONE か LOCAL_REVERSIBLE。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

出所・秘匿の刻印として外の変換 backend で透かしを入れるとき、偽装した入力や pin していない設定で送ってしまうこと、そして戻った出力が要求したものか確かめないまま渡してしまうこと（すり替え）を防ぎます。

使う場面

• 文書や画像への透かしを外の変換 backend に任せ、その手前と後ろで検めたいとき。
• 透かしの出力 profile と params を pin して、決めた形でしか入れさせたくないとき。
• backend が返した出力の bytes が、receipt の digest と一致したときだけ受け取りたいとき。
• 同じ要求を二重に送りたくないとき。障害のあとの再送は照会（lookup）で解きます。

使わない場面

• 電子契約が要るとき。電子契約（J-06）は作っておらず、この部品は J-06 を担いません。電子契約の操作を求める要求は送りません。
• 何を刻印するか・何を秘匿するかを決めたいとき。決定は核（redact-facts）と人の役目で、この継手は送る前と受け取った後の検めだけです。
• 透かしの入った出力を、信頼や開示の許可の根拠にしたいとき。どの結果も trust: NOT_DERIVED で、開示の許可も導きません。
• 透かしを入れる仕組みそのものがほしいとき。この継手は透かしを入れず、実 backend も含みません。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。

検査すること

• 入力を検めます。入力の bytes の digest が要求と合わないもの、上限（max_input_bytes）を超えるもの、許可していない content-type のもの、先頭の magic bytes が content-type と合わないもの（偽装した入力）は、変換 backend へ送りません。
• 操作・出力 profile・params を検めます。許可していない操作、電子契約（J-06）の操作、pin していない出力 profile・params を求める要求は送りません。
• 出力の bytes の digest を自分で計算し、receipt と違えば受理せず（OUTPUT_REJECTED）、以後は停止します（すり替えた出力は受け取りません）。
• receipt（MediaTransformReceipt）を照合します。request_digest の偽り、別の要求の receipt、操作のすり替え、外への効果を増やす receipt は受理せず、以後は停止します（HALTED）。
• receipt が検証済み・開示の許可あり・信頼できると名乗るもの（content_verification NOT_VERIFIED・fidelity_assertion NOT_ASSERTED・disclosure_authorization NOT_DERIVED・trust_assertion NOT_DERIVED 以外の値）は受理しません。
• 結果の形を検めます。出力の digest の無い SUCCEEDED、extracted_ref の無い OCR_EXTRACT・QR_DECODE の SUCCEEDED、出力や効果を伴う FAILED は受理しません。PARTIAL は成功として扱いません。
• 同じ request_id は二度送りません。backend の障害は UNKNOWN とし、再送は照会（lookup）で解きます。

しないこと・既知の限界

• 透かしを入れることそのものはしません。入れるのは外の変換 backend で、この継手がするのは送る前の検めと、受け取った後の照合だけです。
• 電子契約はしません。電子契約（J-06）は作っていません。
• 変換の見た目の忠実さ（透かしが見たとおりに入っているか）は確かめません。
• 実 backend を含みません。どの変換エンジン・OCR サービスにつなぐか、port の実装、pin する profile は未定で、接続するときに別の関門（gate）で決めます。
• magic bytes は先頭の数 bytes だけを見ます。ファイル全体の構造の検査（壊れた PDF など）はしません。
• どの結果も承認ではありません（approval: false）。どの結果にも content_verification: NOT_VERIFIED・trust: NOT_DERIVED が付きます。
• 契約を変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/document-media/v1 でつなぎます。createMediaTransformClient({ cfg, port }) の transform(request, bytes) は、TRANSFORMED・PARTIAL・FAILED・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・OUTPUT_REJECTED・HALTED のどれかを返します（どれも approval: false）。利用側が用意するもの: 変換 backend への port（transform、任意で lookup）と cfg（許可リスト・pin・上限）。副作用は NONE か LOCAL_REVERSIBLE。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

核（redact-facts）が決めた黒塗りを外の変換 backend で描画させるとき、偽装した入力を送ってしまうこと、「開示の許可あり」と名乗る receipt を受け取ってしまうこと、戻った出力が要求したものか確かめないまま渡してしまうこと（すり替え）を防ぎます。

使う場面

• 核（redact-facts）と人が決めた黒塗りの描画を外の変換 backend に任せ、その手前と後ろで検めたいとき。
• 描画の結果を開示の許可と取り違えたくないとき。disclosure_authorization が NOT_DERIVED 以外の receipt は受理しません。
• backend が返した出力の bytes が、receipt の digest と一致したときだけ受け取りたいとき。
• 同じ要求を二重に送りたくないとき。障害のあとの再送は照会（lookup）で解きます。

使わない場面

• 何を黒塗りにするかを決めたいとき。黒塗りの対象の決定は核と人の役目で、この継手は描画の要求を渡すだけです。
• 黒塗りした出力を開示してよいかを判断したいとき。黒塗りの描画は開示の許可ではありません。
• 黒塗りが見たとおりに描かれているか（忠実さ）を確かめたいとき。確かめません。
• 黒塗りを描く仕組みそのものがほしいとき。この継手は描画をせず、実 backend も含みません。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。

検査すること

• receipt が検証済み・開示の許可あり・信頼できると名乗るもの（content_verification NOT_VERIFIED・fidelity_assertion NOT_ASSERTED・disclosure_authorization NOT_DERIVED・trust_assertion NOT_DERIVED 以外の値）は受理しません。
• 入力を検めます。入力の bytes の digest が要求と合わないもの、上限（max_input_bytes）を超えるもの、許可していない content-type のもの、先頭の magic bytes が content-type と合わないもの（偽装した入力）は、変換 backend へ送りません。
• 操作・出力 profile・params を検めます。許可していない操作、電子契約（J-06）の操作、pin していない出力 profile・params を求める要求は送りません。
• 出力の bytes の digest を自分で計算し、receipt と違えば受理せず（OUTPUT_REJECTED）、以後は停止します（すり替えた出力は受け取りません）。
• receipt（MediaTransformReceipt）を照合します。request_digest の偽り、別の要求の receipt、操作のすり替え、外への効果を増やす receipt は受理せず、以後は停止します（HALTED）。
• 結果の形を検めます。出力の digest の無い SUCCEEDED、extracted_ref の無い OCR_EXTRACT・QR_DECODE の SUCCEEDED、出力や効果を伴う FAILED は受理しません。PARTIAL は成功として扱いません。
• 同じ request_id は二度送りません。backend の障害は UNKNOWN とし、再送は照会（lookup）で解きます。

しないこと・既知の限界

• 黒塗りの描画そのものはしません。描くのは外の変換 backend で、この継手がするのは送る前の検めと、受け取った後の照合だけです。
• 黒塗りの対象を決めず、開示を許可しません。対象の決定は核（redact-facts）と人の役目です。
• 変換の見た目の忠実さは確かめません。
• 実 backend を含みません。どの変換エンジン・OCR サービスにつなぐか、port の実装、pin する profile は未定で、接続するときに別の関門（gate）で決めます。
• magic bytes は先頭の数 bytes だけを見ます。ファイル全体の構造の検査（壊れた PDF など）はしません。
• どの結果も承認ではありません（approval: false）。どの結果にも content_verification: NOT_VERIFIED・trust: NOT_DERIVED が付きます。
• 契約を変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/document-media/v1 でつなぎます。createMediaTransformClient({ cfg, port }) の transform(request, bytes) は、TRANSFORMED・PARTIAL・FAILED・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・OUTPUT_REJECTED・HALTED のどれかを返します（どれも approval: false）。利用側が用意するもの: 変換 backend への port（transform、任意で lookup）と cfg（許可リスト・pin・上限）。副作用は NONE か LOCAL_REVERSIBLE。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

障害調査のためにログを外部の sink へ流すとき、メールアドレスや資格情報のような機微な値や自由文がログに混じって sink へ複製されること、そして sink が受け付けなかった記録が黙って消えることを防ぎます。許可したキーの短い基本型だけを送り、欠落は SUNK_PARTIAL と dropped で返します。

使う場面

• 機械可読の記録として、ts・level・event・attrs の形の構造化ログを外部の sink へ送りたいとき。
• ログに載せてよいイベント（log_events）とキー（log_attrs）を決めておき、それ以外を送らないようにしたいとき。
• ログから機微な値を sink へ複製したくないとき。最小化の記録（redaction_manifest_ref）を必須にできます。
• sink が受け付けなかったログを、黙って捨てずに欠落の事実として受け取りたいとき。
• 同じ batch を二重に流したくないとき。同じ request_id は ALREADY_SUNK として送りません。

使わない場面

• 自由文のメッセージや長い本文をそのままログに残したいとき。自由文の欄はなく、許可キーの短い基本型だけを送ります。
• エラー追跡（K-04）やアラート（K-06）が要るとき。別の部品で、この継手には含みません。
• すぐに使える sink がほしいとき。実 sink（各社の log の受け口）は含まず、まだ決まっていません。
• sink の受付の数を、ログの内容が正しいことの検証として扱いたいとき。観測は検証済みの事実ではありません。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。

検査すること

• 機微らしい値を検めます。メールアドレス、10 桁以上の数字の並び、Bearer、JWT、鍵、資格情報らしい記述が含まれていれば送りません（REFUSED）。
• 自由文の欄、許可していないイベントやキー（attrs）を含む記録は送りません。
• 大きさを検めます。batch の大きさ（max_payload_bytes）、記録の数（max_records）、値の長さ（max_attr_len）の上限を超えるものは送りません。
• pin した sink を検めます。pin していない sink へは送りません。payload の改ざん（payload_digest の不一致）があれば送りません。
• 最小化の記録（redaction_manifest_ref）を必須とし、無いものは送りません。これは契約より厳しくした点です。
• 受領（SinkReceipt）を照合します。request の digest を偽った受領や、送った数より多い受付は受理せず（RECEIPT_REJECTED）、以後は停止します（HALTED）。
• sink の障害（500 の応答）は UNKNOWN とし、再送は照会（lookup）で解きます。受領の observation_state が UNKNOWN なら照合しません。

しないこと・既知の限界

• ログの構造を決めるのは核（policy-facts）、最小化を決めるのは核（redact-facts）の役目です。この継手がするのは sink の手前での検めだけです。
• 機微の判定は文字の型による近似です。名前・住所などの自由な語は、許可キーと値の短さで抑えているだけで、見分けてはいません。
• 実 sink を含みません。どの受け口につなぐか、port の実装、pin する対象は未定で、接続するときに別の関門で決めます。
• 観測は検証済みの事実ではありません。verified が true になるのは、受領が VERIFIED と検証者を示したときだけです。成功は承認ではありません（approval: false）。
• 契約を変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。payload の中身の形は、契約ではなく継手の側の定めです。
• この部品は K-01 のほか、K-02（メトリクス）・K-03（分散トレース）も同じ 1 つの部品として担い、試験と検査も共通です。ID ごとの行（K-01・K-02・K-03）が、この部品を指します。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 監視サービスの使い方の雛形ではありません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/request-receipt-group/v1（SinkRequest / SinkReceipt）でつなぎます。createSinkClient({ cfg, port }) の sink(SinkRequest, bytes) に log の { records: [...] } を渡すと SUNK・SUNK_PARTIAL・ALREADY_SUNK・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED のどれかを返します（どれにも approval: false）。cfg は pin する sink・許可イベントとキー・上限。利用側は sink への port（write、任意で lookup）を用意します。副作用は EXTERNAL_REVERSIBLE。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

メトリクスを外部の sink へ流し続けるとき、決めていない metric やラベルが増えたり、ラベルに機微な値が混じって sink へ複製されたりすること、そして sink が受け付けなかった数値が黙って消えることを防ぎます。送った数より多い受付のような受領の異常では止まります。

使う場面

• 数値の常時計測として、ts・name・type・value・labels の形のメトリクスを外部の sink へ送りたいとき。
• 送ってよい metric（metrics）とラベル（metric_labels）を決めておき、それ以外を送らないようにしたいとき。
• sink が受け付けなかった数値を、黙って捨てずに欠落の事実（SUNK_PARTIAL と dropped）として受け取りたいとき。
• 送った数より多い受付を返す受領を異常として扱い、以後の送信を止めたいとき。
• 同じ batch を二重に流したくないとき。同じ request_id は ALREADY_SUNK として送りません。

使わない場面

• メトリクスの閾値を判定したり、アラートを出したりしたいとき。閾値の事実は核（monitor-detect）の役目で、アラート（K-06）は別の部品です。
• ラベルに自由文や長い値を載せたいとき。自由文の欄はなく、許可ラベルの短い基本型だけを送ります。
• すぐに使える sink がほしいとき。実 sink（各社の metrics の受け口）は含まず、まだ決まっていません。
• sink の受付の数を、計測値が正しいことの検証として扱いたいとき。観測は検証済みの事実ではありません。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。

検査すること

• 許可していない metric やラベル、自由文の欄を含む記録は送りません（REFUSED）。
• 機微らしい値を検めます。メールアドレス、10 桁以上の数字の並び、Bearer、JWT、鍵、資格情報らしい記述が含まれていれば送りません。
• 大きさを検めます。batch の大きさ（max_payload_bytes）、記録の数（max_records）、値の長さ（max_attr_len）の上限を超えるものは送りません。
• pin した sink を検めます。pin していない sink へは送りません。payload の改ざん（payload_digest の不一致）があれば送りません。
• 受領（SinkReceipt）の受付の数を照合します。送った数より多い受付や、request の digest を偽った受領は受理せず（RECEIPT_REJECTED）、以後は停止します（HALTED）。
• 最小化の記録（redaction_manifest_ref）を必須とし、無いものは送りません。これは契約より厳しくした点です。
• sink の障害（500 の応答）は UNKNOWN とし、再送は照会（lookup）で解きます。受領の observation_state が UNKNOWN なら照合しません。

しないこと・既知の限界

• 閾値の判定はしません。metrics の閾値の事実は核（monitor-detect）、最小化の決定は核（redact-facts）の役目で、この継手は sink の手前で検めるだけです。
• 機微の判定は文字の型による近似です。名前・住所などの自由な語は、許可ラベルと値の短さで抑えているだけで、見分けてはいません。
• 実 sink を含みません。どの受け口につなぐか、port の実装、pin する対象は未定で、接続するときに別の関門で決めます。
• 観測は検証済みの事実ではありません。verified が true になるのは、受領が VERIFIED と検証者を示したときだけです。成功は承認ではありません（approval: false）。
• K-02 専用の部品ではありません。K-01（構造化ログ）・K-03（分散トレース）と同じ 1 つの部品で、試験と検査も共通です。ID ごとの行（K-01・K-02・K-03）が、この部品を指します。
• 契約を変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。payload の中身の形は、契約ではなく継手の側の定めです。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 監視サービスの使い方の雛形ではありません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/request-receipt-group/v1（SinkRequest / SinkReceipt）でつなぎます。createSinkClient({ cfg, port }) の sink(SinkRequest, bytes) に metrics の { records: [...] } を渡すと SUNK・SUNK_PARTIAL・ALREADY_SUNK・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED のどれかを返します（どれにも approval: false）。cfg は pin する sink・許可 metric とラベル・上限。利用側は sink への port（write、任意で lookup）を用意します。副作用は EXTERNAL_REVERSIBLE。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

遅延の原因を追うために trace を外部の sink へ流すとき、別の trace の span が混じる、親の見つからない span がある、根が複数ある、といった相関の壊れた trace や、途中の断片だけの trace を流してしまうことを防ぎます。span の attrs に機微な値が混じって sink へ複製されることも拒否します。

使う場面

• 処理の経路追跡として、trace_id・span_id・parent_span_id・name・start_ts・end_ts・attrs の形の span を外部の sink へ送りたいとき。
• 1 つの trace をまとまった形（根の span がちょうど 1 つで、親がすべて同じ batch の中にある形）でだけ送りたいとき。
• trace ごとに相関の参照（correlation_ref）を必ず付けて送りたいとき。trace では correlation_ref を必須としています。
• span に載せてよいキー（span_attrs）を決めておき、それ以外を送らないようにしたいとき。
• sink が受け付けなかった span を、黙って捨てずに欠落の事実（SUNK_PARTIAL と dropped）として受け取りたいとき。

使わない場面

• trace の途中の断片だけを送りたいとき。根の span がちょうど 1 つで、親がすべて同じ batch の中にある batch だけを送ります。
• trace の連結が正しいかの最終の判断を、この継手に任せたいとき。trace の連結は核（provenance-facts）の役目です。
• エラー追跡（K-04）やアラート（K-06）が要るとき。別の部品で、この継手には含みません。
• すぐに使える sink がほしいとき。実 sink（各社の trace の受け口）は含まず、まだ決まっていません。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。

検査すること

• trace の相関を検めます。別の trace の span が混じる、終了が開始より前の span があるときは送りません（REFUSED）。
• 根の span の数と親の場所を検めます。根が複数ある batch、親が batch の外にある span（orphan）を含む batch は送りません。
• trace に相関の参照（correlation_ref）と最小化の記録（redaction_manifest_ref）が無いものは送りません。どちらも契約より厳しくした点です。
• span の attrs を検めます。許可していないキー、自由文の欄、メールアドレス・10 桁以上の数字の並び・Bearer・JWT・鍵・資格情報らしい記述を含むものは送りません。
• 大きさと宛先を検めます。batch の大きさ・記録の数・値の長さの上限を超えるもの、pin していない sink 宛て、payload の改ざん（payload_digest の不一致）があるものは送りません。
• 受領（SinkReceipt）を照合します。request の digest を偽った受領や、送った数より多い受付は受理せず（RECEIPT_REJECTED）、以後は停止します（HALTED）。
• sink の障害（500 の応答）は UNKNOWN とし、再送は照会（lookup）で解きます。同じ request_id は二重に流しません（ALREADY_SUNK）。

しないこと・既知の限界

• trace の連結を決めるのは核（provenance-facts）、最小化を決めるのは核（redact-facts）の役目です。この継手がするのは sink の手前での検めだけです。
• 機微の判定は文字の型による近似です。名前・住所などの自由な語は、許可キーと値の短さで抑えているだけで、見分けてはいません。
• 実 sink を含みません。どの受け口につなぐか、port の実装、pin する対象は未定で、接続するときに別の関門で決めます。
• 観測は検証済みの事実ではありません。verified が true になるのは、受領が VERIFIED と検証者を示したときだけです。成功は承認ではありません（approval: false）。
• K-03 専用の部品ではありません。K-01（構造化ログ）・K-02（メトリクス）と同じ 1 つの部品で、試験と検査も共通です。ID ごとの行（K-01・K-02・K-03）が、この部品を指します。
• 契約を変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。payload の中身の形は、契約ではなく継手の側の定めです。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 監視サービスの使い方の雛形ではありません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/request-receipt-group/v1（SinkRequest / SinkReceipt）でつなぎます。createSinkClient({ cfg, port }) の sink(SinkRequest, bytes) に span の { records: [...] } を渡すと SUNK・SUNK_PARTIAL・ALREADY_SUNK・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED のどれかを返します（どれにも approval: false）。cfg は pin する sink・span の許可キー・上限。利用側は sink への port（write、任意で lookup）を用意します。副作用は EXTERNAL_REVERSIBLE。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

エラーの記録を外部のエラー追跡の基盤へ送るとき、決めていない送り先へ送ってしまうこと、解決できない失敗の参照を送ってしまうこと、そして基盤の receipt を照合しないまま「記録できた」と扱ってしまうことを防ぎます。記録できたことを、検証済みの事実として扱わないための検めです。

使う場面

• 「たまに落ちる」のような失敗の記録を、エラー追跡の基盤へ送りたいとき。
• 送ってよいエラー追跡の送り先（sink_refs）を決めておき、それ以外へ送らないようにしたいとき。
• 失敗の参照（failure_ref）を、ai-execution-error の記録へ解決できるときだけ送りたいとき。
• 同じエラーの記録を二重に送りたくないとき。同じ request_id は二度送らず、再送は照会（lookup）で解きます。

使わない場面

• 例外そのものを集めたいとき。この継手はエラー追跡の要求を運ぶ継手で、例外を集める機能は含みません。
• 記録できたことを、検証済みの事実や承認として扱いたいとき。DONE の結果は verified_fact: NOT_ASSERTED で、approval: false です。
• failure_ref が指す記録の中身まで検めたいとき。この継手が確かめるのは、解決できるかどうかだけです。
• すぐに使える基盤がほしいとき。実の基盤（どのエラー追跡・監視・通知・フラグ・計測のサービスか）は含まず、まだ決まっていません。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。

検査すること

• pin していない送り先への要求は送りません。
• failure_ref を載せた要求は、port の resolveFailureRef で ai-execution-error の記録へ解決できないとき、または解決の手段が無いとき、送りません（REFUSED）。
• 参照が空のとき、パスや「..」を含むとき（path traversal）、追加のフィールドがあるときは送りません。参照は pin した一覧にあるものだけで、空の一覧は何も許しません。
• 同じ request_id は二度送りません（ALREADY_DONE）。同じ冪等キーで別の中身の要求は送らず（REFUSED）、重複（DEDUP_HIT）の receipt が新しい効果を名乗れば受理しません。
• receipt を照合します。request_digest の偽り、外への効果を増やす receipt、効果の分からない（UNKNOWN の）receipt、別の要求の receipt は受理せず（RECEIPT_REJECTED）、以後は停止します（HALTED）。
• 基盤の障害は UNKNOWN として返します。再送は照会（lookup）で解きます。

しないこと・既知の限界

• 例外を集める機能は含みません。エラー追跡の要求を検めて基盤へ運び、receipt を照合するだけです。
• failure_ref が指す ai-execution-error の記録の中身は検めません（解決できるかだけ）。
• 記録できたことを、検証済みの事実とはしません（verified_fact: NOT_ASSERTED）。
• 記録できたことは承認ではありません（approval: false）。
• 許可・意味の正しさ・業務の事実の判断は、核（monitor-detect・policy-facts）と人の役目です。この継手がするのは、送る前の検めと受け取った後の照合だけです。
• 実の基盤を含みません。どのサービスにつなぐか、port の実装、pin する一覧は未定で、接続するときに別の関門（gate）で決めます。
• 契約を変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/observability-ext/v1。createObservabilityExtClient({ cfg, port }) の submit(request) は DONE・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED を返します（すべて approval: false）。DONE の result: track_state・observation_state・verified_fact: NOT_ASSERTED。利用側の用意: cfg（pin する sink_refs ほか）と port（submit・任意で lookup・failure_ref 用に resolveFailureRef）。副作用は最大 EXTERNAL_REVERSIBLE。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

生死・準備状態を確かめるとき、決めていない対象へ問い合わせてしまうこと、そしてヘルスの PASS を「中身も正しい」と読み違えることを防ぎます。意味の正しさを名乗る receipt は受理しません。

使う場面

• 生死・準備状態のヘルスチェックの要求を、基盤へ運びたいとき。
• 問い合わせてよい対象（health_targets）を決めておき、それ以外を問い合わせないようにしたいとき。
• ヘルスの結果（health_state）と、意味の正しさ（semantic_correctness）を分けて受け取りたいとき。

使わない場面

• ヘルスの PASS を、処理結果の意味の正しさの証明として使いたいとき。この継手は PASS から意味の正しさを導きません。
• 異常を見つけて自動で復旧させたいとき。この継手はヘルスチェックの要求を運ぶ継手で、復旧の機能は含みません。
• 閾値で異常を判定したいとき。閾値と検出の事実は核（monitor-detect）の役目です。
• すぐに使える基盤がほしいとき。実の基盤（どのエラー追跡・監視・通知・フラグ・計測のサービスか）は含まず、まだ決まっていません。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。

検査すること

• pin していない対象へのヘルスチェックの要求は送りません。
• 意味の正しさを主張するヘルスの receipt は受理しません。
• ヘルスチェックの効果は NONE です。外への効果を名乗る receipt は、効果を増やすものとして受理しません。
• 参照が空のとき、パスや「..」を含むとき（path traversal）、追加のフィールドがあるときは送りません。参照は pin した一覧にあるものだけで、空の一覧は何も許しません。
• 同じ request_id は二度送りません（ALREADY_DONE）。同じ冪等キーで別の中身の要求は送らず（REFUSED）、重複（DEDUP_HIT）の receipt が新しい効果を名乗れば受理しません。
• receipt を照合します。request_digest の偽り、外への効果を増やす receipt、効果の分からない（UNKNOWN の）receipt、別の要求の receipt は受理せず（RECEIPT_REJECTED）、以後は停止します（HALTED）。
• 基盤の障害は UNKNOWN として返します。再送は照会（lookup）で解きます。

しないこと・既知の限界

• ヘルスの PASS から、意味の正しさを導きません。
• 復旧の機能は含みません。ヘルスチェックの要求を検めて基盤へ運び、receipt を照合するだけです。
• ヘルスの結果は承認ではありません（approval: false）。
• 許可・意味の正しさ・業務の事実の判断は、核（monitor-detect・policy-facts）と人の役目です。この継手がするのは、送る前の検めと受け取った後の照合だけです。
• 実の基盤を含みません。どのサービスにつなぐか、port の実装、pin する一覧は未定で、接続するときに別の関門（gate）で決めます。
• 契約を変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/observability-ext/v1。createObservabilityExtClient({ cfg, port }) の submit(request) は DONE・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED を返します（すべて approval: false）。DONE の result: health_state・semantic_correctness。利用側の用意: cfg（health_targets などの pin する一覧）と port（submit、任意の lookup）。ヘルスチェックの副作用は NONE です。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

異常を通報するとき、決めていない宛先や任意の URL へアラートを送ってしまうこと、そして「届けた」を「受け取られた」と読み違えることを防ぎます。

使う場面

• 異常の通報（アラート）の要求を、基盤へ運びたいとき。
• アラート（alert_refs）と宛先（alert_destinations）を pin し、任意の URL へ送らないようにしたいとき。
• 届けた（delivered）と受け取られた（acknowledged）を、分けて受け取りたいとき。

使わない場面

• アラートが実際に人に届いたか・対応されたかを確かめたいとき。この継手は receipt の状態を返すだけで、確かめません。
• オンコールの当番を組んだり、呼び出しを段階的に広げたりしたいとき。この継手はアラートの要求を運ぶ継手で、それらの機能は含みません。
• 異常を閾値で判定したいとき。閾値と検出の事実は核（monitor-detect）、アラートの方針は核（policy-facts）の役目です。
• すぐに使える基盤がほしいとき。実の基盤（どのエラー追跡・監視・通知・フラグ・計測のサービスか）は含まず、まだ決まっていません。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。

検査すること

• pin していないアラート、pin していない宛先への要求は送りません。宛先に任意の URL を差し込む要求（destination injection）も送りません。
• delivered は DELIVERED か ACKNOWLEDGED のときだけ、acknowledged は ACKNOWLEDGED のときだけ認めます。外への効果を伴わずに届けたと名乗る receipt は受理しません。
• 参照が空のとき、パスや「..」を含むとき（path traversal）、追加のフィールドがあるときは送りません。参照は pin した一覧にあるものだけで、空の一覧は何も許しません。
• 同じ request_id は二度送りません（ALREADY_DONE）。同じ冪等キーで別の中身の要求は送らず（REFUSED）、重複（DEDUP_HIT）の receipt が新しい効果を名乗れば受理しません。
• receipt を照合します。request_digest の偽り、外への効果を増やす receipt、効果の分からない（UNKNOWN の）receipt、別の要求の receipt は受理せず（RECEIPT_REJECTED）、以後は停止します（HALTED）。
• 基盤の障害は UNKNOWN として返します。再送は照会（lookup）で解きます。

しないこと・既知の限界

• アラートが実際に人に届いたか・対応されたかは確かめません。receipt の状態を返すだけです。
• オンコールの当番や呼び出しの機能は含みません。アラートの要求を検めて基盤へ運び、receipt を照合するだけです。
• アラートを届けたことは承認ではありません（approval: false）。
• 許可・意味の正しさ・業務の事実の判断は、核（monitor-detect・policy-facts）と人の役目です。この継手がするのは、送る前の検めと受け取った後の照合だけです。
• 実の基盤を含みません。どのサービスにつなぐか、port の実装、pin する一覧は未定で、接続するときに別の関門（gate）で決めます。
• 契約を変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/observability-ext/v1。createObservabilityExtClient({ cfg, port }) の submit(request) は DONE・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED を返します（すべて approval: false）。DONE の result: alert_state・delivered・acknowledged。利用側の用意: pin する一覧（alert_refs・alert_destinations など）の cfg と、port（submit・任意の lookup）。副作用は EXTERNAL_REVERSIBLE（DEDUP_HIT・FAILED は NONE）。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

機能の出し分けのために機能フラグを読み書きするとき、決めていないフラグや値を立ててしまうこと、そしてフラグが立っていることを「許可された」と読み違えることを防ぎます。許可を名乗るフラグの receipt は受理しません。

使う場面

• 機能フラグの READ・SET・CLEAR の要求を、基盤へ運びたいとき。
• 扱ってよいフラグ（flag_refs）と値（flag_value_refs）を決めておき、それ以外を扱わないようにしたいとき。
• フラグの状態（flag_state）と許可（authorization）を分けて受け取りたいとき。

使わない場面

• フラグの状態を、利用者や機能の許可として使いたいとき。この継手はフラグの状態から許可を導きません。
• READ でフラグの値そのものを受け取りたいとき。値は receipt に無く、この継手は状態だけを返します。
• 段階公開の割合や対象を決めたいとき。この継手は機能フラグの要求を運ぶ継手で、出し分けを決める機能は含みません。フラグの方針は核（policy-facts）の役目です。
• すぐに使える基盤がほしいとき。実の基盤（どのエラー追跡・監視・通知・フラグ・計測のサービスか）は含まず、まだ決まっていません。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。

検査すること

• pin していないフラグ・pin していない値の要求は送りません。
• value_ref は SET のときだけ必須で、READ に値を載せた要求は送りません。op と効果が合わない要求（READ は NONE、SET・CLEAR は EXTERNAL_REVERSIBLE）も送りません。
• 状態が op に対応しない receipt（READ→READ・SET→SET・CLEAR→CLEARED か FAILED 以外）は受理しません。
• 許可を名乗るフラグの receipt は受理しません。
• 参照が空のとき、パスや「..」を含むとき（path traversal）、追加のフィールドがあるときは送りません。参照は pin した一覧にあるものだけで、空の一覧は何も許しません。
• 同じ request_id は二度送りません（ALREADY_DONE）。同じ冪等キーで別の中身の要求は送らず（REFUSED）、重複（DEDUP_HIT）の receipt が新しい効果を名乗れば受理しません。
• receipt を照合します。request_digest の偽り、外への効果を増やす receipt、効果の分からない（UNKNOWN の）receipt、別の要求の receipt は受理せず（RECEIPT_REJECTED）、以後は停止します（HALTED）。
• 基盤の障害は UNKNOWN として返します。再送は照会（lookup）で解きます。

しないこと・既知の限界

• フラグの状態から許可を導きません。
• フラグの値そのもの（READ で何が返るか）は返しません。状態だけを返します。
• 出し分けを決める機能は含みません。機能フラグの要求を検めて基盤へ運び、receipt を照合するだけです。
• フラグを立てたことは承認ではありません（approval: false）。
• 許可・意味の正しさ・業務の事実の判断は、核（monitor-detect・policy-facts）と人の役目です。この継手がするのは、送る前の検めと受け取った後の照合だけです。
• 実の基盤を含みません。どのサービスにつなぐか、port の実装、pin する一覧は未定で、接続するときに別の関門（gate）で決めます。
• 契約を変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/observability-ext/v1。createObservabilityExtClient({ cfg, port }) の submit(request) は DONE・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED を返します（すべて approval: false）。DONE の result: flag_state・authorization。利用側の用意: pin する一覧（flag_refs・flag_value_refs など）の cfg と、port（submit・任意の lookup）。副作用は READ が NONE、SET・CLEAR が EXTERNAL_REVERSIBLE（FAILED は NONE）。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

使用量を外部の計測の基盤へ記録するとき、決めていない計測器や単位で記録してしまうこと、小数・負・上限を超える量を送ってしまうこと、そして記録した量を検証済みの業務の事実と読み違えることを防ぎます。

使う場面

• 使用量のイベントを、計測の基盤へ運びたいとき。
• 記録してよい計測器（meter_refs）と単位（unit_refs）、量の上限（max_quantity）を決めておき、それ以外を送らないようにしたいとき。
• 同じ使用量を二重に記録したくないとき。同じ冪等キーで別の量は送らず、同じ request_id は二度送りません。

使わない場面

• 課金をしたいとき。この継手は使用量のイベントを運ぶ継手で、課金の機能は含みません。
• 記録した量を、そのまま課金に使いたいとき。量の正しさ（課金に使えるか）は確かめず、検証済みの業務の事実ではありません。
• 小数の量を記録したいとき。量は 0 以上の整数だけで、小数の量は digest を作れないため送りません。
• すぐに使える基盤がほしいとき。実の基盤（どのエラー追跡・監視・通知・フラグ・計測のサービスか）は含まず、まだ決まっていません。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。

検査すること

• pin していない計測器・pin していない単位の要求は送りません。
• 量が小数のとき、負のとき、上限（max_quantity）を超えるときは送りません。max_quantity は使用量を記録するとき必須です。
• 量を検証済みの業務の事実と主張する receipt は受理しません。
• 参照が空のとき、パスや「..」を含むとき（path traversal）、追加のフィールドがあるときは送りません。参照は pin した一覧にあるものだけで、空の一覧は何も許しません。
• 同じ request_id は二度送りません（ALREADY_DONE）。同じ冪等キーで別の中身の要求は送らず（REFUSED）、重複（DEDUP_HIT）の receipt が新しい効果を名乗れば受理しません。
• receipt を照合します。request_digest の偽り、外への効果を増やす receipt、効果の分からない（UNKNOWN の）receipt、別の要求の receipt は受理せず（RECEIPT_REJECTED）、以後は停止します（HALTED）。
• 基盤の障害は UNKNOWN として返します。再送は照会（lookup）で解きます。

しないこと・既知の限界

• 課金はしません。使用量のイベントを検めて基盤へ運び、receipt を照合するだけです。
• 量の正しさ（課金に使えるか）は確かめません。記録した量は検証済みの業務の事実ではありません。
• 小数の量は扱いません（契約は number ですが、この継手は 0 以上の整数に締めています）。
• 使用量を記録できたことは承認ではありません（approval: false）。
• 許可・意味の正しさ・業務の事実の判断は、核（monitor-detect・policy-facts）と人の役目です。この継手がするのは、送る前の検めと受け取った後の照合だけです。
• 実の基盤を含みません。どのサービスにつなぐか、port の実装、pin する一覧は未定で、接続するときに別の関門（gate）で決めます。
• 契約を変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/observability-ext/v1。createObservabilityExtClient({ cfg, port }) の submit(request) は DONE・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED を返します（すべて approval: false）。DONE の result: meter_state・business_fact_verification。利用側の用意: pin する一覧（meter_refs・unit_refs など）と max_quantity の cfg、port（submit・任意の lookup）。副作用は EXTERNAL_REVERSIBLE（DEDUP_HIT・FAILED は NONE）。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

「時間がずれる」の裏で、夏時間の飛びで存在しない時刻や、重なりで二度ある時刻を、ほかの時刻に黙って寄せてしまうこと、2 月 30 日・24 時・60 秒のような欄を繰り上げて受け取ってしまうことを防ぎます。結果に tz データと ICU の版を添えるので、どの規則で出した答えかを後から確かめられます。

使う場面

• epoch ミリ秒の瞬間を、IANA の zone（例: Asia/Tokyo）の壁時計と UTC からのずれに変えたいとき（toZoned）。
• zone の壁時計を epoch ミリ秒の瞬間に変えたいとき（fromZoned）。二度ある壁時計は既定で止め、earlier・later を明示したときだけ早い方・遅い方を選びます。
• 二度ある壁時計を止めたときに、早い方・遅い方の瞬間の候補（candidates_ms）を受け取り、どちらにするかを使う側で決めたいとき。
• どの tz データ・ICU の版で出した答えかを、結果といっしょに残したいとき（tzdata の tz・icu・matches_pin）。
• 例外を投げない変換が要るとき。toZoned と fromZoned はどちらも例外を投げず、入力を書き換えません。
• 現在時刻・乱数・環境の locale を読まず、外の境界を持たない処理として、手元で呼びたいとき。依存パッケージはありません。

使わない場面

• tz データや ICU の版にかかわらず同じ答えが要るとき。答えはこの実行環境の tz データ（2026c）と ICU（78.3）に依り、版が変われば同じ入力でも答えが変わりえます。ほかの版では確かめていません（tzdata.matches_pin が false になります）。
• 1970 年より前、2100 年より後の時刻を扱うとき。OUT_OF_RANGE で止めます。
• 閏秒を扱いたいとき。瞬間は閏秒を数えない POSIX の時刻で、60 秒は INVALID_DATE で止めます。
• +09:00 のような UTC からのずれの書き方で zone を渡したいとき。zone は IANA の名前の形だけで、ほかは INVALID_ZONE で止めます。
• 存在しない壁時計を、近い時刻に寄せてほしいとき。NONEXISTENT_LOCAL_TIME で止め、disambiguation に関わらずほかの時刻に寄せません。
• Node.js v24.21.0（tz データ 2026c・ICU 78.3）のほかの版で使うとき。ほかの版は確かめていません（NOT_VERIFIED）。

検査すること

• 瞬間が安全な整数でないとき（小数・NaN・Infinity・文字列・Date・bigint）INVALID_INSTANT、瞬間や年が 1970〜2100 の外のとき OUT_OF_RANGE で止めます。
• zone が文字列でない・64 文字を超える・IANA の名前の形でないとき（ずれの書き方・空白・空の区切り）INVALID_ZONE、形は合うがこの実行環境の Intl が知らないとき UNKNOWN_ZONE で止めます。
• 壁時計が素のオブジェクトでない、必須の欄が無い、ほかのキー・getter・列挙しないプロパティ・symbol のキーがある、値が整数でないとき、INVALID_LOCAL で止めます。getter は呼びません。
• 欄の値が範囲の外のとき（2 月 30 日・平年や 2100 年の 2 月 29 日・4 月 31 日・13 月・24 時・60 分・60 秒・1000 ミリ秒・負の値）、繰り上げずに INVALID_DATE で止めます。
• 夏時間の飛びで存在しない壁時計のとき NONEXISTENT_LOCAL_TIME、重なりで二度ある壁時計のとき（disambiguation が reject（既定））AMBIGUOUS_LOCAL_TIME で止め、候補を添えます。
• options が素のオブジェクトでない、ほかのキー・getter がある、disambiguation が reject・earlier・later のどれでもないとき INVALID_OPTIONS、調べること自体が例外になるとき（Proxy の罠など）INSPECTION_FAILED で止めます。
• 壁時計が範囲の中でも、変換した瞬間が範囲の外に出るとき（例: Asia/Tokyo の 1970-01-01 08:59）、OUT_OF_RANGE で止めます。

しないこと・既知の限界

• tz データを自分では持ちません。変換の規則は Node.js の ICU のもので、答えの正しさはこの実行環境の tz データが正しいときだけです。将来の時刻は、その tz データが作られた時点の規則の見込みで、規則の変更（夏時間の廃止など）はその版の tz データが出るまで反映されません。
• 答えを独立に突き合わせたのは UTC・Asia/Tokyo（1970〜2100 年）と America/New_York・Europe/London（2010〜2035 年）だけです。ほかの zone は往復と性質の検めだけで、答えを別に確かめてはいません。
• fromZoned は前後 15 時間を 3 時間ごとに見たずれから候補を作ります。3 時間より短い間隔で変わり目が続く zone・時期では、候補を取りこぼすことがあります（1970〜2100 年の tz データで起きるかは全部は確かめていません）。
• 何時を締め切りにするか・どの zone を使うか・営業日などの意味の判断はしません。使う側（Kernel・業務）に残ります。
• Temporal や外のライブラリとの答えの互換は確かめていません。Proxy の罠は、この部品が調べる操作（getPrototypeOf・ownKeys・getOwnPropertyDescriptor）のものだけを確かめました。
• 変換できたことは、その時刻が正しいことでも、受け入れてよいことでもありません（result_is_approval: false）。権限も作りません（derives_authority: false）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 特定の日付ライブラリの使い方の雛形ではありません。

つなぎ方

src/timezone.js の toZoned(instantMs, zone)・fromZoned(local, zone, options) を呼びます（投げません）。受け取るのは epoch ミリ秒か壁時計、IANA の zone の名前、任意の { disambiguation } です。返すのは { ok: true, errors: [], local か instant_ms, offset_seconds, zone, resolved_zone, tzdata, … } か { ok: false, errors: [{ code }], tzdata }（code は error_taxonomy）。副作用（NONE）・外の接続・資格情報は無く、利用側が用意するものはありません。状態は書式の覚え置き（プロセスの中だけ）で、答えには影響しません。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

翻訳の基盤へ要求を運ぶとき、本文をそのまま送ってしまうこと、pin していない基盤や locale へ送ってしまうこと、そして機械翻訳を人が確かめた翻訳や正本と取り違えることを防ぎます。

使う場面

• 機械翻訳の要求を、本文ではなく参照だけで、pin した翻訳の基盤へ運びたいとき。
• 訳す前と後の locale を pin した一覧に限り、訳す前と後が同じ locale の要求を送らないようにしたいとき。
• 戻った receipt を、request_id・request_digest・参照の一致で照合してから受け取りたいとき。DONE の result には translation_state・output_ref・human_verification・authoritative_status が添えられます。
• 基盤の障害で結果が不明（UNKNOWN）になっても、同じ request_id を二度送らず、lookup で解きたいとき。

使わない場面

• 画面の文言を言語ごとに切り替えたいとき、または多言語の文言カタログを管理したいとき。この継手は機械翻訳の要求を運ぶ継手で、文言の切替・カタログの管理の機能は含みません。
• 機械翻訳の結果を、人が確かめた翻訳や正本として扱いたいとき。そう名乗る receipt は受理しません。
• 訳の正しさを確かめたいとき、または訳した文言の公開を承認させたいとき。訳の確認と公開の承認は、外の判断と人・組織の役目です。
• 時刻の変換・通貨や数の書式・単位の換算・並べ替えなど、手元の計算で済む地域対応をしたいとき。この継手の対象ではありません。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。
• すぐに使える基盤がほしいとき。実の翻訳・住所・参照データの基盤は含みません。

検査すること

• pin していない基盤・locale への要求は送りません。設定の一覧が空のとき、空の項目があるときも送りません（空の一覧は何も許しません）。
• 参照が空のもの・パスや .. を含むもの、追加のフィールド、決まった値（const）と違う値の要求は送りません。
• 訳す前と後の locale が同じ要求は送りません。
• 人が確かめた翻訳（human verification）や正本（authoritative）を名乗る receipt は受理しません。
• できた（PRODUCED）のに出力の参照（output_ref）が無い receipt、できなかった（FAILED・UNAVAILABLE）のに出力の参照や効果を名乗る receipt は受理しません。
• 意図と違う副作用の要求は送りません。意図より外への効果を増やす receipt、効果が不明（UNKNOWN）な receipt は受理しません。
• 別の要求の receipt（request_digest の偽り）は受理せず、受理できない receipt が来たら停止します（HALTED）。

しないこと・既知の限界

• 文言の切替・多言語カタログの管理はしません。この継手は機械翻訳の要求を運ぶ継手で、その機能は含みません。
• 機械翻訳は、人が確かめた翻訳でも正本でもありません。訳の正しさは確かめません。
• どの結果も承認ではありません（approval: false）。訳せた・見つかったは、公開の承認でも、届く住所の確認でも、正本でもありません。
• 実の翻訳・住所・参照データの基盤を含まず、一度も接続していません。port の実装と pin する一覧は、接続するときに別の関門で決めます。
• 契約を変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 特定の翻訳・地図・暦サービスの使い方の雛形ではありません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/localization/v1 でつなぎます。createLocalizationClient({ cfg, port }) の submit(request) に TranslationRequest を渡すと、DONE・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED のどれかを返します（どれも approval: false）。利用側が用意するもの: cfg（backends・locales・regions・datasets の pin する一覧）と、基盤への port（submit と、任意で lookup）。秘密は port 側が持ちます。副作用は EXTERNAL_REVERSIBLE（FAILED・UNAVAILABLE は NONE）。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

表示の裏で、動かす環境の国際化 API（ICU）によって表記が変わってしまうこと、桁を捨てたり丸めたりして表記が元の整数に戻らなくなること、表に無い通貨・locale や余分なキー（丸め方などのつもりの指定）を黙って近いものに寄せたり無視したりすることを防ぎます。

使う場面

• すでに通貨の最小単位にした安全な整数を、表の通貨（日本・米国の通貨と、EUR・GBP・KRW・CNY・BHD）と locale（ja-JP・en-US）で、記号と桁区切りの付いた表記の文字列にしたいとき（formatMinor）。
• 動かす環境に左右されない表記が要るとき。時計・乱数・環境の locale・国際化 API（ICU）を使わず、表はこの部品のファイルの中に固定していて、同じ入力からはいつでも同じ text ができます。
• 表記を最小単位に戻すと、受け取った整数の絶対値にちょうど戻ること（桁を捨てない・丸めない）が要るとき。
• 受け取れない入力を、どの欄か（field）とコードで、当てはまるものをすべて返してほしいとき。
• 例外を投げない整形が要るとき。formatMinor は例外を投げず、入力を書き換えず、getter を呼びません。

使わない場面

• 小数を含む値や、まだ最小単位にしていない値を渡したいとき。この部品は整数だけを受け取り、丸めもしません。最小単位にするときの丸め方の方針・換算は、使う側か G 系の部品の役目です。
• 表の 7 通貨と 2 locale のほかを扱いたいとき。UNKNOWN_CURRENCY・UNKNOWN_LOCALE で止め、ja-jp・en-GB・ja などに寄せません。
• CLDR・Intl.NumberFormat と同じ出力が要るとき。一致は主張しません。記号の選び方と書き方はこの部品の決まりで、日本の通貨の記号は半角の U+00A5（CLDR の ja の全角 U+FFE5 ではない）、BHD は ISO 4217 のコードと空白（U+0020）です。
• 記号を数の後ろに置く書き方、ほかの桁区切り（ピリオド・空白・インドの 2 桁区切り）、会計の書き方（括弧の負の数）、全角の数字・記号が要るとき。
• Node.js v24.21.0 のほかの版で使うとき。ほかの版は確かめていません（NOT_VERIFIED）。

検査すること

• 入力がオブジェクトでないとき（null・配列・数・文字列など）、キーが getter・setter のとき、入力を調べること自体が例外になるとき（Proxy の罠など）、INVALID_INPUT で止めます。getter は呼びません。
• amount_minor・currency・locale のほかのキーを持つとき（列挙しないキー・symbol のキーを含む）、黙って無視せずに UNKNOWN_FIELD で止めます。継承したキーは読みません。
• amount_minor が無い、number でない（bigint・文字列）、整数でない、安全な整数の範囲の外、NaN・Infinity のとき、INVALID_AMOUNT で止めます。
• currency が無い、文字列でない、表のコードでないとき（小文字・前後の空白・__proto__ などの継承した名前を含む）、UNKNOWN_CURRENCY で止めます。
• locale が無い、文字列でない、表の locale でないとき、近い locale に寄せずに UNKNOWN_LOCALE で止めます。
• いくつもの欄が受け取れないとき、errors に amount_minor → currency → locale の順で、当てはまるものをすべて並べます（入力の形が違うとき・余分なキーのときは 1 件だけ）。

しないこと・既知の限界

• 通貨整形の部品は表示の整形だけで、通貨の換算・丸め・税・請求・支払いの判断は含みません。それらは G 系の部品や使う側に残ります。
• 受け取った整数の意味（最小単位にしたときの丸め・通貨の正しさ）は確かめません。受け取った整数をそのまま書きます。
• 表の 7 通貨と 2 locale のほかは扱いません。ja-JP と en-US の出力は同じで（桁区切りはコンマ・小数点はピリオド・3 桁ごと・記号は数の前）、locale ごとの違いは作りません。
• 記号は Unicode の文字そのままで、正規化はしません。表は CLDR・各国の慣行の写しではなく、この部品の決まりです。表は凍結していて、使う側は書き換えられません。
• 表記の文字列ができたことは、額が正しいことでも、請求・支払いをしてよいことでもありません（result_is_approval: false）。権限も作りません（derives_authority: false）。
• 工房の定義の tsugite-l-03 は検めの型だけで、整形の実装は無く、比べる相手はありません。この部品は整形の実装になる候補です。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 特定の国際化ライブラリの使い方の雛形ではありません。

つなぎ方

src/currency.js の formatMinor({ amount_minor, currency, locale }) を呼びます（投げません）。受け取るのは 3 つのキーだけのオブジェクトで、amount_minor は最小単位の安全な整数、currency は表の ISO 4217 のコード、locale は ja-JP か en-US です。返すのは { ok: true, errors: [], text } か { ok: false, errors: [{ code, field }], text: null }（code は error_taxonomy）。text は、負のときだけの符号・表の記号・3 桁ごとに区切った整数部・最小単位の桁数の小数部の順です。副作用（NONE）・状態・外の接続・資格情報は無く、利用側が用意するものはありません。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

換算の途中に浮動小数点の誤差が入ること（"0.1" が 1/10 ちょうどでなくなるなど）、次元の違う換算や絶対零度より低い温度を黙って計算してしまうこと、似た綴りの単位や余分なキー（精度などのつもりの指定）を黙って近いものに寄せたり無視したりすることを防ぎます。

使う場面

• 長さ（m・km・cm・mm・in・ft・mi）、質量（kg・g・lb・oz）、圧力（Pa・kPa・MPa・bar・psi）、温度（K・C・F）の同じ次元の中で、値を換算したいとき（convert）。
• 換算の結果を、正確な有理数から小数 fraction_digits 桁に half-even で 1 回だけ丸めた値として受け取りたいとき（途中で丸めない）。
• 係数の出どころが定義値であることが要るとき（in = 0.0254 m、lb = 0.45359237 kg、bar = 100000 Pa、K = °C + 273.15 など）。
• 派生の値を注入するときの換算の規則として使いたいとき。
• 時計・乱数・環境の locale に左右されず、外の境界・状態を持たない処理として、手元で呼びたいとき。convert は例外を投げず、入力を書き換えず、getter を呼びません。

使わない場面

• dB の系（dBm↔mW・dB など）を換算したいとき。カタログの一言は「dBm/MPa 等」ですが、dB の系は対数で結果が有理数にならないため v1 に無く、表に無い単位として UNKNOWN_UNIT で止めます。
• 表の 19 単位のほかを使いたいとき。μm・hPa のような接頭語の組み合わせは自動では作りません。
• 温度の差（Δ°C ↔ Δ°F）を換算したいとき。温度は絶対温度として換算し、絶対零度より低い値は止めます。
• 有効数字・誤差（不確かさ）の伝わり方や、half-even のほかの丸めが要るとき。
• locale による書き方（小数点のコンマなど）や桁区切りの付いた出力が要るとき。出力は桁区切りの無い 10 進の文字列だけです。
• 浮動小数点で換算するほかの実装と同じ結果が要るとき。丸めの境目の近くで結果が違うことがあります。
• Node.js v24.21.0 のほかの版で使うとき。ほかの版は確かめていません（NOT_VERIFIED）。

検査すること

• 入力がオブジェクトでないとき、キーが getter・setter のとき、調べること自体が例外になるとき（Proxy の罠など）INVALID_INPUT、5 つのキーのほかのキーを持つとき（列挙しないキー・symbol のキーを含む）UNKNOWN_FIELD で止めます。
• value が文字列でない、64 文字を超える、10 進の文法に合わないとき（指数・16 進・NaN・Infinity・+・空白・桁区切り・"1."・".5"・先頭の余分な 0・ASCII でない数字）、MALFORMED_VALUE で止めます。
• from・to が表の単位でないとき（dBm・mW などの dB の系、"°C"・"KM"・"kpa" などの似た綴り、__proto__ などの継承した名前を含む）、UNKNOWN_UNIT で止めます。
• from と to の次元が違うとき、黙って計算せずに INCOMPATIBLE_UNITS で止めます。
• 温度の値が絶対零度（0 K = -273.15 °C = -459.67 °F）より低いとき、BELOW_ABSOLUTE_ZERO で止めます。絶対零度ちょうどは受け取ります。
• fraction_digits が 0〜18 の整数でないとき INVALID_FRACTION_DIGITS、rounding が無いか "half-even" ちょうどでないとき UNSUPPORTED_ROUNDING で止めます。
• いくつもの欄が受け取れないとき、errors に value → from → to → fraction_digits → rounding の順で、当てはまるものをすべて並べます。

しないこと・既知の限界

• 単位変換の部品は、カタログの一言にある dBm を含む dB の系の換算は含みません。v1 は有理数で正確に書ける長さ・質量・圧力（MPa を含む）・温度だけです。
• どの値を換算してよいか・突き合わせ（reconcile）は決めません。使う側に残ります。
• 係数の値は定義から写したもので、オラクルも同じ定義から作ったため、定義そのものの写し違いは両方に同じく入りえます。確かめたのは既知の答えの試験（1 in = 25.4 mm・1 lb = 453.59237 g・1 psi = 6894.757293168361 Pa など）の範囲だけです。
• 単位の名前は ASCII の記号そのままです（"C" は摂氏で、クーロンではありません）。
• 換算できたことは、元の値や単位の選び方が正しいことでも、その値で設計・判断してよいことでもありません（result_is_approval: false）。権限も作りません（derives_authority: false）。
• 工房の定義の tsugite-l-04 は検めの型だけで、換算の実装は無く、比べる相手はありません。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 特定の単位換算ライブラリの使い方の雛形ではありません。

つなぎ方

src/unitconvert.js の convert({ value, from, to, fraction_digits, rounding }) を呼びます（投げません）。受け取るのは 5 つのキーだけのオブジェクトで、value は 64 文字までの 10 進の文字列、from・to は表の単位の名前、fraction_digits は 0〜18 の整数、rounding は "half-even" ちょうど（省略できない）です。返すのは { ok: true, errors: [], value } か { ok: false, errors: [{ code, field }], value: null }（code は error_taxonomy）。副作用（NONE）・状態・外の接続・資格情報は無く、利用側が用意するものはありません。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

住所の基盤へ照会を運ぶとき、住所の文面をそのまま送ってしまうこと、pin していない基盤や地域へ送ってしまうこと、そして見つかった住所の候補を、届く住所の確認や住んでいる証明と取り違えることを防ぎます。

使う場面

• 住所の候補の照会を、住所の文面ではなく参照（query_ref）だけで、pin した住所の基盤へ運びたいとき。
• 照会する地域を、pin した一覧に限りたいとき。
• 外への効果の無い照会（副作用 NONE）として運びたいとき。
• 戻った receipt を、request_id・request_digest・参照の一致で照合してから受け取りたいとき。DONE の result には lookup_state・candidate_ref・deliverability・residence_proof が添えられます。
• 基盤の障害で結果が不明（UNKNOWN）になっても、同じ request_id を二度送らず、lookup で解きたいとき。

使わない場面

• 届く住所かどうか（配送できるか）を検証したいとき。住所の候補は届く住所の確認ではなく、そう名乗る receipt は受理しません。
• 本人がそこに住んでいることの証明がほしいとき。住所の候補は住んでいる証明ではありません。本人の住所の証明は、外の判断と人・組織の役目です。
• 住所の表記ゆれをそろえる（正規化する）仕組みそのものがほしいとき。この継手は住所の候補の照会の要求を運ぶ継手で、正規化の機能は含みません。
• 住所の文面を基盤へ送りたいとき。運ぶのは参照だけで、空白を含む参照は住所の文面とみなして送りません。
• 電話番号の正規化など、手元の計算で済む地域対応をしたいとき。この継手の対象ではありません。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。
• すぐに使える基盤がほしいとき。実の翻訳・住所・参照データの基盤は含みません。

検査すること

• pin していない基盤・地域への要求は送りません。設定の一覧が空のとき、空の項目があるときも送りません（空の一覧は何も許しません）。
• 照会の参照（query_ref）に空白があれば、住所の文面とみなして送りません。
• 参照が空のもの・パスや .. を含むもの、追加のフィールド、決まった値（const）と違う値の要求は送りません。
• 届く住所の確認（deliverability）や住んでいる証明（residence proof）を名乗る receipt は受理しません。
• 見つからない（NOT_FOUND）のに候補の参照（candidate_ref）を持つ receipt、できなかったのに出力の参照や効果を名乗る receipt は受理しません。
• 意図と違う副作用の要求は送りません。意図より外への効果を増やす receipt、効果が不明（UNKNOWN）な receipt は受理しません。
• 別の要求の receipt（request_digest の偽り）は受理せず、受理できない receipt が来たら停止します（HALTED）。

しないこと・既知の限界

• 届く住所かの検証も、住んでいる証明もしません。住所の候補は、そのどちらでもありません。届く住所かの確認と本人の住所の証明は、外の判断と人・組織の役目です。
• 住所の正規化（表記ゆれの統一）の機能は含みません。この継手は住所の候補の照会の要求を運ぶ継手です。
• 住所の候補の正しさは確かめません。また、住所の文面の検出は空白の有無だけを見る網で、すべての文面を見分けるものではありません。守りの本体は、参照だけを運ぶ作りです。
• どの結果も承認ではありません（approval: false）。訳せた・見つかったは、公開の承認でも、届く住所の確認でも、正本でもありません。
• 実の翻訳・住所・参照データの基盤を含まず、一度も接続していません。port の実装と pin する一覧は、接続するときに別の関門で決めます。
• 契約を変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 特定の翻訳・地図・暦サービスの使い方の雛形ではありません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/localization/v1 でつなぎます。createLocalizationClient({ cfg, port }) の submit(request) に AddressLookupRequest を渡すと、DONE・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED のどれかを返します（どれも approval: false）。利用側が用意するもの: cfg（backends・locales・regions・datasets の pin する一覧）と、基盤への port（submit と、任意で lookup）。秘密は port 側が持ちます。副作用は NONE です（住所の照会）。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

SMS の裏で、宛先の番号の書き方のゆれ（空白・ハイフン・ドット・丸かっこ、国内の形と国際の形）を決まった形にそろえます。そのときに、表に無い国番号・地域を推し量ったり、内線やほかの国際の頭の番号を黙って外したりせず、決まったコードで止めます。

使う場面

• JP・NANP（US/CA）・GB の電話番号の文字列を、E.164 の文字列と、表の地域・国番号・NSN に分けて受け取りたいとき（normalize）。
• 国内の形（先頭が + でない）の番号を、default_region（JP・US・CA・GB）を渡して、国内の頭の番号（trunk）を外した E.164 にしたいとき。
• SMS の宛先の形の検めに合う文字列を作りたいとき。この部品の出力は、通知の継手の SMS の宛先の形の検め（/^\+[1-9][0-9]{6,14}$/）にいつも合います（作業場で 1 回突き合わせたもので、部品の試験には入れていません）。
• どの版の表で正規化したかを結果といっしょに残したいとき。どの結果にも metadata_revision が付きます。
• 例外を投げない呼び方が要るとき。normalize は例外を投げず、入力（options を含む）を書き換えず、options の getter を呼びません。

使わない場面

• 番号が存在する・使われている・つながる・誰かのものであることを確かめたいとき。この部品は確かめません（existence_verified はいつも false）。確かめるには別の手段（SMS の確認コードなど）が要ります。
• 番号計画の全体（割り当て済みの番号帯・市外局番の一覧・番号の種類）を検めたいとき。表の長さと頭の数字に合うだけの番号も受け取ります。
• JP・NANP・GB のほかの地域を扱うとき、US と CA を区別したいとき。region は表の見出し（NANP）で、回線のある国ではありません。
• 内線付きの番号、ほかの国際の頭の番号（00・010・011）で始まる番号、全角の数字、語呂合わせの英字を変換してほしいとき。v1 では受け取りません。
• 番号計画の改定を自動で追ってほしいとき。表の値は 2026-09-30 に作った保守的なものです。
• Node.js v24.21.0 のほかの版で使うとき。ほかの版は確かめていません（NOT_VERIFIED）。

検査すること

• text が文字列でないとき NOT_A_STRING、64 文字を超えるとき中身を読まずに INPUT_TOO_LONG で止めます。
• opts が素のオブジェクトでない、default_region のほかのキー・getter がある、調べること自体が例外になるとき（Proxy の罠など）INVALID_OPTIONS、default_region が JP・US・CA・GB のどれでもないとき UNKNOWN_REGION で止めます。
• 内線の印（#・;・, または x・ext・extension）があるとき EXTENSION_NOT_SUPPORTED、ASCII の英字があるとき LETTERS_NOT_ALLOWED で、黙って外さずに止めます。
• 受け取る文字のほかの文字があるとき（全角の数字・タブ・改行・ノーブレークスペース・先頭でない + ・2 つ目の + など）INVALID_CHARACTER、数字が 1 つも無いとき EMPTY_NUMBER で止めます。
• 国際の形で国番号が 1・44・81 のどれでもないとき UNSUPPORTED_COUNTRY_CODE、国内の形なのに default_region が無いとき MISSING_REGION で止め、推し量りません。
• 国内の形の頭がその地域の国際の頭の番号（JP の 010・00、GB の 00、NANP の 011）のとき INTERNATIONAL_PREFIX_NOT_SUPPORTED、JP・GB の国内の形の頭に 0 が無いとき MISSING_TRUNK_PREFIX で止めます。
• NSN の桁数が表の長さでないとき INVALID_LENGTH、決まった位置の数字が下限より小さいとき（国番号の後の trunk の 0、NANP の市外局番・局番の頭の 0・1）INVALID_NUMBER_PATTERN で止めます。
• 止めるときのエラーはいつも 1 つで、検める順番は決まっています（error_taxonomy の並びの順）。

しないこと・既知の限界

• 電話番号正規化（E.164）の部品は、宛先の文字列を決まった形にするだけです。SMS・通話への送り出しは含まず、それは通知の継手（D）の側です。
• 正規化できたことは、番号が存在する・つながる・誰かのものである・その人に連絡してよいことの証明ではありません（existence_verified はいつも false）。
• 文字は ASCII だけを見ます。全角の数字などを半角にする変換・Unicode の正規化はせず、丸かっこの対応・飾りの置き場所は検めません。
• 表は 3 地域に限った保守的なものです。地域を足すときは表の版を上げ、試験とオラクルを足して再検証する別の作業になります。
• 正規化できたことは、受け入れてよいことではありません（result_is_approval: false）。権限も作りません（derives_authority: false）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 特定の電話番号ライブラリ（libphonenumber など）の写しや使い方の雛形ではありません。

つなぎ方

src/phone.js の normalize(text, opts) を呼びます（投げません）。受け取るのは 64 文字までの文字列 text と、省略か { default_region } だけの opts（国内の形では必須）です。返すのは { ok: true, errors: [], e164, region, country_code, national_number, metadata_revision, existence_verified: false } か { ok: false, errors: [{ code }], e164: null, … }（code は error_taxonomy）。toE164 は受け取れなければ PhoneError を投げます。副作用（NONE）・状態・外の接続・資格情報は無く、利用側が用意するものはありません。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

参照データの基盤へ要求を運ぶとき、pin していない基盤・データセット・locale へ送ってしまうこと、そして取ってきた参照データを、正本の暦や法域の権威と取り違えることを防ぎます。

使う場面

• 祝日の暦などの参照データを、pin した基盤・データセットから取ってきたいとき。
• 参照データの locale（locale_ref）を、pin した一覧に限りたいとき。
• 外への効果の無い取得（副作用 NONE）として運びたいとき。
• 戻った receipt を、request_id・request_digest・参照の一致で照合してから受け取りたいとき。DONE の result には data_state・data_ref・authoritative_status・jurisdiction_authority が添えられます。
• 基盤の障害で結果が不明（UNKNOWN）になっても、同じ request_id を二度送らず、lookup で解きたいとき。

使わない場面

• 和暦への変換や営業日の計算など、日付の計算をさせたいとき。この継手は参照データを取ってくる要求を運ぶ継手で、日付の計算の機能は含みません。
• 取ってきた参照データを、正本の暦や法域の権威として扱いたいとき。そう名乗る receipt は受理しません。
• 時刻の変換など、手元の計算で済む地域対応をしたいとき。この継手の対象ではありません。
• 参照データの正しさを確かめたいとき。正本の暦の判断は、外の判断と人・組織の役目です。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。
• すぐに使える基盤がほしいとき。実の翻訳・住所・参照データの基盤は含みません。

検査すること

• pin していない基盤・locale・データセットへの要求は送りません。設定の一覧が空のとき、空の項目があるときも送りません（空の一覧は何も許しません）。
• 参照が空のもの・パスや .. を含むもの、追加のフィールド、決まった値（const）と違う値の要求は送りません。
• 正本の参照データ（authoritative）や法域の権威（jurisdiction authority）を名乗る receipt は受理しません。
• できなかった（FAILED・UNAVAILABLE・NOT_FOUND）のに、出力の参照（data_ref）や効果を名乗る receipt は受理しません。
• 意図と違う副作用の要求は送りません。意図より外への効果を増やす receipt、効果が不明（UNKNOWN）な receipt は受理しません。
• 別の要求の receipt（request_digest の偽り）は受理せず、受理できない receipt が来たら停止します（HALTED）。

しないこと・既知の限界

• 日付の計算（和暦・営業日）はしません。この継手は参照データを取ってくる要求を運ぶ継手で、日付の計算の機能は含みません。
• 参照データは、正本の暦でも法域の権威でもありません。ERABAZU は法域の権威を名乗りません。正本の暦の判断は、外の判断と人・組織の役目です。
• 参照データの正しさは確かめません。
• どの結果も承認ではありません（approval: false）。訳せた・見つかったは、公開の承認でも、届く住所の確認でも、正本でもありません。
• 実の翻訳・住所・参照データの基盤を含まず、一度も接続していません。port の実装と pin する一覧は、接続するときに別の関門で決めます。
• 契約を変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 特定の翻訳・地図・暦サービスの使い方の雛形ではありません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/localization/v1 でつなぎます。createLocalizationClient({ cfg, port }) の submit(request) に ReferenceDataRequest を渡すと、DONE・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED のどれかを返します（どれも approval: false）。利用側が用意するもの: cfg（backends・locales・regions・datasets の pin する一覧）と、基盤への port（submit と、任意で lookup）。秘密は port 側が持ちます。副作用は NONE です（参照データ）。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

一覧の裏で、並び順が実行環境の既定の locale に黙って落ちて変わってしまうこと、照合で同じ文字列を同一とみなしてしまうこと、照合で同じ文字列どうしの順が定まらないことを防ぎます。結果に ICU の版を添えるので、どの版の順かを後から確かめられます。

使う場面

• 文字列の配列を ja か en の照合順序で並べ、結果と ICU の版を受け取りたいとき（sortList。例外を投げません）。
• 照合で同じ文字列どうしを元の位置の順に残したいとき（sortStable）、または UTF-16 の符号単位の順で決めて全順序にしたいとき（sortTotal）。
• 2 つの文字列を比べて -1・0・1 のどれかを受け取りたいとき（compare。反対称で -0 を返しません）。
• 実行環境の既定の locale に依らず、明示した locale だけで並べたいとき。Collator の解決が頼んだとおりでなければ止めます。
• 入力を書き換えずに並べたいとき。すでに並んでいても新しい配列を返し、要素の getter を呼びません。

使わない場面

• ICU の版にかかわらず同じ順が要るとき。順は実行環境の ICU（78.3）に依り、版が変われば同じ入力でも順が変わりえます。ほかの版では確かめていません（icu.matches_pin が false になります）。
• 重複の判定や鍵に使いたいとき。照合で同じことは同一ではありません（例: ja の variant で「あ」と「ア」）。
• 漢字の読み（音読み・訓読み）の順で並べたいとき。ja の漢字の順は ICU の ja の規則（JIS の順）です。読みの順で並べるときは、使う側が読みを渡して並べます。
• ja と en のほかの locale（ja-JP・EN・und を含む）を使いたいとき。UNSUPPORTED_LOCALE で止めます。
• 数の照合（"10" と "2" を数として比べる）が要るとき。この部品はしません。
• Node.js v24.21.0（ICU 78.3）のほかの版で使うとき。ほかの版は確かめていません（NOT_VERIFIED）。

検査すること

• opts が素のオブジェクトでない、キーが locale・strength（sortList は order も）ちょうどでない、order が stable・total のどちらでもないとき、INVALID_OPTIONS で止めます。
• locale が ja・en のどちらでもないとき UNSUPPORTED_LOCALE、strength が base・accent・variant のどれでもないとき UNSUPPORTED_STRENGTH で止めます。
• Intl.Collator が頼んだ locale と固定の設定のとおりに解決されないとき（ICU にその locale が無いなど）、ほかの locale に黙って落ちずに LOCALE_NOT_AVAILABLE で止めます。
• 比べる値・要素が文字列でないとき（String オブジェクト・穴・getter の要素を含む）NOT_A_STRING、65,536 符号単位を超えるとき STRING_TOO_LONG で止め、要素なら index に位置を返します。
• list が配列でないとき（配列のようなオブジェクト・Set を含む）NOT_AN_ARRAY、100,000 要素を超えるとき LIST_TOO_LONG で止めます。
• sortList で値を調べること自体が例外になるとき（Proxy の罠など）、INSPECTION_FAILED を返し、例外を投げません。

しないこと・既知の限界

• 照合順序を自分では持ちません。照合順序は ICU（78.3）のもので、独立には作り直していません。ファズのオラクルも同じ ICU の Collator を使うので、ICU の順が正しいかは確かめていません（確かめたのは並べ替えの性質・安定性・同点の決め方・止めるコードと、ja・en の既知の答え数組）。
• 並び順が使う人の期待（辞書・電話帳・読みの順など）と同じとは限りません。どの順で見せるかの判断は使う側に残ります。
• sortTotal の符号単位の比べで、Unicode の正規化はしません。
• Proxy の罠を INSPECTION_FAILED に変えるのは sortList だけです。投げる関数（compare・sameKey・sortStable・sortTotal）は罠の例外をそのまま外に出します。
• 並べられたことは、その順が正しいことでも、受け入れてよいことでもありません（result_is_approval: false）。権限も作りません（derives_authority: false）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 特定の並べ替えのライブラリの使い方の雛形ではありません。

つなぎ方

src/collation.js の sortList(list, { locale, strength, order }) を呼びます（投げません）。受け取るのは 100,000 要素までの文字列の配列と、3 つのキーだけの素のオブジェクトです。返すのは { ok: true, errors: [], sorted, icu, … } か { ok: false, errors: [{ code, index? }], icu }（code は error_taxonomy）。compare・sameKey・sortStable・sortTotal は受け取れない値で CollationError を投げます。副作用（NONE）・外の接続・資格情報は無く、利用側が用意するものはありません。状態は Collator の覚え置き（プロセスの中だけ）で、答えに影響しません。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

呼の合図を通信基盤へ運ぶとき、参加者の参照にメールアドレスや電話番号を置いてしまうこと、合図の op と合わない呼の状態を受け取ってしまうこと、そしてつながったことを参加者の同意や本人の確認と取り違えることを防ぎます。

使う場面

• ビデオ通話の発信（INITIATE）・応答（ANSWER）・終了（END）の合図を、通信基盤へ運びたいとき。
• 戻った呼の状態が合図の op に対応しているか（INITIATE→RINGING・CONNECTED、ANSWER→CONNECTED、END→ENDED。どれも FAILED は可）を照合したいとき。
• 戻った receipt を、request_id・request_digest・参照と op の一致で照合してから受け取りたいとき。DONE の result には op・call_state・consent・identity_verification が添えられます。
• 通信基盤の障害で結果が不明（UNKNOWN）になっても、同じ request_id を二度送らず、lookup で解きたいとき。

使わない場面

• 映像・音声そのもの（WebRTC・SFU のメディア）を運びたいとき。この継手は呼の合図を運ぶ継手で、映像・音声を運ぶ機能は含みません。
• 映像・音声の品質・遅延・暗号化を確かめたいとき。この部品の対象外で、確かめていません。
• つながったことを、参加者の同意や本人の確認として扱いたいとき。そう名乗る receipt は受理しません。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。
• すぐに使える通信基盤がほしいとき。実の通信基盤は含みません。

検査すること

• 参照が空のもの・パスや .. を含むもの、追加のフィールド、決まった値（const）と違う値、契約に無い op の要求は送りません。
• 参加者・本人の参照にメールアドレス・電話番号の形があれば送りません（検出はその代表的な形だけです）。
• 合図の op と合わない呼の状態の receipt は受理しません。
• 同意（consent）や本人の確認（identity verification）を名乗る receipt は受理しません。
• 意図と違う副作用の要求は送りません。失敗（FAILED）なのに効果を名乗る receipt、意図より外への効果を増やす receipt、効果が不明（UNKNOWN）な receipt は受理しません。
• 別の要求の receipt（request_digest の偽り）は受理せず、受理できない receipt が来たら停止します（HALTED）。

しないこと・既知の限界

• 映像・音声そのもの（WebRTC・SFU のメディア）は運びません。ビデオ通話の項目で運ぶのは、呼の合図（発信・応答・終了）だけです。
• 映像・音声の品質・遅延・暗号化は、この部品の対象外で、確かめていません。
• つながったは、参加者の同意でも本人の確認でもありません。本人の確認と同意は、外の判断と人・組織の役目です。
• どの結果も承認ではありません（approval: false）。届いた・読まれた・つながったは、本人の確認でも同意でも権限でもありません。
• 実の通信基盤（WebRTC・SFU・SIP・プレゼンス・メッセージのサービス）を含まず、一度も接続していません。port の実装と pin する一覧は、接続するときに別の関門で決めます。
• 契約を変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 特定の通話・チャットサービスの使い方の雛形ではありません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/communication/v1 でつなぎます。createCommunicationClient({ cfg, port }) の submit(request) に CallSignalRequest（op は INITIATE・ANSWER・END）を渡すと、DONE・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED のどれかを返します（どれも approval: false）。利用側が用意するもの: cfg（channel_refs・presence_subjects）と、通信基盤への port（submit と、任意で lookup）。秘密は port 側が持ちます。副作用は EXTERNAL_REVERSIBLE（FAILED は NONE）。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

呼の合図を通信基盤へ運ぶとき、参加者の参照にメールアドレスや電話番号を置いてしまうこと、合図の op と合わない呼の状態を受け取ってしまうこと、そしてつながったことを参加者の同意や本人の確認と取り違えることを防ぎます。

使う場面

• 音声通話の発信（INITIATE）・応答（ANSWER）・終了（END）の合図を、通信基盤へ運びたいとき。
• 戻った呼の状態が合図の op に対応しているか（INITIATE→RINGING・CONNECTED、ANSWER→CONNECTED、END→ENDED。どれも FAILED は可）を照合したいとき。
• 戻った receipt を、request_id・request_digest・参照と op の一致で照合してから受け取りたいとき。DONE の result には op・call_state・consent・identity_verification が添えられます。
• 通信基盤の障害で結果が不明（UNKNOWN）になっても、同じ request_id を二度送らず、lookup で解きたいとき。

使わない場面

• 音声そのもの（SIP のメディア）を運びたいとき。この継手は呼の合図を運ぶ継手で、音声を運ぶ機能は含みません。
• 音声の品質・遅延・暗号化を確かめたいとき。この部品の対象外で、確かめていません。
• つながったことを、参加者の同意や本人の確認として扱いたいとき。そう名乗る receipt は受理しません。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。
• すぐに使える通信基盤がほしいとき。実の通信基盤は含みません。

検査すること

• 参照が空のもの・パスや .. を含むもの、追加のフィールド、決まった値（const）と違う値、契約に無い op の要求は送りません。
• 参加者・本人の参照にメールアドレス・電話番号の形があれば送りません（検出はその代表的な形だけです）。
• 合図の op と合わない呼の状態の receipt は受理しません。
• 同意（consent）や本人の確認（identity verification）を名乗る receipt は受理しません。
• 意図と違う副作用の要求は送りません。失敗（FAILED）なのに効果を名乗る receipt、意図より外への効果を増やす receipt、効果が不明（UNKNOWN）な receipt は受理しません。
• 別の要求の receipt（request_digest の偽り）は受理せず、受理できない receipt が来たら停止します（HALTED）。

しないこと・既知の限界

• 音声そのもの（SIP のメディア）は運びません。音声通話の項目で運ぶのは、呼の合図（発信・応答・終了）だけです。
• 音声の品質・遅延・暗号化は、この部品の対象外で、確かめていません。
• つながったは、参加者の同意でも本人の確認でもありません。本人の確認と同意は、外の判断と人・組織の役目です。
• どの結果も承認ではありません（approval: false）。届いた・読まれた・つながったは、本人の確認でも同意でも権限でもありません。
• 実の通信基盤（WebRTC・SFU・SIP・プレゼンス・メッセージのサービス）を含まず、一度も接続していません。port の実装と pin する一覧は、接続するときに別の関門で決めます。
• 契約を変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 特定の通話・チャットサービスの使い方の雛形ではありません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/communication/v1 でつなぎます。createCommunicationClient({ cfg, port }) の submit(request) に CallSignalRequest（op は INITIATE・ANSWER・END）を渡すと、DONE・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED のどれかを返します（どれも approval: false）。利用側が用意するもの: cfg（channel_refs・presence_subjects）と、通信基盤への port（submit と、任意で lookup）。秘密は port 側が持ちます。副作用は EXTERNAL_REVERSIBLE（FAILED は NONE）。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

プレゼンスを通信基盤へ出すとき、出してよいと決めていない本人のプレゼンスを出してしまうこと、本人の参照にメールアドレスや電話番号を置いてしまうこと、そして「オンライン」を人がいることと取り違えることを防ぎます。

使う場面

• 在席・状態（プレゼンス）の公開を、pin した本人の参照（仮名）に限って通信基盤へ運びたいとき。
• 戻った receipt を、request_id・request_digest・参照の一致で照合してから受け取りたいとき。DONE の result には publish_state・human_availability が添えられます。
• プレゼンスの公開を、取り消せる外への効果（EXTERNAL_REVERSIBLE）として扱いたいとき。
• 通信基盤の障害で結果が不明（UNKNOWN）になっても、同じ request_id を二度送らず、lookup で解きたいとき。

使わない場面

• 「オンライン」を、人がそこにいることの確認として使いたいとき。そう名乗る receipt は受理しません。
• 出してよいと決めていない本人のプレゼンスを出したいとき。pin していない本人のプレゼンスは出しません。
• 本人の参照にメールアドレスや電話番号をそのまま使いたいとき。その要求は送りません。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。
• すぐに使える通信基盤がほしいとき。実の通信基盤は含みません。

検査すること

• pin していない本人のプレゼンスは出しません。設定の一覧が空のとき、空の項目があるときも送りません（空の一覧は何も許しません）。
• 参照が空のもの・パスや .. を含むもの、追加のフィールド、決まった値（const）と違う値、契約に無い op の要求は送りません。
• 本人の参照にメールアドレス・電話番号の形があれば送りません（検出はその代表的な形だけです）。
• 人がいること（human availability）を名乗る receipt は受理しません。
• 意図と違う副作用の要求は送りません。失敗（FAILED）なのに効果を名乗る receipt、意図より外への効果を増やす receipt、効果が不明（UNKNOWN）な receipt は受理しません。
• 別の要求の receipt（request_digest の偽り）は受理せず、受理できない receipt が来たら停止します（HALTED）。

しないこと・既知の限界

• 「オンライン」を出しても、人がいるとは限りません。人がいることは確かめません。
• プレゼンスを出してよい本人を決めません。どの本人を出すかは、利用側が pin する一覧（presence_subjects）で決めます。
• どの結果も承認ではありません（approval: false）。届いた・読まれた・つながったは、本人の確認でも同意でも権限でもありません。
• 実の通信基盤（WebRTC・SFU・SIP・プレゼンス・メッセージのサービス）を含まず、一度も接続していません。port の実装と pin する一覧は、接続するときに別の関門で決めます。
• 契約を変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 特定の通話・チャットサービスの使い方の雛形ではありません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/communication/v1 でつなぎます。createCommunicationClient({ cfg, port }) の submit(request) に PresencePublishRequest を渡すと、DONE・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED のどれかを返します（どれも approval: false）。利用側が用意するもの: cfg（channel_refs・presence_subjects）と、通信基盤への port（submit と、任意で lookup）。秘密は port 側が持ちます。副作用は EXTERNAL_REVERSIBLE（FAILED は NONE）。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

字幕の区切りを通信基盤へ運ぶとき、本文を digest の欄に置いて送ってしまうこと、pin していないチャンネルへ送ってしまうこと、そして届いた・読まれたを、本人の確認や理解・権限と取り違えることを防ぎます。

使う場面

• ライブ字幕の区切りを、本文ではなく digest（payload_digest）で、pin したチャンネルへ運びたいとき。
• 戻った receipt を、request_id・request_digest・参照と op の一致で照合してから受け取りたいとき。DONE の result には delivery_state・delivered・identity_verification・comprehension・authority_assertion が添えられます。
• 受け手の参照にメールアドレス・電話番号の形を置かずに運びたいとき。
• 通信基盤の障害で結果が不明（UNKNOWN）になっても、同じ request_id を二度送らず、lookup で解きたいとき。

使わない場面

• 字幕の本文そのものを運びたいとき。この継手は字幕の区切りを digest で運ぶ継手で、本文は運びません。本文を payload_digest に置いた要求は送りません。
• 字幕の正しさを確かめたいとき。字幕の正しさは確かめず、外の判断と人・組織の役目です。
• 字幕の品質・遅延・暗号化を確かめたいとき。この部品の対象外で、確かめていません。
• 届いた・読まれたを、本人の確認や理解・権限として扱いたいとき。そう名乗る receipt は受理しません。
• 届いたメッセージを取り消したいとき。メッセージの副作用は取り消せない外への効果（EXTERNAL_IRREVERSIBLE）です。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。
• すぐに使える通信基盤がほしいとき。実の通信基盤は含みません。

検査すること

• pin していないチャンネルへの要求は送りません。設定の一覧が空のとき、空の項目があるときも送りません（空の一覧は何も許しません）。
• 本文を payload_digest に置いた要求、形の崩れた digest の要求は送りません。
• 参照が空のもの・パスや .. を含むもの、追加のフィールド、決まった値（const）と違う値、契約に無い op の要求は送りません。
• 受け手の参照にメールアドレス・電話番号の形があれば送りません（検出はその代表的な形だけです）。
• 本人の確認（identity verification）・理解（comprehension）・権限（authority）を名乗る receipt は受理しません。
• 意図と違う副作用の要求は送りません。失敗（FAILED）なのに効果を名乗る receipt、意図より外への効果を増やす receipt、効果が不明（UNKNOWN）な receipt は受理しません。
• 別の要求の receipt（request_digest の偽り）は受理せず、受理できない receipt が来たら停止します（HALTED）。

しないこと・既知の限界

• 字幕の本文は運びません。運ぶのは字幕の区切りの digest だけです。字幕の本体の運搬・品質・遅延・暗号化は、この部品の対象外で、確かめていません。
• 字幕の正しさ、届いたメッセージの中身は確かめません。
• 届いた・読まれたは、本人の確認でも理解・同意でも権限でもありません。
• どの結果も承認ではありません（approval: false）。届いた・読まれた・つながったは、本人の確認でも同意でも権限でもありません。
• 実の通信基盤（WebRTC・SFU・SIP・プレゼンス・メッセージのサービス）を含まず、一度も接続していません。port の実装と pin する一覧は、接続するときに別の関門で決めます。
• 契約を変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 特定の通話・チャットサービスの使い方の雛形ではありません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/communication/v1 でつなぎます。createCommunicationClient({ cfg, port }) の submit(request) に RealtimeMessageRequest を渡すと、DONE・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED のどれかを返します（どれも approval: false）。利用側が用意するもの: cfg（channel_refs・presence_subjects）と、通信基盤への port（submit と、任意で lookup）。秘密は port 側が持ちます。副作用は EXTERNAL_IRREVERSIBLE（FAILED は NONE）。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

巨大なファイルを区切って送るとき、途中の障害で結果が分からない区切りを二重に積んだり、欠けや違う中身のまま「送れた」と扱ったりすることを防ぎます。区切りの長さと sha256 は送る前に自分で確かめ、全体の sha256 は受け取られた区切りだけで積み上げます。

使う場面

• 1 回で送れない大きさのファイルを、区切って保管先へ送りたいとき。
• 転送が途中で止まったとき、再開位置（committed_offset）を問い合わせて続きから送りたいとき。
• 全部そろった中身の sha256 が始めの payload_digest と同じことを確かめてから、確定したいとき。
• 結果の分からない区切りを、二重に積まずに解きたいとき。再開位置の問い合わせか、同じ要求の再送（lookup でも解けます）で解きます。
• 状態の食い違う receipt が出たら、人が確かめるまで転送を止めたいとき。

使わない場面

• 区切りを並列に送ったり、順不同で受け取ったりしたいとき。契約 v1 の範囲外で、この継手は送りません。
• 1 回で送れる大きさの保管だけが要るとき。それはオブジェクト保管（C-01）の継手です。
• 確定を、中身が正しい・受け入れてよいという判断として扱いたいとき。確定は中身の受け入れではありません（content_acceptance は NOT_DERIVED）。
• 別のプロセスからの再開や、再起動をまたぐ再開をしたいとき。転送の状態はこの継手の中だけにあり、再起動で消えます。
• すぐに使える保管先がほしいとき。実の保管の基盤には一度も接続しておらず、実の転送は 0 回です。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。

検査すること

• 区切りの順番を検めます。committed_offset から順番どおりでない区切り（飛ばした offset、戻った offset、全体の大きさを超える区切り）、最後のほか chunk_size でない区切りは送らず、基盤へも送りません。
• 区切りの中身を検めます。中身の長さまたは sha256 が宣言と違う区切りは送りません。送る前に自分で確かめます。
• 確定を検めます。全部の区切りがそろう前の確定と、始めの payload_digest と違う sha256 での確定は送りません。COMPLETED は MATCH の証拠と stored_digest がないと受け取りません。
• 設定の範囲を検めます。許していない content-type、上限を超える全体の大きさ・区切りの大きさ、allow_worm が true でないときの WORM（取り消せない確定）は送りません。
• 転送の状態を検めます。未解決の区切りがあるうちの別の送信、期限切れ・閉じた・確定した・中止した転送への送信は送りません。中止の後は再開できません。
• receipt を照合します。状態の食い違うもの、外への効果を増やすもの、別の要求の request_digest を名乗るもの、受け入れを名乗る完了は受理せず、受理できない receipt で停止します（HALTED）。
• 基盤の障害を検めます。障害で結果が分からなくなった区切りは UNKNOWN とし、再開位置の問い合わせの答えが合わなければ受理しません。何が残ったか分からない効果は受け取りません。

しないこと・既知の限界

• 巨大ファイルそのものの保管はしません。この継手は、保管の基盤へ区切りを運び、返る receipt を照合するだけです。実の保管の基盤には一度も接続しておらず、実の転送は 0 回です。
• 並列の分割も、順不同の受け取りもしません。契約 v1 の範囲外で、区切りは committed_offset から順番どおりだけです。
• 中身そのものの検査はしません。確認・受け入れ・保持の判断は、外の判断と人・組織の役目です。確定は中身の受け入れではありません（content_acceptance は NOT_DERIVED）。
• 転送の状態を永続化しません。状態はこの継手の中だけで、再起動で消えます。別のプロセスからの再開もしません。
• 期限（expires_at）は形だけを検めます。期限切れは基盤の答えから知ります。
• どの結果も承認ではありません（approval: false）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 特定のクラウド保管サービスの分割アップロードの使い方の雛形ではありません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/object-store-resumable/v1でつなぎます。createResumableClient({ cfg, port }) の submit(request, bytes) に TransferStart・ChunkSend・ResumeQuery・TransferComplete・TransferAbort を渡すと、DONE・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED のどれかを返します（どれにも approval: false）。bytes は ChunkSend だけ。用意するもの: 基盤への port（submit、任意で lookup）。副作用は WORM の確定と中止が EXTERNAL_IRREVERSIBLE。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

呼の合図を通信基盤へ運ぶとき、参加者の参照にメールアドレスや電話番号を置いてしまうこと、合図の op と合わない呼の状態を受け取ってしまうこと、そしてつながったことを参加者の同意や本人の確認と取り違えることを防ぎます。

使う場面

• 画面共有の発信（INITIATE）・応答（ANSWER）・終了（END）の合図を、通信基盤へ運びたいとき。
• 戻った呼の状態が合図の op に対応しているか（INITIATE→RINGING・CONNECTED、ANSWER→CONNECTED、END→ENDED。どれも FAILED は可）を照合したいとき。
• 戻った receipt を、request_id・request_digest・参照と op の一致で照合してから受け取りたいとき。DONE の result には op・call_state・consent・identity_verification が添えられます。
• 通信基盤の障害で結果が不明（UNKNOWN）になっても、同じ request_id を二度送らず、lookup で解きたいとき。

使わない場面

• 画面そのもの（画面共有のメディア）を運びたいとき。この継手は呼の合図を運ぶ継手で、画面を運ぶ機能は含みません。
• 画面の品質・遅延・暗号化を確かめたいとき。この部品の対象外で、確かめていません。
• つながったことを、参加者の同意や本人の確認として扱いたいとき。そう名乗る receipt は受理しません。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。
• すぐに使える通信基盤がほしいとき。実の通信基盤は含みません。

検査すること

• 参照が空のもの・パスや .. を含むもの、追加のフィールド、決まった値（const）と違う値、契約に無い op の要求は送りません。
• 参加者・本人の参照にメールアドレス・電話番号の形があれば送りません（検出はその代表的な形だけです）。
• 合図の op と合わない呼の状態の receipt は受理しません。
• 同意（consent）や本人の確認（identity verification）を名乗る receipt は受理しません。
• 意図と違う副作用の要求は送りません。失敗（FAILED）なのに効果を名乗る receipt、意図より外への効果を増やす receipt、効果が不明（UNKNOWN）な receipt は受理しません。
• 別の要求の receipt（request_digest の偽り）は受理せず、受理できない receipt が来たら停止します（HALTED）。

しないこと・既知の限界

• 画面そのもの（画面共有のメディア）は運びません。画面共有の項目で運ぶのは、呼の合図（発信・応答・終了）だけです。
• 画面の品質・遅延・暗号化は、この部品の対象外で、確かめていません。
• つながったは、参加者の同意でも本人の確認でもありません。本人の確認と同意は、外の判断と人・組織の役目です。
• どの結果も承認ではありません（approval: false）。届いた・読まれた・つながったは、本人の確認でも同意でも権限でもありません。
• 実の通信基盤（WebRTC・SFU・SIP・プレゼンス・メッセージのサービス）を含まず、一度も接続していません。port の実装と pin する一覧は、接続するときに別の関門で決めます。
• 契約を変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 特定の通話・チャットサービスの使い方の雛形ではありません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/communication/v1 でつなぎます。createCommunicationClient({ cfg, port }) の submit(request) に CallSignalRequest（op は INITIATE・ANSWER・END）を渡すと、DONE・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED のどれかを返します（どれも approval: false）。利用側が用意するもの: cfg（channel_refs・presence_subjects）と、通信基盤への port（submit と、任意で lookup）。秘密は port 側が持ちます。副作用は EXTERNAL_REVERSIBLE（FAILED は NONE）。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

相手の所在を外の登録の基盤に頼るとき、期限の過ぎた lease を登録済みと扱うこと、古い instance を健全なまま返すこと、そして「載っている」ことを正しさ・許可・身元と取り違えることを防ぎます。lease の期限と照会の古さは、注入した時計で確かめます。

使う場面

• マイクロサービスの instance を、外の登録の基盤に lease つきで登録し、HEARTBEAT で延ばし、不要になったら取り消したいとき。
• 相手の所在を照会し、古い instance も隠さずに、stale: true と effective_health: STALE の印つきで受け取りたいとき。
• 使ってよい registry・service・登録してよい endpoint・ttl の上限を設定で決め、その外へは送りたくないとき。
• lease の期限や照会の古さを、登録の基盤の言い分ではなく、注入した時計で確かめたいとき。

使わない場面

• 手元だけの静的な名前解決がほしいとき。この継手は外の登録の基盤へ運ぶ継手で、手元の名前解決は別の Primitive の範囲です。
• 照会で得た endpoint を、そのまま本物・健全・呼んでよい相手として使いたいとき。この継手は確かめません（endpoint_identity は NOT_VERIFIED、correctness・authority は NOT_DERIVED）。
• lease の状態を再起動の後も持ち越したいとき。状態はこの継手の中だけで、再起動の後は前に登録した instance の HEARTBEAT・DEREGISTER を送りません。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。
• すぐに使える登録の基盤への接続がほしいとき。実の登録の基盤には一度も接続しておらず、port の実装・資格情報・設定の値は接続するときに別の関門で決めます。

検査すること

• 設定を検めます。設定が無い、一覧に無い registry・service・endpoint、register_endpoints・max_ttl_seconds の無い REGISTER、stale_after_seconds の無い QUERY は送りません。
• ttl を検めます。整数でない ttl、設定の上限を超える ttl、86400 を超える ttl・上限の設定は送りません。
• 時計を検めます。時計が無い・壊れていれば何も送らず、receipt も受け取りません。
• lease の扱いを検めます。まだ有効な lease がある instance への REGISTER、lease の無い・期限の過ぎた lease への HEARTBEAT、この継手が登録していない instance の DEREGISTER は送りません。
• 参照と要求の形を検めます。.. や絶対パス・ドライブ・制御文字を含む参照、Ref でない request_id、形の悪い service_name、未知の op、op が使わない欄は送りません。
• receipt を照合します。request_digest の偽り、request_id・registry・service_name・op の食い違い、表の外の状態、効果を増やす・不明な効果は受理せず、停止します（HALTED）。
• lease と照会の中身を照合します。依頼した ttl より長い lease、時刻の形でない lease、未来の last_seen_at、同じ instance が二度載った照会、要求の前や今より後の観測時刻の receipt は受け取りません。
• receipt が正しさや許可を導いていたら（correctness・authority が NOT_DERIVED でない）受理しません。

しないこと・既知の限界

• 載っている endpoint が本物か（身元・証明書）、正しい・健全・呼んでよいかは確かめません。observed_health は登録の基盤の観測をそのまま運ぶだけです。身元の確かめは、たとえば B-09 の証明書と呼ぶ側の信頼の方針の役目です。
• 登録・照会できたことは承認ではありません（approval: false）。呼んでよいかの判断は、外の判断と人・組織の役目です。
• instance の lease_expires_at の長さが妥当かは確かめません（契約に基準がありません）。遠い先の lease を返す基盤では、古い instance が古いと出ないことがあります。他人の instance の DEREGISTER はしません。
• 時計そのものの正しさと、登録の基盤の時計との実際のずれは確かめません。
• lookup の無い port で、結果不明の送信がもう検めを通らないときは、未解決のまま止まります。効果が UNKNOWN の FAILED も受け取らず停止し、登録が残ったかは人が確かめます。
• 登録の基盤の認証に使う資格情報は持ちません。資格情報は port 側が持ちます（HELD_BY_PORT）。契約も変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 特定の登録の基盤（サービスメッシュ・クラウドの名前解決など）の使い方の雛形ではありません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/service-registry/v1 でつなぎます。createServiceRegistryClient({ cfg, port, clock }) の submit(request) に RegistryRequest を渡すと、DONE（result に op ごとの事実。QUERY では instances・endpoint_identity）・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED を返します（どれも approval: false）。利用側が用意するもの: 登録の基盤への port（submit、任意で lookup）と時計 clock。副作用: QUERY は NONE、ほかの 3 つは EXTERNAL_REVERSIBLE。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

認証や流量の集約点であるゲートウェイの裏で、検めを通っていない表や、検めた digest と違う表を反映してしまうこと、人・組織の根拠の無い変更や別の変更への承認で反映してしまうこと、結果の分からない変更を別の要求で送り直してしまうことを防ぎます。

使う場面

• 経路の表を手元で検め（形・参照・衝突・隠れた経路）、検めが通った表だけをゲートウェイへ APPLY したいとき。checkRoutes に route-config の check、gateway に gateway-config の継手のクライアントを注入します。
• 変更を 2 段に分けたいとき。prepareApply・prepareRollback は何も送らずに、承認する対象（gateway_ref・op・base_version_ref・config_digest または rollback_to_version_ref）とその digest を返し、apply・rollback はその digest を含む人・組織の根拠（origin: HUMAN か ORGANIZATION、evidence_ref、subject_digest）を受け取ります。
• APPLY に、手元の検めの出力から継手が作った証跡（validation_evidence）を載せ、続けて人・組織の根拠を継手へ渡してから送りたいとき。
• 前の版へ戻す（rollback）ときも、人・組織の根拠を継手へ渡してから送りたいとき。
• 今の版を効果なしで観測し（observe、STATUS）、rollout_of_request_id を渡したときは、その反映が終わったかを継手の結果のまま受け取りたいとき。observe は保留中でも送れます。
• 結果の分からない変更を保留にし、resolvePending で同じ要求でだけ送り直したいとき。base_version_ref が二重の変更を防ぎます。

使わない場面

• 反映できたこと（APPLIED）を、流れが正しいことや変更の承認として使いたいとき。どの結果にも approval: false・authority: NOT_DERIVED・traffic_correctness: NOT_DERIVED が付きます。
• 人・組織の根拠なしに経路を変えたいとき。経路の変更（APPLY・ROLLBACK）には人・組織の根拠が要り、この部品は根拠を作らず、呼び出し側から受け取ります。
• 根拠の中身（誰が・いつまで）をこの部品に確かめさせたいとき。この部品は、対象の digest が合うことだけを確かめて継手へ渡します。
• リクエストの振り分け（入口の交通整理）そのものを行う部品が要るとき。この部品は経路の表を検め、振り分けを変える反映を束ねた継手に送らせるだけです。
• ゲートウェイが検めと同じ規則で表を読むこと、同じ digest を計算することを当てにしたいとき。どちらも確かめません（route-config の限界のまま）。
• 本物のゲートウェイで確かめた部品が要るとき。本物のゲートウェイ・制御面には一度も接続していません。
• 再起動をまたいで保留の変更を続けたいとき。状態はこのプロセスの中だけで、再起動で保留の要求は消えます。
• Node.js v24.21.0 のほかの版で使うとき。ほかの版は確かめていません（NOT_VERIFIED）。

検査すること

• options が足りない・形が違う・参照が不正・port の関数が無いとき INVALID_OPTIONS、入力の形が違うとき INVALID_INPUT、入力や port の結果の getter が例外を投げたとき INSPECTION_FAILED で止めます。
• 手元の検めが表を断ったとき ROUTES_REFUSED（route_errors を添える）、検めの結果の config_digest の形が違うとき（domain・algorithm・64 桁の 16 進・target）CHECK_RESULT_INVALID、検めの関数が投げたとき PORT_FAILED で、APPLY を送りません。
• 根拠が無い・欄の過不足・出どころが HUMAN か ORGANIZATION でない・参照が不正・subject_digest が 64 桁の 16 進でないとき NO_AUTHORITY_EVIDENCE、根拠の subject_digest がその場で計算し直した対象の digest と違うとき（別の変更の承認）AUTHORITY_SUBJECT_MISMATCH で、APPLY・ROLLBACK を送りません。
• 継手が検めの証跡を返さないとき EVIDENCE_REFUSED、根拠の記録に true ちょうどを返さないとき AUTHORITY_REFUSED で、送りません。
• 継手の結果が分からないとき（UNKNOWN・例外）、変更を GATEWAY_UNKNOWN で保留にし、保留の間は resolvePending と observe のほかを CHANGE_PENDING で止めます。保留が無いのに resolvePending を呼ぶと NOTHING_PENDING です。
• 継手が送らなかったとき GATEWAY_REFUSED（gateway_errors を添える）、receipt を照合できず停止したとき GATEWAY_HALTED で、状態を変えずに伝え、保留も残しません。
• applied は継手の結果が applied: true のときだけ、rollout_completed は継手の結果が true ちょうどのときだけ true にします。observe（STATUS）は効果なし（intended_side_effect NONE）で送ります。
• timestamp が date-time の文字列を返さない・投げたとき CLOCK_FAILED、前の操作が終わっていないとき BUSY で止めます（同時に 1 つの操作だけ）。

しないこと・既知の限界

• API ゲートウェイ・ルーティングの部品は継手ではありません。自分の Request/Receipt は無く、振り分けを変えるという外への効果は、束ねた gateway-config の継手が自分の契約（gateway-config/v1）で起こします。この部品自身は外へ触れません。
• 束ねた部品の意味（検めが通った ≠ 流れが正しい、反映できた ≠ 承認）は、それぞれの部品の側に残ります。
• 反映できたことは、流れが正しいことでも変更の承認でもありません（approval: false・authority: NOT_DERIVED・traffic_correctness: NOT_DERIVED、derives_authority: false）。
• 人・組織の根拠を作りません。経路の変更の根拠は呼び出し側から受け取り、根拠の中身（誰が・いつまで）は確かめません。
• ACCEPTED・APPLYING・PARTIAL の後に反映が終わったかは、observe に rollout_of_request_id を渡して継手の結果のまま返すだけで、この部品は判定しません。
• 本物のゲートウェイ・制御面には一度も接続していません。単体試験とファズは代役で、本物の 2 部品のコードとの結線は、継手の試験用のゲートウェイの代役を相手に確かめました。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 特定のゲートウェイ製品の使い方の雛形ではありません。

つなぎ方

src/routing.js の createGatewayRouting(options) で作ります。受け取るのは gateway_ref・request_prefix・ports・任意の timestamp で、{ ok, errors, instance } を返します。各操作は { ok, errors, approval: false, record_pending, last_change, … } を返します。利用側が用意する port は checkRoutes（route-config の check）と gateway（gateway-config の継手のクライアント。submit と、証跡・根拠を渡す 2 つの関数）です。副作用は束ねた継手が起こし（EXTERNAL_REVERSIBLE）、資格情報は port が持ちます。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

通知先（Webhook の宛先）を外部に登録するとき、任意の callback URL を差し込まれること、receipt で宛先を差し替えられること、そして「登録できた」を「通知が届いた」と取り違えることを防ぎます。

使う場面

• 通知先（Webhook の宛先）の登録・管理を、外部の連携先に対して行いたいとき。宛先は、あらかじめ pin した一覧の中からだけ選びます。
• 購読の登録（SUBSCRIBE）・更新（UPDATE）・取り消し（REVOKE）の結果を、receipt の状態（REGISTERED・UPDATED・REVOKED か FAILED）で照合してから扱いたいとき。
• 同じ要求を二重に送りたくないとき。連携先の障害で結果が分からないときは UNKNOWN とし、照会（lookup）で解きます。
• 照合できない receipt を受け取ったら、以後の送信を止めたいとき（RECEIPT_REJECTED のあとは HALTED）。

使わない場面

• Webhook の配送・署名の検証・受領をしたいとき。この継手が扱うのは購読の登録だけです。
• 購読の receipt を、通知が届いた証拠として使いたいとき。receipt が言えるのは登録の段階（SUBSCRIPTION_REGISTERED）までです。
• 任意の callback URL を利用者に指定させたいとき。pin していない宛先には送りません。
• 特定の SaaS 専用の接続器がほしいとき。この継手は SaaS ごとの接続器ではなく、どの連携先にも同じ検めをかけます。
• すぐに使える連携先がほしいとき。実の連携先は含まず、どこにつなぐかはまだ決まっていません。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。

検査すること

• 宛先を検めます。pin した Webhook の宛先の一覧に無い宛先（callback URL の差し込み）には送りません。空の一覧は何も許しません。
• receipt の宛先を照合します。宛先が差し替えられていたら受理せず、停止します（HALTED）。
• 配送や受領まで言う購読の receipt は受理しません。状態が操作に対応しない（SUBSCRIBE→REGISTERED・UPDATE→UPDATED・REVOKE→REVOKED のどれでもなく FAILED でもない）receipt も受理しません。
• 参照を検めます。空の参照、パスの形や「..」を含む参照、追加のフィールド、決まった値（const）と違う値は送りません。
• 外への効果を増やす receipt、効果が UNKNOWN の receipt、別の要求の receipt（request_digest の偽り）を受理しません。受理できない receipt で停止します（HALTED）。購読の効果は EXTERNAL_REVERSIBLE（FAILED は NONE）です。
• 同じ request_id は二度送りません。同じ冪等キーで別の中身の要求は送りません（REFUSED）。連携先の障害は UNKNOWN とし、照会（lookup）で解きます。

しないこと・既知の限界

• Webhook の配送・署名の検証・受領はしません。この継手の範囲外です（購読の登録だけ）。
• 意味の正しさ・Schema Authority・業務の許可を決めるのは、核（reconcile-facts・policy-facts）と人の役目です。この継手がするのは、送る前の検めと受け取った後の照合だけです。
• 運べた・登録できた・接続できたことは承認ではありません（どの結果にも approval: false が付きます）。
• 実の連携先を含みません。どの SaaS・どの ETL 基盤につなぐか、port の実装、pin する一覧は未定で、接続するときに別の関門で決めます。
• N-01 サービス発見・N-02 API ゲートウェイの機能は、この継手にはありません。N-01 は継手 service-registry-tsugite（契約 service-registry/v1）、N-02 は部品(Component) gateway-routing-component が担います。
• 契約を変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/integration-etl/v1（WebhookSubscription）でつなぎます。createIntegrationClient({ cfg, port }) の submit(request) は、DONE・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED のどれかを返します（常に approval: false）。DONE には subscription_state・subscription_ref・lifecycle_stage が付きます。利用側の用意: 連携先の port（submit と任意の lookup）と cfg の pin 一覧。副作用: EXTERNAL_REVERSIBLE（FAILED は NONE）。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

外部からデータを取り込むとき、pin していない取込元や対応表から取り込んでしまうこと、そして件数や一部の失敗をごまかして「全部取り込めた」と扱ってしまうことを防ぎます。

使う場面

• 外部から自系へのデータの取り込み（移行・同期）を、pin した取込元・スキーマ・対応表の範囲に限って行いたいとき。
• 取込の結果を、件数（received = accepted + rejected）と却下の参照（rejected_record_refs）で照合してから扱いたいとき。
• 一部だけ失敗した取込を、一部失敗（PARTIAL）のまま受け取りたいとき。
• 取り消せない取込を、設定で明示して許したとき（allow_irreversible: true）だけ送りたいとき。
• 同じ要求を二重に送りたくないとき。連携先の障害で結果が分からないときは UNKNOWN とし、照会（lookup）で解きます。

使わない場面

• 取り込んだデータの意味や対応表が正しいかを確かめたいとき。この継手が見るのは件数と参照だけです（semantic_correctness: NOT_VERIFIED）。
• 取込の突き合わせの判断を任せたいとき。突き合わせは核（reconcile-facts）の役目です。
• 特定の SaaS 専用の接続器がほしいとき。この継手は SaaS ごとの接続器ではなく、どの連携先にも同じ検めをかけます。
• すぐに使える連携先がほしいとき。実の連携先は含まず、どこにつなぐかはまだ決まっていません。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。

検査すること

• 取込元・スキーマ・対応表を検めます。pin した一覧に無いものは送りません。空の一覧は何も許しません。
• 参照を検めます。空の参照、パスの形や「..」を含む参照、追加のフィールド、決まった値（const）と違う値は送りません。
• 取り消せない取込は、設定が allow_irreversible: true のときだけ送ります。そうでなければ送りません。
• 件数を照合します。received = accepted + rejected にならない receipt、却下の件数と却下の参照の数が合わない receipt、却下の参照に重複がある receipt は受理しません。
• 結果の状態を照合します。受け入れと却下の片方しかない PARTIAL、却下があるのに完了とする receipt、受け入れがあるのに FAILED とする receipt は受理しません。
• 外への効果を増やす receipt、効果が UNKNOWN の receipt、別の要求の receipt（request_digest の偽り）を受理しません。受理できない receipt で停止します（HALTED）。取込の効果は EXTERNAL_*（FAILED は NONE）です。
• 同じ request_id は二度送りません。同じ冪等キーで別の中身の要求は送りません（REFUSED）。連携先の障害は UNKNOWN とし、照会（lookup）で解きます。

しないこと・既知の限界

• 取り込んだデータの意味の正しさ・対応表の正しさは確かめません（件数と参照だけ）。
• 意味の正しさ・Schema Authority・業務の許可を決めるのは、核（reconcile-facts・policy-facts）と人の役目です。この継手がするのは、送る前の検めと受け取った後の照合だけです。
• 運べた・登録できた・接続できたことは承認ではありません（どの結果にも approval: false が付きます）。
• 実の連携先を含みません。どの SaaS・どの ETL 基盤につなぐか、port の実装、pin する一覧は未定で、接続するときに別の関門で決めます。
• N-01 サービス発見・N-02 API ゲートウェイの機能は、この継手にはありません。N-01 は継手 service-registry-tsugite（契約 service-registry/v1）、N-02 は部品(Component) gateway-routing-component が担います。
• 契約を変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/integration-etl/v1（DataImport）でつなぎます。createIntegrationClient({ cfg, port }) の submit(request) は、DONE・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED のどれかを返します（常に approval: false）。DONE には partial_state・件数・rejected_record_refs・semantic_correctness: NOT_VERIFIED が付きます。利用側の用意: 連携先の port（submit と任意の lookup）と cfg の pin 一覧。副作用: EXTERNAL_*（FAILED は NONE）。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

自系のデータを外部へ書き出すとき、pin していない行き先へ送ってしまうこと、そして「作れた」だけで「相手に届いた」「相手が受け取った」と扱ってしまうことを防ぎます。

使う場面

• 自系から外部へのデータの書き出しを、pin した行き先・スキーマ・profile の範囲に限って行いたいとき。書き出しの選択も、任意で pin できます（selection_refs）。
• 書出しの結果を、作れた（GENERATED）・届けた（DELIVERED）・受け取られた（ACCEPTED）に分けて扱いたいとき。DONE には delivery_state・delivered・destination_accepted が添えられます。
• 取り消せない書出しを、設定で明示して許したとき（allow_irreversible: true）だけ送りたいとき。
• 同じ要求を二重に送りたくないとき。連携先の障害で結果が分からないときは UNKNOWN とし、照会（lookup）で解きます。

使わない場面

• 作れた（GENERATED）ことを、相手に届いた証拠として使いたいとき。この継手は 3 つの段階を分けて返します。
• 書き出すデータの意味の正しさを確かめたいとき。意味の正しさは核と人の役目で、この継手は送る前と受け取った後の検めだけをします。
• どの連携を許すかを決めたいとき。その決定は核（policy-facts）の役目です。
• 特定の SaaS 専用の接続器がほしいとき。この継手は SaaS ごとの接続器ではなく、どの連携先にも同じ検めをかけます。
• すぐに使える連携先がほしいとき。実の連携先は含まず、どこにつなぐかはまだ決まっていません。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。

検査すること

• 行き先・スキーマ・profile を検めます。pin した一覧に無いものは送りません。空の一覧は何も許しません。
• 参照を検めます。空の参照、パスの形や「..」を含む参照、追加のフィールド、決まった値（const）と違う値は送りません。
• 取り消せない書出しは、設定が allow_irreversible: true のときだけ送ります。そうでなければ送りません。
• 段階と効果を照合します。作れた（GENERATED）なのに外への効果を言う receipt、届けた（DELIVERED）なのに効果の無い receipt は受理しません。GENERATED の効果は NONE か LOCAL_REVERSIBLE、DELIVERED・ACCEPTED は EXTERNAL_* です。
• 外への効果を増やす receipt、効果が UNKNOWN の receipt、別の要求の receipt（request_digest の偽り）を受理しません。受理できない receipt で停止します（HALTED）。
• 同じ request_id は二度送りません。同じ冪等キーで別の中身の要求は送りません（REFUSED）。連携先の障害は UNKNOWN とし、照会（lookup）で解きます。

しないこと・既知の限界

• 意味の正しさ・Schema Authority・業務の許可を決めるのは、核（reconcile-facts・policy-facts）と人の役目です。この継手がするのは、送る前の検めと受け取った後の照合だけです。
• 運べた・登録できた・接続できたことは承認ではありません（どの結果にも approval: false が付きます）。
• 実の連携先を含みません。どの SaaS・どの ETL 基盤につなぐか、port の実装、pin する一覧は未定で、接続するときに別の関門で決めます。
• N-01 サービス発見・N-02 API ゲートウェイの機能は、この継手にはありません。N-01 は継手 service-registry-tsugite（契約 service-registry/v1）、N-02 は部品(Component) gateway-routing-component が担います。
• 契約を変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/integration-etl/v1（DataExport）でつなぎます。createIntegrationClient({ cfg, port }) の submit(request) は、DONE・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED のどれかを返します（常に approval: false）。DONE には delivery_state・delivered・destination_accepted が付きます。利用側の用意: 連携先の port（submit と任意の lookup）と cfg の pin 一覧。副作用: 段階で異なります（NONE〜EXTERNAL_*）。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

契約（型）を共有するためにスキーマを登録するとき、pin していないスキーマを登録してしまうこと、そして「登録できた」ことを「そのスキーマが権威（Schema Authority）や Canonical になった」と扱ってしまうことを防ぎます。

使う場面

• 契約（型）の共有のために、pin したスキーマだけを連携先に登録したいとき。
• 登録の結果を、receipt の registration_state・schema_authority・canonical_status で照合してから扱いたいとき。
• 登録の効果を EXTERNAL_REVERSIBLE、重複（DUPLICATE）と失敗（FAILED）を効果なし（NONE）として照合したいとき。
• 同じ要求を二重に送りたくないとき。連携先の障害で結果が分からないときは UNKNOWN とし、照会（lookup）で解きます。

使わない場面

• 登録によって、そのスキーマを権威や Canonical にしたいとき。スキーマの登録は Schema Authority も Canonical も生みません。
• どのスキーマを権威とするか（Schema Authority）を決めたいとき。それは核と人の役目で、この継手の契約の権威も、まだ定まっていません（NOT_SPECIFIED）。
• 特定の SaaS 専用の接続器がほしいとき。この継手は SaaS ごとの接続器ではなく、どの連携先にも同じ検めをかけます。
• すぐに使える連携先がほしいとき。実の連携先は含まず、どこにつなぐかはまだ決まっていません。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。

検査すること

• スキーマを検めます。pin したスキーマの一覧に無いものは送りません。空の一覧は何も許しません。
• 参照を検めます。空の参照、パスの形や「..」を含む参照、追加のフィールド、決まった値（const）と違う値は送りません。
• 権威（Schema Authority）を名乗る登録の receipt、Canonical を名乗る登録の receipt は受理しません。
• digest の対象を照合します。契約の読みとして、schema_digest の対象は schema_identity、content_digest の対象は request_id です。
• 外への効果を増やす receipt、効果が UNKNOWN の receipt、別の要求の receipt（request_digest の偽り）を受理しません。受理できない receipt で停止します（HALTED）。登録の効果は EXTERNAL_REVERSIBLE（DUPLICATE・FAILED は NONE）です。
• 同じ request_id は二度送りません。同じ冪等キーで別の中身の要求は送りません（REFUSED）。連携先の障害は UNKNOWN とし、照会（lookup）で解きます。

しないこと・既知の限界

• スキーマの登録は、Schema Authority も Canonical も生みません。
• 意味の正しさ・Schema Authority・業務の許可を決めるのは、核（reconcile-facts・policy-facts）と人の役目です。この継手がするのは、送る前の検めと受け取った後の照合だけです。
• 運べた・登録できた・接続できたことは承認ではありません（どの結果にも approval: false が付きます）。
• 実の連携先を含みません。どの SaaS・どの ETL 基盤につなぐか、port の実装、pin する一覧は未定で、接続するときに別の関門で決めます。
• N-01 サービス発見・N-02 API ゲートウェイの機能は、この継手にはありません。N-01 は継手 service-registry-tsugite（契約 service-registry/v1）、N-02 は部品(Component) gateway-routing-component が担います。
• 契約を変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/integration-etl/v1（SchemaRegistration）でつなぎます。createIntegrationClient({ cfg, port }) の submit(request) は、DONE・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED のどれかを返します（常に approval: false）。DONE には registration_state・schema_authority・canonical_status が付きます。利用側の用意: 連携先の port（submit と任意の lookup）と cfg の pin 一覧。副作用: EXTERNAL_REVERSIBLE（DUPLICATE・FAILED は NONE）。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

イベントのスキーマを変えるとき、互換が確かめられていない（UNKNOWN）結果や試験に落ちた結果を「互換あり」と扱ってしまい、後方互換を壊すことを防ぎます。

使う場面

• 後方互換の管理のために、スキーマ互換の確認の結果を照合してから扱いたいとき。
• 互換の主張（BACKWARD・FORWARD・FULLY）と試験の PASS がそろったときだけ、互換（compatible: true）として扱いたいとき。
• pin したスキーマ（イベントのスキーマを含む）に限って、互換を確かめたいとき。
• 同じ要求を二重に送りたくないとき。連携先の障害で結果が分からないときは UNKNOWN とし、照会（lookup）で解きます。

使わない場面

• 互換 UNKNOWN や、試験が未実行（NOT_RUN）の主張を、互換として扱いたいとき。この継手はそれを互換として扱いません。
• スキーマの意味の正しさや、どれを権威とするか（Schema Authority）を決めたいとき。それは核と人の役目です。
• 特定の SaaS 専用の接続器がほしいとき。この継手は SaaS ごとの接続器ではなく、どの連携先にも同じ検めをかけます。
• すぐに使える連携先がほしいとき。実の連携先は含まず、どこにつなぐかはまだ決まっていません。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。

検査すること

• スキーマを検めます。pin したスキーマの一覧に無いものは送りません。空の一覧は何も許しません。
• 参照を検めます。空の参照、パスの形や「..」を含む参照、追加のフィールド、決まった値（const）と違う値は送りません。
• 互換が UNKNOWN の receipt は、試験が PASS でも互換として受理しません。
• 試験に落ちた（FAIL）のに互換（compatible: true）とする receipt、互換の主張（BACKWARD・FORWARD・FULLY）と FAIL が並ぶ矛盾した receipt は受理しません。
• 外への効果を増やす receipt、効果が UNKNOWN の receipt、別の要求の receipt（request_digest の偽り）を受理しません。受理できない receipt で停止します（HALTED）。互換の確認の効果は NONE です。
• 同じ request_id は二度送りません。同じ冪等キーで別の中身の要求は送りません（REFUSED）。連携先の障害は UNKNOWN とし、照会（lookup）で解きます。

しないこと・既知の限界

• 意味の正しさ・Schema Authority・業務の許可を決めるのは、核（reconcile-facts・policy-facts）と人の役目です。この継手がするのは、送る前の検めと受け取った後の照合だけです。
• 運べた・登録できた・接続できたことは承認ではありません（どの結果にも approval: false が付きます）。
• 実の連携先を含みません。どの SaaS・どの ETL 基盤につなぐか、port の実装、pin する一覧は未定で、接続するときに別の関門で決めます。
• N-01 サービス発見・N-02 API ゲートウェイの機能は、この継手にはありません。N-01 は継手 service-registry-tsugite（契約 service-registry/v1）、N-02 は部品(Component) gateway-routing-component が担います。
• 契約を変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/integration-etl/v1（SchemaCompatibility）でつなぎます。createIntegrationClient({ cfg, port }) の submit(request) は、DONE・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED のどれかを返します（常に approval: false）。DONE には compatibility・test_result・compatible が付きます。利用側の用意: 連携先の port（submit と任意の lookup）と cfg の pin 一覧。副作用: NONE。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

連携アカウントの接続を登録するとき、token や鍵の値を参照の代わりに渡してしまうこと、許可していない scope で登録してしまうこと、そして「接続できた」を「業務として許された」と扱ってしまうことを防ぎます。

使う場面

• 連携アカウントの接続を、pin した接続（connection_refs）・credential の参照（credential_refs）・許可する scope（allowed_scopes）の範囲に限って登録したいとき。
• credential を値（bytes）ではなく、参照だけで渡したいとき。
• 登録の結果を、receipt の connection_state・credential_binding_state・business_authorization で照合してから扱いたいとき。
• 同じ要求を二重に送りたくないとき。連携先の障害で結果が分からないときは UNKNOWN とし、照会（lookup）で解きます。

使わない場面

• OAuth の手続きを行わせたいとき、token を発行・保管させたいとき。この継手はそれをしません。credential の参照が何を指すかの解決は secret-ref／portable-credential-ref の仕組みの役目です。
• 接続できたことを、業務の許可として使いたいとき。どの連携を許すかの決定は核（policy-facts）の役目です。
• token や鍵の形の値を見分けて守る仕組みとして頼りたいとき。この検出は代表的な形だけを見る網で、すべての秘密を見分けるものではありません。本当の守りは pin した参照の一覧です。
• 特定の SaaS 専用の接続器がほしいとき。この継手は SaaS ごとの接続器ではなく、どの連携先にも同じ検めをかけます。
• すぐに使える連携先がほしいとき。実の連携先は含まず、どこにつなぐかはまだ決まっていません。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。

検査すること

• 接続・credential の参照・scope を検めます。pin した一覧に無い接続や参照、許可していない scope は送りません。空の一覧は何も許しません。
• credential_ref が token や鍵の形なら、pin されていても送りません。
• 接続できたことから業務の許可を導く receipt は受理しません。
• 参照を検めます。空の参照、パスの形や「..」を含む参照、追加のフィールド、決まった値（const）と違う値は送りません。
• 外への効果を増やす receipt、効果が UNKNOWN の receipt、別の要求の receipt（request_digest の偽り）を受理しません。受理できない receipt で停止します（HALTED）。接続の登録の効果は NONE か LOCAL_REVERSIBLE です。
• 同じ request_id は二度送りません。同じ冪等キーで別の中身の要求は送りません（REFUSED）。連携先の障害は UNKNOWN とし、照会（lookup）で解きます。

しないこと・既知の限界

• 実の OAuth の手続き、token の発行と保管はしません。credential の参照が何を指すかの解決は secret-ref／portable-credential-ref の仕組みの役目です。
• token や鍵の形の検出は代表的な形だけを見る網で、すべての秘密を見分けるものではありません。
• 意味の正しさ・Schema Authority・業務の許可を決めるのは、核（reconcile-facts・policy-facts）と人の役目です。この継手がするのは、送る前の検めと受け取った後の照合だけです。
• 運べた・登録できた・接続できたことは承認ではありません（どの結果にも approval: false が付きます）。
• 実の連携先を含みません。どの SaaS・どの ETL 基盤につなぐか、port の実装、pin する一覧は未定で、接続するときに別の関門で決めます。
• N-01 サービス発見・N-02 API ゲートウェイの機能は、この継手にはありません。N-01 は継手 service-registry-tsugite（契約 service-registry/v1）、N-02 は部品(Component) gateway-routing-component が担います。
• 契約を変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/integration-etl/v1（ExternalConnectionRegister）でつなぎます。createIntegrationClient({ cfg, port }) の submit(request) は、DONE・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED のどれかを返します（常に approval: false）。DONE には connection_state・credential_binding_state・business_authorization が付きます。利用側の用意: 連携先の port（submit と任意の lookup）と cfg の pin 一覧。副作用: NONE か LOCAL_REVERSIBLE。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

取り込みの来歴の土台になります。受け取れない記録は黙って読み飛ばさずに決まったコードと位置で止め、事前署名 URL の痕跡（://・X-Amz-Signature・X-Amz-Credential・Signature=、クエリつきの URL の形）を記録のどこにも入れません。記録の hash は正準の bytes の sha256 で、キーの順や空白に左右されません。

使う場面

• 取得の事実（source・platform_profile・retention_class・kind_declared・fetch_state・fetch_record）から、fetch.json の記録を作りたいとき（buildFetchRecord）。schema と folder_stamp は部品が足します。
• 契約 raw-fetch/v1 の受け取り（RawFetchReceipt）の fetch_record を、そのまま写して記録に入れたいとき。
• 保管した記録を読み戻して検め、同じ canonical と record_sha256 を得たいとき（checkFetchRecord。folder_stamp は fetched_at から作り直して比べる）。
• has_more が true のまま止まった取得（PARTIAL）も、取れた分の記録として残したいとき。
• 時計・乱数・外の接続を持たない、決定的な処理として手元で呼びたいとき。fetched_at は呼ぶ側が渡します。

使わない場面

• ファイルがあるか、byte_size と sha256 が中身と合うかを確かめたいとき。それは I-10 の役目で、この部品は検めません。
• 記録に秘密が入っていないことを確かめたいとき。URL・署名の印の網は粗く、:// を含まない秘密（トークン・鍵の値そのもの）や、印を崩した URL は見つけられません。
• 取得が本当に FETCHED・PARTIAL だったか、fetched_at が取得した時刻として正しいか・未来でないかを確かめたいとき。写しとして受け取り、形と暦だけを検めます。
• 保持の方針（retention_class の意味・期間）を決めたいとき。ここでは決めません。
• 大文字・小文字を区別しないファイルシステムで、name の重なりを見つけたいとき。a と A は別の名前として受け取ります。
• 宣言された media type が中身に合うか・charset が正しいかを確かめたいとき。宣言のまま記録します（読むのは I-09・I-10）。
• 契約 raw-fetch/v1 が改訂された後に、写し直さずに使うとき。パターンの文字列は契約の写しで、改訂されたら写し直して検め直す必要があります。Node.js v24.21.0 のほかの版も確かめていません（NOT_VERIFIED）。

検査すること

• 記録（または build の入力）がオブジェクトでないとき NOT_AN_OBJECT、RFC 8785 で正準化できない値（小数・undefined・getter・Date など）を含むとき NOT_CANONICALIZABLE（detail に I-08 のコード）で止めます。getter は呼ばず、正準化した写しの上で検めます。
• 決まっていないキーがあるとき（build に schema・folder_stamp を渡した場合を含む）UNKNOWN_FIELD、必須のキーが無いとき MISSING_FIELD で止めます。fetch_params_digest と files[].file_ref も必須です。
• schema・source・platform_profile・retention_class・kind_declared・fetch_state が決まった値や形でないとき、INVALID_SCHEMA・INVALID_SOURCE・INVALID_PLATFORM_PROFILE・INVALID_RETENTION_CLASS・INVALID_KIND_DECLARED・INVALID_FETCH_STATE で止めます。fetch_record を持たない状態（NOT_READY・FAILED など）は受け取りません。
• fetched_at が契約のパターン（1970 年以降・UTC の Z・うるう秒なし）に合わない、またはその月に無い日（2 月 30 日・平年の 2 月 29 日など）のとき INVALID_FETCHED_AT、folder_stamp が fetched_at から作り直した値と違うとき FOLDER_STAMP_MISMATCH で止めます。
• Digest の形（キー・algorithm・value・domain）が違うとき、files[].sha256.target が name と違うとき INVALID_DIGEST、files が空・キーが違う・byte_size が 0 以上の整数でないとき INVALID_FILES、name が契約のパターンでない（.. を含む）とき INVALID_FILE_NAME、同じ name が 2 つ以上のとき DUPLICATE_FILE_NAME、declared_media_type が契約の形でない・255 文字を超えるとき INVALID_MEDIA_TYPE で止めます。
• pages が空、seq が 0 から 1 ずつでない、cursor がつながらない、has_more が状態に合わない（FETCHED は最後だけ false、PARTIAL はすべて true）とき、INVALID_PAGES で止めます。
• platform_profile が amazon-sp-api-reports・amazon-pay-reports なのに lineage が無いとき LINEAGE_REQUIRED、stripe なのに api_version が null のとき API_VERSION_REQUIRED で止めます（FETCHED でも PARTIAL でも）。lineage の形が違うときは INVALID_LINEAGE です。
• 記録のどこかの文字列がクエリつきの URL の形を含むとき URL_WITH_QUERY_REFUSED、://・X-Amz-Signature・X-Amz-Credential・Signature= を含むとき URL_FORM_REFUSED で止めます（大文字・小文字を区別せず、探しは線形の時間）。止めたときは、決まった順で最初の 1 つを code と path（JSON Pointer）で返します。

しないこと・既知の限界

• Stripe（Amazon）は接続先として名前を挙げているだけで、提携・承認ではありません。
• 何も取得しません。ファイルの読み書きもしません。
• 記録を受け取れたことは、取得が正しかったこと・ファイルがあること・digest が中身と合うこと・秘密が入っていないこと・受け入れてよいことを意味しません。
• 契約の runtime 規則のうち、要求（request）を持たないと確かめられないもの（fetch_params_digest の target・value が要求と合うか）や、記録の外のことは検めません。
• 可読性の検め（I-09）、封（H-11）、保持の方針は、この部品の外に残ります。
• 記録ができたことは、承認ではありません（result_is_approval: false）。権限も作りません（derives_authority: false）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 特定の取得ツールの記録形式の雛形ではありません。

つなぎ方

src/fetch-record.js の buildFetchRecord({ source, platform_profile, retention_class, kind_declared, fetch_state, fetch_record }) と checkFetchRecord(record) を呼びます（投げません）。check は schema と folder_stamp を含む 8 つのキーの記録を受け取ります。返すのは { ok: true, errors: [], record, canonical, record_sha256 } か { ok: false, errors: [{ code, path }] }。副作用・状態・外の接続・資格情報は無く、利用側が用意する port はありません。依存は Node.js の組み込みの crypto だけです。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

連携の取り込みの裏で、受け取ったままかが見えなくなることを防ぎます。受け取ったバイト列の長さと sha256 を計算し直して記録と照らし、カーソルの連鎖・API の版・宣言を確かめ、事前署名の URL を残さず、取得を判断や受け入れと取り違えません。

使う場面

• Stripe の一覧の API（charges・payment_intents・refunds・balance_transactions・payouts・disputes・invoices・events）の応答を、受け取った形のまま残したいとき。
• 受け取ったバイト列の byte_size と sha256 が、取得の記録（fetch_record）と同じことを確かめてから受け取りたいとき。
• 頁を途中で止めても、続きを取れるようにしたいとき。PARTIAL のときの result.resume_cursor を、次の要求の starting_after にします。
• 取得の記録を、N-09 の取得の記録（fetch.json）へそのまま写したいとき。result.fetch_record は receipt のままです。

使わない場面

• 応答の中身を読みたい・型にはめたい・正規化したいとき。共通形への写像・重複の判断・突き合わせは、ほかの層と人・ルールの役目です。
• レポートを作らせたいとき（CREATE_REPORT）。この継手が送るのは op FETCH だけで、ほかの profile も送りません。
• Stripe の API クライアントの雛形がほしいとき。この継手はその雛形ではありません。
• 保持の期限を守らせたいとき。保持を守るのは保管（C-01）とその区画の役目です。
• すぐに使える取得の仕組みがほしいとき。実の Stripe からの取得は 0 回で、port の実装・資格情報・設定の値は、接続するときに別の関門で決めます。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。

検査すること

• 要求を検めます。送るのは profile stripe・op FETCH・limit 1〜100・starting_after と ending_before の一方だけの要求で、口座（account_refs）と資格情報（credentials）が設定に pin されているときだけです。外れたら送りません（REFUSED）。
• 資格情報は参照だけです。用途 FETCH・スコープ READ_ONLY と書いた参照だけを使い、署名の鍵（signing_key_refs）と同じ参照を credentials に書いた設定は受けません。
• 受け取ったバイト列を写してから照合します。files[] と同じ順・名前・数で、byte_size が実のバイト数、sha256 が実のバイト列の sha256 のときだけ受け取ります。
• pages を照合します。seq は 0 から 1 ずつの切れないカーソルの連鎖で、FETCHED は has_more false で終わり、PARTIAL は続きのカーソルを持って止まるものだけを受け取ります。FETCHED と PARTIAL には api_version の文字列が要ります。
• 事前署名の URL を記録しません。presigned_url_recorded は false で、要求と receipt のどの値にも ://・X-Amz-Signature・X-Amz-Credential・Signature= を（大文字小文字を問わず）許しません。
• 宣言（kind_declared・retention_class・identity_basis）が要求と同じ値の receipt だけを受け取ります。
• 状態の食い違う receipt、効果を増やす receipt（FETCH はどの状態でも NONE）、効果の不明な receipt、別の要求の receipt は受理せず、停止します（RECEIPT_REJECTED のあとは HALTED）。
• 同じ request_id の別の中身は送りません。Stripe（port）の障害は UNKNOWN とし、読むだけなので同じ要求を送り直して構いません。

しないこと・既知の限界

• Stripe は接続先として名前を挙げているだけで、提携・承認ではありません。
• 受け取ったバイト列の中身（形・件数・正しさ・PII を含むか）は確かめません。宣言が中身に合うか、declared_media_type が中身の型に合うかも確かめません。
• Stripe の一覧の API の実の振る舞い（並び順・ending_before の向き・has_more）は代役で真似ただけで、実の Stripe とは突き合わせていません。API の版の値の形も確かめません。
• 時刻（observed_timestamp・fetched_at）は形と実在する日時だけを検め、正しさ・古さは確かめません。1 回で何頁取るか・時間の予算は port の役目です。
• 照合済みの記録はこの継手の中だけで、再起動で消えます。fetch.json・payload の書き出しは N-09 と保管の役目です。
• 取得できたことは承認ではなく、中身が正しいことでも、受け入れたことでも、突き合わせたことでもありません（どの結果にも approval: false が付きます）。
• 契約を変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/raw-fetch/v1（RawFetchRequest / RawFetchReceipt、profile stripe・op FETCH）でつなぎます。createRawFetchClient({ cfg, port }) の submit(request) は DONE・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED を返します（常に approval: false）。利用側の用意: Stripe の port（submit が { receipt, files } を返す）と cfg（account_refs・credentials・signing_key_refs）。副作用: NONE。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

レポートの取り込みの裏で、受け取ったままかが見えなくなることを防ぎます。文書を gzip のまま運び、長さと sha256・lineage・宣言を照らし、事前署名の URL を残さず、作らせたレポートを二度作らせません。

使う場面

• 自動で作られるレポート（決済報告書）を、REPORT_PROCESSING_FINISHED の通知（別の port）の後に report_id で取りたいとき（op FETCH）。
• オンデマンドのレポートを作らせて report_id を受け取りたいとき（op CREATE_REPORT）。作らせてよい種類は設定 allowed_report_types に書いたものだけです。
• 受け取った文書の byte_size と sha256 が取得の記録と同じで、GZIP の文書が展開されていないことを確かめてから受け取りたいとき。
• 取得の記録を、N-09 の取得の記録（fetch.json）へそのまま写したいとき。result.fetch_record は receipt のままで、lineage を含みます。

使わない場面

• 文書を展開したい・TSV を読みたい・共通形へ写したいとき。それはほかの層の役目で、判断は人・ルールの役目です。
• 自動で作られる決済報告書（GET_V2_SETTLEMENT_REPORT_…）を作らせたいとき。その種類は設定に入れられません。
• REPORT_PROCESSING_FINISHED の通知を受けたいとき。通知の受け口は別の port です。
• SP-API の Reports クライアントの雛形がほしいとき。この継手はその雛形ではありません。
• 保持の期限（顧客の PII の期限など）を守らせたいとき。保持を守るのは保管（C-01）とその区画の役目です。
• すぐに使える取得の仕組みがほしいとき。実の SP-API からの取得は 0 回で、port の実装・資格情報・設定の値は、接続するときに別の関門で決めます。

検査すること

• 要求を検めます。送るのは profile amazon-sp-api-reports の要求で、口座（account_refs）と資格情報（credentials）が設定に pin されているときだけです。許していないレポートの種類、同じ request_id の別の中身は送りません（REFUSED）。
• 資格情報は参照だけです。用途 FETCH・スコープ REPORTS_ONLY と書いた参照だけを使い、署名の鍵（signing_key_refs）と同じ参照を credentials に書いた設定は受けません。
• 受け取ったバイト列を写してから照合します。files[] と同じ順・名前・数で、byte_size が実のバイト数、sha256 が実のバイト列の sha256 のときだけ受け取ります。GZIP の文書は application/gzip と宣言し、gzip の頭（1f 8b）で始まるときだけ受け取ります。
• lineage を照合します。FETCHED と PARTIAL には lineage が要り、FETCH の lineage.report_id は要求の report_id と同じでなければ受け取りません。lineage に文書の URL は書かせません。
• 事前署名の URL を記録しません。presigned_url_recorded は false で、要求と receipt のどの値にも ://・X-Amz-Signature・X-Amz-Credential・Signature= を（大文字小文字を問わず）許しません。
• 効果を照合します。REPORT_REQUESTED は EXTERNAL_REVERSIBLE をちょうど名乗るものだけを受け取り、ほかの状態は NONE だけです。レポートが作られたか分からない receipt は受け取らず、停止します。
• 結果の分からない CREATE_REPORT は未解決として覚え、同じ要求の再送で解きます（port.lookup があれば先に探します）。レポートを二度作らせず、解けるまでほかの要求は送りません。
• 宣言（kind_declared・retention_class・identity_basis）が要求と同じ値の receipt だけを受け取ります。照合できない receipt のあとは停止します（RECEIPT_REJECTED のあとは HALTED）。

しないこと・既知の限界

• Amazon は接続先として名前を挙げているだけで、提携・承認ではありません。
• 受け取ったバイト列の中身（形・件数・正しさ・PII を含むか）は確かめません。宣言が中身に合うか、declared_media_type が中身の型に合うかも確かめません（GZIP のときの gzip の頭 2 バイトだけは見ます）。
• SP-API の実の振る舞い（レポートの処理時間・CANCELLED や FATAL の扱い・文書の URL の寿命・GZIP の有無）は代役で真似ただけで、実の SP-API とは突き合わせていません。
• 未解決の CREATE_REPORT はこの継手の中だけで覚え、再起動で消えます。lookup の無い port で送り直すと、レポートがもう 1 つ作られることがあります。
• どの種類をオンデマンドで作れるかは、設定 allowed_report_types に任せます。決済報告書のほかに自動で作られる種類は知りません。
• 取得できたことは承認ではなく、中身が正しいことでも、受け入れたことでも、突き合わせたことでもありません（どの結果にも approval: false が付きます）。
• 契約を変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/raw-fetch/v1（RawFetchRequest / RawFetchReceipt、profile amazon-sp-api-reports）でつなぎます。createRawFetchClient({ cfg, port }) の submit(request) は DONE・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED を返します（常に approval: false）。利用側の用意: SP-API の port（submit と任意の lookup。{ receipt, files } を返す）と cfg の一覧。副作用: CREATE_REPORT だけ EXTERNAL_REVERSIBLE。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

決済報告の取り込みの裏で、受け取ったままかが見えなくなることを防ぎます。決済報告書を受け取った形のまま運び、長さと sha256・lineage・宣言を照らし、短命のダウンロードの URL を残さず、取得を判断や受け入れと取り違えません。

使う場面

• 決済報告書の通知（別の port）を受けた後に、その report_id で決済報告書を取りたいとき（op FETCH）。処理中は NOT_READY、無いレポートは REJECTED が返ります。
• 受け取った決済報告書の byte_size と sha256 が取得の記録と同じことを確かめてから受け取りたいとき。
• ダウンロードの URL（30 秒で切れる）を記録に残さずに取りたいとき。URL は port がすぐに使って捨て、継手には渡しません。
• 取得の記録を、N-09 の取得の記録（fetch.json）へそのまま写したいとき。result.fetch_record は receipt のままで、lineage を含みます。

使わない場面

• レポートを作らせたい・予約したいとき。決済報告書は自動で作られ、この継手は CREATE_REPORT を送りません（契約で無効）。
• CSV を読みたい・共通形へ写したいとき。それはほかの層の役目で、判断は人・ルールの役目です。
• 決済報告書の通知を受けたいとき。通知の受け口は別の port です。
• Amazon Pay の Reports クライアントの雛形がほしいとき。この継手はその雛形ではありません。
• 保持の期限を守らせたいとき。保持を守るのは保管（C-01）とその区画の役目です。
• すぐに使える取得の仕組みがほしいとき。実の Amazon Pay からの取得は 0 回で、port の実装・資格情報・設定の値は、接続するときに別の関門で決めます。

検査すること

• 要求を検めます。送るのは profile amazon-pay-reports・op FETCH・report_id だけの要求で、口座（account_refs）と資格情報（credentials）が設定に pin されているときだけです。CREATE_REPORT、ほかの profile、同じ request_id の別の中身は送りません（REFUSED）。
• 資格情報は参照だけです。用途 FETCH と、スコープ READ_ONLY か NO_READ_ONLY_SCOPE_OFFERED（相手が読み取りだけのスコープを持たないと明示した）を書いた参照だけを使います。記録の署名の鍵（signing_key_refs）と同じ参照を credentials に書いた設定は受けません。
• 受け取ったバイト列を写してから照合します。files[] と同じ順・名前・数で、byte_size が実のバイト数、sha256 が実のバイト列の sha256 のときだけ受け取ります。GZIP と書かれたときは、application/gzip と宣言し gzip の頭（1f 8b）で始まるときだけ受け取ります。
• lineage を照合します。FETCHED と PARTIAL には lineage が要り、FETCH の lineage.report_id は要求の report_id と同じでなければ受け取りません。
• 事前署名の URL を記録しません。presigned_url_recorded は false で、要求と receipt のどの値にも ://・X-Amz-Signature・X-Amz-Credential・Signature= を（大文字小文字を問わず）許しません。
• 宣言（kind_declared・retention_class・identity_basis）が要求と同じ値の receipt だけを受け取ります。
• 状態の食い違う receipt、効果を増やす receipt（FETCH はどの状態でも NONE）、効果の不明な receipt、別の要求の receipt は受理せず、停止します（RECEIPT_REJECTED のあとは HALTED）。
• Amazon Pay（port）の障害は UNKNOWN とします。読むだけなので、同じ要求を送り直して構いません。

しないこと・既知の限界

• Amazon は接続先として名前を挙げているだけで、提携・承認ではありません。
• 受け取ったバイト列の中身（形・件数・正しさ・PII を含むか）は確かめません。宣言が中身に合うか、declared_media_type が中身の型に合うかも確かめません（GZIP と書かれたときの gzip の頭 2 バイトだけは見ます）。
• Reports API の実の振る舞い（レポートの処理・ダウンロードの URL の寿命・compressionAlgorithm の値）は代役で真似ただけで、実の Amazon Pay とは突き合わせていません。
• Amazon Pay の資格情報が読み取りだけのスコープを持てるかは確かめていません。実の鍵の用途は port が確かめます。
• 照合済みの記録はこの継手の中だけで、再起動で消えます。fetch.json・payload の書き出しは N-09 と保管の役目です。時刻は形と実在する日時だけを検め、正しさ・古さは確かめません。
• 取得できたことは承認ではなく、中身が正しいことでも、受け入れたことでも、突き合わせたことでもありません（どの結果にも approval: false が付きます）。
• 契約を変えません。契約の権威（schema authority）は、まだ定まっていません（NOT_SPECIFIED）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/raw-fetch/v1（RawFetchRequest / RawFetchReceipt、profile amazon-pay-reports・op FETCH）でつなぎます。createRawFetchClient({ cfg, port }) の submit(request) は DONE・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED を返します（常に approval: false）。利用側の用意: Amazon Pay の port（submit が { receipt, files } を返す）と cfg（account_refs・credentials・signing_key_refs）。副作用: NONE。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

「検索で出た」の裏で、索引の版や鮮度が見えなくなることを防ぎます。設定で狭めて運び、問い合わせの文書の digest と cursor の決定性を照らし、引いた結果を確かめた事実や権威と取り違えません。

使う場面

• 索引の基盤（既定は利用者の SQLite・FTS5 の部品。差し替えられる）に、索引の書込・検索・取り出しを、同じ検めをかけて運びたいとき。
• 完全一致の絞り込み（STRUCTURED）で引きたいとき。問い合わせの文書 canonical({filters:[{field, op, value}]}) の sha256 を query_digest と照らしてから渡します。
• ページを続けて引くとき、同じ索引・版・問い合わせの ANSWERED の答えで受け取った cursor だけを使いたいとき。
• 個人情報を消すとき、索引の項目を墓標（tombstone true、content_digest なしの UPSERT）で上書きしたいとき。

使わない場面

• 引いた結果を、確かめた事実や権威として使いたいとき。取り出した ≠ 真、似ている ≠ 確かめた事実、順位 ≠ 権威です。結果の確かめ・判断は外の判断と人・組織の役目です。
• 取り出した中身のバイト列を受け取りたいとき。この継手を通るのは digest と出所だけで、中身が digest と合うかは受け取る側で確かめます。
• 特定の検索エンジン・ベクトル DB・SQLite の拡張の使い方の雛形がほしいとき。この継手はその雛形ではありません。
• Canonical に定まった分類・契約の上で使いたいとき。分類 O と契約 search-retrieval/v1 は DESIGN_CANDIDATE で、この継手もその上の候補です。
• すぐに使える索引の基盤がほしいとき。実の基盤への呼び出しは 0 回で、port の実装・設定の値は、接続するときに別の関門で決めます。
• 表の業務ロジックを組みたいとき。この継手は裏方・インフラの API 専用で、業務ロジックは部品（Kernel）が担います。

検査すること

• 設定は狭めるだけで広げません。index_profiles・index_ops・retrieval_modes・max_page_size・structured_fields・source_prefixes の外の要求は送りません（DELETE を外せば DELETE は送りません）。設定に知らないキーがあれば何も送りません。
• STRUCTURED の文書を検めます。形（filters は 1 つ以上、op は EQ・GTE・LT、value は文字列、field は設定の structured_fields）と sha256 が query_digest と合わないときは送りません。結果は score 1 だけ受け取ります。
• cursor を検めます。別の index_revision・別の問い合わせの cursor、受け取っていない cursor は送りません。決定的でない cursor、最初の頁と続きの頁で同じ cursor、page_size を超える結果、同じ source の重複は受理しません。
• 検索の答えを照合します。ANSWERED でない答えは結果も cursor も持たず、鮮度は UNKNOWN のときだけ受け取ります。結果の項目は {source_ref, score, provenance_ref} だけで、verified などの欄は受け取りません。
• 効果を照合します。INDEXED・DELETED は EXTERNAL_REVERSIBLE、検索・取り出しは NONE、UNKNOWN は索引の書込の FAILED だけです。効果を増やす receipt、別の版や op、別の要求の receipt は受理せず、停止します（HALTED）。
• 結果の見えない索引の書込（port の障害、FAILED・効果 UNKNOWN の receipt）は未解決として保ちます。送り直す前に、索引の項目を EntryReadRequest / EntryReadReceipt（port.readEntry）で読み、効いていれば送り直しません。読めないときは送り直さず、解けるまでほかは送りません。

しないこと・既知の限界

• ACL を結果を返す前に当てたか、鮮度（freshness_state）が本当か、結果が本当に一致・関連しているかは確かめません（基盤の申告。結果は NOT_VERIFIED のまま運びます）。
• STRUCTURED で基盤が値で比べたか、絞り込みの値が宣言した型に合うかは確かめません（基盤が FILTER_INVALID で答えます）。
• VECTOR・HYBRID の意味（どの埋め込みか・どう混ぜるか）は契約に無く、score を確からしさとして運ぶだけです。ベクトル検索は基盤の必須にはしません。
• cursor の照合と記録はこのクライアントの中だけで、再起動で消えます。再起動の前の cursor ではページを続けられず、最初のページから引き直します。
• readEntry の答えが本当に索引の今の項目かは確かめません。readEntry の無い port では、FAILED・UNKNOWN の後は送り直さず、索引に何が残ったかは人が確かめます。
• doc_ref・acl_ref・provenance_ref の文字列に個人情報が書かれても見分けません。個人情報そのものを索引に入れないことは運用の決まりです。
• 運べた・索引に入れたことは承認ではなく、中身を確かめたことでもありません（どの結果にも approval: false が付きます）。契約を変えず、契約の権威は NOT_SPECIFIED です。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。

つなぎ方

契約 erabazu.candidate/certified-tsugite/search-retrieval/v1（Index・Query・Retrieve・EntryRead の Request と Receipt）でつなぎます。createSearchRetrievalClient({ cfg, port, clock? }) の submit(request, query) は DONE・ALREADY_DONE・REFUSED・UNKNOWN・RECEIPT_REJECTED・HALTED を返します（常に approval: false）。利用側の用意: 索引の基盤の port（submit と任意の lookup・readEntry）と cfg の一覧。副作用: 索引の書込は EXTERNAL_REVERSIBLE、検索・取り出しは NONE。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

帳簿の検索の裏にある索引のための部品です。検めていない記録や txn_id の合わない取引を索引に入れること、pii の取引先をそのまま追記だけの索引に入れること、索引の項目を DELETE で消してしまうこと、索引が答えなかった問い合わせを「結果の無い成功」と読むことを防ぎます。

使う場面

• fetch.json の記録を N-09 で検め、取得（source・folder_stamp・fetched_at・retention_class・検査の状態と版・ファイルの数）を fetch の索引へ UPSERT で 1 つ入れたいとき（indexFetch）。doc_ref は raw/<source>/<folder_stamp> です。
• 共通形の取引（erabazu.common.txn/1）の txn_id を G-12 で計算し直し、合った取引だけを txn の索引へ入れたいとき（indexTxn）。文書は occurred_on・amount_key・currency・counterparty_key・raw_refs で、doc_ref は txn_id です。
• 取引を、取引年月日（EQ・GTE・LT）・金額（amount_key の EQ・GTE・LT。同じ通貨の EQ と組む）・通貨と取引先（EQ だけ）で探し、txn_id の候補を受け取りたいとき（queryTxn）。
• 金額を、文字列の順が数の順と同じになる 58 文字の固定幅の amount_key に、取引先を counterparty_key（"id:" か "name:" で始まる値。pii は sha256）にして、問い合わせの値を作りたいとき（amountKey・counterpartyKey）。
• UPSERT だけの索引から pii の取引を取り除きたいとき。txn の索引の項目を墓標（tombstone true・content_digest なしの UPSERT）で上書きします（tombstoneTxn）。墓標にした取引は、このインスタンスでは入れ直しません。
• 結果の分からなかった索引の書込（墓標を含む）を、同じ要求で送り直したいとき（resolvePending）。

使わない場面

• 問い合わせの結果を、条件に合う取引の事実や、漏れの無い一覧として使いたいとき。結果は候補（NOT_VERIFIED）で、当たった取引が本当に条件に合うか、索引に漏れが無いかは基盤の申告です。
• pii の取引先の sha256 を匿名化として扱いたいとき。sha256 は塩（秘密の鍵）を入れていないので、候補の名前や id を順に試せば当てられます（仮名化で、匿名化ではありません）。日付・金額・通貨・raw の参照は pii の取引でもそのまま索引に入ります。
• 通貨をまたいで金額を比べたいとき。amount_key の絞り込みは同じ通貨の中だけで意味があり、為替の換算はしません。
• 全文検索をしたいとき。全文検索（FTS5）は基盤の側で、この部品は構造化した絞り込みだけを送ります。fetch の索引への問い合わせの操作は v1 にありません。
• 墓標で、保管にある raw まで消したいとき。墓標は索引の項目だけを上書きします。保管が raw を本当に消したかは確かめません。fetch の索引の項目には墓標の操作がありません。
• 再起動の後やほかのプロセスでも、墓標にした取引の入れ直しを止めたいとき。墓標にした txn_id の控えはこのインスタンスの中だけです。控えを保つ場所は呼び出し側の運用です。
• Node.js v24.21.0 のほかの版で使うとき。ほかの版は確かめていません（NOT_VERIFIED）。

検査すること

• options が足りない・形が違う・2 つの profile が同じとき INVALID_OPTIONS、入力の形が違うとき INVALID_INPUT、取引の記録が索引に使える形でないとき INVALID_TXN、問い合わせの形が違うとき（amount_key に currency の EQ が無い など）INVALID_QUERY で止めます（where にその位置）。
• N-09 が fetch.json を受け取らないとき FETCH_RECORD_REFUSED、N-09 が投げた・答えが食い違うとき CHECK_PORT_FAILED で何も送りません。同じ folder_ref に別の fetch.json、同じ probe_version に別の文書のとき FETCH_INDEX_CONFLICT で送りません（直しは新しい probe_version）。
• G-12 が入力を受け取らないとき TXN_ID_REFUSED、G-12 が投げた・答えが食い違うとき TXN_ID_PORT_FAILED、計算し直した txn_id が記録と違うとき TXN_ID_MISMATCH（recomputed_txn_id を添える）で送りません。G-12 には 5 つの事実の写しだけを渡します。
• pii として送った txn_id を、ほかの区画で送る・墓標にするとき TXN_CLASS_CONFLICT、墓標にした txn_id を入れ直そうとするとき TXN_TOMBSTONED で送りません。
• 索引の書込の結果が分からないとき INDEX_UNKNOWN で保留にし、保留の間は INDEX_PENDING で操作を受けません。継手が送らなかったとき INDEX_REFUSED、索引に入らなかった・答えが照合できない・別の doc_ref・別の op・別の index_revision・DELETED のとき INDEX_FAILED です。
• 問い合わせの結果が分からないとき QUERY_UNKNOWN、送らなかったとき QUERY_REFUSED、結果の検め（score 1・NOT_VERIFIED・送った版・txn_id の形と重なり）に合わない・墓標にした txn_id が答えにあるとき QUERY_FAILED です。索引が答えなかったとき（query_state が ANSWERED でない）は QUERY_NOT_ANSWERED と query_state を返します。
• amountKey で金額が形・範囲（38 桁・scale 0〜18）の外のとき INVALID_AMOUNT、counterpartyKey で取引先の形が違うとき INVALID_COUNTERPARTY、区画が 3 つのどれでもないとき INVALID_RETENTION_CLASS です。timestamp が実在する日時を返さないとき CLOCK_FAILED で何も送らず、前の操作が終わっていないとき BUSY です。

しないこと・既知の限界

• 取得・取引の索引の部品は継手ではありません。自分の Request/Receipt は無く、索引の書込と問い合わせは、束ねた O-01 の継手が自分の契約（search-retrieval/v1）で行います（問い合わせは NONE）。この部品自身は外へ触れません。
• 束ねた部品の意味（索引に入れた ≠ 中身を確かめた・似ている ≠ 事実・記録を受け取れた ≠ 取得の正しさ・ID が合う ≠ 取引が実在する）は、それぞれの部品の側に残ります。索引の基盤（SQLite・FTS5）と全文検索は基盤の側です。
• 結果は事実でも承認でもありません（approval: false・authority: NOT_DERIVED、result_verification: NOT_VERIFIED、derives_authority: false）。
• DELETE は送りません。送るのは UPSERT の IndexRequest と STRUCTURED の QueryRequest だけです。
• 取引の記録は、索引に使う欄とキーの集合だけを検めます。明細などの中身の検めは G-13 の役目です。retention_class は呼び出し側が渡す値をそのまま使い、raw の区画と合っているかは確かめません。文書の中身を基盤へ渡すのは、呼び出し側と基盤の結線の役目です。
• 本物の O-01・N-09・G-12 には、この部品の試験では接続していません。単体試験とファズは代役です。結線の検めは通りましたが、墓標・query_state などの結線はその検めにありません。実の索引の基盤には接続していません。状態はプロセスの中だけで、再起動で消えます。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。
• 特定の検索エンジン・データベースの雛形ではありません。

つなぎ方

src/ledger-index.js の createLedgerIndex(options) で作り、{ ok, errors, instance } を返します。options は 2 つの索引の profile と revision・request_prefix・ports・任意の timestamp です。操作は indexFetch・indexTxn・tombstoneTxn・queryTxn・resolvePending・status・amountKey・counterpartyKey で、結果に approval: false が付きます。port は index.submit（O-01 の継手のクライアント）・checkFetchRecord（N-09）・computeTxnId（G-12）です。txn の索引の項目の型は TXN_FIELD_TYPES で宣言します。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

入力の形の検めは、画面の裏で必ず要ります。どのスキーマで検めたか分からないまま適合扱いすること、JSON の重複キーを見落とすこと、pattern の正規表現の破滅的なバックトラック（ReDoS）で処理が止まらなくなることを防ぎます。

使う場面

• 値が、呼び出し側の渡すスキーマ（type・properties・required・additionalProperties: false・enum・const・items・minItems/maxItems・minLength/maxLength・minimum/maximum・pattern）に合うかを、事実として出したいとき（checkContract）。
• スキーマの同一性を確かめてから検めたいとき。schema_ref.digest が "sha256:" と RFC 8785 の正準形の SHA-256 の 16 進と一致しなければ、値を検めず SCHEMA_UNKNOWN とし、conforms は false です。digest だけは schemaDigest({ schema }) で出せます。
• JSON の文字列（value_text、UTF-8 で 1 MiB まで）を自前の厳密な読み取りで読み、重複キーを DUPLICATE_KEY として位置つきで受け取りたいとき。重複は JSON.parse と同じく後の値で検めます。
• 足りない欄（missing）と、必要な能力のうち宣言に無いもの（capabilities_missing。capabilities_required から capabilities_declared を引いた集合）も、同じ呼び出しで受け取りたいとき。
• 未入力を空として扱わず、need_input にしたいとき。digest が無いとき、capabilities_required があって capabilities_declared が無いときは、state が need_input です。
• issue を決まった順で 1000 件まで受け取り、切ったことを issues_total と issues_truncated で知りたいとき。
• 時計・乱数・環境の locale を使わず、同じ入力から byte 単位で同じ出力が要るとき。キーの並びに関係なく、同じスキーマからは同じ digest ができます。

使わない場面

• 完全な JSON Schema の検証が要るとき。参照のキーワード ref・allOf/anyOf/oneOf・format・if/then・null の型・型の配列・タプルの items・数の小数の範囲などは扱わず、UNSUPPORTED_KEYWORD か INVALID_SCHEMA になります。
• 能力の宣言が本物か（権限の真正性）を確かめさせたいとき。この部品は宣言の集合の差を出すだけで、真正性は Host が確かめます。
• pattern に後方参照・後読み・先読み・入れ子の量指定子・\p・大文字と小文字を区別しない照合・m フラグ・s フラグを使いたいとき。扱わない形は SCHEMA_PATTERN_UNSAFE になり、適合しません。
• 値が業務として正しいか（スキーマの意味）を判断させたいとき。
• 読み取り済みの値（value）で重複キーを確かめたいとき。value では重複キーが見えず、duplicate_keys_checked は false です。整数でない数は受け取りますが、どの型・どの enum とも一致しません。
• I-01 の入力スキーマ検証の部品と同じ結果を期待するとき。キーワードの範囲も結果の形も違い、互換ではありません。
• Node.js v24.21.0 のほかの版で使うとき。ほかの版は確かめていません（NOT_VERIFIED）。

検査すること

• 引数の形が違うとき（知らないキー・getter・schema_ref か schema が無い・value_text と value の両方がある／どちらも無い・schema_ref の形の誤り）INVALID_ARGUMENT、値を調べること自体が例外になるとき（Proxy の罠など）INSPECTION_FAILED で止めます。
• 知っているキーワードの形が違うとき（type が 6 つの名前でない・required の重複・空の enum・items がスキーマでない・負の件数・pattern が u フラグの正規表現として読めないなど）INVALID_SCHEMA で止めます。知らないキーワードと additionalProperties の false 以外の値は UNSUPPORTED_KEYWORD の issue にし、スキーマを信用しません。
• pattern は 128 文字・命令 4,096 個・{n,m} の 1000 までで、後方参照・後読み・入れ子の量指定子は SCHEMA_PATTERN_UNSAFE にします。照合は自前の線形時間の照合器（Pike VM）で、手間の合計を先に数え、50,000,000 を超えるときは照合を始める前に RESOURCE_LIMIT で止めます。
• digest が無いときは need_input、違うときは done で、どちらも SCHEMA_UNKNOWN の issue とし、適合しません。書き方は "sha256:" と小文字の 16 進だけで、大文字や接頭辞なしは一致しません。capabilities_declared が無いときも need_input です。
• value_text が JSON（RFC 8259）として読めないとき（BOM・先頭の 0・制御文字・誤ったエスケープを含む）INVALID_JSON、単独のサロゲートは LONE_SURROGATE で、文字の位置 offset つきで止めます。入れ子 64 段・1 MiB・値の個数の上限を超えるときは RESOURCE_LIMIT です。
• value が素の JSON でないとき（undefined・関数・BigInt・NaN・Infinity など）INVALID_VALUE、能力の一覧が 1〜128 文字の重複のない文字列の配列（256 個まで）でないとき INVALID_CAPABILITIES で止めます。"__proto__" も普通のキーとして扱い、原型を書き換えません。
• 結果を、src の補助関数を使わずに規則から書き直した独立オラクルと突き合わせるファズで、不一致と fail-open が 0 であることを確かめました。pattern の照合は、オラクル側の Node.js の RegExp（u フラグ）と突き合わせています。

しないこと・既知の限界

• 返すのは事実だけです。inference と advice はいつも null で、結果は承認ではなく（result_is_approval: false）、権限も作りません（derives_authority: false）。
• 結果は、スキーマの決まった一部に値が合うかの事実です。値の意味の正しさ・利用の許可・権限の真正性を示すものではなく、データの検証サービスや権限の判定でもありません。
• pattern の照合の意味は、Node.js v24.21.0 の RegExp（u フラグ）と、生成した pattern と文字列で突き合わせたものです。ECMAScript の正規表現の全体を証明したものではありません。
• 照合の手間の上限（pattern_steps）と value の値の個数の上限（value_nodes）は、単体試験だけで確かめました（ファズでは生成していません）。
• 業務ごとの規則は持ちません。スキーマは呼び出し側が渡します。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。

つなぎ方

src/contract-check.js の checkContract({ schema_ref, schema, value_text | value, capabilities_declared?, capabilities_required? }) を呼びます（例外を投げません）。返すのは { ok: true, errors: [], facts }（state・conforms・schema_trusted・issues・missing など、inference: null・advice: null）か { ok: false, errors: [{ code, path, ... }] } です。schemaDigest({ schema }) は digest だけを出します。副作用・状態・外の接続・資格情報は無く、利用側が用意する port はありません。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

移行や連携のデータの写し替えで、確認していない対応や AI の案を事実として当てること、表に無い値を推測で埋めること、意味の違う 2 つの値（入金済と予約枠確保など）を 1 つにまとめてしまうこと、浮動小数点や丸めで合計が狂うことを防ぎます。

使う場面

• 確認済みの対応だけでレコードを先の形に写したいとき（reconcileMap）。status が candidate の対応と origin が ai_candidate の対応は当てず、candidates_not_applied に理由（STATUS_CANDIDATE・ORIGIN_AI_CANDIDATE）つきで並べます。
• 変換を 4 つ（copy の写し・enum_map の表による置き換え・unit の 10 進の正確な掛け算・decimal_scale の小数の桁そろえ）に限って使いたいとき。丸めはせず、rounding は "none" だけです。
• 件数・キー・合計を照合したいとき。合計は sum_paths の位置の 10 進の文字列と整数を BigInt で正確に足し、元・写した先・expected を比べた結果と、足せなかった値の数を一緒に出します。
• 欠損（missing_source_values）・未知（unknown_values。{ "unknown": true } のまま写す）・0・空を分けて数えたいとき。0・空の文字列・空の配列は値として写します。
• 未対応の欄・表に無い値・変換できない値・キーの重複と欠けを、隠さず一覧で受け取りたいとき（unmapped_fields・unmapped_values・transform_failures・duplicate_keys・missing_keys）。
• 時計・乱数・環境の locale を使わず、同じ入力から byte 単位で同じ出力が要るとき。外の境界・状態はありません。

使わない場面

• 対応の意味が正しいか（同名異義を本当に見分けたか）を判断させたいとき。SAME_NAME_DIFFERENT_TARGET は同じ元の位置から違う先の位置への対応を並べるだけで、違う名前の同じ意味は見つけません。
• 確認（status: confirmed・origin）が本物かを確かめさせたいとき。呼び出し側の記録によります。AI の案を人が採用したときは、呼び出し側が origin を human か registered にして渡します。
• 配列の中を添字でたどる位置や、配列の要素ごとの変換が要るとき。v1 は配列をまるごと写すか、未対応の葉として数えます。
• 単位の体系（次元・換算の正しさ）を確かめたいとき。from と to の名前の文字列を比べるだけで、factor の正しさは呼び出し側が持ちます。
• 丸めが要るとき。decimal_scale で 0 でない桁を捨てる必要があれば、INEXACT_SCALE として transform_failures に数えます。
• 変換の結果を適用・保存したいとき。この部品は写した候補を出すだけで、原子的な適用はこの部品の外の役目です。
• Node.js v24.21.0 のほかの版で使うとき。ほかの版は確かめていません（NOT_VERIFIED）。

検査すること

• 引数の形が違うとき（知らないキー・必要なキーが無い・id と版が 1〜256 文字でない・sum_paths の重複）INVALID_ARGUMENT、値を調べること自体が例外になるとき INSPECTION_FAILED、JSON Pointer の形でない（16 段・1024 文字を超える・単独のサロゲート）とき INVALID_PATH で止めます。
• 対応表の形が違うとき INVALID_MAP、transform の kind が 4 つ以外か rounding が "none" 以外のとき UNSUPPORTED_TRANSFORM で止めます（丸めを暗黙にしません）。
• レコードが素の JSON のオブジェクトでないとき（null・整数でない数・単独のサロゲート・{ "unknown": true } に似た形）INVALID_RECORDS、expected の形が違うとき INVALID_EXPECTED、上限を超えたとき RESOURCE_LIMIT（limit つき）で止めます。"__proto__" のキーで原型を書き換えません。
• 当てる候補の対応の中で、同じ先に 2 つ（TWO_SOURCES_ONE_TARGET）・先の位置の入れ子（TARGET_PATH_OVERLAP）・同じ元から違う先（SAME_NAME_DIFFERENT_TARGET）・同じ元の unit の from の違い（UNIT_MISMATCH）を競合として並べ、当てません。
• 1 つの enum_map の表で 2 つ以上の元の値が同じ先の値になるときは MERGED_ENUM_VALUES として並べ、merge_confirmed: true が無ければ当てません。
• enum の表に無い値は推測で埋めず unmapped_values に、10 進でない値（NOT_A_DECIMAL）と桁を捨てる値（INEXACT_SCALE）は transform_failures に数え、どちらも converted のその欄を作りません。key_path を読む対応が当たっていなければ state は need_input（KEY_NOT_MAPPED）です。
• 結果を、src の補助関数を使わずに規則から書き直した独立オラクルと突き合わせるファズで、不一致と fail-open が 0 であることを確かめました。

しないこと・既知の限界

• 返すのは事実だけです。inference と advice はいつも null で、結果は承認ではなく（result_is_approval: false）、権限も作りません（derives_authority: false）。
• 結果は、対応表とレコードから機械的に写した候補と照合の事実です。対応の意味の正しさ・データの移行の採用・適用の許可ではありません。採用と適用は Host・Runtime と人が行います。
• AI 由来の対応（ai_candidate）を事実にしません。converted は候補で、確定・適用ではありません。
• 業務ごとの意味の対応表は持ちません。対応表は呼び出し側が渡します。
• レコードの値の個数の上限（record_nodes）は単体試験とファズのまれな生成だけで確かめ、expected.keys の上限（100,000 個）は試験していません。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。

つなぎ方

src/map-reconcile.js の reconcileMap({ source_schema_id, target_schema_id, source_version, map, records, key_path, sum_paths?, expected? }) を呼びます（例外を投げません。入力を書き換えません）。返すのは { ok: true, errors: [], facts }（converted・candidates_not_applied・conflicts・reconciliation・need_input など、inference: null・advice: null）か { ok: false, errors: [{ code, path[, limit] }] } です。副作用・状態・外の接続・資格情報は無く、利用側が用意する port はありません。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

「元に戻す」の裏の差分で、古い版に patch を当ててしまうこと、保護された位置を書き換えること、取り消しで後の別の変更を壊すこと、逆にできない変更を一部だけ逆にして済ませることを防ぎます。

使う場面

• 2 つの版の JSON の差分を、old つきの patch（add・remove・replace）として出したいとき（diff）。オブジェクトのキーは UTF-16 の符号単位の順に歩きます。
• patch の逆を出したいとき（invert）。逆にできない操作（old の無い remove・replace）は NOT_INVERTIBLE として全部並べ、そのときは逆の patch を出しません。
• patch を当てた候補を、確定せずに出したいとき（apply）。base_revision が document_revision と違えば STALE_BASE、保護された位置に触れれば PROTECTED_PATH として、当てる前に全部並べます。committed はいつも false です。
• 目的（intent）ごとの取り消しの計画を出したいとき（plan_undo）。intent が同じ変更を新しい順に逆にしてつなぎ、後の取り消さない変更と重なる位置は LATER_CHANGE_OVERLAPS として並べます。
• AI がした intent の割り当て（intent_origin: ai_candidate）を事実にせず、candidate_intent_changes に分けたいとき。その変更は取り消しに入れず、残す変更として重なりの相手にします。
• 時計・乱数・環境の locale を使わず、同じ入力から byte 単位で同じ出力が要るとき。外の境界・状態はありません。

使わない場面

• 変更を確定・保存したいとき、版を採番したいとき。原子的な適用・保存・版の採番はこの部品の外の役目で、apply は候補を出すだけです。
• 文字列の中の文字単位の差分が要るとき。文字列が違えば replace 1 つです（文書の文字の断片編集は P-09 の範囲）。
• 配列の要素の挿入・移動を見つけたいとき。並べ合わせ（LCS など）はせず、先頭への挿入は後ろの要素の replace の列になります。
• RFC 6902 の JSON Patch として使いたいとき。move・copy・test と配列の末尾の "-" は扱わず、old を持つ点・add が既にあるキーに置かない点でも別のものです。
• 自然文の目的を変更に対応づけさせたいとき。割り当ては呼び出し側が決め、AI がした割り当ては ai_candidate として渡します。
• 外部への送信や決済の取り消しに使いたいとき。対象外です。
• 意味の上での依存（ある変更が別の変更を前提にしていること）を見たいとき。位置の重なりでしか見ません（意味の依存は P-04 の範囲）。
• Node.js v24.21.0 のほかの版で使うとき。ほかの版は確かめていません（NOT_VERIFIED）。

検査すること

• 引数が決まったキーだけを持つ素のオブジェクトでないとき（知らないキー・足りないキー・getter・列挙されないプロパティ・symbol のキー）INVALID_ARGUMENT、値を調べること自体が例外になるとき INSPECTION_FAILED、operation が 4 つのどれでもないとき UNSUPPORTED_OPERATION で止めます。
• 文書・value・old が JSON の値でないとき（undefined・NaN・単独のサロゲート・__proto__ というキー・穴のある配列・配列の派生クラス・クラスのインスタンスなど）INVALID_VALUE で止めます。
• patch の op が move・copy・test のとき UNSUPPORTED_OP、patch の形が違うとき（add・remove の path が根）INVALID_PATCH、JSON Pointer の形が違うとき（__proto__ という token を含む）INVALID_POINTER で止めます。
• 版が 1〜128 文字の整った文字列でないとき INVALID_REVISION、origin・intent_origin が語彙の外のとき INVALID_ORIGIN、変更の形が違うとき INVALID_CHANGE、同じ change_id が 2 つあるとき DUPLICATE_CHANGE_ID、上限（操作 10,000・深さ 64・値 200,000 個など）を超えたとき RESOURCE_LIMIT（limit つき）で止めます。
• apply では、STALE_BASE と PROTECTED_PATH（等しい・下・上・配列の詰め替えで動く位置）を当てる前に全部並べ、どちらかがあれば当てません。無ければ写しの上で順に当て、PRECONDITION_FAILED（old の不一致・add の位置に値がある）か PATH_NOT_FOUND（"-"・先頭の 0 を含む）の最初の 1 つで止めます。
• plan_undo では、履歴の途切れ（HISTORY_GAP）・現在の版との違い（STALE_BASE）・逆にできない変更（NOT_INVERTIBLE）・後の変更との重なり（LATER_CHANGE_OVERLAPS）を conflicts に並べ、1 つでもあれば undo_patch を出しません。取り消す変更が無ければ no_matching_change です。
• apply(base, diff(base, target)) の候補が target と等しく、apply(target, invert(diff(base, target))) の候補が base と等しいことを、単体試験とファズで確かめました。
• 結果を、src の補助関数を使わずに規則から書き直した独立オラクルと突き合わせるファズで、不一致と fail-open が 0 であることを確かめました。

しないこと・既知の限界

• 返すのは事実だけです。inference と advice はいつも null で、結果は承認ではなく（result_is_approval: false）、権限も作りません（derives_authority: false）。
• 結果は差分・逆・候補・計画の事実の提示で、変更の確定・保存・取り消しの実行ではありません。どの変更をどの目的に属させるか、候補を採用するかは、この部品の外（利用者・Runtime）で決めます。
• 配列の詰め替えの判定は token の形だけで行います。数字の形のキーを持つオブジェクトでも詰め替えとして扱い、多めに止めます。
• need_input は使いません。facts.state はいつも done で、止める理由は refusals・conflicts・not_invertible に並べます（このとき ok は true）。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。

つなぎ方

src/patch-conflict.js の patchConflict({ operation, ... }) を呼びます。diff・invert・apply・planUndo を直接呼ぶこともできます（例外を投げません。入力を書き換えません）。返すのは { ok: true, errors: [], facts }（state: "done"・operation と操作ごとの事実、inference: null・advice: null）か { ok: false, errors: [{ code, path }] }（RESOURCE_LIMIT は limit も）です。履歴・版・保存は呼び出し側が持ちます。副作用・状態・外の接続・資格情報は無く、利用側が用意する port はありません。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

変更の影響範囲は、表からは見えません。AI の候補の依存を登録済みの依存と混ぜて事実にすること、欠けた辺や版の違いを黙ってたどること、届かなかった node を「無関係」と扱うことを防ぎます。

使う場面

• 変更（changed）から、登録済みの辺だけで影響が届く node を、深さと最短の経路（path・edges）つきで出したいとき（analyzeProvenance）。同じ長さの経路は node の id の並びがいちばん小さいものを選びます。
• AI の候補の辺（ai_candidate）を使わないと届かない node を candidate_impacted に分け、経路の中の候補の辺の index も受け取りたいとき。impacted と candidate_impacted は重なりません。
• 循環を、登録済みの辺だけの強連結成分（cycles）と、候補の辺で初めてできる・大きくなる成分（candidate_cycles）に分けて受け取りたいとき。
• 無い node への辺（NODE_ABSENT）と版の違う辺（VERSION_MISMATCH）を missing として受け取り、それらをたどらずに state を need_input にしたいとき。
• 権限外の node（allowed: false）について、届いても id だけを not_allowed に出し、kind や version を出さないようにしたいとき。到達はその node を通って続けます。
• 探索の深さ（max_depth、1〜256、無ければ 256）を決め、深さで切ったことを depth_limit_hit（登録済みの探索と、候補を入れた探索の別）で知りたいとき。
• 時計・乱数・環境の locale を使わず、node の並びやキーの並びに関係なく、同じ入力から byte 単位で同じ出力が要るとき。

使わない場面

• 影響の有無や修正の要否を判断させたいとき。到達と欠けの事実を出すだけです。
• 届かなかった node が無関係だと示したいとき。unreached は探索の中で届かなかったという事実で、無関係であることの証明ではありません（unreached_meaning: not_reached）。
• 辺の種類（kind）ごとにたどり方を変えたいとき。kind は読まず、どの kind も同じにたどります。
• 版の前後関係を見たいとき。from_version・to_version は文字列の一致だけを見ます。
• allowed の印が正しいか（権限の真正性）を確かめさせたいとき、権限外の node の中身を遮らせたいとき。どちらも Host の役目で、Host は権限外の node の中身を渡しません。
• 辺の向きを部品に決めさせたいとき。辺 { from, to } は「from が変わると to に響く」の向きで渡します（来歴なら 元 → 派生）。
• Node.js v24.21.0 のほかの版で使うとき（NOT_VERIFIED）や、上限いっぱいの入力の時間とメモリーを前提にしたいとき。上限いっぱいの入力は単体試験で 1 回ずつ確かめただけで、時間とメモリーは測っていません。

検査すること

• 入力が素のデータでないとき（getter・クラスのインスタンス・穴のある配列・配列の余分なプロパティ・記号のキー・列挙できないプロパティ）、知らないキー・足りないキー・null・語彙の外の値（origin が registered・ai_candidate 以外など）・1〜128 文字でない id・単独のサロゲートがあるとき INVALID_INPUT で止めます。
• max_depth が 1〜256 の整数でないとき INVALID_INPUT、値を調べること自体が例外になるとき（Proxy の罠・取り消された Proxy）INSPECTION_FAILED、id が重なるとき DUPLICATE_ID で止めます。
• 上限（nodes 100,000 件・edges 400,000 件・changed 100,000 件・出力の経路の node id の合計 4,000,000）を超えたら、どの上限かを limit に入れて RESOURCE_LIMIT で止めます。失敗を空の成功にしません。
• 辺の from_version・to_version が書かれていて、その node の version と違えば VERSION_MISMATCH、端の node が無ければ NODE_ABSENT として missing に出します。その辺はたどらず、循環の計算にも入れません。
• 版の違う変更の node は、変わったことを Host が述べた事実として始点にし、VERSION_MISMATCH も出します。変更された node 自身は impacted・candidate_impacted・unreached のどれにも入れません。
• 止めるときは最初に見つけた 1 つだけを { code, path, limit? } で返します。path は JSON Pointer（入力全体は空文字）です。
• 結果を、src の補助関数を使わずに規則から書き直した独立オラクルと突き合わせるファズで、不一致と fail-open が 0 であることを確かめました。

しないこと・既知の限界

• 返すのは事実だけです。inference と advice はいつも null で、結果は承認ではなく（result_is_approval: false）、権限も作りません（derives_authority: false）。AI 由来（ai_candidate）のものを事実に変えません。
• 結果は到達と欠けの事実の提示で、影響の有無・修正の要否の判断ではありません。影響の判断や修正の計画の代行でもありません。最終の権限・遮断・適用は Host と Runtime の役目です。
• max_depth で切った場合、登録済みの辺では深い位置にある node が、候補の辺の短い経路で candidate_impacted に入ることがあります（そのとき depth_limit_hit.registered は true です）。
• 入出力の形は v1 で定めたもので、使う側の受け入れはまだ済んでいません。
• ファイル・通信を使わず、資格情報を持ちません。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。

つなぎ方

src/provenance-graph.js の analyzeProvenance({ nodes, edges, changed, max_depth? }) を呼びます（例外を投げません。入力を書き換えません）。返すのは { ok: true, errors: [], facts }（state・impacted・candidate_impacted・cycles・candidate_cycles・missing・not_allowed・unreached・depth_limit_hit・need_input、inference: null・advice: null）か { ok: false, errors: [{ code, path, limit? }] } です。副作用・状態・外の接続・資格情報は無く、依存パッケージも無く、利用側が用意する port はありません。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

予定を組むときに、不可分の工程を短い枠へ縮めて入れてしまうこと、探索を途中で打ち切っただけなのに「成り立たない」と言ってしまうこと、最適だと証明できていない案を最適として出すこと、分からない所要時間や時間窓を推測で埋めることを防ぎます。

使う場面

• 工程（0〜200 件）と枠（0〜200 件）から、目的 objective に合わせて割当の案を出したいとき（solveSchedule）。目的は feasible（全部置ける案）・min_unassigned（外す工程の数の最小）・earliest_finish（全部置いたときのいちばん遅い終わりの最小）の 3 つです。
• 不可分の工程（indivisible: true）を、1 つの枠に duration.min の長さのまま丸ごと置きたいとき。枠と時間窓の重なりが min より短ければ、その枠には入れません（20 分の不可分工程を 10 分の枠へ入れません）。
• 分けられる工程を、どの部分も splittable_min 以上、合計がちょうど duration.min になるように分けて置きたいとき。同じ工程の部分は時間が重ならず、part は時間の順に 1 から振られます。
• 前提（requires）・資源（resource）・時間窓（window）を守った割当が要るとき。前提の工程はこの工程のどの部分よりも前に終わり、前提の工程が置かれなければこの工程も置きません。資源は工程と枠の両方にあるときだけ一致を求めます。
• 成り立たないことを、理由のコードつきで受け取りたいとき。静的な理由（NO_SLOTS・NO_SLOT_FOR_RESOURCE・WINDOW_EMPTY・INDIVISIBLE_TOO_LONG・CAPACITY_TOO_SMALL・PRECEDENCE_CYCLE）と、探索を尽くした印 SEARCH_EXHAUSTED を reasons に出します。
• 探索の手数を max_nodes（1〜1,000,000）で区切り、上限に届いたことを search_limit_reached と status（search_limit）で、最適性を optimality（proven か not_proven）で区別して受け取りたいとき。
• AI 由来の工程（origin: ai_candidate）を含むかどうかを、割当の行の origin・ai_candidate_tasks・plan_includes_ai_candidate で分けて受け取りたいとき。
• 時計・乱数・環境の locale を使わず、配列の並びやキーの並びに関係なく、同じ入力から byte 単位で同じ出力が要るとき。

使わない場面

• 案を採るか、工程を分け直すか、所要時間が正しいかを判断させたいとき。結果は割当の案と成り立たない理由・探索の上限の事実で、採用・実行の判断ではありません。
• 工程の分け方や所要時間を部品に決めさせたいとき。どちらも呼び出し側が決めて渡します。この部品は工程を作らず、所要時間を推測しません。
• 同じ人の時間の重なる 2 つの枠に、違う工程を同時に置くことを止めさせたいとき。枠どうしは独立の受け皿として扱います。1 人の予定なら、呼び出し側が重ならない枠を渡します。
• 工程の間の移動・準備の時間、暦・時間帯、分より細かい時刻を扱いたいとき。時刻と長さは 0〜100,000,000 の整数の分だけです。
• 重み・優先・柔らかい制約・締切の遅れの最小などの目的が要るとき。目的は 3 つだけで、ほかは UNSUPPORTED_OBJECTIVE で止めます。min_unassigned は工程の数を数え、長さは数えません。
• min より長くかかる工程の余裕を取りたいとき。duration.max は形を検めるだけで、置く長さはいつも duration.min です。
• 大きな問題を決まった時間で解きたいとき。探索は指数的で、大きな問題では search_limit になりえます。速さは約束しません。max_nodes に達すると必ず止まります。
• Node.js v24.21.0 のほかの版で使うとき。ほかの版は確かめていません（NOT_VERIFIED）。

検査すること

• 引数が { tasks, slots, objective, search } の 4 つのキーだけを持つ素のオブジェクトでないとき INVALID_ARGUMENT、値を調べること自体が例外になるとき（Proxy の罠など）INSPECTION_FAILED、素のデータでないとき（getter・クラスのインスタンス・穴のある配列・配列の余分なプロパティ・symbol のキー・__proto__ のキー・列挙されないキー）NOT_PLAIN_DATA で止めます。素のデータに写してから検め、検めた値と探索に使う値は同じです。
• 工程の形が違うとき（知らないキー・足りないキー・id・origin・indivisible の形、duration.min が 1 未満・max が min 未満・整数でない、不明の印の形の違い、不可分の工程の splittable_min・min を超える splittable_min、requires の重複・配列でない、時間窓の end が start 以下・負の値）INVALID_TASK で止めます。null は受け取りません。
• 枠の形が違うとき（end が start 以下・整数でない・負など）INVALID_SLOT、search が { max_nodes } でないとき INVALID_SEARCH、objective が 3 つの目的のどれでもないとき UNSUPPORTED_OBJECTIVE、同じ id の工程か枠が 2 つあるとき DUPLICATE_ID、requires が無い工程の id を指すとき UNKNOWN_TASK_REF で止めます。
• 上限（工程 200 件・枠 200 件・前提は工程ごとに 200 件・max_nodes 1,000,000・時刻と長さ 100,000,000 分・配列 4096 要素・入れ子 4 段）を超えたら、どの上限かを limit に入れて RESOURCE_LIMIT で止めます。止めるときは { code, path, limit? } を返し、path は JSON Pointer です。
• duration か window が不明の印 { unknown: true } のとき、推測せず state を need_input にし、足りないものを need_input に並べます。探索はせず、status・assignment・objective_value は null、reasons は空です（途中までの結果を出しません）。
• feasible と earliest_finish では、静的な理由が 1 つでもあれば探索せず infeasible にします（nodes_explored は 0）。上限に届いて案が無ければ infeasible と言わず search_limit にし、上限に届いた後に残った案は not_proven にします（search_limit_reached が true なら nodes_explored = max_nodes）。
• 結果を、src の補助関数を使わずに規則から書き直した独立オラクル（小さな問題の総当たりと割当の検算を含む）と突き合わせるファズで、不一致と fail-open が 0 であることを確かめました。

しないこと・既知の限界

• 返すのは割当の事実だけです。inference と advice はいつも null で、出力のどの文字列にも直し方や優先の語を入れません。結果は承認ではなく（result_is_approval: false）、権限も作りません（derives_authority: false）。AI 由来の工程（ai_candidate）を事実に変えず、正しいかも判断しません。
• 結果は割当の案と成り立たない理由・探索の上限の事実の提示で、予定の判断や実行ではありません。案を採るか、工程を分け直すか、所要時間が正しいかは、この部品の外で利用者が決めます。
• 探索が完全であること（全部置ける案があれば見つかること）は、左詰めの議論と、小さな問題の総当たりとの 1,000,000 回の突き合わせで確かめました。形式的な証明はしていません。
• 総当たりの突き合わせは、工程 4 件・枠 3 件・時刻 20 前後までの小さな問題だけです。それより大きな問題の infeasible・proven は、総当たりでは確かめていません。
• nodes_explored はこの部品の決まった数え方で、ほかの解き方の手数とは比べられません。同じ値の案のどれを出すかは探索の順で決まります。
• 入出力の形と手数の数え方は v1 で定めたもので、既存の実装はありません（新規）。
• 外の境界・状態・時計・乱数を持ちません。副作用は NONE で、資格情報も使いません。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。

つなぎ方

src/constraint-schedule.js の solveSchedule({ tasks, slots, objective, search }) を呼びます（例外を投げません。入力を書き換えません）。返すのは { ok: true, errors: [], facts }（state・status・optimality・assignment・unassigned・reasons・need_input・search_limit_reached など、inference: null・advice: null）か { ok: false, errors: [{ code, path, limit? }] } です。副作用・状態・外の接続・資格情報は無く、依存パッケージも無く、利用側が用意する port はありません。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

試算や判定の式を評価するときに、浮動小数点の誤差が値に入ること、0 での割り算や範囲外の結果が 0 や NaN として紛れ込むこと、欠けた入力を推測で埋めて途中までの計算を出してしまうこと、規則の評価が止まらない繰り返しやコードの実行になることを防ぎます。乱数も明示の seed からだけ作るので、同じ入力と seed から同じ結果を出します。

使う場面

• モデル（params で引数と単位を宣言し、outputs に出力ごとの式を書いたもの）と inputs（値・単位・origin）から、出力ごとの値と正準の単位を 10 進の文字列で出したいとき。式の演算は + - * / min max neg、round（scale 0〜34、half_even・half_up・floor・ceil）、rand です。
• 1 つの引数を sweep で 1〜1000 点動かし、点ごとの値を並べたいとき（点の数 × 節の数は 1,000,000 まで）。
• 乱数を含む式を、明示の seed（0〜2^53−1 の整数）から再現できる形で評価したいとき。生成器は seed から SplitMix64 で 4 語を作る xorshift128 で、出力ごと・走査の点ごとに始め直します。
• 単位の次元をそろえて計算したいとき。単位は記号ごとの指数の組で比べ、* と / は指数を足し引きし、+ - min max は次元がそろうことを求めます。
• 役（roles）・手（moves の when と effects）・終わり（end）で書いた限定ルールと状態から、evaluateRules で役ごとの合法手、手を渡したときの次の状態（候補）か ILLEGAL_MOVE と成り立たなかった最初の条件、終わりと結果を出したいとき。
• 手の列を runRules で max_steps（1〜1000）まで順に当て、当てられなかった最初の手で止めて、その前までの状態を final_state として受け取りたいとき。
• AI 由来（origin が ai_candidate）のモデル・入力・走査・規則を使ったかどうかを、basis（registered_only か includes_ai_candidate）と candidate_sources の位置で分けて受け取りたいとき。

使わない場面

• 結果を実際の需要の予測として使いたいとき。結果は渡された式の計算です。モデルの式・規則・入力の値が正しいかは確かめません。
• 単位の換算（例えば m と km）を部品にさせたいとき。同じ次元の別の単位は別の記号として扱います。係数を掛けるなら式に書きます。
• 暗号用の乱数や、統計の検定を通った乱数が要るとき。xorshift128 は暗号用ではなく、統計の検定はしていません。
• 引数のある手、同時の手番、隠れた情報の確率、時間切れを含む規則を扱うとき。限定ルールにはこれらがありません。
• 繰り返し・再帰・式の評価・コードの実行を規則に書きたいとき。語彙の外は UNSUPPORTED_CONSTRUCT で止めます。
• 状態に真偽値・null・小数を入れたいとき。状態の値は整数・文字列・配列・オブジェクト・UNKNOWN の印 { unknown: true } だけです。
• Node.js v24.21.0 のほかの版で使うとき。ほかの版は確かめていません（NOT_VERIFIED）。

検査すること

• 引数が決まったキーだけを持つ素のオブジェクトでないとき INVALID_ARGUMENT、値を調べること自体が例外になるとき（Proxy の罠など）INSPECTION_FAILED で止めます。getter・クラスのインスタンス・穴のある配列・null・__proto__ のキーは受け取らず、素のデータに写してから検めます。
• 入力の形が違うとき（知らないキー・足りないキー・語彙の外の origin・名前の形・重複・JSON Pointer の形など）INVALID_INPUT、10 進の文字列が決まった形でない・有効桁が 34 桁を超える・範囲（0 か 10^-100 ≤ |値| < 10^100）の外・"-0" のとき INVALID_DECIMAL、単位の文字列の形が違う・合わせた指数が 64 を超えるとき INVALID_UNIT で止めます。
• 宣言の無い引数・役を指すとき UNKNOWN_NAME、足し算・引き算・min・max の単位の次元が違うときと入力・走査の単位が宣言と違う次元のとき UNIT_MISMATCH、式に rand があるのに seed が無いとき SEED_REQUIRED、式の演算子・丸めの方法・条件や効果の op が語彙の外のとき UNSUPPORTED_CONSTRUCT で止めます。
• 上限を超えたとき RESOURCE_LIMIT で止め、limit に上限の名前を入れます。上限は、式の深さ 64・節 10,000・走査 1000 点・状態 256 KiB と深さ 64・文字列 4096 文字・効果の値 4 KiB・max_steps 1000 などです。手を当てた後の状態の大きさもここで確かめます。
• 使う引数に欠け（MISSING）か UNKNOWN が 1 つでもあれば、推測せず state を need_input にし、points を空にします（途中までの計算を出しません）。0 での割り算と範囲外の結果は、その出力だけ DIVISION_BY_ZERO・OUT_OF_RANGE と起きた節の位置で示し、値を 0 や NaN にしません。
• 手は 定義→役→終わり→条件→効果 の順に確かめ、合法でなければ ILLEGAL_MOVE と成り立たなかった最初の条件（または MOVE_NOT_DEFINED・ROLE_MISMATCH・ENDED）を返します。効果を当てられなければ EFFECT_FAILED とし、手全体を捨てます（next_state は null）。状態の UNKNOWN の奥を読む条件や効果は、合法とも違反とも言わず undetermined にし、印の位置を need_input に並べます。
• 結果を、src の補助関数を使わずに書いた独立オラクルと突き合わせるファズで、不一致と fail-open が 0 であることを確かめました。

しないこと・既知の限界

• 返すのは計算の事実だけです。inference と advice はいつも null で、出力のどの文字列にも判断の語を入れません。結果は承認ではなく（result_is_approval: false）、権限も作りません（derives_authority: false）。
• 結果は渡された式と規則の評価の事実で、モデルや規則が正しいこと、実際の需要の予測、遊びとしての良し悪しの判断ではありません。需要の予測・遊びの設計・規則の判定の代行もしません。式・規則・入力の値が妥当かは、使う側で確かめます。
• コードに固有の式や遊びの規則を持ちません。式・単位・規則・状態はすべて入力から受け取ります。
• 34 桁の丸めを節ごとに重ねたときの誤差の大きさは評価しません。数値の不安定さとして出すのは precision_rounded と OUT_OF_RANGE の印だけです。
• 状態の上限（256 KiB・深さ 64）は 1 手を当て終えた後に確かめ、1 手の途中の大きさは見ません。
• 時計・環境の locale・外の境界・状態を持ちません。副作用は NONE で、資格情報も使いません。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。

つなぎ方

src/model-rule.js の evaluateModel({ model, inputs, sweep?, seed? })、evaluateRules({ rules, state, role, move?, max_steps? })、runRules({ rules, state, moves, max_steps }) を呼びます（例外を投げません）。返すのは { ok: true, errors: [], facts }（state が done か need_input、inference: null・advice: null）か { ok: false, errors: [{ code, path, limit? }] }（path は JSON Pointer）です。副作用（NONE）・状態・外の接続・資格情報は無く、利用側が用意する port はありません。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

「その根拠は今も使えるか」を確かめるときに、一部の条件だけが合う主張を全面的に当てはまるとしてしまうこと、資料が更新されたのに前の評価を使い続けること、「不明と入力された」と「まだ入力されていない」を混ぜてしまうこと、推論や仮説を事実に格上げしてしまうことを防ぎます。

使う場面

• 主張（0〜10,000 件）ごとの条件（0〜50 件、op は eq・ne・in・lt・le・gt・ge）を、current.conditions の現在の値と比べ、applies を match・mismatch・unknown で出したいとき。偽の条件があれば mismatch、偽が無く不明・未入力・比べられないものがあれば unknown、すべて真なら match です。
• 出典の版（source.version）を current.source_versions と比べ、source_status（current・changed・not_entered・unknown）と stale を主張ごとに出したいとき。出典が current でなければ applies は unknown です。
• { "unknown": true } と入力された値と、キーが無い（未入力の）値を分けたいとき。未入力だけを need_input（CONDITION_NOT_ENTERED・SOURCE_VERSION_NOT_ENTERED・SUPPORT_NOT_ENTERED）に並べ、state を need_input にします。0・false・空の文字列は値として扱います。
• 主張の型（type）と出どころ（origin）をそのまま保ち、AI 由来（ai_candidate）の主張を candidate_claims に分けて受け取りたいとき。
• supports で書いた主張どうしの支えの関係を、主張ごとに型つきの最短の鎖（id・type・origin・depth・chain）として並べ、循環を support_cycles と in_support_cycle で知りたいとき。循環は止めずに出します。
• applies が unknown や mismatch になった理由を、reasons（決まった順）と failed・unknown_keys・missing_keys・not_comparable_keys で主張ごとに受け取りたいとき。

使わない場面

• 主張が正しいか、採用するかを判定させたいとき。match は渡された条件と現在の値の照合の結果で、主張が真実であることは示しません。主張の内容と出典の位置（locator）の正しさも確かめず、locator はそのまま返すだけです。
• 小数・日付・範囲・文字列の大小・正規表現で条件を比べたいとき。比べるのは文字列・整数・真偽値の一致と整数の大小だけです（日付は呼び出し側が整数にして渡します）。
• 出典の版の前後関係（どちらが新しいか）を見たいとき。新旧は版の文字列の一致だけで見ます。出典の現在の版は呼び出し側が確かめて渡し、この部品は資料を読みません。
• 支えるものの結果で、支えられる主張の applies を変えたいとき。applies は自分の条件だけで決まります。
• 支えの鎖をすべて列挙したいとき。出すのは最短の鎖 1 本だけです。
• Node.js v24.21.0 のほかの版で使うとき。ほかの版は確かめていません（NOT_VERIFIED）。

検査すること

• 入力の形が違うとき（素のデータでない・知らないキー・足りないキー・語彙の外の値・型が違う・null・id が 1〜128 文字でない・単独のサロゲート・集合に同じ値が 2 回）INVALID_INPUT、値を調べること自体が例外になるとき（Proxy の罠・取り消された Proxy など）INSPECTION_FAILED で止めます。
• getter・クラスのインスタンス・穴のある配列・配列の余分なプロパティ・記号のキー・列挙できないプロパティ・null は受け取りません。読んだ値の写しだけで計算し、入力を書き換えません。
• id が重なるとき DUPLICATE_ID、条件の演算子が eq・ne・in・lt・le・gt・ge のどれでもないとき UNSUPPORTED_OPERATOR で止めます。in の値が 0 件か 65 件以上のとき、lt・le・gt・ge の値が安全な整数でないときも止めます。
• 上限（claims 10,000 件・1 つの主張の conditions 50 件・in の値 64 件・supports 64 件・current.conditions と source_versions 各 10,000 個・出力の支えの鎖の id の合計 2,000,000）を超えたとき RESOURCE_LIMIT で止め、limit に上限の名前を入れます。
• 等しさは型も含めて厳密に見ます（"5" と 5、true と 1 は違う）。lt・le・gt・ge で現在の値が整数でないときは偽にせず not_comparable とし、applies を unknown にします。
• 止めるときは、最初に見つけた 1 つだけを { code, path, limit? } で返します（path は JSON Pointer）。
• 結果を、src の補助関数を使わずに書いた独立オラクルと突き合わせるファズで、不一致と fail-open が 0 であることを確かめました。

しないこと・既知の限界

• 返すのは事実だけです。inference と advice はいつも null です。結果は承認ではなく（approval: false）、権限も作りません（derives_authority: false）。
• 結果は条件の当てはまりと出典の版の事実の提示で、主張が正しいかの判断でも、採否の判断の代行でもありません。主張の真実性は約束せず、権利の認定もしません。最終の権限・遮断・適用は Host と Runtime の役目です。
• 支えの鎖に fact があっても、inference・hypothesis を格上げしません。主張をまとめることもしません。
• 条件のキーと値の意味（何をもって成立とするか）は決めません。呼び出し側が決めて渡します。
• 入出力の形はこの部品の v1 で定めたもので、使う側の受け入れはまだです。上限いっぱいの入力は単体試験で 1 回ずつ確かめただけで、時間とメモリーの測定はしていません。
• 時計・乱数・環境の locale・外の境界・状態・資格情報を持たず、ファイル・通信を使いません。副作用は NONE です。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。

つなぎ方

src/evidence-claim.js の evaluateClaims({ claims, current }) を呼びます（例外を投げず、入力を書き換えません）。受け取るのは主張の一覧 claims と、現在の条件と出典の版 current です。返すのは { ok: true, errors: [], facts }（claims・candidate_claims・support_cycles・need_input、inference: null・advice: null）か { ok: false, errors: [{ code, path, limit? }] }（path は JSON Pointer）です。副作用（NONE）・状態・外の接続・資格情報は無く、利用側が用意する port はありません。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

画面と処理のあいだの変換で、データに無い欄を空の値と取り違えること、表示の設定で編集できない欄を編集できるようにしてしまうこと、表示の定義にスクリプトや関数が混ざること、操作のたびに AI を呼ぶことを防ぎます。

使う場面

• 表示契約の fields（path・label_key・kind（text・number・enum・list・bool）・editable・range・enum・max_length）に従って、entity.data から欄ごとの view（value・value_state・editable）を作りたいとき。
• 欄の値を value_state（present・missing・unknown・kind_mismatch・out_of_contract）で分けたいとき。データに無い欄は { missing: true }、{ unknown: true } は不明のまま、型の違う値は { kind_mismatch: true } として出し、空の文字列・0・false・空の一覧と区別できます。
• settings（hidden・order・editable）で欄を隠す・並べ替える・編集不可にしたいとき。隠した欄は view から除き、hidden に並べます。
• 操作 event（event_type・event_id・path・value）を、(event_type, path) の組で選んだ command 定義（op は set・increment・select・toggle）に照らし、型付きの command（op・path・value・base_version・event_id・event_type）の候補に変えたいとき。base_version には渡した entity_version を写します。
• 操作の違反（UNKNOWN_EVENT・NOT_EDITABLE・VALUE_KIND_MISMATCH・RANGE_VIOLATION）と、値が無い・不明の event の need_input（VALUE_ABSENT・VALUE_UNKNOWN）を、ok: false ではなく事実として受け取りたいとき。

使わない場面

• 画面を描画したいとき、権限を判断したいとき、操作を適用したいとき。この部品は表示と操作の変換だけをします。描画は App、権限・基底版の照合・適用は Host（Runtime）の役目です。
• 表示契約が登録済みか、版が正しいか、entity の版が今の版かを確かめたいとき。渡された契約と版を写して返すだけです。
• 小数や 10 進の文字列の数を扱うとき、文字列以外の要素の一覧を扱うとき。number は安全な整数だけ、list は文字列の配列だけです。
• 表示の文言の辞書や翻訳が要るとき。label_key は id の形だけを検め、文言は持ちません（App の役目）。
• 同じ event_id の再送を見分けたいとき。重複は判定しません。
• Node.js v24.21.0 のほかの版で使うとき。ほかの版は確かめていません（NOT_VERIFIED）。

検査すること

• 引数が決まったキーだけを持つ素のオブジェクトでないとき INVALID_ARGUMENT、値を調べること自体が例外になるとき（Proxy の罠など）INSPECTION_FAILED で止めます。getter・クラスのインスタンス・穴のある配列・__proto__ のキー・記号のキー・null は受け取らず、素のデータに写してから検めます。
• どこかに関数があるとき、表示契約・設定に宣言に無いキーがあるとき SCRIPT_REFUSED で止めます。式やスクリプトを評価する経路はありません。
• 表示契約の形が違うとき（kind・op の語彙の外、op と kind の組の違い、min > max、enum の空や重なり、max_length の範囲外、path や (event_type, path) の重なり、command の path が欄に無いなど）INVALID_CONTRACT で止めます。command の制約 allowed で欄の enum を広げることもここで止めます。
• entity の形が違うとき INVALID_ENTITY、entity.kind が契約の entity_kind と違うとき ENTITY_KIND_MISMATCH、設定の形が違うとき INVALID_SETTINGS、設定が契約に無い path を名指しするとき SETTINGS_PATH_UNKNOWN、event の形が違うとき INVALID_EVENT で止めます。
• 契約が編集不可の欄を設定で編集可にしようとしたとき EDITABLE_WIDEN_REFUSED で止めます。表示の違いで権限を増やしません。command は契約の editable だけを見ます。
• command では、組が無ければ UNKNOWN_EVENT、欄が編集不可なら NOT_EDITABLE、値の型が合わない・toggle に値があるとき VALUE_KIND_MISMATCH、範囲を外れれば RANGE_VIOLATION を返します。値は欄の制約と command の制約の両方を満たすときだけ通します。
• 上限（入れ子 32 段・値の数 200,000・文字列 65,536・配列 10,000 要素・欄 256・command 256・enum と allowed 各 256）を超えたとき RESOURCE_LIMIT で止め、limit に上限の名前を入れます。
• 結果を、src の補助関数を使わずに書いた独立オラクルと突き合わせるファズで、不一致と fail-open が 0 であることを確かめました。

しないこと・既知の限界

• 返すのは変換の事実だけです。inference と advice はいつも null です。結果は承認ではなく（approval: false）、権限も作りません（derives_authority: false）。AI を呼ばず、時計・乱数・ファイル・通信も使いません。
• command は候補で、適用ではありません。適用・基底版の照合・権限の真正性・同時更新の競合は Host（Runtime）の役目です。
• increment の適用後の値が欄の range に入るかは確かめません。基底版の値を持たないため、command の range で増減の幅だけを限ります。
• out_of_contract の値は隠さずそのまま写して出します。kind_mismatch の値は出しません。
• 画面・描画エンジン・権限の仕組みではありません。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。

つなぎ方

src/view-model.js の project({ contract, entity, settings? }) と command({ contract, entity_version, event }) を呼びます（どちらも例外を投げず、入力を書き換えません）。返すのは { ok: true, errors: [], facts }（project は view・hidden、command は command・violation・need_input。inference: null・advice: null）か { ok: false, errors: [{ code, path, limit? }] }（path は JSON Pointer）です。副作用（NONE）・状態・外の接続・資格情報は無く、利用側が用意する port はありません。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

コメントや参照の位置が、文書の改版でずれる事故を防ぎます。改版後に曖昧になった位置を勝手に 1 つに決めないこと、絵文字などのサロゲートの組を割った位置を作らないこと、保護された文字に触れる編集を差分にしないこと、消した文字を失わないことを、決まった規則で行います。

使う場面

• ある版で作ったアンカー（doc_version・block_id・start・end・quote・prefix・suffix）を、今の文書（version・blocks）の中で探し直し、status（exact・relocated・ambiguous・lost）と location を受け取りたいとき（operation: resolve）。
• 探し直しを決まった段の順で行いたいとき。exact（同じ版・位置の文字が quote と同じ）→ 前後つき（prefix+quote+suffix）が同じブロック → 前後つきが全部のブロック → quote だけが同じブロック → quote だけが全部のブロック の順で、一致が 1 つでもあった最初の段で決めます。
• 曖昧な位置を確定させたくないとき。一致が 2 つ以上なら ambiguous とし、location を null にして候補を全部並べます（一覧は 1,000 件まで、candidate_count は全部の数、candidates_truncated で切ったことを示します）。
• ブロックの [start, end) を replacement に置き換える断片の編集から、diff（消した文字 removed と入れた文字 inserted を含む）と new_block_text を候補として受け取りたいとき（operation: edit）。replacement の出どころ（registered・human・ai_candidate）は replacement_origin として返します。
• 呼び出し側が決めた保護範囲（protected）に重なる編集を止めたいとき。重なれば status を refused とし、violations に PROTECTED_RANGE を並べ、diff と new_block_text を null にします。

使わない場面

• 置き換えた後に前後の文の意味が保たれるかを判定させたいとき。見るのは文字の保護だけで、meaning_checked はいつも false です。
• Unicode の正規化（NFC・NFKC）、大文字・小文字・空白の違いを同じとみなしたいとき、似た文をあいまいに探し直したいとき。比べるのは符号単位だけです。
• 書記素（結合文字・絵文字の ZWJ 列・異体字セレクタ）の境目を守りたいとき。割らないのはサロゲートの組だけです。
• ブロックをまたぐアンカーや編集を扱うとき、ブロックの分割・結合を追いかけたいとき。
• 文書の保存、版の採番、共同編集の競合の処理、出典（どの資料のどの版か）の保持が要るとき。この部品はアンカーと版を返すだけです。
• Node.js v24.21.0 のほかの版で使うとき。ほかの版は確かめていません（NOT_VERIFIED）。

検査すること

• 引数が決まったキーだけを持つ素のオブジェクトでないとき（知らないキー・足りないキー・getter・列挙されないプロパティ・symbol のキー）INVALID_ARGUMENT、値を調べること自体が例外になるとき（Proxy の罠など）INSPECTION_FAILED、operation が resolve・edit のどちらでもないとき UNSUPPORTED_OPERATION で止めます。
• 文書の形が違うとき（単独のサロゲートを含む文など）INVALID_DOCUMENT、同じ id のブロックが 2 つあるとき DUPLICATE_BLOCK_ID、アンカーの形が違うとき（start > end、quote の長さが end − start でない、prefix・suffix が 32 符号単位を超えるなど）INVALID_ANCHOR で止めます。
• 編集の形が違うとき INVALID_EDIT、origin が語彙の外のとき INVALID_ORIGIN、保護範囲の形が違う・空・文書に無いブロック・長さを超える・組の間のとき INVALID_PROTECTED、編集する block_id が無いとき BLOCK_NOT_FOUND、end が文の長さを超えるとき INVALID_RANGE、start か end が組の間のとき SURROGATE_SPLIT で止めます。
• 上限を超えたとき RESOURCE_LIMIT で止め、limit に blocks（10,000）・document_bytes（文の UTF-8 の合計 1,048,576 バイト。編集の後の文書も）・protected（1,000）のどれかを入れます。
• 消す範囲 [start, end) が保護範囲と 1 文字でも重なるとき、または挿入（start = end）が保護範囲の内側（両端を除く）にあるとき、PROTECTED_RANGE を violations に並べ、差分を出しません（ok は true）。
• 一致は重なりも数え（"aaa" の中の "aa" は 2 か所）、ブロックをまたいだ一致はしません。出力の位置にも、編集・保護の位置にも、サロゲートの組の間を使いません。
• 結果を、src の補助関数を使わずに書いた独立オラクルと突き合わせるファズで、不一致と fail-open が 0 であることを確かめました。

しないこと・既知の限界

• 返すのは事実だけです。inference と advice はいつも null で、resolve は文書の文を出しません。結果は承認ではなく（approval: false）、権限も作りません（derives_authority: false）。
• edit は候補を出すだけで、文書を確定・保存しません（committed はいつも false）。ambiguous の候補からどれを選ぶか、編集を採用するかは、この部品の外（利用者・Runtime）で決めます。
• 結果は位置の候補と編集の候補の事実の提示で、位置の確定でも、意味が保たれることの約束でもありません。位置の確定や文書の編集の代行もしません。
• 保護範囲は作りません。どこを保護するかは呼び出し側が決めて渡します。
• W3C Web Annotation の TextQuoteSelector・TextPositionSelector に近い形ですが、それに準拠するとは言いません（位置は UTF-16 の符号単位で、ブロックの id を持ちます）。
• 時計・乱数・外の境界・状態を持ちません。副作用は NONE で、資格情報も使いません。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。

つなぎ方

src/document-anchor.js の documentAnchor({ operation: "resolve" | "edit", ... }) を呼びます（resolve・edit を直接も呼べます。例外を投げません）。resolve は { document, anchor }、edit は { document, block_id, start, end, replacement, origin, protected } を受け取ります。返すのは { ok: true, errors: [], facts }（state は done、inference・advice は null）か { ok: false, errors: [{ code, path }] } です。副作用（NONE）・状態・外の接続・資格情報は無く、利用側が用意する port もありません。

保存された検査記録の結果です。実サービスへの接続や出荷可否の評価とは別です。 v24.21.0

どんな困りごとを解くか

履歴から今の状態を作るときに、再送された event で数が二重に増えること、seq の飛びや逆行を見逃して状態を作ってしまうこと、区切りの途中で規則が替わること、1 つの event の規則が途中まで当たった中途半端な状態が残ること、無い値を 0 として足してしまうことを防ぎます。

使う場面

• reducer（version と、種類ごとに 0〜64 件の規則 { op, path, from（"payload.<キー>"）か value }）で、state に events（0〜10,000 件の { event_id, seq, at, type, payload }）を順に当て、new_state の候補と aggregates.by_type（当てた event の種類ごとの件数）を受け取りたいとき。
• 同じ event_id の再送を当てたくないとき。seen_event_ids にあれば duplicates（source: seen）、同じ束で 2 度目なら duplicates（source: batch）に並べ、増加は 0 です。
• seq の連続を確かめたいとき。直前の seq + 1 だけを受け取り、飛び（gap）は need_input（SEQ_GAP）、逆行（reversal）は order_violations に並べ、どちらもその後の event を not_applied にします。last_seq で最初に期待する seq を決められます。
• window（start・end・reducer_version）で区切りを決め、start ≤ at < end の外の event を outside_window にしたいとき（当てませんが seq は進めます）。
• 1 つの event の規則を全部当てるか全く当てないかで扱いたいとき。当てられなければ、その event で変えたものをすべて戻し、apply_failures に event_id・rule_index・code を並べ、その後の event を not_applied にします。

使わない場面

• イベントの台帳・配信基盤・データベースとして使いたいとき。保存・確定・配信、重複の台帳・時刻・lease・永続化は Host（Runtime）の役目です。
• 同じ event_id で中身の違う event を見分けたいとき。重複は event_id だけで判定し、中身は比べません。
• events を seq で並べ替えてから当てたいとき。配列の順に当てます。並べ替えが要るときは、渡す前に呼び出し側で行います。
• 10 進の小数を足したいとき。add は安全な整数どうしだけです。
• 配列の添字への set や、一覧の中の差し替えが要るとき。set は親がオブジェクトのときだけです。
• Node.js v24.21.0 のほかの版で使うとき。ほかの版は確かめていません（NOT_VERIFIED）。

検査すること

• 引数が決まったキーだけを持つ素のオブジェクトでないとき INVALID_ARGUMENT、値を調べること自体が例外になるとき（Proxy の罠など）INSPECTION_FAILED で止めます。getter・クラスのインスタンス・穴のある配列・__proto__ のキー・記号のキー・null・関数は受け取らず、素のデータに写してから当てます。
• reducer の形が違うとき（知らないキー・op の語彙の外・path の形・__proto__ の token・from と value の数・from の形・add の value が整数でないなど）INVALID_REDUCER で止めます。reducer は宣言だけで、式・スクリプト・関数を評価する経路はありません。
• state の形が違うとき INVALID_STATE、events の形が違うとき（seq と at が 0 以上の整数でないなど）INVALID_EVENTS、seen_event_ids が id の一覧でないとき INVALID_SEEN、window の形が違うとき（start > end など）INVALID_WINDOW で止めます。
• window の reducer_version が reducer.version と違うとき RULE_SWITCH_IN_WINDOW で止めます。区切りの途中で規則を切り替えません。
• 規則を当てられない理由を code で返します。種類の規則が無い NO_RULE_FOR_TYPE、payload にキーが無い PAYLOAD_KEY_MISSING、親がオブジェクトでない PARENT_NOT_OBJECT、対象が無い・整数でない・一覧でない TARGET_MISSING・TARGET_NOT_INTEGER・TARGET_NOT_LIST、値が整数でない VALUE_NOT_INTEGER、和があふれる INTEGER_OVERFLOW です。無い値・不明・文字列を 0 として扱いません。
• 上限（入れ子 32 段・値の数 400,000・文字列 65,536・配列 100,000 要素・events 10,000・種類 256・種類ごとの規則 64・append 後の一覧 10,000）を超えたとき RESOURCE_LIMIT で止め、limit に上限の名前を入れます。
• 結果を、src の補助関数を使わずに書いた独立オラクルと突き合わせるファズで、不一致と fail-open が 0 であることを確かめました。

しないこと・既知の限界

• 返すのは事実だけです。inference と advice はいつも null です。結果は承認ではなく（approval: false）、権限も作りません（derives_authority: false）。
• new_state は候補で、確定ではありません。保存・配信・適用の確定は Host の役目です。
• seen_event_ids が本当に当てた event か、state の版が今の版か、at が正しい時刻かは確かめません。どれも Host が渡します。時計は読まず、at と window は入力の値だけを使います。
• 同じ seq の別の event（event_id が違う）は逆行として止めます。どちらが正しいかは決めません。
• 値つきの remove の等しさは、キーの集まりと値の一致で見ます（数の -0 と 0 は等しい）。
• 時計・乱数・ファイル・通信・外の境界・状態を持ちません。副作用は NONE で、資格情報も使いません。
• 工房の検査に通ったことは、認証ではありません。出荷してよいかは評価しておらず、公開もしておらず、権限も与えません。