Intent, Evidence and Decisions
The desired graph answers “What do we want?” It does not, by itself, answer “What is running?” or “What should we do about the difference?”
Observed state extends rescile beyond describing intent. Independent collectors provide evidence about the environment; action-owned comparisons evaluate that evidence against selected intent under each action’s explicit policy. The build pipeline remains the owner of desired configuration. It does not become a continuously overwritten mirror of the provider.
Three things that flow
Open the diagram at full size.
| Flow | Question | Where it comes from | How it changes |
|---|---|---|---|
| Intent | What should exist? | Workspace assets, models, compliance rules and rendered configuration | Rebuilt when workspace inputs change; stable between builds |
| Evidence | What did a source observe? | Independent provider reads and collector reports | Recorded independently of builds; retains provenance and ages over time |
| Decisions | What does the difference mean, and may we act? | Intent + usable evidence + workspace policy | Findings are recomputed as inputs change; proposals, approvals and execution records preserve the exact context of a decision |
Intent and evidence have different owners and update cycles. Decisions derive from both; they are not a new source of truth for either. A read-only query can show desired and observed values together without merging their authoritative stores.
Observed state is not actual state
Actual state is what exists in the environment. Observed state is the evidence available to the controller.
A provider API can return an old value. A collector can lack permission to read a disk. A paginated inventory can fail halfway through. Two sources can report different CPU counts because one measures allocated vCPUs and another measures online guest CPUs.
Each observation therefore needs identity, source, scope, read time and coverage. Freshness and source authority determine whether it can support a comparison. Unknown, unreadable, unsupported, stale and absent are different conditions—not interchangeable values.
For example, four reported servers against five desired servers do not necessarily mean that one server is missing. Only a complete authoritative inventory of the relevant boundary can establish absence. A failed or partial scan cannot.
A difference is not yet permission to act
Consider a desired server with eight allocated vCPUs:
- The workspace build publishes desired CPU
8. - An independent provider read reports CPU
4, with its identity, source and read time. - Reconciliation checks that the resource and field are managed, the meanings match, and the evidence is authoritative and fresh.
- A finding explains the mismatch. Workspace and deployment policy determine whether to report it or offer an approval workflow.
- An approved correction uses frozen configuration and exact inputs through the existing action queue.
- A new independent read checks the outcome. The action’s requested value or successful exit is not proof of convergence.
If the evidence becomes stale or the resource identity is uncertain, the next result may be “not enough evidence”, not “resize the server.” A finding identifies a condition; an approval authorizes a specific response. Neither silently rewrites intent.
Close the loop without mixing the records
Collection continues independently of execution. A correction changes the environment; it does not manufacture a successful observation. A matching fresh observation can establish that the compared property now agrees with intent, but it does not by itself establish that all work has stopped.
Possible scoped execution remains held until a qualifying independent read supplies state plus both provider and runner terminal assertions. Runner terminality covers the root process, descendants and resumable work. This distinguishes convergence, execution finality and successful execution: a terminal failed job can be finished without having achieved the desired result.
The loop does not adopt provider values into CSV assets, infer permission to delete unexpected resources, or retry uncertain mutations. Changing intent remains an explicit workspace change.
Put the model to work
- Define observation contracts and comparisons.
- Collect evidence, review drift and approve a correction.
- Read the raw input contract and current implementation limits.
- Model generic and provider-specific resource bindings; those graph patterns describe configuration, not proof of live provider state.