How Vigilo learns a workflow: from repeated decisions to a validated rule

A real workflow never fits entirely inside a procedure

Written instructions, contracts, rate matrices and standard operating procedures provide a valuable foundation. They describe approved sources, expected checks and decisions that must not be automated. Yet part of the work still lives in the team’s experience: calling a contact before a sensitive amendment, requesting approval after a cut-off time or selecting a slot in response to a local constraint.

Vigilo is designed to represent this reality without reducing a company to a standard scenario. Within the agreed scope, it observes events and decisions, links each choice to the relevant record and makes recurring practices explicit. The goal is not to imitate every habit, but to distinguish stable rules from exceptions and decisions that must remain human.

What Vigilo retains when a decision is made

A correction in isolation does not explain why it was right. To be useful, the decision must remain connected to the situation that prompted it and to the outcome that was subsequently checked.

• the initial event, its channel, timestamp and source;
• the versions of the record and documents that were consulted;
• the constraints known when the decision was made;
• the selected option, its rationale and the person or mechanism that approved it;
• the action prepared or executed in the business system;
• the outcome actually observed and any subsequent corrections.

From repeated decisions to a candidate rule

1. 01
   Observe

   The human decision is retained with the record, its sources and the verified outcome.

2. 02
   Compare

   Vigilo looks for comparable situations rather than a superficial resemblance between words or gestures.

3. 03
   Identify recurrence

   The same decision appears in a sufficiently stable context to warrant review.

4. 04
   Formulate a candidate rule

   The proposal describes its conditions, supporting examples, excluded cases and intended authorization level.

5. 05
   Obtain approval

   The team confirms the business meaning, adjusts the scope and decides whether the rule remains advisory, supervised or active.

6. 06
   Version and monitor

   Every change remains attributable to a version, with an owner, date and suspension mechanism.

Example: a request received after the cut-off time

Several orders received after the cut-off time are sent for approval before creation. The action looks identical, but the reasons may differ: remaining capacity, type of goods, customer commitments or a slot that has already been confirmed. Vigilo retains these factors with each decision instead of immediately inferring a general rule.

If the same decision recurs across genuinely comparable records, Vigilo can propose a candidate rule: for this flow and customer scope, request approval after the defined cut-off. The team checks the exclusions, appoints an owner and selects the authorization level. An order outside that scope continues to be escalated to an operator.

Adaptation becomes a product asset, not a one-off project

Two companies can use the same TMS and still follow different operating methods. Conversely, two different systems may support a similar workflow. Vigilo’s adaptability therefore relies on stable building blocks — events, records, rules, actions, checks and escalations — configured around the company’s actual way of working.

Sources, identifiers, screens, action rights and rules remain specific to the deployed scope. Their configuration is tested and versioned. This approach allows the product foundation to be reused when a new flow or system is added, without claiming compatibility before access methods, screens, volumes and required controls have been assessed.

What the team validates before activation

This validation is not only a risk control. It turns tacit knowledge into transferable knowledge: a new team member can understand the rule, review the cases from which it emerged and know when not to apply it.

• the business purpose of the rule and the records that support it;
• the customers, flows, entities, systems and periods to which it applies;
• the explicitly excluded cases and situations considered sensitive;
• the source of truth when information conflicts;
• the permitted actions and the checks required after execution;
• the owner authorized to change, suspend or withdraw the rule.

When Vigilo must stop

Adaptability does not mean that Vigilo should process every case. Conflicting sources, a changed interface, missing mandatory data or a situation outside the validated scope must trigger an explicit stop. The record handed to the team then contains the event, reconstructed context, relevant rule and reason for stopping.

This behavior is part of the workflow. It allows autonomy to evolve on the basis of observable evidence without concealing areas where the organization, system or rule has changed.

Measured progression

1. 01
   Observe without acting

   Compare Vigilo’s reconstruction with the decisions made by the team.

2. 02
   Propose

   Present actions and candidate rules without changing business systems.

3. 03
   Authorize a precise scope

   Activate only the cases, systems and actions whose controls have been validated.

4. 04
   Expand or reduce

   Adjust coverage in response to outcomes, system changes and newly encountered cases.