1. A-Sheets（要件定義）：設計憲法とポリシーID

「何を、いつまで守るか」をポリシーとして刻む

A-Sheets の役割は、ビジネス要件を「A-No」という一意のポリシーIDへ変換することです。

• 聖域（Sanctuary）の指定: 「壊してはいけないデータ（聖域）」と「いつでも交換できるインフラ（器）」を明確に峻別します。
• SLAの自動執行（Enforcement）: 「30分以内に復旧」といった定性的な願いを、システムが監視すべき具体的な指標（SLI）と目標（SLO）へ落とし込みます。
  • 例：HTTP 200 応答率、平均レイテンシ、DB 接続成功率など

このシートで定義された A-No は、そのまま Terraform のタグや監視ポリシーの名称となり、実装と完全に同期します。

2. B-Sheets（構成設計）：論理的ブレードシステム

「器」と「データ」を分離し、コードへ流し込む

B-Sheets は、A-Sheets で定義されたポリシーを具体化する「実装図」です。 Google Cloud における VPC、サブネット、IAM、そして Terraform のライフサイクル設定を記述します。

• 器（Vessel）の交換可能性: VM やコンテナを「論理的なブレード」として扱い、いつでも破棄・再構築できる構成を定義します。
• 物理的な削除保護: 聖域（DB等）に対して、IaC（Terraform）レベルの prevent_destroy と、Google Cloud 側の削除保護を二重に定義します。また、Terraform State 自体も「聖域」として保護対象に含めます。

3. C-Sheets（試験検証）：ガバナンスの物理的証明

「本当に守られているか」を破壊によって証明する

従来の試験は「つながること」の確認でした。 NWMA における C-Sheets は、**「ガバナンスが機能していること」**の証明です。

• 破壊による自動復旧試験: 「器」を意図的に破壊し、A-Sheets で定義したポリシー（A-No）通りに自動復旧フローが起動するかを検証します。
  • 例：MIG（マネージドインスタンスグループ）のオートヒーリング、GKE の再スケジューリング確認など
• 聖域存続試験: 誤った削除操作がコードおよびプラットフォーム側のガードによって正しくブロックされるかを確認します。