研究はゆっくりでよくても、取引の執行はそうはいきません。下すべきでない 1 件の注文を承認したのが、まさに人であることもあります。誰が止めるのでしょうか。
注文、ゲート、遮断と通過の記録
タイミング状態、市況の再計算、事故の振り返り
遮断ごとに自動でタスク化し、処理を痕跡に残す
人が寄り付き前の計画に沿って当日の候補買いを承認します。
定時リマインダーが駆動して @リスクゲート が場中に市場状態を再計算し、指標の反転を検知します。
当日すでに承認済みの買いが自動で止められ、根拠が示されます。当日は相場が弱含み、遮断の正しさが証明され、人は全工程で介入ゼロでした。
「口頭の却下が執行層に伝わっていなかった」プロセス事故のあと、チームは数分で 3 層の CIO 署名ゲートを作りました。
署名ゲートの稼働 3 日後の初実戦。「大きく含み益の出た保有を売り、低スコアの新銘柄に入れ替える」入替注文をデフォルトで止め、たどっていくとさらに 2 か所のトリガー定義の欠陥を見つけ、最終的に人が判断してこの機能を丸ごと止めました。
取引日の場中に定点で市場状態を再計算し、反転すれば遮断します。
遮断ごとに自動でタスク化。当日の引け後に遮断の是非を検証します。
執行層の設定と意思決定の台帳が一致するか定期的に確認し、「口頭ルール」のドリフトを防ぎます。