Compute
Describe your configuration as a file
Keep a secret-free configuration file with bounded desired values that map to resources Compute already supports. The file describes what you want; it never authorizes an apply or a run.
A file is not execution authority
A desired-state file describes the configuration you want. It is an input to a plan, and nothing else.
Committing it changes nothing. Merging it changes nothing. A change happens only when someone applies a plan built from it, and paid work still needs its own separate approval.
Say that out loud to your team before you adopt this pattern. A file in a repository looks authoritative, and it is not.
Keep every secret out of the file
Reference a credential; never write one. Register the credential once, then name its reference in the file.
The same rule covers signed URLs, tokens and bank details. If a value would be dangerous in a code review, it does not belong in a configuration file.
project:
name: evaluation-team
cost_allocation_label: rnd-evals
source:
kind: tabular
adapter: object_storage
location: s3://example-bucket/evals/
credential_ref: evals-reader
profile:
quality:
preset: verified
limits:
deadline: PT6H
maximum_price:
currency: USD
Bound every desired value
Write values that state a limit, not values that state "whatever is available". A deadline, a maximum price and a quality preset are bounds a plan can check.
Leave the price amount out of the file if your team sets it per engagement. An unbounded limit is the one field that turns a review into a rubber stamp.
Do not encode a batch item ceiling from memory. The maximum item count for a workflow is stated on its descriptor and repeated on your quote.
Map only to resources that exist
Every block in your file must correspond to a resource family Compute already manages. That means the organization, projects, members, identities and keys, and spend and approvals.
It also covers sources, destinations, profiles and rubrics, schedules and webhooks, and finance mappings. Nothing outside that set is planable.
Compute does not create a resource type because your file names one. An unmapped block is refused with a reason, not silently ignored.
Check the workflow descriptor before you add a parameters block. Parameters are validated against the workflow's generated schema, so an invented knob fails at plan time.
Turn the file into a plan
Run the plan against the sandbox first.
lithi configuration plan --sandbox desired-config.yaml
Read the plan the way you would read a code review. It names each resource, the current value, the desired value, and whether the change needs an approval.
A plan expires. Apply it while it is current, and quote its digest when you do.
Confirm success
Each resource in the plan reads back as VERIFIED or ALREADY_MATCHED, and the change as a whole returns COMPLETE.
ALREADY_MATCHED across the whole file is the healthy steady state. It means your file and your account agree.
When the plan refuses
REFUSED names an unmapped block, an out-of-range bound or a missing credential reference. Fix the file, plan again, and keep the fix in version control.
CONFLICT means someone changed the account after your plan was built. Inspect current state, replan from the same file, and apply the new plan.