> ## Documentation Index > > Fetch the complete documentation index at: https://lithi.ai/llms.txt > > Use this file to discover all available pages before exploring further. --- title: Approval and authority in Compute description: >- Six authorities govern Compute: assessment, configuration, quoting, work admission, external writes and payment. Each is approved on its own, so approving spend never approves a payment. route: /docs/compute/concepts/approval-and-authority page_id: docs-compute-concepts-approval-and-authority page_type: concept content_layer: guided documentation surface_profile: guided_docs audience: Compute customers, organization administrators and finance approvers voice: D reader_question: Which approvals does Compute ask for, and what does each one authorize? primary_action: Review spend and approval settings source_locale: en-US source_status: APPROVED source_version: docs-compute-concepts-approval-and-authority-en-us-2026-09-05-v1 last_updated: '2026-09-05' robots: index claim_registry_pinned: true claim_registry_resync: "npm run governed:tsx -- scripts/build-compute-public-claim-registry.ts --write" --- ## Six authorities, approved separately An authority is permission to cause one specific effect. Compute separates six of them: assessment, configuration planning, quote creation, work admission, external writes and payment. Each one is approved on its own. Holding one never implies holding the next. That is why approving spend is never approving a payment. A ceiling says how much work may be admitted. A payment moves money, and a person authorizes that separately. ## What each authority causes | Authority | What it causes | What it never does | |---|---|---| | Assessment | Describes your data and the shape of the work | Create a charge or run anything | | Configuration planning | Produces a change plan you can read | Apply the change | | Quote creation | Returns a signed, expiring price | Admit or run work | | Work admission | Approves one job to run and be charged | Write into your own systems | | External writes | Lets a result be written to a destination you registered | Settle an invoice | | Payment | Settles an invoice through the hosted payment page | Raise a spend ceiling | ## Why the boundaries hold A quote carries `non_authorizing = true`, an expiry and a signature. It prices the work and stops there. Admission is the separate act that lets a job run. If the priced facts change before you approve, admission answers `REPLAN_REQUIRED`. You are asked to price the new facts rather than run something you never saw. ## Where each authority lives Work submission and account administration use different credentials. A work key carries work scopes only, and management scopes are never mintable on a work key. Finance, delivery destinations and identity administration stay disjoint from work submission. Someone who can run a job cannot register a destination or rotate a key with the same credential. ## A worked example Your administrator plans and applies the account configuration, including one delivery destination. That is configuration planning plus the authority for external writes. A member then assesses one input, requests a quote, reads it, and approves the job. That is assessment, quote creation and work admission. Finance settles the resulting invoice later. That is payment, and nobody in the earlier steps performed it. ## What separation does not give you Separate authorities keep effects deliberate. They do not make an effect reversible. An invitation that was sent, a write that landed in your warehouse and a payment that settled are all forward-repair problems. Withdraw the membership, write a corrected result, or raise an adjustment. Do not expect a configuration rollback to undo any of them. Set your ceilings and approval rules next, so admission has something concrete to check against. [Review spend and approval settings](/docs/compute/configure/spend-and-approvals)