起案し、交渉し、確定する。
そして残るのは 後で通用する証拠

確定時に、その版の内容（UTF-8）に対して SHA-256 を計算します。フィンガープリントは証拠報告書と A4 文書の最終ページの「デジタル認証フィンガープリント」欄に印字されます。同じフィンガープリントを第三者のタイムスタンプ機関に送り、RFC 3161 のトークンを受け取ります。.tsr ファイルはシステムからダウンロードでき、openssl ts -verify で独立に検証できます——こちらのシステムも、こちらへの信頼も必要ありません。証拠報告書は、タイムスタンプが対象とするハッシュと現在の確定フィンガープリントを突き合わせ、「タイムスタンプ一致：現在の確定フィンガープリントを対象としています」または「タイムスタンプ不一致：現在の確定フィンガープリントではありません」と表示します。

これが証明しないこと： タイムスタンプが証明するのは、そのハッシュ値が発行時点より前に存在していたことだけです。内容が真実であることを証明するものではなく、署名者が誰かを証明するものでもなく、公証と同等でもありません。

監査証跡は append-only のハッシュチェーンで、各イベントのハッシュが直前のハッシュを含みます。そのため「1 件だけ書き換えて以降を再計算しない」は即座に検出されます。しかしチェーン全体を再計算できる側——つまり私たち——が再計算したチェーンは、検証上まったく正常に見えます。だからチェーンの先頭を第三者のタイムスタンプ機関に送って RFC 3161 のタイムスタンプを取得し、その時点より前のイベントには手を出せなくします。証拠報告書は区間ごとに「アンカー済み」「未アンカー」を表示し、未アンカーとは本プラットフォーム内部の記録が整合しているという意味にすぎず、第三者の裏づけはまだない、と明記します。データベース層にもう二段あります。書き込み済みの署名行は append-only トリガーが UPDATE を拒否し、署名証拠に関わる外部キーはすべて ON DELETE RESTRICT です——契約や招待に署名証拠が一度でも付けば、データベースがその削除を拒みます。

これが証明しないこと： ハッシュチェーンそれ自体は本プラットフォームに対抗する効力を持たず、未アンカーの区間は私たち自身の整合性チェックを通っただけです。これは宣伝文句ではなく、証拠報告書にそのまま印字されている文です。

各日の終了後、その日の全署名を 1 本の Merkle ツリーに集約します。葉は SHA-256(0x00 ‖ 正規化レコード)、内部ノードは SHA-256(0x01 ‖ 左 ‖ 右)。接頭バイトが両者を区別し、葉を内部ノードに見せかけることを防ぎます。奇数ノードは自分自身と対にせず、そのまま昇格させます。葉のレコードは長さ接頭形式（名前=バイト長:値）で、フィールド順は v, signature_id, request_id, contract_id, chain_head_hash, chain_head_seq, signed_at に固定——証拠報告書で公開しており、自分で再計算できます。ルートは自己記述的なステートメント（日付、フォーマット版、ルート、当日件数）とともに三か所へ送られます：RFC 3161 タイムスタンプ（複数機関でフォールバックし、実際に署名した機関を記録）、Sigstore Rekor の公開透明性ログ、そして OpenTimestamps（最終的に Bitcoin のトランザクションに書き込まれます）。Rekor はステートメントの SHA-256 でインデックスを逆引きするため、第三者は「どれがあなたのものか」についてこちらの言い分を受け入れる必要がありません。OpenTimestamps のレシートが Bitcoin で確認されれば、検証に必要なのは Bitcoin だけです——私たちも、Sigstore も、OpenTimestamps 自体が存続していることも必要ありません。証拠報告書は三者を別々に、それぞれの状態とともに列挙します。OTS の未確認の待機状態も、確認後の Bitcoin ブロック高も含みます。印字されるのはあなたのその日の実際の値です——ルート、Rekor の logIndex、Bitcoin のブロック高——説明文中の例ではありません。どれも対応する公開システムで照会でき、それらのシステムは本プラットフォームとは無関係です。

