Enterprise use cases
The constraint is not the industry. It is whether the workflow can be governed.
A process does not qualify because it is manual and tedious. It qualifies when its steps can be observed, its rules stated, its exceptions escalated, its risk bounded and its result independently confirmed.
§ 01
What makes a workflow a good candidate.
Suited
- It repeats, at a volume that justifies building for it.
- The systems involved are reachable under an authorised path.
- Its rules can be written down.
- Its results can be confirmed objectively.
- Its exceptions have a named owner to escalate to.
- A bad outcome is containable.
- It can be divided into short, individually checkable steps.
Not suited
- It depends on judgement that cannot be explained.
- There is no agreed definition of a correct outcome.
- An error would be severe and cannot be contained.
- The process changes fundamentally and continuously.
- There is no authority to access the systems involved.
- It requires a long horizon that cannot be divided.
Scoping that concludes a process is not a good candidate is a useful result. The most expensive automation failures begin with a workflow accepted because someone wanted the engagement.
§ 02
The first workflow: controlled invoice creation.
Chosen because it is unforgiving in the right ways. It writes to a system of record, creates a financial commitment, is arithmetically checkable, and produces an unambiguously wrong result if it duplicates.
Enter one invoice for an existing customer from supplied line items, check the total against an independent expectation, submit it once, and confirm the result from the application's own records.
A read-only or draft-only workflow would have been easier to build and would demonstrate considerably less. The question this development exists to answer is whether a system like this can be trusted to write — so the first workflow writes.
How correctness is established
One record exists for the request; its customer, line items, quantities, prices, discount, tax and total match what was intended; its status is the expected one; and nothing else changed. The check is performed independently of the component that acted.
-
01 Identify the customer and the items
Resolve the request against the records in the system. Where two candidates are equally plausible, the intended behaviour is to stop rather than choose.
-
04 Submit once
Designed so that an interruption during submission does not result in a second record.
-
05 Confirm from the system's own records
One record exists, its contents match what was intended, its status is the expected one, and nothing else changed. Only then is the run reported as successful.
§ 03
Workflow shapes that fit.
Categories that meet the criteria above. These describe the kind of work IVAI OS is being built for.
Document to system entry
A structured document arrives, its fields are checked against master data, and a record is created in the system of record — with the created record read back and compared before the run is reported as complete.
Cross-system reconciliation
The same fact is held in two systems and has to agree. The matching rules are applied, a correction is proposed, and the cases the rules do not decide are escalated.
Rule-bound case processing
A queue of similar cases resolved by written policy, with a defined escalation path. Standard cases complete; exceptions reach a person with the evidence already assembled.
Controlled master-data maintenance
Changes to reference data applied under approval, with before-and-after values captured and the effect confirmed from the system's own records.
Periodic operational checks
A recurring inspection across several screens or systems, producing a confirmed report and raising exceptions. Read-heavy and low-risk — a sensible first step.
Request intake and preparation
An incoming request validated and enriched from the relevant systems and prepared up to the point of commit, leaving the commit with the accountable person.