IGRE

Most operational tools eventually hit the same problem as Git, but with a worse substrate.

Git assumes files are mostly still until someone commits. Operational systems are not like that. They are datastreams. The world changes while the operator is reading it. A customer changes a setting. A sync finishes. A row is updated by another worker. A remote API returns a view that is already aging by the time the CLI prints it.

Then an operator commits.

The uncomfortable question is not just “was the action correct?” It is:

What state did the operator think they were looking at when they acted?

Without that answer, blame and repair both get mushy. A bad outcome might come from a risky action, stale state, incomplete verification, an honest race with the system, or someone acting on dubious grounding. If the tool only records “command ran” and “response failed,” the organization cannot tell those apart.

IGRE is an answer to that gap.

The Commit Claim

An IGRE commit always says:

I have this relevant state from these sources.
I am this sure about that state.
I am taking this action based on that state.
The risk profile of taking this action on this grounding is known.
The rollback truth is known.
Commit.

That state is later inspectable. The risk profile is derived from the domain catalog and the verification shape, not from a vibes-based operator opinion. The rollback claim is explicit. If the CLI cannot undo the action, it says so.

The Problem

Operators need to act on changing systems.

They usually bootstrap local state first:

• read a cache
• query a remote API
• inspect a local file
• generate a plan
• compare a few identifiers

But every observation has a divergence threshold. A local cache may be ten seconds old, ten hours old, or simply missing a relevant row. A remote API read may already be stale relative to another worker. A local plan may depend on a fetch whose freshness budget has expired.

Traditional CLIs rarely make that threshold visible.

So when something breaks, the team argues about intent:

• Did the operator take a risky action?
• Did they act from stale state?
• Was the stale state expected slippage?
• Did the tool hide an unverifiable assumption?
• Did someone act after a warning that should have stopped them?

IGRE turns those arguments into ledger questions.

The Solution

IGRE makes operators commit against explicit grounding.

Before mutation, the tool records observations as fetch artifacts. It then records an immutable intent derived from those fetches. The intent names the action, the data paths, the verification plan, the risk anchor, the blind spots, and the rollback truth.

At action time, the CLI revalidates:

• the fetches still exist
• the fetches are fresh enough
• the catalog versions still match
• the requested action matches the intent
• the action target is local or remote as declared
• the risk and rollback structures still lint

If the grounding is too old, action is blocked. If the grounding is fresh enough, action proceeds with a visible threshold of alignment.

This is not pretending the operator has perfect truth. It is making the operator’s divergence threshold explicit.

The Result

Operators can commit.

Everyone else can later see what alignment threshold they committed on.

Sometimes things still break. IGRE does not remove races, bad APIs, incomplete checks, or risky decisions. But it makes repair easier because the ledger can distinguish:

• a risky action taken on good grounding
• a reasonable action taken on stale grounding
• an action that crossed a declared blind spot
• an action whose verification failed after mutation
• an action that should have been blocked by freshness or catalog drift

That also changes blame.

If an operator took a high-risk action, the ledger shows that. If an operator acted from state the tool can prove was likely dubious, the ledger shows that. If the system changed honestly within the accepted slippage window, the ledger shows that too.

IGRE does not make operational work safe. It makes operational work inspectable.

The Shape

The protocol uses this command shape:

lfetch / fetch -> intend -> laction / action

• lfetch observes local true state.
• fetch observes remote true state.
• intend create-* records an immutable proposed intervention.
• intend list and intend status inspect the intent repository.
• laction mutates local true state.
• action mutates remote true state.

The rest of this documentation describes the mechanics behind that shape.