Overview

Canonical Computer Use is the trust-core layer of the Allternit Computer Use Engine. It defines a provider-neutral contract that separates what an agent wants to do from how a browser, desktop, or sandbox adapter does it. The canonical router exposes this layer over HTTP at /v1/computer-use/canonical, and a matching MCP server exposes the same primitives as tools. The canonical layer is designed for safety and auditability:
  • Immutable observations — every screenshot and accessibility tree is assigned a unique state ID and never overwritten.
  • State-scoped references — actions target elements or coordinates that belong to a specific observation.
  • Stale-write rejection — the runtime tracks an epoch per resource and rejects transactions that were planned against an old state.
  • Honest outcomes — providers report worked, didnt, unknown, or blocked for every step instead of collapsing failures into success.
Canonical Computer Use powers:
  • Multi-provider dispatch across browser, desktop, mobile, and sandbox adapters.
  • Human-in-the-loop approvals bound to exact transaction state.
  • Integrity-hashed receipts and append-only event trajectories.
  • Evidence-gated migration from legacy routes to canonical providers.
  • Scoped environments, leases, snapshots, and image governance.

Key concepts

Canonical contract

The canonical contract lives in contracts/canonical.py and uses only the Python standard library so that native adapters, browser extensions, sandboxes, and test harnesses can share it without pulling in framework dependencies. The current contract version is 1.0.0-alpha.1. Every provider must declare these invariants:

Observations and transactions

An observation is the atomic unit of perception. It contains a state ID, session/environment/resource scope, epoch, element tree, optional image evidence, and discovered roots. A transaction is a plan to move one resource from a base state to a successor state. It contains:
  • base_state_id — the observation the plan was built against.
  • steps — ordered ActionStep values (action, target ref or coordinates, arguments).
  • postcondition — optional semantic condition to verify after execution.
  • approval_id — optional approval bound to the exact transaction.
The runtime executes steps one at a time, stops at the first non-worked outcome, captures a successor observation, and records a signed receipt.

Provider registry

CanonicalComputerService maintains a registry of providers. Each provider advertises a CapabilityManifest that declares supported actions, observation channels, execution modes, operating systems, and limitations. Providers are discovered lazily at startup:
Unavailable providers are reported truthfully in diagnostics instead of being silently omitted.

Resource scheduler

The ResourceScheduler serializes live work per physical resource using an async lock and an integer epoch. This prevents two agents from planning against the same screenshot and then racing to apply conflicting actions. If a transaction’s base_state_id resolves to an epoch lower than the resource’s current epoch, the runtime returns 409 stale_resource_state with the expected and actual epochs.

Policy engine

CanonicalPolicyEngine evaluates every transaction before execution. It is fail-closed:
  • Read-only transactions are allowed without approval.
  • Side-effect actions require a matching approval.
  • Irreversible actions such as deleteFile, install, or submit are flagged as critical risk.
  • Sandboxed mode cannot target an implicit host environment.
  • Transactions over 50 steps or with argument payloads over 128 KiB are denied.

Approvals

There are two approval authorities:
  • ApprovalAuthority issues single-use grants bound to the SHA-256 hash of a canonical transaction. The grant is consumed when the transaction executes.
  • OperationApprovalAuthority issues grants for non-transaction environment operations such as file writes, clipboard writes, shell execution, or mobile actions.
Both authorities use HMAC-signed IDs, expire after a configurable TTL (default 120 seconds, max 600), and can be used only once.

Receipt ledger

Every executed transaction produces a CanonicalReceipt stored in SQLite. The receipt includes:
  • Transaction and successor state IDs.
  • Provider ID and execution mode.
  • Action hash and outcome hash.
  • Approval ID and approver identity.
  • An integrity hash over all of the above.
Receipts can be retrieved and verified through the /receipts/{receipt_id} endpoint.

Environment authority

EnvironmentAuthority is the durable registry for environments, images, snapshots, pools, and leases. It enforces:
  • Image digest validation and scan attestation.
  • Owner quotas (default 8 active environments per owner).
  • Lease exclusivity per environment.
  • State-machine transitions for environments (requestedprovisioningrunningstoppingstopped).
  • TTL-based cleanup.
Environment backends include local host control, local VM sandboxes, container GUI sandboxes, and customer-cloud BYOC provisioning.

Session authority

SessionAuthority records logical resource bindings across providers. When /roots is called, the runtime discovers application roots (browser pages, desktop windows, mobile screens) and binds them to a (session_id, environment_id, resource_id, provider_id) tuple so later observations and transactions can be routed correctly.

Routing and evaluation

RoutingAuthority manages staged migration between legacy routes and canonical providers per capability cell. The stages are:
Transitions require a passing evaluation gate from EvaluationAuthority. A gate passes when a provider has at least 3 measured samples, a mean score ≥ 0.8, and a Wilson 95% confidence lower bound ≥ 0.5.

Shadow comparisons

The /shadow/observe endpoint captures the same resource through a primary provider and a shadow provider, then returns a semantic Jaccard comparison of element trees and image evidence. Shadow results can also be recorded against a legacy receipt to compare status agreement before retiring a route.

Architecture

Base URL

Local gateway:
When running behind the Allternit platform gateway, routes are available under the platform API host.

Endpoints

Providers and health

Observations and roots

Transactions and approvals

Environments

Evaluation, routing, and sessions

Shadow and migration

Request / response examples

List providers

Capture an observation

Issue a transaction approval

Execute a transaction

Create and provision an environment

Acquire a lease and provision:

Record an evaluation result

Transition a routing cell

Configuration

Environment variables

Start the gateway

Start the MCP server

The MCP server reads ALLTERNIT_COMPUTER_URL (default http://127.0.0.1:8760) and calls the canonical HTTP surface.

Error codes

Concepts

  • Observation — an immutable snapshot of a resource at a specific epoch.
  • Transaction — a state-bound plan composed of action steps and an optional postcondition.
  • Capability cell — a fine-grained routing unit such as browser.click or desktop.type.
  • Receipt — an integrity-hashed record of a transaction outcome.
  • Lease — an exclusive, time-bounded right to operate an environment.
  • Release gate — an evidence threshold that must pass before a routing cell advances.
  • Shadow comparison — a read-only comparison between a primary provider and a candidate provider.