Product
A governed execution layer, not a more capable agent.
IVAI OS is designed to operate a company's existing business applications to complete defined operational workflows — following that company's policies and permissions, checking conditions before acting and results afterwards, and escalating what needs a human decision.
§ 01
What it is.
A digital worker is not a chatbot with a mouse. It is a bounded operator for one named workflow: it receives a request, gathers what it needs, applies the operating rules that govern that process, obtains approval where the risk requires it, acts, confirms the result, and records what happened.
What an organisation gets is not a model. It is a completed workflow with a reviewable record behind each decision — and a change of role for the people who run it, from executing steps by hand to owning the policy, handling the exceptions and holding the authority.
IVAI OS is deliberately narrow. One workflow, one accountable owner, one agreed definition of success. Breadth, if it is ever justified, follows from what actually repeats.
- Not an autonomous agent
- Sensitive actions are designed to pass a policy check and, where the risk requires it, a recorded human approval. Autonomy is a setting per action class, not a product identity.
- Not classic RPA
- Screens are intended to be read semantically rather than by fixed coordinates, with governance and verification in the core rather than added as reporting.
- Not a general desktop tool
- IVAI OS is intended to be built per workflow, against named systems, under named permissions — not as an operator for arbitrary software.
- Not a model vendor
- IVAI OS does not train foundation models and is designed so that no part of the system depends on one particular model.
§ 02
The control model.
Each layer has one responsibility. The authority boundary is a distinct layer, in the middle of the picture, on purpose.
Supervision
Where an accountable person starts a run, follows it, approves or declines a proposed action, and can stop it at any point.
task
Perception
Establishes what the application currently shows and holds. Models are used here — to interpret an interface, not to decide what happens next.
proposed action
approved action
Execution
Carries out approved actions in the customer's existing system, through its own interface. No replacement interface, no undocumented route into the data.
result
Verification and evidence
Confirms the business result independently of the component that performed it, and keeps a structured record of the decision, the authority and the outcome.
How it works describes the sequence this model follows for each consequential step.
§ 03
Autonomy is a setting, not a personality.
How much a workflow may do without asking is configured per action class and per customer, and is designed to increase only on evidence.
| Level | The system | The accountable person |
|---|---|---|
| Observation | Proposes the action it would take and the result it would expect. Executes nothing. | Compares proposals against their own judgement and calibrates the rules. |
| Assisted | Prepares the work and stops before the commit. | Reviews the prepared state and performs or approves the commit. |
| Approved execution | Executes within the workflow, pausing for approval on every action class marked sensitive. | Approves, declines, requests a change or escalates — and can stop the run. |
| Bounded autonomy | Completes standard low-risk cases within explicit rate, value and volume limits. | Reviews exceptions and owns the limits. |
§ 04
What it is not designed to do.
These are product boundaries rather than a temporary scope note.
Never carried out independently
- A final medical, credit, legal or regulatory determination.
- An unauthorised financial transfer.
- An irreversible deletion without approval.
- Sending sensitive material outside the organisation without an explicit policy that permits it.
- Any action whose result cannot be objectively confirmed.
- Any action outside an approved workflow.
Outside the product
- Operating arbitrary desktop software.
- Unrestricted control of a machine.
- Executing generated code or shell commands.
- Repairing a broken workflow step without human review.
Why the boundary is public
An automation vendor that accepts every workflow is describing its sales pressure rather than its technology. Stating the boundary before the conversation is more useful to both sides than discovering it during one.