Anchored does not mean anchored now: the window before the anchor
Between a decision and its anchor on chain there is a window in which only your own system protects the entry. Chain the entries, anchor on events, and say anchored only when final.
Anchoring a decision log on a blockchain does not happen at the moment of the decision. Entries are collected, hashed together and anchored every so often, because each anchor costs a transaction and takes time to become final. Between the decision and the anchor there is a window, and during that window the only thing protecting the entry is your own system.
What the window is
When the agent decides, the entry goes into the ledger. The system computes a hash, often combined with other entries into a single root, and publishes that root on the chain at some cadence. Until that publication is included and final, nobody outside your organisation can prove the entry existed in that form. Anyone with write access to your store could still alter or drop a recent entry, and nothing on the chain would contradict them. The longer the cadence, the longer the window. This is not a flaw. It is a cost trade-off that has to be written down rather than hidden. Even a short window matters when decisions are frequent: many entries wait for the same anchor, and all of them share the same exposure.
Shrinking the damage
Link every entry to the previous one by including the previous hash in the next, and give each a sequence number. Now removing or changing an entry in the middle breaks the chain, and the break shows at the next anchor. The window does not disappear, but an attack inside it has to rewrite everything after the point it touches before the next anchor lands, and it has to do so without leaving a gap in the sequence. You can also anchor on events, not only on a timer: a decision above a certain impact, or a manual close at the end of the day, triggers an anchor right away. Cadence then follows risk, and cost follows the decisions that matter.
Say anchored only when it is final
A transaction that has been broadcast is not an anchor. Wait for the number of confirmations your chosen chain treats as final, and record in the ledger which block carries the root and when it became final. Show the three states honestly in the verifier: recorded, submitted, final. An auditor who sees "anchored" on an entry that is still pending has been told something untrue. Finality is not instant either, and the confirmation depth is a decision that needs a reason, not a default copied from a tutorial.
What this means for a delivery
Put the cadence, the trigger rules and the confirmation depth into the design document, with the reason for each, next to the cost of one anchor on the chosen chain. The question an auditor asks is not whether you anchor. It is what you cannot prove yet, and for how long.
Also decide who is told when an anchor fails or stays pending past its expected time. That is an incident, not a log line: the window is growing, and someone has to own it.
What is the longest an entry in your ledger can exist without being anchored?