Intake
Any trusted system that can produce the versioned request contract can submit work. Runseal is ITSM-agnostic. The intake layer stays replaceable.
Architecture
A governed execution layer, inside your own tenant
Runseal runs inside the Azure environment you already govern. It is contract-driven and message-based, so execution is deterministic, isolated per domain and traceable end to end.
The execution model
From request to evidence, one governed path
- 01
Request
A user or trusted system requests an approved business outcome.
- 02
Governed action contract
The action has a defined schema, permissions, risk tier, execution identity and lifecycle behaviour.
- 03
Policy and approval
Runseal validates the caller, the context and any applicable approval requirements.
- 04
Constrained execution
A deterministic worker performs only the defined action, through a managed identity with limited permissions.
- 05
Evidence and lifecycle
The result, execution context, ownership and future lifecycle obligations remain traceable.
Four layers, one governed path
Contract and validation
Each request is a versioned envelope with a defined schema. Runseal validates the caller, the context and the applicable approval requirements before anything executes.
Queues and workers
One queue and one worker per domain. A deterministic worker performs only its defined action, through a managed identity with least-privilege access. Failed messages park for replay rather than disappear.
Evidence and lifecycle
Every request and result produces an operational record. Created resources can carry ownership, review dates, expiry and a governed deprovisioning path.
Runseal deploys as code into your subscription. It does not require a separate external automation control plane, and its runtime and operational data remain in your environment by design.