これが証明しないこと： 外に出るのは 64 文字のハッシュ値と日付だけです。契約内容も氏名も金額も入っていません——プライバシー上そうする必要がありますが、同時に内容が何であったかを証明しないということでもあります。集約は「日」単位で、その日が終わってからツリーを作るため、今日署名したものは今日が終わるまで待ちます。監査ハッシュチェーンより前の古い署名は永久に対象になりません。報告書はそのとおりに書きます。OpenTimestamps が「送信済み・未確認」と表示している間、そのレシートはまだ独立に検証できる時刻の証明にはなりません。通常は数時間かかります。その間、たとえそのダイジェストが実際にはすでに Bitcoin のトランザクションに書き込まれていたとしても、報告書はブロック高を表示しません。レシートが完成するまでは、「あなたのダイジェストはあのトランザクションの下にある」というのは calendar の言い分であって、検証可能な経路ではないからです。私たちは、他人の言葉を借りて早く言うより、報告書が遅れて言うほうを選びます。最後に：あるデータのハッシュが Bitcoin 上に現れたからといって、その地位を高める法条はどこにもありません。高まるのはあなたの立証能力です。

宛先は発信者が入力し、署名ページではマスク表示のみで、相手方は変更できません。6 桁の確認コードは 10 分間有効、5 回間違えると失効、再送は 60 秒間隔、1 件の招待につき最大 5 回までです。署名履歴は、招待送信・確認通過・契約書の初回閲覧・同意文へのチェック・署名完了を、それぞれ時刻・送信元 IP・User-Agent とともに記録します。証拠報告書には実際に到達した水準を記録し、L1 から L4 までの水準表を丸ごと併記します。L3 の多要素（メール＋Passkey によるデバイス認証、メール＋指定アドレスと一致する Google／Microsoft アカウントへのログイン、またはメール＋発信者が指定した携帯番号へ送信される SMS コード。組織ごとに個別付与されるオプション機能）は達成時にそのまま記載され、L4 の証明書ベース電子署名（TWID 本人確認のうえ TWCA が発行する証明書で契約 PDF に電子署名。こちらも組織ごとに個別付与されるオプション）も達成時にそのまま記載されます——どの水準も上限だと読まれないようにするためです。

これが証明しないこと： L2 が証明するのは、署名の時点で相手方がその指定アドレスのメールを受け取れたことです。自然人の身元ではありません。メールボックスは複数人で共有されていることも、転送設定があることも、他人が代理で受け取っていることもあります。私たちは「本人確認済み」とは書きませんし、システムは身分証・自然人証明書・法人証明書のいずれの照合も行いません。

同意文には「本人は、上記署名者の氏名・役職および会社情報が正確であることを確認し、かつ本人が上記契約当事者を代表して本契約に署名する権限を有することを確認します」が含まれ、送信時点の全文がそのまま署名記録にスナップショットされます。証拠報告書はさらに「発信者の想定」と「署名者の申告」を項目ごとに並べます。会社名、統一編号（台湾の事業者番号）、署名者氏名、役職、メールのドメインの 5 項目で、それぞれ一致／不一致／申告のみ、比較対象なし／想定のみ、申告なし／双方とも未提供と表示します。不一致でも署名は止まりません。両方をそのまま保存し、調整はしません——差異そのものが一つの事実だからです。

これが証明しないこと： 突き合わせは、全角と半角、大文字と小文字、空白、会社の法的形態（「股份有限公司」と「(股)」）の正規化のみで、あいまい一致はありません。第三の列「政府公開情報」は、署名時点で台湾経済部商業司の会社登記オープンデータに照会した結果のスナップショットで、証明できるのは「その時点の登記内容がそうであった」ことだけです。報告書には「会社登記照合：一致」と記し、「代表者を確認済み」とは決して書きません——登記情報は画面の前にいる人がその自然人であることを証明できず、本当に代表権があったかの判断もしないからです。同意文にチェックを入れても代理権が無から生じることはなく、残るのはそのときの自身の権限についての明確な陳述です。

