OTANIS Suitability by System Type
A practical lens for irreversibility, latency tolerance, and execution-time governance.
OTANIS (Operational Trust and Authority Normative Integrated System) is intended for critical live agentic systems where actions can produce irreversible external effects. It is not appropriate for every AI system. This page summarises where the framework is usually a strong fit, where judgement and boundary design matter most, and where it is generally a poor match for direct application inside the fastest execution paths.
The main decision variables are irreversibility, latency tolerance, and the cost of wrong action versus delay.
Related: Services · OTANIS FAQs · Industries · Dr Masayuki Otani
How to read this page
OTANIS is generally a strong fit where actions are materially binding and latency budgets are measured in hundreds of milliseconds to seconds, so execution-boundary checks can complete without breaking the operational model.
It is borderline where customer-facing or operational timing constraints are tighter, or where refusal and escalation must be designed with exceptional care to avoid collateral harm or systemic instability.
It is generally not suitable inside microsecond or hard real-time control loops where continuous or ultra-frequent decisions leave no room for multi-step admissibility and authority verification at the same layer.
Even then, the framework may still be relevant above those fast loops, for example at a supervisory, policy, or approval layer that governs modes, limits, or commit classes before the low-latency path runs.
Where OTANIS is usually a good fit
The examples below are illustrative, not exhaustive. They share characteristics that align well with discrete commit events, identifiable irreversibility boundaries, and enough latency headroom for defensible execution-time governance.
| System type | Fit | Typical latency tolerance | Example irreversible event | Why it fits |
|---|---|---|---|---|
| Enterprise payment execution | Good | 100 ms to 2 s | Bank transfer submission | High financial risk, natural delays already exist, refusal acceptable |
| Insurance claim settlement | Good | 200 ms to 3 s | Claim payout release | Legal and financial binding action, low need for sub-second execution |
| Treasury operations | Good | 100 ms to 1 s | Liquidity movement, hedging execution | Controlled environment, high consequence, moderate latency tolerance |
| Booking and reservations | Good | 200 ms to 2 s | Booking confirmation | Irreversible commercial commitment, delay rarely critical |
| Privileged access control | Good | 50 ms to 500 ms | Admin access grant | Security risk outweighs latency cost |
| Procurement order release | Good | 200 ms to 2 s | Purchase order issuance | Business commitment, not time-critical |
| Logistics dispatch release | Good | 200 ms to 1 s | Shipment dispatch | Physical irreversibility, delay acceptable |
| Healthcare admin actions | Good | 200 ms to 2 s | Record disclosure, transfer approval | Compliance critical, moderate urgency |
| Industrial supervisory control | Good | 100 ms to 1 s | Machine start, batch release | Works at supervisory layer, not control loop |
In aggregate, these systems usually have:
- discrete commit events
- identifiable irreversibility boundaries
- meaningful refusal or escalation options
- enough time for execution-boundary checks without breaking the operational model
Borderline cases
Borderline cases are not automatic exclusions. They are domains where success depends on precise separation of layers, realistic SLAs, dependency control, and an honest refusal and escalation model that the organisation can accept operationally.
| System type | Fit | Typical latency tolerance | Example irreversible event | Risk |
|---|---|---|---|---|
| Card payment authorisation | Borderline | 100 ms to 300 ms | Transaction approval | Tight SLA, external dependencies can cause refusal spikes |
| Real-time fraud blocking | Borderline | 50 ms to 200 ms | Payment approval or decline | Latency budget constrained, failure impacts customer experience |
| Emergency healthcare ops | Borderline | <500 ms to seconds | Urgent transfer execution | Delay can impact outcomes, requires careful fallback design |
| Energy grid switching | Borderline | 50 ms to 500 ms | Load switching | Some actions fast, some supervisory, must separate layers |
| Telecom provisioning | Borderline | 50 ms to 200 ms | Service activation | Depends on system architecture and SLA expectations |
These are not impossible fits, but they require very careful boundary design, stricter dependency engineering, and a realistic refusal model. Treating them like standard good-fit workflows without that rigour often produces either governance theatre or operational failure.
Where OTANIS is usually a poor fit
The systems below are poor candidates for placing full execution-boundary governance directly in the fastest path. Latency budgets and control semantics typically prevent the kind of admissibility and authority checks OTANIS describes at that layer.
| System type | Fit | Typical latency tolerance | Example irreversible event | Why not suitable |
|---|---|---|---|---|
| High-frequency trading | Poor | Microseconds to <1 ms | Order execution | Latency budget too small, governance would break function |
| Exchange matching engines | Poor | Microseconds | Trade matching | Deterministic speed critical, no room for multi-domain checks |
| Flight control systems | Poor | <10 ms | Control surface actuation | Hard real-time safety constraints |
| Automotive safety systems | Poor | <10 ms | Braking, steering correction | Requires deterministic control loops |
| Robotics collision avoidance | Poor | <10 ms | Movement correction | Continuous control, no discrete commit boundary |
| Network packet routing | Poor | Microseconds | Packet forwarding | Extremely high frequency decisions |
| Industrial servo loops | Poor | <5 ms | Motor control | Real-time closed-loop system |
Architectural interpretation
Where OTANIS tends to work best
- discrete, identifiable commit events
- a clear irreversibility boundary
- ability to pause, refuse, or escalate without negating the purpose of the system
- situations where multiple authority domains may need to converge before commitment
- latency tolerance broadly in the region of roughly 100 ms or more at the governed boundary
Where it tends to break down
- continuous control instead of a discrete commit
- latency budgets in microseconds or low milliseconds at the proposed governance point
- systems where refusal is not operationally viable at the boundary under review
- environments where the true commit boundary cannot be intercepted cleanly
Important nuance
Even in poor-fit domains at the lowest layer, OTANIS can still be relevant above the fast path. Examples include approving trading strategies rather than individual trades, approving control modes rather than each actuator signal, or approving access policy changes rather than per-packet routing decisions.
Pushing execution-boundary governance directly into ultra-low-latency loops typically fails technically, or the controls are weakened until they no longer govern anything meaningful at the true point of commitment.
The real decision
The real design decision is not simply whether to use OTANIS or not. It is where the true irreversibility boundary sits, and whether there is enough time to govern that boundary properly while preserving a safe and commercially viable operating model.
Organisations assessing critical agentic workflows can use this suitability lens to determine where execution-time governance is proportionate, where it becomes borderline, and where a different control architecture is required for the fast path, with OTANIS potentially applied at a slower supervisory or approval layer instead.
For scoped architectural review or OTANIS-aligned design work, see Services or get in touch.
Get in Touch