Automation needs receipts

The minimum useful execution record

Currivo's current automation execution data includes an event identifier, status, action-step results, errors, and timestamps. The fuller standard below is product direction, not a claim that every field exists in the current build.

• The event that triggered the run.
• The version of the rule that evaluated it.
• The conditions that passed or failed.
• Each attempted action and its result.
• A correlation identifier for related logs and events.

Fail visibly

A retry queue is necessary, but it is not an operating interface. Teams need to know when a customer-facing action is delayed, exhausted, or awaiting a provider. The system should preserve the original intent and the evidence needed to retry safely.

Keep authority on the server

Hidden buttons do not create authorization. Every automated action should resolve the active workspace and actor on the server, enforce the same permissions as a manual action, and reject ambiguous or cross-workspace identifiers.

Let people override with context

An override should be deliberate, attributable, and recorded. The point is not to make automation impossible to interrupt. The point is to make exceptions understandable after the urgent moment has passed.