署名トランザクションの完了後、システムがバックグラウンドで完了通知を送ります。契約書 PDF と証拠報告書 PDF は本物の MIME 添付であり、ダウンロードリンクではありません——控えは双方それぞれのメールボックスに残り、本プラットフォームの存続に依存しません。発信者と署名者はそれぞれ自分宛の 1 通を受け取ります。本文には contract.pdf と evidence-report.pdf の SHA-256、および確定内容のフィンガープリントを直接印字し、この 3 つが対象とするものは同じではないと注記します。前の 2 つは添付ファイルのバイト列のハッシュ、最後の 1 つだけがタイムスタンプの発行対象です。

これが証明しないこと： 添付は送信サービスの 1 通 10MB の上限を受けます。超えた場合は縮退し、送信状態にどちらが「添付されていない」かをそのまま表示します。PDF のレンダリングに失敗した場合はメール自体を送りません——書類を添付したと称して添付していないメールは送らない、ということです。

契約書 PDF は必ずサーバー側の headless Chromium でレンダリングし、バージョンを Chrome for Testing 152.0.7977.54 に固定しています。カラープロファイルは sRGB、フォントのヒンティングと LCD サブピクセル平滑化はオフ、タイムゾーンは Asia/Taipei、viewport と device scale factor も固定です。出力後、PDF 内で毎回変わる唯一の値である /CreationDate と /ModDate を固定値に正規化します。万一 trailer に /ID が現れた場合はレンダリングを失敗させます。後で突き合わなくなるファイルを黙って作るよりよいからです。確定後の契約は内容が変わらないため、同じ契約は何度レンダリングしても同じバイト列になります。

これが証明しないこと： この保証が及ぶのは契約書 PDF だけです。証拠報告書はその後のイベントとともに増えていきます——送信に成功するたび送信記録が 1 件増えます——ので、2 つの証拠報告書 PDF がバイト単位で同一とは限りません。システム内に PDF ファイルを封存しているとは主張しません。恒久的に保存しているのは契約の内容とそのフィンガープリントであり、PDF は必要に応じて再レンダリングされます。

契印は会社印を等幅の N 片に分割し、各ページの右端に 1 片ずつ、垂直位置を固定して印字します。ページが順番に並んではじめて印が完成するため、1 枚抜く、1 枚差し替える、順序を入れ替えるといずれも片が合わなくなります。利用には「設定 → 組織設定」で会社印をアップロードする必要があり、2 ページ以上の文書にのみ押され、文書ごとに切り替えるか新規契約の既定にでき、確定後はロックされます。

これが証明しないこと： これは紙の上の目視による識別であって、暗号学的な保護ではありません。印影は複製できますし、全体を刷り直せば再び整列します。さらに契印の設定は確定フィンガープリントの対象範囲外です——改ざん耐性を担っているのは内容ハッシュ、RFC 3161 タイムスタンプ、監査ハッシュチェーンであって、この印ではありません。

日次集約はその日に完了した全署名を 1 本の Merkle ツリーにまとめ、外部に出るのはルートだけです（送り先は上の「タイムスタンプ会社を選んだのはそちら」の項を参照）。証拠報告書には、あなたの葉のレコードを一字一句、葉のハッシュ、その日の中での位置（M 片中の N 片目）、そして inclusion proof の各ステップが印字されます。兄弟ノードのハッシュは完全な形で印字され、方向は「左（前）」「右（後）」と表示されます。葉は SHA-256(0x00 || レコード)、内部ノードは SHA-256(0x01 || 兄弟 || 現在値) で、domain separation により両者を区別します。これに沿って自分でルートまで再計算できます。証明は保存せず毎回その場で再計算します。保存した証明が後で実データと食い違うことを避けるためです。

これが証明しないこと： 集約それ自体は、私たちがツリー全体を作り直していないことを証明しません。効力を生むのは、あくまでルートを送った先の第三者です。その日のツリーは営業日が終わってから作られるため、当日完了した署名はまず「未収録」と表示されます。

