Fabric Basics

Different projects sometimes need more computing capacity than one machine can comfortably provide. Compute Fabric aims to describe available workers, place bounded jobs where they fit, and return evidence about what ran without making the worker responsible for the project's decisions.

A placement is not permission by itself. Shared Workbench decides whether a capability, destination, data disclosure, cost, and execution are allowed. The project that requested the work still judges the result. For example, another machine might run a test batch and return a receipt, while the project's own validator decides whether those tests satisfy its requirements.

The current project has synthetic execution and planning evidence, not a live general-purpose compute service. Real nodes and model workloads require separate qualification and release proof.

The planned fabric has four distinct routes. A local single host runs a bounded task on one machine. A local cell coordinates nearby machines when a workload genuinely benefits from close, fast connections. A trusted remote worker receives a self-contained work package rather than acting as part of one long-distance inference machine. An approved cloud gateway may use an external provider only when disclosure, model, cost, and permission fit the exact task.

These routes are not interchangeable. A slow Internet connection does not turn separate locations into a useful local inference cell, and a provider being available does not mean private work may be sent there. For example, a task restricted to a local machine stays local even if a cloud model looks faster.

The project currently tests route descriptions and some failure rules with synthetic fixtures. Real transport, enrolled workers, and WCF model execution remain future, separately gated work.

Compute Fabric separates a plan, permission to execute, evidence of execution, and acceptance of a result. A plan may identify a suitable worker, but it does not grant that worker access to private material or the right to change a project. An execution receipt says what happened; it does not declare the answer correct.

Long-running work needs bounded recovery rules. A worker that stops responding cannot immediately be replaced with a second writer: the lease, restart grace period, and checkpoint must first be checked. A returning worker with an older generation must not be allowed to commit as though nothing changed.

For example, after a machine restarts, a verified checkpoint may make continuation possible. Shared Workbench must still authorize a replacement execution, and the requesting project must still validate the returned work. Current tests model these rules with disposable synthetic data; they do not prove live recovery on enrolled machines.