「千に勝るは手に如かず。」紙の上で正しい理論は、十分に長く運用されて初めて、誰も予測しなかった穴が露見するのとはまったく別物だ。
それはポリシーエンジンのコード行数の話でもない。広告されているロジックの複雑さの話でもない。サポートされるポリシー言語数の話でもない。
より単純な問いがある──あるポリシーが、これまで想定していなかった境界状況に遭遇したとき、システムは「安全のため拒否」するのか、「条件のブロックに一致しないから許可する」のか？
それは小さなディテールだが、本当の安全性を左右する。@NewtonProtocol の安全性は、想定外の処理の仕方によって、どんな機能よりもこのシステム全体の哲学が語られるからだ。
既知のケース向けにポリシーを書くのは簡単だ。未知のケースに備えて設計するのは難しい──拒否をデフォルトにすればシステムは守れるが、正当な取引を誤って止めてしまう可能性がある。許可をデフォルトにすれば体験は滑らかになるが、ポリシーが本来防ぐべき「それ」にすり抜けてしまう可能性がある。
もしNewton Protocolが、想定外の状況では安全側にデフォルトを選ぶなら、時に正当なユーザーにとって面倒でも、それは真剣な設計の兆候だ。この保護層が、事前にプログラムされていなかった状況でどれほど信頼できるか――$NEWT が示すのは、うまく処理できた既存事例の数だけではない。
自己反論：まだ具体的な情報がない。Newton Protocolがポリシーの範囲外に遭遇したときのデフォルト挙動については、直接確認が必要で、現時点では証拠に基づく推測はしていない。
しかし、未知へのシステムの対応は、既知への対応以上に多くを語る。そして、それこそが、このコンプライアンス層に大きな取引を預ける前に問い直すべき重要なディテールだ。
#newt $NEWT