確定時に、その版の内容（UTF-8）に対して SHA-256 を計算します。フィンガープリントは証拠報告書と A4 文書の最終ページの「デジタル認証フィンガープリント」欄に印字されます。同じフィンガープリントを第三者のタイムスタンプ機関に送り、RFC 3161 のトークンを受け取ります。.tsr ファイルはシステムからダウンロードでき、openssl ts -verify で独立に検証できます——こちらのシステムも、こちらへの信頼も必要ありません。証拠報告書は、タイムスタンプが対象とするハッシュと現在の確定フィンガープリントを突き合わせ、「タイムスタンプ一致：現在の確定フィンガープリントを対象としています」または「タイムスタンプ不一致：現在の確定フィンガープリントではありません」と表示します。

これが証明しないこと： タイムスタンプが証明するのは、そのハッシュ値が発行時点より前に存在していたことだけです。内容が真実であることを証明するものではなく、署名者が誰かを証明するものでもなく、公証と同等でもありません。

監査証跡は append-only のハッシュチェーンで、各イベントのハッシュが直前のハッシュを含みます。そのため「1 件だけ書き換えて以降を再計算しない」は即座に検出されます。しかしチェーン全体を再計算できる側——つまり私たち——が再計算したチェーンは、検証上まったく正常に見えます。だからチェーンの先頭を第三者のタイムスタンプ機関に送って RFC 3161 のタイムスタンプを取得し、その時点より前のイベントには手を出せなくします。証拠報告書は区間ごとに「アンカー済み」「未アンカー」を表示し、未アンカーとは本プラットフォーム内部の記録が整合しているという意味にすぎず、第三者の裏づけはまだない、と明記します。データベース層にもう二段あります。書き込み済みの署名行は append-only トリガーが UPDATE を拒否し、署名証拠に関わる外部キーはすべて ON DELETE RESTRICT です——契約や招待に署名証拠が一度でも付けば、データベースがその削除を拒みます。

これが証明しないこと： ハッシュチェーンそれ自体は本プラットフォームに対抗する効力を持たず、未アンカーの区間は私たち自身の整合性チェックを通っただけです。これは宣伝文句ではなく、証拠報告書にそのまま印字されている文です。

各日の終了後、その日の全署名を 1 本の Merkle ツリーに集約します。葉は SHA-256(0x00 ‖ 正規化レコード)、内部ノードは SHA-256(0x01 ‖ 左 ‖ 右)。接頭バイトが両者を区別し、葉を内部ノードに見せかけることを防ぎます。奇数ノードは自分自身と対にせず、そのまま昇格させます。葉のレコードは長さ接頭形式（名前=バイト長:値）で、フィールド順は v, signature_id, request_id, contract_id, chain_head_hash, chain_head_seq, signed_at に固定——証拠報告書で公開しており、自分で再計算できます。ルートは自己記述的なステートメント（日付、フォーマット版、ルート、当日件数）とともに三か所へ送られます：RFC 3161 タイムスタンプ（複数機関でフォールバックし、実際に署名した機関を記録）、Sigstore Rekor の公開透明性ログ、そして OpenTimestamps（最終的に Bitcoin のトランザクションに書き込まれます）。Rekor はステートメントの SHA-256 でインデックスを逆引きするため、第三者は「どれがあなたのものか」についてこちらの言い分を受け入れる必要がありません。OpenTimestamps のレシートが Bitcoin で確認されれば、検証に必要なのは Bitcoin だけです——私たちも、Sigstore も、OpenTimestamps 自体が存続していることも必要ありません。証拠報告書は三者を別々に、それぞれの状態とともに列挙します。OTS の未確認の待機状態も、確認後の Bitcoin ブロック高も含みます。印字されるのはあなたのその日の実際の値です——ルート、Rekor の logIndex、Bitcoin のブロック高——説明文中の例ではありません。どれも対応する公開システムで照会でき、それらのシステムは本プラットフォームとは無関係です。

