Stateless reconciliation — drift detection without owning a state file

October 4, 2026 · Kishore Babu Gutta

Many infrastructure tools reconcile desired state by maintaining their own state file.

Engineering Runtime is exploring a different model for engineering operations:

Git stores reviewed intent. Providers store reality. Runtime observes, decides, executes, verifies and records evidence.

The Runtime does not need to become the authoritative database for every resource it touches.

The basic idea

A capability expresses the intended engineering outcome.

The provider remains authoritative for the actual current state.

On every run, Runtime reads the provider again before deciding whether a mutation is required.

desired intent
    ↓
read authoritative provider state
    ↓
compare
    ↓
decide
 ┌───────────────┬────────────────┬─────────────────┐
 │ already right │ missing state  │ correctable drift│
 ↓               ↓                ↓
SATISFIED        APPLIED          RECONCILED

The important part is that the decision is made from live provider state, not from a Runtime-owned record of what happened last time.

Reconciliation is opt-in at the capability step

Runtime should not guess which mutations are safe to reconcile.

The capability author defines the engineering intent and, for the steps that support this model, provides enough information for Runtime/provider logic to observe the current state and compare it with the intended state.

capability author
      ↓
declares intended outcome
      ↓
marks / uses a step with an observable reconciliation contract
      ↓
Runtime reads live provider state
      ↓
compare → decide → execute if required → verify

That means not every capability step automatically becomes a desired-state step.

A purely imperative action may remain imperative.

A read-only operation may only observe.

A mutation should participate in stateless reconciliation only when its contract has a reliable way to answer:

• what state is intended?
• how is current authoritative state read?
• how do we determine that the state is already satisfied?
• what correction is safe when drift exists?
• how is the result verified afterwards?

The capability author chooses the operation and intent.

Runtime enforces the declared contract.

The author declares what should be true. Runtime should not invent desired state from a command.

This keeps reconciliation explicit and reviewable rather than turning every command into hidden automation logic.

Why this is stateless reconciliation

"Stateless" does not mean Runtime has no logs, evidence, caches or execution metadata.

It means the reconciliation decision does not depend on Runtime owning a separate authoritative resource-state database.

For a durable provider-backed operation:

new run
  ↓
observe provider
  ↓
derive current truth
  ↓
compare with intended state
  ↓
act only if required

If the previous execution disappeared entirely, the next run can still reason from the current provider state.

Drift detection

Drift is simply the difference between the intended state and the authoritative state now observed.

For example:

intent: branch protection enabled
provider: branch protection missing
              ↓
            drift

Runtime can then decide whether the drift is:

• already satisfied,
• safely correctable,
• ambiguous and requiring verification,
• or outside the operation's supported reconciliation contract.

This is not a promise that every engineering action is automatically reversible or reconcilable.

Some operations are inherently imperative, destructive, or ambiguous.

The useful rule is:

Reconcile only where authoritative state can be observed and the correction is well-defined.

Live verification is separate from execution

A successful mutation response is not enough.

After execution, Runtime can perform a bounded read against the authoritative provider and verify that the intended state actually exists.

mutate
  ↓
provider says success
  ↓
read provider again
  ↓
compare observed state with intent
  ↓
verified result

That distinction matters because:

Execution success and state correctness are not the same thing.

A provider may accept a request while the final state is different from what the caller intended.

Verification closes that gap.

Rerunning after partial failure

This becomes especially useful when a capability fails partway through.

A naive workflow may blindly replay every previous mutation.

A stateless reconciliation model instead starts the next run by observing reality again.

step 1 completed
step 2 completed
step 3 failed
        ↓
fix cause
        ↓
rerun from the beginning
        ↓
observe live state again
        ↓
step 1 → SATISFIED
step 2 → SATISFIED
step 3 → APPLIED
remaining work → continue

The new run does not trust a local "last applied" record.

It trusts the provider.

Why this matters for agents

Agents may retry operations, lose conversation state, switch models or hand work to another agent.

A reconciliation model that depends on hidden session memory is fragile.

A model grounded in authoritative provider state is more durable:

agent changes
session disappears
previous run metadata is unavailable
        ↓
provider state still exists
        ↓
Runtime can observe again

This fits the broader Engineering Runtime principle:

Reasoning can change. Execution truth should come from the systems that own it.

What Runtime still records

Stateless reconciliation does not remove evidence.

Runtime can still record:

• what was requested,
• what state was observed,
• what decision was made,
• whether a mutation ran,
• what the provider returned,
• what verification observed,
• whether the final result was satisfied, applied, reconciled or failed.

That evidence explains execution.

It does not become the provider's source of truth.

The design principle

A compact version is:

Git stores intent. Providers store reality. Runtime reconciles between them.

That gives Engineering Runtime a way to support drift detection and rerunnable operations without becoming a universal state database.