完了証明書： それぞれが何を主張し、誰がそれを担当しますか。

1. 証明書チェーン

命名はオペレーターと契約によって異なりますが、基本的な流れは一貫しています。建設報告書、受領者による承認、コミッショニング準備完了報告書、サービス開始準備完了報告書です。

一部のプロジェクトでは、証明書より前に機械的完成（MC）通知を挿入したり、RFCを規律ごとの承認に分割したりします。構造よりも重要な一つのルールがあります。 各証明書には、署名される前に確認できる明確な証拠セットが必要です。

2. 各証明書の裏付けとなる証拠

機械的完成（MC）証明書

• サブシステム境界内のタグに関するすべてのA-ITR（検査記録）が署名・承認されました。
• サブシステム ウォークダウン 顧客立ち会いのもと完了しました。
• Category Aパンチはクリアされ、Category BおよびCは繰り越しとしてリストアップされ、承認されました。
• 図面からの逸脱について取得された竣工マークアップ。
• サブシステムが稼働せず休止する箇所で確立され、現行の保全（プリザベーション）が実施されています — 参照 保全（プリザベーション）作業リスト.

コミッショニング準備完了

• MCCはサブシステム、およびそれが依存するすべてのアップストリームサブシステムに対して発行されます。
• プレコミッショニング完了：フラッシング、クリーニング、乾燥、校正、モーター単独運転。
• 対象システム向けのコミッショニング手順書が承認され、利用可能です。
• 安全性および隔離体制が合意され、許可経路が確立されています。

起動準備完了

• すべてのB-ITR（検査記録）が署名済み — ループチェック、機能テスト、保護およびインターロック試験。
• コミッショニング手順書が実行され、結果が記録されて署名されました。
• 合意されたRFSUしきい値内のパンチステータス（全ての未完了項目は分類され、担当者が割り当てられています）。
• 運用手順、スペア部品、およびベンダーのドキュメントが運用部門で利用可能。

3. 署名権限は管理の一部です

証明書の価値は、その背後にある権限によってのみ決まります。適切に運営されているプロジェクトでは、署名権限は慣習ではなく役割属性です。フィールドエンジニアはITR（検査記録）に署名でき、専門分野のリードはDACを受け入れることができ、指名されたコミッショニングマネージャーのみがRFSUを発行できます。

署名権限が非公式な場合、2つの問題が生じます。1つは、主張を行う能力のない人物によって署名された証明書、もう1つは、唯一の承認された署名者が3週間沖合にいるため遅延する証明書です。これらは両方とも明示的に解決されます。 役割ベースのアクセス制御 口頭ではなく記録された委任で。

4. 部分的、条件付き、および取り消された証明書

• 部分的な証明書 — サブシステムの定義された部分に対して発行され、下流工程の作業を開始できるようにします。正当ですが、除外される範囲は暗示的ではなく、明示的に記載する必要があります。
• 条件付き証明書 — 指定された例外を付加して発行されます。すべての例外には所有者と目標日が必要であり、そうしないと誰も追跡しない恒久的な除外事項となります。
• 取り消し — 証明書発行後、サブシステムへのさらなる変更は証拠の一部を無効にします。存在しないプラントを記述する署名済み証明書を残すのではなく、変更管理によって影響を受ける記録を再開する必要があります。

取り消し事例は、ほとんどのシステムがうまく処理できないものです。認定されたサブシステム内のタグが変更された場合、証明書は影響を受けるITR（検査記録）を明確に表示すべきです。そうしないと、ドシエとプラントの状態が矛盾してしまいます。

5. 証明書が遅れて届く理由

1. 証拠が散在しています。 ITRは一箇所、パンチリストは別の場所、ウォークダウンは紙。パックの作成は作業完了よりも時間がかかります。
2. 境界が一致しません。 ITRが作成されたサブシステムは、証明書が発行されるサブシステムと異なるため、完全性チェックは決して一致しません。
3. 基準が解釈されます。 前提条件リストが手順書にある場合、証明書会議で2人が異なる解釈をします。
4. パンチカテゴリが増加します。 ゲート付近ではすべてがカテゴリーAとなり、ゲートはブロッキング要因とノイズを区別しなくなります。

この4つはすべて、努力の問題ではなく構造的な問題です。その際に 証明書モジュール ライブ記録セットから準備状況を継続的に計算することで、証明書会議は調査ではなく署名となります。