これが証明しないこと： 外に出るのは 64 文字のハッシュ値と日付だけです。契約内容も氏名も金額も入っていません——プライバシー上そうする必要がありますが、同時に内容が何であったかを証明しないということでもあります。集約は「日」単位で、その日が終わってからツリーを作るため、今日署名したものは今日が終わるまで待ちます。監査ハッシュチェーンより前の古い署名は永久に対象になりません。報告書はそのとおりに書きます。OpenTimestamps が「送信済み・未確認」と表示している間、そのレシートはまだ独立に検証できる時刻の証明にはなりません。通常は数時間かかります。その間、たとえそのダイジェストが実際にはすでに Bitcoin のトランザクションに書き込まれていたとしても、報告書はブロック高を表示しません。レシートが完成するまでは、「あなたのダイジェストはあのトランザクションの下にある」というのは calendar の言い分であって、検証可能な経路ではないからです。私たちは、他人の言葉を借りて早く言うより、報告書が遅れて言うほうを選びます。最後に：あるデータのハッシュが Bitcoin 上に現れたからといって、その地位を高める法条はどこにもありません。高まるのはあなたの立証能力です。

宛先は発信者が入力し、署名ページではマスク表示のみで、相手方は変更できません。6 桁の確認コードは 10 分間有効、5 回間違えると失効、再送は 60 秒間隔、1 件の招待につき最大 5 回までです。署名履歴は、招待送信・確認通過・契約書の初回閲覧・同意文へのチェック・署名完了を、それぞれ時刻・送信元 IP・User-Agent とともに記録します。証拠報告書には実際に到達した水準を記録し、L1 から L4 までの水準表を丸ごと併記します。L3 の多要素（メール＋Passkey によるデバイス認証、メール＋指定アドレスと一致する Google／Microsoft アカウントへのログイン、またはメール＋発信者が指定した携帯番号へ送信される SMS コード。組織ごとに個別付与されるオプション機能）は達成時にそのまま記載され、L4 の証明書ベース電子署名（TWID 本人確認のうえ TWCA が発行する証明書で契約 PDF に電子署名。こちらも組織ごとに個別付与されるオプション）も達成時にそのまま記載されます——どの水準も上限だと読まれないようにするためです。

これが証明しないこと： L2 が証明するのは、署名の時点で相手方がその指定アドレスのメールを受け取れたことです。自然人の身元ではありません。メールボックスは複数人で共有されていることも、転送設定があることも、他人が代理で受け取っていることもあります。私たちは「本人確認済み」とは書きませんし、システムは身分証・自然人証明書・法人証明書のいずれの照合も行いません。

同意文には「本人は、上記署名者の氏名・役職および会社情報が正確であることを確認し、かつ本人が上記契約当事者を代表して本契約に署名する権限を有することを確認します」が含まれ、送信時点の全文がそのまま署名記録にスナップショットされます。証拠報告書はさらに「発信者の想定」と「署名者の申告」を項目ごとに並べます。会社名、統一編号（台湾の事業者番号）、署名者氏名、役職、メールのドメインの 5 項目で、それぞれ一致／不一致／申告のみ、比較対象なし／想定のみ、申告なし／双方とも未提供と表示します。不一致でも署名は止まりません。両方をそのまま保存し、調整はしません——差異そのものが一つの事実だからです。

これが証明しないこと： 突き合わせは、全角と半角、大文字と小文字、空白、会社の法的形態（「股份有限公司」と「(股)」）の正規化のみで、あいまい一致はありません。第三の列「政府公開情報」は、署名時点で台湾経済部商業司の会社登記オープンデータに照会した結果のスナップショットで、証明できるのは「その時点の登記内容がそうであった」ことだけです。報告書には「会社登記照合：一致」と記し、「代表者を確認済み」とは決して書きません——登記情報は画面の前にいる人がその自然人であることを証明できず、本当に代表権があったかの判断もしないからです。同意文にチェックを入れても代理権が無から生じることはなく、残るのはそのときの自身の権限についての明確な陳述です。

