Compute
Compute scopes and roles
What each Compute credential can hold, and what it can never hold. Work, configuration, delivery, identity and finance grants stay separate on every role.
The two grant families
| Family | What it covers | How it authenticates | Where it is available |
|---|---|---|---|
| Work | quote, run, batch, status, result | A bounded personal, service or automation work key | REST, SDK, CLI and exactly five MCP tools |
| Management | Organization and projects, members and roles, identities and keys, sources and destinations, profiles and rubrics, schedules and webhooks, finance and invoices, audit and receipts | A human portal session, or a separately admitted management service identity | REST, SDK, CLI and the portal, with no MCP work-tool expansion |
A work key holds six work scopes. Management scopes are never mintable on a work key.
Credential to grant matrix
Your organization names its own roles. This table describes what a credential can carry, not what you called it.
| Grant area | Work key | Portal session with administration authority | Management service identity |
|---|---|---|---|
| Work submission | Yes, within its six scopes | No | No |
| Configuration and profiles | No | Yes | Only where explicitly granted |
| Sources and destinations | No | Yes | Only where explicitly granted |
| Identities and keys | No | Yes | Only where explicitly granted |
| Spend and approvals | No | Yes | Decide only where explicitly granted |
| Finance, statements and invoices | No | Yes, with no debit operation | Only where explicitly granted, with no debit operation |
| Audit and receipts | Reads its own results only | Yes | Only where explicitly granted |
A management service identity can only narrow the authority of its current human owner. It can never hold a grant that owner does not.
Management resource families and their operations
| Family | Minimum operations |
|---|---|
| Organization and account | describe, get, plan/update, read-back |
| Projects and subaccounts | list, get, plan, create, update, archive, read-back |
| Members, invitations and grants | list, get, plan, invite, grant, suspend, remove, read-back, events |
| Identity sync and role mappings | describe, plan, apply, pause, revoke, read-back, events |
| Personal, service and automation identities and keys | plan, create, rotate, revoke, read-back; plaintext once only |
| Spend and approval | get, plan, apply, request, decide, expire, read-back |
| Sources and credentials | describe, list, get, plan, register, test, revoke, read-back; secret reference only |
| Destinations and delivery | describe, list, get, plan, register, test, revoke, read-back, events |
| Workflow profiles and rubrics | describe, list, get, plan, create, version, retire, read-back |
| Schedules and webhooks | describe, list, get, plan, apply, pause, resume, replay, revoke, read-back, events |
| Finance and cost allocation | describe, list, get, inspect, plan, apply, export, reconcile, read-back |
| Statements, invoices and payment | list, get, export, open-hosted-action, read-status, reconcile; no debit operation |
| Audit and receipts | list, get, with stable cursors and content-free projections |
Separation rules
- Finance, destination and identity administration stay disjoint from work submission.
- No management family carries a debit operation. Compute never takes money from an account.
- A profile may narrow a ceiling, a deadline, a data profile or an output scope. It may never widen one.
- An override that would widen a higher grant is refused with a reason and a next action.
- Approving spend permits work to be admitted. It never authorizes a payment.
The shared lifecycle
Every management family follows the same sequence:
describe -> inspect -> plan -> approve as required -> apply -> read back -> events -> revoke
Rollback never implies undoing an invitation, an external write or a payment. Those are reversed, where they can be, by a forward act with its own record.
Reading a grant back
Every response carries an envelope. It names a request_id, the operation, the contract release, the typed state, an evidence class, an observed_at time and a valid_until time.
A read older than its valid_until is stale. Read it again rather than treating it as current.
Per-resource apply states are PLANNED, WAITING_APPROVAL, READY, APPLYING, APPLIED_UNVERIFIED, VERIFIED, ALREADY_MATCHED, REFUSED, CONFLICT, RETRYABLE, REVOKED and ROLLED_BACK. The change as a whole returns COMPLETE, PARTIAL_WITH_NEXT_ACTION, REFUSED or EXPIRED.
Where the exact names live
Scope names, role names and per-operation error schemas are generated per release. There is no single global error-code table; every operation carries its own error_schema.
Read the current names on the key when you create it, in the portal, and in the OpenAPI description you download. See the management API reference for the operation shapes.