Workspace settings

Workspace settings holds the name, team, policies and defaults every member works under. Owners and admins change them, every member reads them, and every change is audited.

Owners and admins rename the workspace; its id never changes. The id and the slug have copy controls, and the id is the one to quote to support.

• The plan's request-data policy, shown to every member: on the free plan, request inputs and generated outputs may be used for training; on the lower and the higher paid plans, request-data training is off by default.
• On the lower and the higher paid plans, an owner or admin may turn training on request data on, and off again; each change is audited and applies from then on. A plan lapse never changes the policy.
• Region and SSO: region selection and SSO are intended features of the higher paid plan.
• Customer-owned model weights will never be used to train other models on any plan.

An owner or admin can keep the workspace's requests out of the Community pool: the workspace's objection to providers as a category, always available and needing no reason. Within about a minute every new request and batch runs in the Certified pool with fallback off, whatever its key, the tool defaults or its headers say, and a request that names the Community pool, or turns fallback on, is refused with 400 requirement_conflict; requests already running finish where they are. Requests may then find less capacity, since HIPS never relaxes a requirement to make one succeed. Allow the Community pool again to undo it.

The pool, pricing mode and fallback every person's signed-in tool uses in this workspace: hi, HIPS Code and HIPS Provider. A change applies to every signed-in tool at once, and a request can still override a default with its own header. A workspace needs its tool defaults before a person can approve a tool's sign-in to it (tool_defaults_required).

Which notices reach you, by email: security (a sign-in from a new device, a passkey added, a key created or revoked, a policy change, a member invited), billing (receipts, low balance, budget crossings, subscription changes), deployments (ready, degraded, stopped, allocation stop warnings) and plan changes. The owner cannot turn off the security notices, nor the paused, frozen and deletion notices.

A public repository needs no token. For a private or gated one, add a read-only access token for its hub, with a label and the repositories it is for. HIPS keeps only read-only tokens: one the hub reports as able to write is refused. One that can read more than the repositories named, or whose permissions the hub does not report, is stored only after a warning and your confirmation. Only the last four characters are shown, and the token is used only to import your models. Deleting it at HIPS does not revoke it at the hub. Import and run your model has the rest.

• Pause stops spend and revokes nothing: new requests are refused until a member resumes it, and always-on allocations keep charging. Only a member's own pause is lifted here.
• Delete revokes every key at once and is restorable for 30 days, from Account, then purged. Only the owner deletes the workspace; type its name to confirm.

Every member sees why a workspace is paused, at the top of every screen, with the way to lift it. Reads work; writes that spend credit wait. The API answers the same way:

The audit log lists every change to the workspace, its keys, members and settings, as it is made: when, who (a member, the platform or HIPS support), the action, its target and a summary, with HIPS's note where it left one. Filter by actor, by action name (such as key.create) and by date. Owners and admins read it.