Authority boundary
A client or agent may request work, but the request does not become permission simply because it was generated successfully.
Architecture
Authority lives in the control plane.
ILAIOS separates user interfaces, intelligent capabilities, and execution tools from the backend authority that governs policy, authorization, validation, state, and evidence.
System model
A layered path from intent to evidence.
Each boundary exists to keep presentation, intelligence, execution, and authority from collapsing into one opaque component.
01ClientsDesktop, mobile, and web interfaces present controlled projections of system state and collect goals, approvals, and user decisions.
governed boundary ↓
governed boundary ↓
03Policy & approvalsPermissions, approval requirements, and execution conditions are evaluated before sensitive work proceeds.
governed boundary ↓
04Execution & toolsDeterministic steps are preferred; intelligent capabilities operate through bounded task and tool contracts.
governed boundary ↓
05Validation & evidenceResults are checked and durable evidence records support review, audit context, recovery, and accountable delivery.
Trust boundaries
Separate permission from capability.
Being able to produce a plan, call a model, or access a tool is not the same as having authority to create a side effect.
Execution boundary
Tools and services receive only the scope needed for an approved job rather than inheriting unrestricted ambient authority.
Validation boundary
Completion is determined by explicit checks and acceptance criteria where possible, not by model confidence alone.
Evidence boundary
Meaningful execution events remain reconstructable so operators can understand what happened and why a result was accepted.
Architecture questions
Four questions define the operating model.
Who is authoritative?
Backend/control-plane services remain the source of truth for security- and product-critical runtime decisions.
Where does intelligence fit?
Models and agents are capabilities inside governed workflows; they can assist planning, interpretation, and execution without owning global authority.
How is change contained?
Durable contracts separate clients, control logic, execution services, and evidence so one presentation surface can evolve without redefining system trust.
How does failure behave?
Critical paths are designed to stop, escalate, or remain pending when required policy, approval, validation, or evidence conditions are not satisfied.
Core rule
Clients are projections, not system authority.
Security and product-critical decisions are not delegated to a desktop or mobile interface merely because the interface can display or request them.
This separation lets clients evolve while policy, execution, validation, and evidence contracts remain durable behind them.