コーディング、設計、インフラストラクチャ、運用に関わるすべての活動は本文書に準拠させること。
1. セキュリティ
常日頃（Business As Usual）から対応
セキュリティは後付けではなく、最初から組み込むこと。 各セキュリティスキャンやレビューは定期的またはリリース前に実施し、検出事項は放置せず何らかの対処を行うこと。
注） 対処は解決だけでなく、他の施策による対応、あるいは対応不要の判断も含む。ただし対応不要とする場合は理由を記録しレビューで承認を得ること。
権限管理
必要ない権限は極力渡さないこと（最小権限の原則）。
どうしても必要な場合はそのときだけ権限を付与すること（例・ブレイクグラスやJust-In-Timeアクセスの利用）。
2. 信頼性
コード品質
すべてのコードはプロダクション品質の基準を満たさなければならない。コード品質はリンター、静的解析ツール、フォーマッタなどのツールと人間またはAIによるレビューによって向上させ、テストによって保証する。コードは仕様とコーディング標準に準拠させること。
厳密なテストファースト開発は必須ではないが、自動テストは常に実装すること。ユニットテストのコードカバレッジはあくまで参考とし、重要ロジックが網羅されていることを優先する。ただし決済などのクリティカルな箇所は100%のカバレッジを実施すること。また全ての関数が一度は呼ばれること。
結合テスト機能のカバレッジは全機能を網羅すること。
仕組みによる信頼性向上
信頼性向上は仕組みによって担保すること。一個人の能力や注意力、献身に組織として依存しないこと。
自動化の推進
頻繁に行う作業や信頼性が重要な作業はなるべくコード化・自動化すること。手動作業と比べてオペミスが少なく、再現性に勝り、かつAIの活用も容易である。
変更管理
重要な変更は内容・理由・影響を記録すること。 また独断で行わず、レビューを経て承認を受けること。
3. 運用上の優秀性
設計・コード・UIの標準化
どの作業も標準化を推進すること。誰であれ同じタスクは同じ方法で対応できるべきであるし、同じ目的を持つ設計は同じ構造を持つべきである。
可観測性、モニタリング
ログやメトリクスを用意し、テストや障害調査を可能にしておくこと。すべてのシステムコンポーネントは可能な限り可観測であるべきである。 障害の予兆や発生をシステム的に検知できるようにすること。
トレーサビリティ
重要な事項は記録を残すこと。（例・本番作業やアーキテクチャ決定など）
成果物ベースの評価
十分な品質の成果物の生成を目的とすること。既存プロセスを守っていれば不十分な品質の成果物を出してもよい、とはならない。必要に応じてプロセス改善や例外対応を行い、品質を確保すること。その理由と影響を記録し、適切な担当者の承認を得ていれば、例外対応も差し支えない。
ただし正当な理由なく定められたプロセスを無視してはならない。（例・面倒だからテストせずリリース）
※ これは結果責任を作業者に負わせることではなく、劣化あるいは硬直化したプロセスの弊害の軽減を目的としたポリシーである。
非難なき事後分析
障害発生時は個人のミスを責めるのではなく、ミスを誘発した、あるいは防げなかった『システムやプロセスの欠陥』を特定し、根本原因を解決すること。
継続的改善
作った仕組みは定期的または必要時に見直すこと。
4. パフォーマンス効率
設計段階からのパフォーマンス考慮
パフォーマンス要件は事前に定義し、継続的に検証すること。本番相当のデータ量でスケーラビリティを確かめること。
ただし最適化はバランスを保たなければならない。明確なパフォーマンス上の必要性がない限り、早すぎる最適化や過度な最適化は避ける。
5. コスト最適化
開発・運用のコスト最適化は要件を満たす範囲内で行うこと。ただし不要な支出は避ける。