The questions operations leaders ask before they start.

Three deployment options, and you choose. On-premise — everything runs on your hardware. Private tenancy — a dedicated instance in your own cloud region, under your keys. MIRAI-managed — an isolated tenancy we operate, which is the fastest to start.

In all three, no third-party model provider sees your data. That is the point of MIRAI Model: custody, not performance.

No. Your operational data runs your workflows and nothing else. It is not used to train shared models, and it is not pooled with other clients' data.

Access follows the roles you already operate. Approval authority, value thresholds and visibility are configured per workflow and enforced by the system, not by convention.

MIRAI staff access to a live environment is granted for a named piece of work, logged in the same audit history as everything else, and revoked when the work is done.

You take it with you. Workflow definitions, case records and the full audit history export in open formats — at any point in the engagement, not only at the end.

The history is designed to survive outside MIRAI, because an audit trail you cannot remove from the system is not really an audit trail.

We will not list badges on a website. Ask us and we will send our current certification position in writing, along with the controls that sit behind it, before you go any further.

Our data handling is written to align with Singapore's Personal Data Protection Act — see the privacy policy for how that works in practice.

The standard implementation runs to 90 days for one workflow — map, move, manage, measure. Automated steps run against your real cases well before that, in observation mode, so you watch the system get it right before it is allowed to act.

The full sequence is set out on the Method page.

Nothing beyond the conversation. You get a written view of what the workflow costs today, what could be automated, what must stay with people, and what a Blueprint would measure. If you take that document elsewhere, that is a legitimate outcome.

We say so, in writing, before you spend anything on building it. Some workflows are better fixed by changing the process. Some are better left manual because the volume does not justify the work.

A no at this stage is cheap. A no eighteen months into a platform programme is not.

Heaviest during mapping, when we need the person who genuinely runs the work — not a description of how it is supposed to run. Expect a few hours across the first fortnight, then short review sessions at each stage.

We do not run discovery workshops for their own sake, and we do not need a project team standing by.

No. MIRAI connects the systems you already run. Replacing a system is a separate decision, made later, on its own merits — and usually a much easier one once you can see what the workflow actually costs.

It happens more often than vendors admit. Depending on the system there are usually options — scheduled file exchange, database-level integration, or a supervised desktop step that a person still confirms.

Where none of those is safe, we say the workflow cannot be run properly and we do not build it. That constraint is identified during mapping, not discovered during rollout.

No. Most of our clients do not have one. You need someone who can grant access to your systems and someone who owns the workflow operationally — often the same person.

Where you do have IT, they are involved early, because integration decisions are theirs to review.

MIRAI is bought for capacity, not headcount reduction. What gets removed is coordination work — chasing, re-keying, checking whether something happened — so the same team carries more volume without proportional hiring.

What you then do about roles is your decision, not a consequence of the system. We will not pretend otherwise, and we will not sell it as a redundancy plan.

For most people, very little — the work arrives in a queue, and approvals arrive as a decision with the context attached. The change is that the system now tells them what needs deciding, rather than them working it out from an inbox.

Workflow owners and approvers get a longer session, because they are the ones setting thresholds and handling exceptions.

You do. Any automated step can be returned to manual immediately, by your team, without our involvement. Thresholds and limits are yours to change.

Where you want us to keep running it, that is a Managed Operations arrangement — a service, not a dependency you cannot exit.

There is no price list, because there is no standard scope — a three-step approval workflow and a twelve-system onboarding process are not the same piece of work. Pricing is quoted per workflow after the Operations Review, when what is being built is understood by both sides.

The first conversation costs nothing. The Blueprint is scoped and quoted before it starts, and that figure remains fixed unless the agreed scope changes.

One workflow. Not a department, not a platform, not a transformation programme. We map a single operational workflow, establish its baseline, and prove the value there before anything expands.

Workflows return to manual, and your data and history export in open formats. Because MIRAI connects your systems rather than replacing them, the systems of record you depended on before are still the systems of record.

Exit terms are written into the engagement at the start, not negotiated at the end.

We are based in Singapore and work across Southeast Asia. Deployment region is a decision you make per engagement, and data residency requirements are handled at the deployment layer rather than by exception.