このレポートには、膨大なサポートを奪われ、実行中のコードベース（ほぼ9年間使用されなかったコードの実行によりエラーが発生した）と、ソフトウェア開発者とITプロフェッショナルの間のやり取りの恐ろしい悲しい歴史におけるすべての技術的負債の特性が含まれています。
ハイライト：
2012年8月1日に開始予定のニューヨーク証券取引所の流動性プログラム（PL）に顧客が参加できるように、ナイトは注文処理プロセスに関連するシステムとプログラムコードに多くの変更を加えました。 これらの変更には、SMARSでの新しいコードの開発と展開が含まれていました。 SMARSは、注文を市場に送信する自動化された高速アルゴリズムルーターです。 SMARSの主な機能の1つは、ナイト取引プラットフォームの他のコンポーネントからの注文（「親」注文）を受け取り、必要に応じて、利用可能な流動性に基づいて、1つ以上の代表（または「子会社」）注文を実行のために外部サービスに送信することです。
13.デプロイ時に、SMARSの新しいPLコードは、ルーターの対応する部分の未使用コードを置き換えることになっています。 この未使用のコードは以前、Power Peg機能に必要でしたが、同社は長年使用していませんでした。 それにも関わらず、潜水艦の配備中に運用され、呼び出されました。 新しいPLコードは、以前はPower Pegに関連付けられていたフラグを使用しました。 Knightは、このフラグがアクティブになったときに潜水艦の新しい機能が使用され、パワーペグではなく、パワーペグコードを削除したかったのです。
14.以前、Power Pegを使用する場合、加算機能は実行された子注文の株式数を計算し、親注文の完了後に子注文の発行を停止する必要があることを通知しました。 2003年、ナイトはパワーペグの使用を停止しました。 2005年に、Knightは親の注文追跡機能をSMARSコードシーケンスの初期段階に移動することにより、Power Pegコードを変更しました。 Knightの変更が実行されなかった後、Power Pegコードのテストを繰り返しましたが、手順が正しく機能することを確信していませんでした。
15. 2012年7月27日から、KnightはSMARSに新しいサブコードを展開し、限られた数のサーバーに配置しました。 新しいコードの展開中、技術者の1人が8つのSMARSサーバーの1つに新しいコードをコピーしませんでした。 Knightには展開をテストするための2人目の技術者がいなかったため、Power Pegコードが8番目のサーバーから削除されず、新しいPLコードが追加されなかったことを誰も理解していませんでした。 Knightには、そのような検証を必要とする書面による手順はありませんでした。
16. 8月1日、ナイトは、クライアントがサブに参加できるブローカーディーラーから注文を受けました。 7つのサーバーが注文を正しく処理しました。 しかし、起動フラグが設定された8番目のサーバーに送信された注文は、このサーバーにまだ存在していた欠陥のあるPower Pegコードを起動しました。 その結果、サーバーは注文を親として受け取り、取引センターへの子注文の送信を開始しました。 親注文の実行を確認する機能がプロセスの別の段階に移動したという事実により、サーバーは子注文をノンストップで続けました-親注文がすでに完了しているという事実に注意を払っていません。 注文処理システムの一部は親注文が完了したと判断しましたが、この情報はSMARSには入りませんでした。
19. 8月1日、ナイトは潜水艦に関連する注文も受け取りましたが、市場が開くまで取引を目的としていました。 6つのSMARSサーバーがこれらの注文を処理し、午前8時1分ごろから、内部システムがSMARSを参照し、エラーを「Power Peg Disabled」と説明する自動メッセージ（「BNET障害」と呼ばれる）を生成しました。 Knightシステムは、市場が開かれた午前9時30分まで97個のメッセージを送信しました。 このタイプのメッセージはシステムによって危険と見なされず、スタッフはそれらをまったく読みませんでした。
その後、さらに楽しい：
27. 8月1日、ナイトにはインシデント対応手順がありませんでした。 つまり、重大な問題が発生した場合、会社には人事管理の管理手順がありませんでした。 8月1日、ナイトは技術者チームのサービスを使用して、ライブトレーディング環境でSMARSの問題を特定し、修正しました。 Knightシステムは、スタッフが問題の原因を特定しようとする間、何百万という「子供」の注文を送り続けました。 同社は、正しくインストールされた7台のサーバーから新しいPLコードを削除しました。 これは状況を悪化させました。新しい「親」命令が、8台目のサーバーで既に発生していたのと同様に、これらのサーバーに存在するPower Pegコードをアクティブにしたためです。
もちろん、ドキュメント全体を読む価値があります。このような悲劇を避けるために、人々が実行する新しい検証手順に大きな注意を払っています。 もちろん、開発者の間違いは人的要因に関連していましたが、そのような結果は、不適切な展開シナリオと不快な監視の結果でした。 これはどのようなオフィスで、クラスターのソフトウェアバージョンもチェックしませんか？ リターンコードがチェックされる展開シナリオは言うまでもありません。
ウィキペディアによるとこれはそうではないと言っていますが、未使用のコードの「書かれた検証手順」が体系的なテストを暗示していることを願うだけです。
デザートの場合：罰金はさらに1,200万ドルでしたが、監査はシステムが常に投機的な空売りを試みていることを示しました。