Anything can say it did the work.
Claritty keeps the provider’s own confirmation for every action, records who approved it and where, and seals the ledger so a later edit shows up.
The confirmation is the id Gmail returned. Our own record that we made the call is not stored as evidence that it arrived, because those are different facts.
A run log is the agent’s account of its own work
It is written by the same thing that did the work, which is exactly the wrong witness. When a Claritty automation sends, files or pays, what gets stored is the confirmation the provider returned — the id the service assigned. Whether we called the API and whether the message arrived are different facts, and only the second one is evidence.
The person who decided, and where they were standing
A run executes as the account that owns the credentials, because those are the only ones authorised for it. That is rarely the person who approved it. If the record only names the owner, a colleague approving a payment from Slack and the owner approving it themselves look identical afterwards — and telling those apart is the entire value of an approval trail.
So the action carries both: who pressed the button, and the platform they pressed it on.
An audit you can check, not one you have to believe
Ledger rows are sealed with a hash chain. Re-checking gives one of three answers, and the third is the one that matters.
Intact
Every sealed row recomputed to the hash stored with it. Nothing has been changed since it was written.
Altered
At least one did not. It names the first row that failed, and says outright when rows are missing rather than leaving you to notice the count.
Not yet sealed
There is nothing to check. Reported as its own answer, because "we could not check" is not "it checked out" and collapsing the two is the whole failure this prevents.
It tells you what it could not do
Most of the cost of automation is not the run that fails loudly. It is the answer that arrives looking complete and is not. So a run reports its own shortfalls:
Five rows could not be judged against the rule, so they were left out of the answer rather than guessed at. The count is in the report.
A column the rule depends on stopped coming back. That is raised as a change in the page, not absorbed into a smaller result.
We stopped watching before the app finished. Reported as an outcome nobody observed, which is neither a success nor a failure.
And it cannot quietly get expensive
Every run carries a hard spending ceiling, checked before each model call rather than totalled afterwards. An automation can declare a tighter budget for itself; it cannot raise one. What a run cost is measured from what it actually used, not estimated.
Ask this of anything that acts for you
When it says it sent something, what is that based on? Who approved it? And can you still show both in six months?