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.