After the click: how Vigilo verifies that an action actually succeeded

A click is not proof

A “Save” button may have been clicked while an off-screen required field prevents submission. An API may return successfully before an asynchronous process fails. A window may close even though the change never appears in the record. Measuring only the command that was sent creates a false sense of reliability.

Vigilo separates execution from verification. Before acting, the workflow describes the expected state. After the action, it observes the target system again and looks for the evidence defined for that case. The loop closes only when the observed outcome meets the approved conditions.

Define success before acting

Verification cannot be added as a generic checkbox after deployment. For every approved action, the team defines what proves success, what indicates failure, and what remains indeterminate.

1. 01
   Expected state

   For example: a record created with a TMS reference, a changed time slot, or a confirmed cancellation status.

2. 02
   Primary evidence

   The state read back from the system that is authoritative for the workflow.

3. 03
   Consistency checks

   Critical values, version, amount, status, timestamp, or document presence.

4. 04
   Acceptable delay

   The period during which a process may legitimately remain pending.

5. 05
   Mismatch handling

   Observe again, use an approved recovery path, or hand the case to the team with evidence.

Example: creating an order in the TMS

An approved request must create an order for pickup in Lyon, delivery in Lille, and an 8–10 a.m. time slot. Vigilo enters the approved fields and submits the form. A green success notification may be useful evidence, but it is not necessarily enough.

The workflow looks for the reference assigned by the TMS, reopens or rereads the record, and compares its critical fields with the prepared order. If the displayed slot is 10 a.m.–12 p.m. or no order can be found, the observed outcome does not match the intent. Vigilo retains that state and routes the case according to the agreed procedure.

Four possible levels of evidence

The right level depends on risk and system capabilities. Changing a comment may need lighter evidence than cancelling an order or approving an invoice. Multiple levels can be combined when the action has downstream consequences.

Example: a change inside 24 hours and the related charge

Within an approved scope, a change received less than 24 hours before the operation may lead to dock waiting time and an additional charge that must later be checked. Vigilo attaches the request to the record, updates the TMS when authorized, and verifies that the new slot is visible. It also keeps the event that will support the financial check.

During invoice reconciliation, the existence of the change is not enough. The workflow compares the actual timeline, the applicable rule, and the invoiced lines. If an expected charge is missing, or if the waiting time is not supported by the required evidence, the record is flagged with the observed difference. Vigilo does not decide an amount on its own when the necessary evidence or rule is missing.

What happens when the outcome is uncertain?

“Indeterminate” is sometimes safer than an assumed success or failure. It lets the team decide without losing context and prevents an automatic reaction from turning a minor incident into a duplicate, an incorrect cancellation, or conflicting information.

• wait for the defined period when processing is asynchronous;
• read the state through another approved view or source;
• avoid blindly repeating a creation that may produce a duplicate;
• retain the screenshot, value, timestamp, and version needed for diagnosis;
• show the operator the intent, attempted action, and observed mismatch;
• resume only through a recovery strategy approved for that case.

API or interface: the same outcome requirement

When an API exposes the required action and states, it is often the most direct path. When it does not cover the need, controlled interaction with the user interface can act as an operator would. In both cases, transport operations cannot be reduced to a successful request or click.

Vigilo therefore adapts the evidence as well as the action: it identifies the authoritative state in the relevant TMS, how to read it back, and which mismatches must interrupt the workflow. A change in the interface or application behavior should trigger detection and reassessment, not silent execution at all costs.

The trace operations and control teams need

This trace helps resolve exceptions, explain decisions, and improve rules. It also connects upstream events to invoicing: a change, wait, or cancellation remains available when the team checks what was actually performed and billed.

• the event and record behind the action;
• the rule, approval, and version used;
• the prepared data and the action actually sent;
• the expected state, observed state, and verification time;
• the mismatch, recovery, or human decision that closed the case.