Shared Services, Small Jobs

Shared Workbench exists because independent projects keep needing the same unglamorous help. One project may need a safe check, another a database, and a third a page on the common website. Rebuilding those foundations separately wastes time and makes it harder to tell what was actually checked.

The shared services do the common jobs once. Projects still own their goals, words, data, prompts, decisions, and acceptance of results. A shared service is a helpful caretaker, not a new project manager with a suspiciously large clipboard.

The small jobs

• Coordination keeps bounded work visible: who is working, which shared resource is claimed, and whether a task finished. It records cooperation; it does not transfer authority.
• Validation checks stated rules and reports failures before they become somebody else's afternoon. It can reject incomplete structure, stale assumptions, or unsafe output, but the owner still decides what to accept.
• Website supplies the common presentation and composes approved project content into the public site. Projects write and approve their own pages; Website controls the shared shell and publication gates.
• Model broker places approved local-model jobs on the available machine resources. Projects choose the task meaning, sources, prompt, and acceptance checks; the broker handles queueing and placement. It does not silently send private work to the cloud.
• Database service provides a maintained PostgreSQL/PostGIS foundation when a project needs relational or map-shaped data. The project owns its schema, migrations, data meaning, and recovery acceptance; the service owns the common engine and platform safeguards.
• Account Services (ScaffoldOnly) defines a safe identity boundary: it can help establish who signed in, but it does not decide what a game, server, administrator, or payment flow may do. It is not a live account provider or endpoint, and account safety remains separate from communications safety.
• Backup and export helpers create reviewable copies and packages when an owner asks for them. A copy is evidence or a recovery aid, not permission to publish, transfer, or rewrite the original.

What a project experiences

Suppose a project wants to publish a map page. It writes the page, marks it eligible, and previews it locally. Website checks the assembled site. Validation reports whether the structure is sound. If the project also needs spatial data, Database supplies the shared engine while the project keeps its own tables and meaning. Nothing in that chain lets one project read another project's private notes or approve its work.

These services are shared infrastructure, not a promise that every optional service is active for every project. A project may use a service only when it has a real need and an explicit owner configuration. Planned ideas remain labelled as planned until the working owner releases and checks them.

When a new project or tool bundle arrives, Workbench first separates the general problem from the project-specific solution. A useful, proven mechanism may be promoted into shared Workbench or Shared Knowledge; a unique or immature helper stays with its project as a thin adapter, with the reason and evidence for reconsidering it recorded. For example, Tracker Archive is the public project name; its internal ID and folder are compatibility labels, while each provider format remains an adapter rather than a second project identity.

The Hosted Application Controller is not a general remote administrator. It can inspect a registered target and qualify a few fixed operations, but qualification alone does not approve an application release. A separately registered application can use a narrow, fixed-target release path when its exact candidate, owner-approved plan, recovery checks, security checks, and live acceptance gates are all satisfied. That limited path does not authorize arbitrary applications, servers, commands, or changes. Each application owner remains responsible for its schema, data, artifacts, recovery requirements, and acceptance; credentials and release mechanics stay with the shared service. A green preflight or qualification is never permission to deploy.

Compute Fabric is Workbench's developing capability for preparing and evaluating bounded computer work. It remains part of the shared Workbench capability set, not a new project authority. Its released pilot records can help check a narrowly described task and result, but a catalogue entry or successful check does not dispatch work, approve the result, grant provider access, or let one project accept another's work.