Enterprise automation, under control

Governed computer-use automation for enterprise systems.

IVAI OS is designed to run repeatable business workflows inside the applications an organisation already uses — under its own policies and permissions, with consequential actions authorised before they happen and confirmed after they happen.

IVAI OS is currently in private pilot development. Capabilities described on this website represent the intended product and validation programme unless explicitly identified as completed.

The control model

01 Observe Read the state of the application through the most reliable channel available.
02 Authorise Check every proposed action against policy, permission and limits.
03 Execute Perform one approved action, once.
04 Verify Confirm the business result from an independent source.

A model may propose an action. It does not authorise or execute one.

§ 01

The work is repeatable. The accountability is the hard part.

A large share of operational work is a person moving structured information between systems that were never designed to talk to each other. It is a good automation candidate — until the automation has to write to a system of record.

At that point the questions change. Who authorised this action, under which rule, with what permission, at what value? And how does anyone establish that the intended result actually occurred, rather than appearing to?

General-purpose agents are improving quickly at short tasks and remain unreliable over long, multi-step work in unfamiliar interfaces. The failure that matters in a production system is rarely a wrong click. It is an unverifiable report of success, or a retry after an interruption that quietly creates a second record.

What has to hold before automation touches a system of record

  • The workflow has a defined boundary, defined inputs and an agreed definition of success.
  • Every action can be traced to an owner, a permission and a rule.
  • Sensitive actions stop for a person, who can see enough to judge them.
  • The result is confirmed from the system's own records.
  • A retry establishes what already happened before acting again.
  • A run that cannot be confirmed stops, and says why.

§ 02

The difference is where authority sits.

IVAI OS is not designed to be an unrestricted autonomous agent. Perception, authority, execution and verification are separated deliberately, and that separation is the product.

An unrestricted agent

The model is the system

  • The model decides what to do, and then does it.
  • Authority is implicit: whatever the session can reach, the agent can change.
  • Success is whatever the model reports, judged from the screen it acted on.
  • Recovery means trying again — which is how one action becomes two records.
  • The audit trail is a transcript.

IVAI OS — the intended model

The boundary is the system

  • A model proposes. It does not execute.
  • Every proposal is checked against policy, permission and scope before anything happens.
  • Results are confirmed from the application's own records, independently of the component that acted.
  • Consequential steps are designed to establish what already happened before retrying.
  • The record is structured for review.

Two design rules

A model proposes; it does not execute. Deciding whether an action is permitted, and carrying it out, are handled elsewhere.

A model does not confirm its own result. Verification reads the resulting business state independently of the component that acted.

§ 03

One loop, applied to every consequential step.

Long workflows are designed to be split into short segments, each with its own checkpoint, because long-horizon autonomy is where current computer-use systems are least dependable.

01 — Scope

Bounded by design

One named workflow, one accountable owner, one definition of success agreed in advance. Workflows whose results cannot be checked objectively are declined rather than attempted.

02 — Authority

Approval that means something

Actions with financial, external, irreversible or uncertain impact are designed to require a human approval bound to an identity, a scope and a set of values — not a standing permission.

03 — Evidence

Reviewable afterwards

The intent is that what was decided, authorised, executed and confirmed forms a structured record, so a completed run can be reviewed rather than reconstructed from memory.

See the full control model

§ 04

Where it goes next.

The first workflow under development is controlled invoice creation: enter one invoice 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 controlled validation programme is planned against a licensed non-production enterprise application using synthetic data, to evaluate governed computer-use workflows against a realistic interface before any customer deployment.

The validation programme

Who we would like to hear from

Operational owners with a repetitive, rule-bound, high-volume process running through a business application — and technical or security reviewers who evaluate automation that touches systems of record.