Concept
Admission, lease-and-claim placement, terminal state.
The scheduler owns task admission and terminal state. Accepted workflows wait in a durable action log; workers on approved hosts claim them by lease and execute the reviewed trajectory.
How a task moves#
- Your service submits origin, action, justification, and idempotency key through the client.
- Admission validates the organization, allowlists, input shape, and justification, then appends the task to the durable action log.
- A worker on an approved host leases and claims the task.
- The worker executes the reviewed trajectory in the deployment-selected verified browser build, resolving scoped Skarbiec credential references — never plaintext from the request.
- The run records its terminal state and evidence; deployments with receipt issuance sign the outcome and evidence digest and return them to the caller.
Approved host#
Browser automation runs only on an approved host: the supervised environment whose local receipt matches the exact Stado release coordinate and checksum selected for the worker. Chromium and Firefox launch only when that receipt matches. The weles onboarding journey explains this boundary on its host-execution screen.
Cancellation#
The client exposes one explicit cancellation operation with a required human-readable reason and idempotency key. There is no hidden retry anywhere in the contract: on ambiguous transport failure, reconcile through an approved status-read channel using the original idempotency key before submitting anything new. A cancellation request alone does not prove the executor stopped before an external side effect — inspect the signed outcome and service evidence.