Why execution must be boring
A process that has to be explained later should never be interesting while it runs. Same input, same outcome, every time, with nothing decided on the fly. Most tooling optimises for the opposite: flexibility, speed, a step that can retry or branch or call out to whatever it likes. That is fine for a build pipeline. It is a liability for a record that someone may one day have to defend.
Amon Sul makes execution deliberately dull. A record is in a state. A sequence of actions runs and produces facts. The policy says what those facts mean, and the record moves to the one state the policy allows. There is no second path, no override, no step that gets to decide for itself.
Why logs are not enough
Logs are written after the fact, by whichever component felt like writing one. They record what a step reported, not what was allowed. They are edited, rotated and lost. And they almost never carry the version of the rules that applied at the time, which is the first thing anyone asks for.
The log in Amon Sul is not a side effect of execution. It is the execution. The entry is written as the decision is made, with the input, the output, the actor and the policy version in force. It is append-only. If the log and the decision disagree, that is impossible by construction, not unlikely by convention.
Why AI in the decision increases risk
A model's output is probabilistic. Run it twice and you may get two answers; ask it why and you get a plausible story, not a reason. Putting that in the path of a decision means the decision inherits those properties. It cannot be reproduced, and it cannot be explained in a way that survives a hostile question.
So there is deliberately no AI inside Amon Sul. A model can sit in front of it, proposing a move or producing a fact. The policy decides whether that move is allowed, and the log keeps what was proposed next to what was done. The model is a signal source. It is never the authority.
Policy as a first-class artefact
In most systems the policy is spread across code, configuration, a wiki page and the memory of whoever built it. Changing it leaves no trace of what it used to be. In Amon Sul the policy is a versioned object: the states, the sequences that run in each, and the routes from one state to the next. Publishing a new version does not delete the old one. Every record remembers which version governed each of its moves.
Audits, disputes and courtrooms
Compliance tooling produces documentation around a process: a register, an assessment, a policy document. It is checked at audit time and proves intent. It is never in the path of the decision. Amon Sul is the runtime those documents describe. When someone asks why a record moved, the answer is not a reconstruction from fragments. It is the entry that was written when it happened, under the rules that applied, reproducible today.