Es gibt etwas, das ich lange falsch eingeschätzt habe.
Ich dachte einmal, dass die Ergebnisse auch dann richtig sein würden, wenn die Policy korrekt formuliert ist.
Beim Lesen von @NewtonProtocol m wurde mir klar: Das reicht nicht.
Die gleiche Policy.
Es genügt, ein paar Parameter zu ändern, etwa die Transaktionsgrenzen, die zulässigen Listen oder die Gültigkeitsdauer—dann kann das Ausführungsergebnis völlig anders ausfallen.
Das Interessante ist: Die Logik ändert sich überhaupt nicht.
Was sich ändert, ist der Kontext, in dem diese Logik angewendet wird.
Damals habe ich eine Erkenntnis gewonnen.
In vielen Systemen ist nicht der Code das, was über das Maß an Vertrauen entscheidet.
Sondern die Konfiguration.
Code wird häufig auditiert.
Konfigurationen werden dagegen selten so genau betrachtet.
Dabei ist sie genau der Ort, an dem die Entscheidungen des Menschen in das System eingespeist werden.
Newton macht das ziemlich gut: Bei jeder Änderung der Konfiguration durch den PolicyClient wird eine neue policyId erzeugt.
Zumindest wissen die Nutzer, dass das System mit einer anderen Konfiguration als zuvor ausgeführt wird.
Aber ich habe noch eine Frage.
Wenn zwei Anwendungen dieselbe Policy verwenden, aber mit völlig unterschiedlicher Konfiguration.
Recyceln wir dann gerade dieselben Regeln.
Oder erstellen wir zwei unterschiedliche Systeme des Vertrauens unter demselben Namen?
Vielleicht wird die Zukunft von Policies nicht nur Transparenz über die Logik bedeuten.
Sondern auch Transparenz über die Annahmen, die eingeführt werden, bevor die Logik überhaupt zu laufen beginnt.
#newt $NEWT $M

What deserves more scrutiny in a policy system?