- Who is this for?
- Executive, product, operations and transformation leaders
- Question addressed
- Assess an AI operator’s ability to adapt to business rules.
Key takeaways
- Business operations cannot be reduced to a prompt or a list of fields.
- Every rule needs a scope, a source and a version.
- Screens and exceptions evolve, so adaptation must be observable.
- Useful configuration is measured by stability and recovery, not by the number of settings.
- The reusable foundation connects events, the case record, rules, actions, verification and supervision; it does not assume that every company works in the same way.
- Channels, mappings, interfaces, responsibilities and permissions still need to be configured and validated against the real workflow.
- Adaptability means reusing testable product logic, not promising universal compatibility or rebuilding the entire solution for every customer.
The same TMS does not mean the same workflow
Two carriers can use the same software and make different decisions. Input channels, customer rules, roles, controls and authorisation levels together define how the operation actually works.
A generic operator may recognise a screen. A business-aware operator must also know which information is expected, why it is used and when processing must stop.
What must be managed as a product
- observed sources and events;
- record entities and identifiers;
- business rules and their versions;
- authorised actions and access rights;
- pre-action and post-action controls;
- escalation reasons;
- quality and drift metrics.
The difference between product configuration and an endless project
Productised adaptation relies on reusable building blocks: event observation, record memory, rules, interaction, verification and supervision. The specific work consists of configuring and testing these building blocks in the company’s environment.
This approach does not eliminate scoping work. It is designed to prevent every customer engagement from starting again as an entirely separate development that cannot evolve in a controlled way.
Questions to ask before choosing
- 01Governance
Who can create, approve, change or deactivate a rule?
- 02Observability
Can a decision be traced back to its sources and the version used?
- 03Maintenance
What happens when a screen or document changes?
- 04Portability
Which building blocks are reused and which parts remain specific?
- 05Measurement
How are quality, rework and exceptions monitored?
The common foundation: six connected functions
A product foundation is not defined by giving every customer the same screen. It is defined by a consistent way of representing work: detect what has happened, link it to the right case, apply an approved rule, prepare or perform an authorised action, check the outcome and make exceptions available for supervision.
These functions form a chain. An action separated from the event that triggered it, the rule used or its final control does not provide the continuity needed to resume the case confidently.
| Common function | Role in the workflow | What must remain verifiable |
|---|---|---|
| Events | Represent a request received, a document added, a status change or a human response. | The source, timestamp, useful identifier and link to the case. |
| Case record | Bring together the events, documents, data, decisions and outcomes relating to one operation. | The timeline, versions and reason for a match or correction. |
| Rules | Express the conditions, thresholds, exceptions and fallback behaviours approved by the business. | The owner, scope, version and decision that caused the rule to apply. |
| Actions | Prepare or perform an authorised operation through an API, a file exchange or interaction with an interface. | The permission used, data sent, target and returned outcome. |
| Verification | Read the target state and compare the observed outcome with the expected one. | Evidence after the action; a click or positive technical response is not always sufficient. |
| Supervision | Hand over ambiguous, sensitive, out-of-rule or unverifiable cases. | The reason for stopping, context already gathered, expected owner and resumption point. |
What changes in practice from one operation to another
Workflow-specific configuration should not hide genuine differences behind a generic setting. It makes the sources, data correspondences, interaction methods and ownership of decisions explicit. Each element is tested with representative cases before permissions are extended.
| Variable dimension | Questions to resolve | Expected validation |
|---|---|---|
| Channels and sources | Does the request arrive through a shared mailbox, file, portal or another authorised source? What counts as a new event? | Recognise expected cases, duplicates, versions and inputs outside the agreed scope. |
| Mappings | Which source field maps to which business value and target field? Which transformations are allowed? | Test present, missing, ambiguous and incompatible values without inventing information. |
| Interfaces | Does the exchange use an API, a file import or authorised interaction with a screen? Which states confirm success? | Check rights, errors, sessions, interface changes and safe recovery. |
| Responsibilities | Who owns the rule, approves an exception, answers a question or authorises a sensitive action? | Assign every handoff, define the useful internal response time and keep the decision in the case record. |
| Permissions | May the system only observe, prepare an action, perform it or request confirmation? | Test each level separately and define a fallback when evidence is missing. |
Fictional comparison — one foundation, two different order-intake workflows
Fictional teaching scenario: the companies Alpha Transport and Beta Freight, their systems and the situations below are invented. They illustrate an adaptation method; they are not evidence of a deployed integration or a customer result.
Both operations want to connect an incoming request to a case, decide whether it can be entered, act in the TMS and then check the result. The event → case → rule → action → verification → supervision chain is therefore shared. Its operational configuration is not.
| Observed point | Alpha Transport — fictional | Beta Freight — fictional | Reused element |
|---|---|---|---|
| Input | An order attached to an email in a shared mailbox. | An order made available on an authorised portal. | Creation of a sourced, timestamped event. |
| Matching | Customer reference and pickup-delivery pair. | Portal identifier and shipment reference. | Case lookup, version management and a record of the match. |
| Mapping | Dates, addresses and weight extracted from the document. | Structured fields mapped to values in the TMS. | Separation of source and target data, with completeness checks. |
| Action | Preparation of a record for approval by the operator. | Authorised creation followed by reading the target status. | An action bounded by permissions and linked to the rule applied. |
| Exception | Missing time slot: an approval request is prepared. | Expired session: the action is suspended and the case handed over. | The reason for stopping, context and resumption point are preserved. |
Adaptable means neither universal nor entirely bespoke
A promise of instant compatibility with every TMS, portal, format or screen would ignore software versions, usage rights, data quality and process variants. Feasibility must be established for each access method and each action actually in scope.
Conversely, recognising this specific work does not mean starting from a blank page. The case record, rule governance, action levels, controls and supervision mechanisms are reusable building blocks. Local project work connects them to the context, configures them and proves that they work.
- Reusable: the structure of events and case records, the rule lifecycle, decision traceability, post-action verification and exception handoff.
- To be qualified: accessible sources, reliable identifiers, fields, formats, interface paths and signals that prove the outcome.
- To be decided with the company: responsibilities, rights, thresholds, sensitive cases and conditions for expanding the scope.
- To be maintained: mappings, rule versions, access methods and controls affected when a system or working practice changes.
Proving adaptability on a new workflow
The evidence is not the number of connectors advertised. It is the ability to show, on a bounded scope, what has been reused, what has been configured and how the team knows that an action and its recovery path are reliable.
- 01Define the expected outcome
Name the starting event, target state, excluded cases and person responsible for the workflow.
- 02Map the variations
Document channels, identifiers, mappings, interfaces, local rules, permissions and available evidence.
- 03Configure the foundation
Connect these elements to the case record, rules, action levels, controls and already structured handoff reasons.
- 04Test the useful paths
Exercise expected, incomplete, contradictory and technically interrupted cases, then check that every stop can be explained and resumed.
- 05Validate responsibilities
Have the relevant owners approve rules, permissions and fallback behaviours before any expansion.
- 06Monitor change
Track exceptions and controls that no longer pass; a change to a screen or working practice triggers targeted requalification, not automatic trust.
Frequently asked questions
Direct answers
Does customisation mean training a model for each customer?
Not necessarily. Adaptation can cover rules, sources, mappings, controls and access rights without requiring dedicated model training.
Why not standardise the process completely?
Some stages can be standardised, but contracts, customers, systems and exceptions create real differences that must be represented explicitly.
How can a rule be kept from becoming obsolete?
By versioning it, monitoring its use and exceptions, and assigning an owner and a review process.
Does a reusable foundation make deployment immediate?
No. It avoids rebuilding the general logic, but access methods, mappings, rules, responsibilities, permissions and evidence still need to be configured and validated against the real workflow.
Is Vigilo compatible with every TMS and portal?
Universal compatibility should not be inferred from adaptability. Feasibility depends on the system, its version, the authorised access method, the actions in scope and the controls available.
How can configuration be distinguished from bespoke rebuilding?
Configuration connects local specifics to common, versioned building blocks. Bespoke rebuilding would recreate case, rule, action, evidence and exception management separately. The work that is genuinely specific must be identified during scoping.
How can a building block be shown to be truly reusable?
Show its common function, what was configured for the new scope, the end-to-end tests and its behaviour during an exception or change. A general statement or a connector name is not sufficient evidence.
Can a business rule be copied unchanged between two companies?
Not automatically. Its structure may be reused, but its meaning, owner, thresholds, exceptions, permissions and scope must be approved in each context.
Sources and methodology
This resource describes Axonovia's product approach based on transport workflows. The examples are illustrative and do not constitute a performance commitment or a universally applicable contractual rule.
Product review: Axonovia team · next review recommended before 31 August 2027 or following a material change in scope.