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, orblockedfor every step instead of collapsing failures into success.
- 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 incontracts/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— orderedActionStepvalues (action, target ref or coordinates, arguments).postcondition— optional semantic condition to verify after execution.approval_id— optional approval bound to the exact transaction.
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:
Resource scheduler
TheResourceScheduler 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, orsubmitare 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:ApprovalAuthorityissues single-use grants bound to the SHA-256 hash of a canonical transaction. The grant is consumed when the transaction executes.OperationApprovalAuthorityissues grants for non-transaction environment operations such as file writes, clipboard writes, shell execution, or mobile actions.
Receipt ledger
Every executed transaction produces aCanonicalReceipt 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/{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 (
requested→provisioning→running→stopping→stopped). - TTL-based cleanup.
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:
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: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
Record an evaluation result
Transition a routing cell
Configuration
Environment variables
Start the gateway
Start the MCP server
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.clickordesktop.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.