架空企業「みらい業務サービス」の社内依頼・承認管理アプリの例。実在する会社・案件・人物は含まない。 記事「「提出したのに履歴が残らない」申告から、初動手順をたどる」（12-02）の本文で実際にまとめた内容をまとめたもの。空欄版は 12-02-incident-response_template.md。

1. 異常時の初動手順

入口症状（申告）確認する記録と事実仮説と切り分け原因影響範囲の判定対応区分暫定対応恒久対応／残課題初動の担当連絡先
利用者の申告（依頼者役・佐藤）＋失敗ログ提出時に「履歴の記録に失敗しました」と表示。一覧では提出済み状態ファイル：提出済み／履歴ファイル：0件／失敗ログ：1件（TypeError）A 通信失敗→消える、B 拒否→消える、C 部分失敗→残る履歴の書き込み失敗（08-04の部分失敗。状態と履歴が別々に書かれる作りに起因）同じ症状の依頼が他に0件、失敗ログ1件→REQ-0003に限る即時対応失敗ログの増加を監視、REQ-0003の扱い（履歴を補う／状態を戻す）は運用管理者が決める、依頼者へ連絡、総務課長へ報告、版が変わっていないため切戻しは行わない候補：状態変更と履歴追加を全部成功か全部取り消しにする（記事B）。題材アプリへの適用は未決運用担当（架空）総務課長（架空）、依頼者本人

2. 完了条件の確認

3. 次工程へ渡すもの