Route standard, strong, and batch cloud computer runtime classes #9

Project

Cloud computer platform

Source: Cloud computer scale architecture audit

Outcome

Expose stable product runtime classes while keeping provider selection, region, and substitution under server policy. Normalize pooled Firecracker, GKE Agent Sandbox, dedicated GCE, and Cloud Run batch execution behind one admitted routing and receipt contract.

Runtime classes

• standard: 1-2 vCPUs and 2-4 GiB after benchmark qualification, local copy-on-write scratch, controlled egress, and a bounded lifetime.
• strong: hardened Firecracker or dedicated GCE for arbitrary native code, higher-risk tools, or a stronger isolation requirement.
• batch: one-shot Cloud Run or SCV-style execution with no promise of an interactive retained runtime.

Scope

• Resolve the provider only after owner, authority, capability, budget, data-location, and capacity admission.
• Store the requested class and effective provider, image, region, policy, and profile digests in the receipt.
• Keep the existing one-GCE-VM-per-sandbox provider as a low-concurrency forensic and strong-isolation fallback.
• Add Cloud Run jobs only for finite tasks that need no listener, retained process, or interactive reattachment.
• Refuse unsupported class and capability combinations with typed errors.
• Make provider fallback explicit, policy-bound, and visible. Never change custody, region, isolation, or interactive behavior silently.
• Keep customer-connected computers as a separate explicit target and never use them as an automatic cloud-capacity fallback.
• Define provider health, drain, circuit-breaker, and incident override behavior.

Deliverables

• Runtime-class policy and provider routing implementation.
• Capability and substitution matrix.
• Dedicated GCE and Cloud Run provider normalization.
• Effective-placement receipt schema and operator projection.
• Routing, refusal, drain, and fallback tests.

Acceptance criteria

• Product callers cannot request a raw provider, project, cluster, zone, instance type, or cloud administration operation.
• A batch execution is never described or returned as an interactive retained computer.
• A provider outage either uses an admitted fallback with a visible receipt or returns a typed queued or refused result.
• A fallback cannot weaken owner scope, authority, isolation, egress, data location, budget, or evidence requirements.
• Dedicated GCE remains bounded by its separate low-concurrency capacity class.

Dependencies

Depends on #3 and #4. Provider promotion also depends on the Firecracker and GKE qualification issues.