署名トランザクションの完了後、システムがバックグラウンドで完了通知を送ります。契約書 PDF と証拠報告書 PDF は本物の MIME 添付であり、ダウンロードリンクではありません——控えは双方それぞれのメールボックスに残り、本プラットフォームの存続に依存しません。発信者と署名者はそれぞれ自分宛の 1 通を受け取ります。本文には contract.pdf と evidence-report.pdf の SHA-256、および確定内容のフィンガープリントを直接印字し、この 3 つが対象とするものは同じではないと注記します。前の 2 つは添付ファイルのバイト列のハッシュ、最後の 1 つだけがタイムスタンプの発行対象です。

これが証明しないこと： 添付は送信サービスの 1 通 10MB の上限を受けます。超えた場合は縮退し、送信状態にどちらが「添付されていない」かをそのまま表示します。PDF のレンダリングに失敗した場合はメール自体を送りません——書類を添付したと称して添付していないメールは送らない、ということです。

契約書 PDF は必ずサーバー側の headless Chromium でレンダリングし、バージョンを Chrome for Testing 152.0.7977.54 に固定しています。カラープロファイルは sRGB、フォントのヒンティングと LCD サブピクセル平滑化はオフ、タイムゾーンは Asia/Taipei、viewport と device scale factor も固定です。出力後、PDF 内で毎回変わる唯一の値である /CreationDate と /ModDate を固定値に正規化します。万一 trailer に /ID が現れた場合はレンダリングを失敗させます。後で突き合わなくなるファイルを黙って作るよりよいからです。確定後の契約は内容が変わらないため、同じ契約は何度レンダリングしても同じバイト列になります。

これが証明しないこと： この保証が及ぶのは契約書 PDF だけです。証拠報告書はその後のイベントとともに増えていきます——送信に成功するたび送信記録が 1 件増えます——ので、2 つの証拠報告書 PDF がバイト単位で同一とは限りません。システム内に PDF ファイルを封存しているとは主張しません。恒久的に保存しているのは契約の内容とそのフィンガープリントであり、PDF は必要に応じて再レンダリングされます。

契印は会社印を等幅の N 片に分割し、各ページの右端に 1 片ずつ、垂直位置を固定して印字します。ページが順番に並んではじめて印が完成するため、1 枚抜く、1 枚差し替える、順序を入れ替えるといずれも片が合わなくなります。利用には「設定 → 組織設定」で会社印をアップロードする必要があり、2 ページ以上の文書にのみ押され、文書ごとに切り替えるか新規契約の既定にでき、確定後はロックされます。

これが証明しないこと： これは紙の上の目視による識別であって、暗号学的な保護ではありません。印影は複製できますし、全体を刷り直せば再び整列します。さらに契印の設定は確定フィンガープリントの対象範囲外です——改ざん耐性を担っているのは内容ハッシュ、RFC 3161 タイムスタンプ、監査ハッシュチェーンであって、この印ではありません。

日次集約はその日に完了した全署名を 1 本の Merkle ツリーにまとめ、外部に出るのはルートだけです（送り先は上の「タイムスタンプ会社を選んだのはそちら」の項を参照）。証拠報告書には、あなたの葉のレコードを一字一句、葉のハッシュ、その日の中での位置（M 片中の N 片目）、そして inclusion proof の各ステップが印字されます。兄弟ノードのハッシュは完全な形で印字され、方向は「左（前）」「右（後）」と表示されます。葉は SHA-256(0x00 || レコード)、内部ノードは SHA-256(0x01 || 兄弟 || 現在値) で、domain separation により両者を区別します。これに沿って自分でルートまで再計算できます。証明は保存せず毎回その場で再計算します。保存した証明が後で実データと食い違うことを避けるためです。

これが証明しないこと： 集約それ自体は、私たちがツリー全体を作り直していないことを証明しません。効力を生むのは、あくまでルートを送った先の第三者です。その日のツリーは営業日が終わってから作られるため、当日完了した署名はまず「未収録」と表示されます。