アーカイブの直後、または後で実行されるベリファイジョブ（P5 CLIを使用）は、ベリファイチェックのタイプについてArchivePlanの設定を尊重します：現時点では、チェックサムまたはファイル比較のベリファイを提供しています。

チェックサムベリファイは、次のように動作します：

アーカイブ中に、ファイルを読み込む際に生成されるストリーム（下記参照 *）がチェックサムされ、チェックサム（とそのタイプ）がメディア（テープ、ディスク）に保存されるデータに付加されます。
検証時には、ストリームチェックサムを計算しながらストリームを読み返し、最後にデータストリームの末尾に付加されたチェックサムと結果を比較することになります。
このチェックの目的は、メディアに書き込んだものをメディアから読み取れるかどうかを確認することです。
このチェックは非常に高速で、元のファイルへのアクセスは必要ありません。

ファイル比較検証の仕組みは以下の通りです：

アーカイブ時に、ファイルを読み込む際に生成されるストリーム（下記参照 *）をチェックサムし、チェックサム（とそのタイプ）をメディア（テープ、ディスク）に保存されたデータに付加します。
検証時には、ストリームを読み返すと同時に、アーカイブ時と同じようにファイルを読みます。両方のストリームをバイト単位で比較します。
このチェックの目的は、ファイルから読み取ったのと同じデータをメディアから読み取ることができるかどうかを確認することです。
これは非常に複雑な設定で、ファイルの送信元クライアントで行う必要があるため、ファイル全体をネットワーク上で転送し、送信元クライアントに戻す必要があります。

ファイルを読みながら生成する各データストリーム（アーカイブ時やファイル比較検証時など）は、以下のような構成からなるCOMPLEXセットアップです：

a. データフォーク
b. オプションのユーザーおよび/またはリソースフォーク(Mac、Windows)
c. 任意のACL
d. オプションの拡張属性
e. ファインダーインフォ記録（Macのみ）
f. ファイルIDおよびプライベートファイルサーバーレコード（Heliosファイルサーバー）
g. プライベートファイルサーバーレコード（Xinet)
e. ファイルの修正/作成/変更時間

上記の項目のいずれかが、メディアにファイルを書き込んだ後に変更された場合、ファイル比較ベリファイが失敗します。
チェックサムベリファイには影響ありません。

上記の情報のいくつかは純粋なバイナリ項目であり、ユーザー領域のユーティリティでは（簡単に）取得できないため、エンドユーザーがファイルの変更点を把握することは実質的に不可能です。

この場合、ベリファイチェックの有効性は事実上低下しますが、ファイル比較のベリファイが失敗した場合に、最終的に何が変更されたかをユーザーが容易に理解/検査できるようになります。
これは、ベリファイ・プロセスの全アイデアを失うか、少なくともその品質を低下させることになるため、意図的にそうしたわけではありません。
両方のオプションを提供すると、ソフトウェアとセットアップがより複雑になるので、それも避けました。