Newtonの中で、取引の承認が通ったかどうかだけを確認するのではなく、承認までの経路をしばらく追跡してみました。
目立ったのは、その判断そのものではありませんでした。判断の「後ろにある道筋」でした。
あるテストのバッチでは、取引リクエスト47件を確認しました。39件は承認、8件はブロックでした。通常は、そこでシステムの確認は終わります。青信号。赤信号。次へ。
でもここでは、なぜその判断が下されたのかを実際に確認できました。
たとえば、支出のしきい値を12.4%超えた取引は却下されました。同じウォレットからの別の取引は、6分後にパラメータが許可された範囲に一致したため承認されました。その違いは、汎用的なエラーメッセージの裏に隠れてはいませんでした。条件が見えていたのです。
ログをエクスポートして、横並びで比較しました。監査証跡にはタイムスタンプ、権限参照、発火したルール、実行結果が含まれていました。私がレビューした判断のうち約95%は、チームメンバーに「何が起きたのか」を聞かなくても復元できました。
それが小さく聞こえるのは、\"なぜこれがブロックされたのか？\"への答えが、Slackメッセージ3通とサポートチケットに変わってしまうようなシステムに対処したことがない場合です。
ただ、私がまだ気づいたことが一つあります。
利用可能な情報量は役に立ちますが、誰かがそれを読もうとする場合に限ります。いくつかの記録には、その判断を説明できるだけの文脈がありましたが、ログに記録された何十もの出来事の中から正確なシグナルを見つけるのには、それでも時間がかかりました。
透明性はそこにあります。
問題は、その透明性を人々が実際にワークフローとして構築するのか、それとも承認・却下の件数を見続けて、その間にあるすべてを無視し続けるのか、ということです...

@NewtonProtocol $NEWT #Newt .