Concepts

Contracts

How OpenKedge narrows approved actions into bounded execution contracts.

Definition

An execution-bound contract is the narrow, time-scoped agreement that defines what an approved mutation may do, under which identity, against which target, and with which side-effect boundaries.

Explanation

Approval is not enough on its own. A system still needs a precise artifact that translates a high-level decision into a limited execution surface. That is the role of the contract.

OpenKedge uses the contract to prevent "approval drift" where a legitimate decision expands into an overly broad runtime capability. The contract can restrict:

  • the exact mutation target
  • the allowable operation set
  • the privilege scope and task identity
  • the validity window for execution
  • the evidence requirements produced after execution

This is why OpenKedge is not simply a policy gate in front of an API. It is a protocol for ensuring that the thing which executes is smaller and safer than the thing the agent originally hoped to do.

Example

An approved restart action might produce a contract like:

{
  target: "kubernetes:deployment/payments-worker",
  action: "rollout_restart",
  identity: "task.restart.payments-worker",
  validForSeconds: 300,
  constraints: {
    namespace: "prod",
    maxUnavailable: 1
  }
}

The agent does not gain ambient cluster access. It receives a contract that permits one restart, under one scoped identity, within one bounded window.