> ## 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: Describe your configuration as a file
description: >-
  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.
route: /docs/compute/configure/desired-state
page_id: docs-compute-configure-desired-state
page_type: howTo
content_layer: guided documentation
surface_profile: guided_docs
audience: Platform and infrastructure teams keeping Compute configuration in version control
voice: D
reader_question: How do I keep my Compute configuration in a file without putting secrets in it?
primary_action: Plan, apply and read back a change
source_locale: en-US
source_status: APPROVED
source_version: docs-compute-configure-desired-state-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"
---

## 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.

```yaml
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.

```bash
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.

[Plan, apply and read back a change](/docs/compute/configure/plan-apply-read-back)