Compute
Approval and authority in Compute
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.
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.