7. OpenKedge Intent Governance

OpenKedge governs the transaction at the boundary between reasoning and execution. It is a protocol for verifiable intent governance for AI agents. The protocol ingests structured intent, evaluates it against active policy and runtime context, generates bounded execution contracts, and records the evidence needed to reconstruct why a system mutation was allowed, denied, escalated, or constrained.

OpenKedge replaces direct, unmonitored agent execution with intent-based mutation governance. Rather than checking only whether an agent possesses API access, the protocol evaluates whether a proposed intent should mutate a target system under the active environmental context, what specific authority is justified, and whether the emitted evidence satisfies audit and replay standards. The OpenKedge reference paper develops these protocol specifications in greater technical detail [1].

From API Calls to Intent Governance

Conventional authorization models evaluate operations; OpenKedge governs semantic intents.

Traditional API authorization checks the caller's identity, the requested operation, and the principal's permissions. While necessary, this model is too narrow for autonomous systems. An AI agent can synthesize a syntactically valid operation while operating on stale context, misunderstanding its high-level objective, selecting an incorrect target, exceeding its intended scope, or choosing an action that is technically permitted but operationally damaging.

Autonomous agency turns access control into a semantic governance problem. The acceptability of an API call depends on the target resource, execution timing, environmental context, operational reversibility, policy constraints, and institutional consequences. A system restricted to traditional permission checks can admit actions that require rejection, modification, simulation, or human escalation.

OpenKedge replaces direct API execution with governed intent evaluation. Agents do not mutate systems by virtue of generating tool calls; instead, they submit proposed state transitions to the governance layer. The governance engine evaluates these proposals against active policy and live context. After approval, an intent compiles into an execution contract and then into bounded runtime authority.

The protocol leaves room for agentic reasoning while keeping execution institutionally governed. Agents optimize reasoning and propose actions; OpenKedge validates whether those proposals satisfy the requirements for governed state mutation.

This division of labor provides system architects with clean boundaries. Agent frameworks focus on reasoning, planning, memory, and tool selection. OpenKedge handles the governance surface: intent normalization, context capture, policy evaluation, contract generation, and evidence emission. Conflating these responsibilities compromises accountability. When the same agent that plans also authorizes and executes, the managing institution loses the ability to audit reasoning quality independently from governance quality.

Neuro-Symbolic Intent Governance

OpenKedge implements a neuro-symbolic governance pipeline: neural reasoning translates ambiguous, high-level objectives into candidate intent, while symbolic governance determines whether that intent qualifies for execution.

This split addresses a practical engineering reality. Large language models are useful for interpreting high-level requests, summarizing operational telemetry, diagnosing system anomalies, and drafting prospective plans. Natural language remains ambiguous and context-dependent, so it is not a reliable basis for execution authority. Natural language may initiate a request, but it should not authorize execution.

The neural model acts as a translator of intent, not the executor. It may interpret the instruction "restore checkout service health" and generate a candidate intent to shift traffic, restart a component, or deploy a previous stable release. This candidate proposal is input for the governance engine, not an authorized command.

OpenKedge serves as the symbolic arbiter between probabilistic reasoning and deterministic execution. It exposes a structured evaluation surface: intent schemas, context snapshots, policy versions, risk classifiers, execution contracts, and evidence trails. Symbolic governance does not require formalizing every operational judgment in code; it requires machine-enforceable policies to apply consistently, while routing ambiguity to escalation, simulation, or denial.

This neuro-symbolic separation preserves the utility of advanced reasoning while keeping authority within the managing institution. The model interprets and proposes; OpenKedge checks that the proposal is well-formed, contextually appropriate, policy-compliant, and evidenced.

For foundational research integrating neural and symbolic models, see [2]. For symbolic policy systems, refer to industry-standard engines like Cedar [3] and OPA [4].

The Intent Object

An intent represents a structured, machine-evaluable specification of a proposed state transition.

As the boundary artifact between reasoning and governance, the intent object enables the control plane to inspect, normalize, enrich, constrain, approve, and replay model proposals. Without this structured substrate, the system is left with raw natural-language outputs, tool-call fragments, or generated scripts: artifacts useful for reasoning but inadequate for deterministic governance.

A valid intent object specifies the requested action, underlying objective, target scope, origin, assumptions, expected blast radius, risk classification, and justification. This format must be machine-readable to allow automated policy evaluation, and human-readable to facilitate manual review. It also needs provenance metadata identifying the model, agent version, user request, and system state that initiated the proposal.

OpenKedge converts model output from a command into a governable claim.

{
"intent_id": "intent-123",
"actor": "ops-agent",
"reasoning_source": "incident-response-agent",
"objective": "restore service health",
"requested_action": "shift_traffic",
"target": "service.checkout",
"scope": {
  "region": "us-west-2",
  "percentage": 20
},
"assumptions": [
  "error_rate_above_threshold",
  "secondary_region_healthy"
],
"justification": "Reduce elevated 5xx rate by shifting traffic.",
"risk_class": "medium"
}

The intent object captures both the proposed action and its underlying rationale. This semantic detail matters. A request to shift traffic due to service degradation demands different policy constraints than a traffic shift for cost optimization. Similarly, updating an access policy during a break-glass incident requires distinct validation compared to routine maintenance. Though the technical operations are identical, the semantic intent and active context differ.

Intent isolation also supports vendor and model neutrality. Because the control plane mandates a standardized, structured intent format, the underlying models and agent frameworks can be swapped, upgraded, or run in parallel without altering the system's authority boundary.

Production environments must reject malformed or incomplete intents prior to policy evaluation. Missing actor identities, ambiguous targets, or unsupported actions should not reach execution. Schema validation is the first line of defense in the governance pipeline.

Context Acquisition

Evaluating an intent in isolation is incomplete; environmental context determines whether the action is acceptable.

This context encompasses infrastructure telemetry, dependency topologies, incident logs, active change windows, compliance parameters, resource metadata, active policies, historical intents, and real-time risk indicators. For instance, cloud operations require dependency maps and service health; administrative workflows require approval thresholds and case status; and automated software deployments require test coverage metrics and protocol invariants.

The operational implications are straightforward. Terminating a virtual machine is acceptable if the instance has been removed from rotation and healthy replacements exist; it is not acceptable if the machine actively serves production traffic or belongs to a protected capacity group. Shifting network traffic is acceptable if the target destination is healthy; it is not acceptable if that destination is currently degraded or under active investigation.

Context acquisition must be tightly bounded and auditable. The governance engine gathers only the context attributes required for the active decision. It records a precise snapshot of this context at decision time, relying on trusted, verifiable context providers. The protocol treats stale context as an immediate trigger to deny, constrain, refresh, or defer execution.

Bounded context protects both sovereignty and operational safety. Under-collecting context leads to the approval of semantically unsafe mutations, while over-collecting leaks sensitive data and introduces operational noise. OpenKedge defines explicit context requirements mapped to intent classes, target resource domains, and risk classifications.

This context snapshot anchors the evidence chain, letting auditors reconstruct exactly what the system knew at decision time. If a decision fails due to stale or contradictory telemetry, the evidence chain exposes the root cause.

Policy Evaluation

OpenKedge evaluates intents against machine-enforceable policies. These policies incorporate security rules, operational safety constraints, compliance mandates, approval workflows, change windows, and service ownership metadata.

The protocol does not require institutions to replace their existing policy systems. Instead, it provides the structured intent and context substrates that enable these systems to govern autonomous actions.

Architecturally, OpenKedge is policy-engine-pluggable. It prepares policy inputs, invokes external policy engines (e.g., Cedar for role authorization, OPA/Rego for operational safety, custom engines for domain-specific constraints), interprets the decisions, and generates execution contracts.

Policy evaluation must support multi-modal outcomes rather than binary gates. Real-world operations demand partial approvals, narrowed scopes, time-bounded authorizations, simulated executions, or human escalations.

All policy inputs must be versioned and replay-compatible. The system logs the exact policy version evaluated, the context supplied, the intent fields analyzed, and the resulting decision. This version-locked audit trail supports deterministic replay and allows operators to simulate historical workloads against updated policies.

Deterministic policy application also satisfies a key sovereignty requirement: policy changes must be explicit, versioned, and auditable. In regulated environments, explaining why a policy allowed or blocked an action is as critical as the enforcement itself.

Blast Radius and Risk Classification

Operational risk is a function of action, context, target criticality, reversibility, and institutional consequence.

The risk of a mutation cannot be inferred from the API call alone. It depends on target criticality, user impact, dependency fanout, data sensitivity, financial exposure, and regulatory implications. A read-only diagnostic command may be routine in a development environment but highly sensitive on a production database. A configuration change might affect a single sandbox environment or disrupt a national-scale service.

Evaluating blast radius determines whether an action can execute, whether it requires sandboxed simulation, how narrow its identity scope must be, and what evidence must be captured. High-risk actions demand shorter execution windows, pre-verification, and explicit escalation paths.

Risk classification serves as a primary input to policy, not an arbitrary label. A medium-risk intent may execute under automated constraints, whereas a high-risk proposal requires simulation and operator sign-off. The control plane logs this classification in the evidence chain, ensuring auditors can reconstruct the rigor applied to each decision.

Risk classifications must remain dynamically recalculable. If the state of the target system mutates prior to execution, the risk profile changes. A contract issued under low-risk assumptions should not authorize execution in a high-risk state; hence, contracts incorporate explicit expiration bounds and revocation conditions.

Execution Contracts

An execution contract represents a bounded, machine-enforceable specification defining the precise operational limits of an approved intent.

The contract contains the approved operation, target resource identifiers, permitted parameters, time bounds, context assumptions, policy references, derived identity scope, maximum blast radius, rollback procedures, and evidence requirements. This schema provides the execution and identity layers with deterministic boundaries.

The execution contract serves as the invariant bridge between governance and runtime authority.

{
"contract_id": "contract-456",
"intent_id": "intent-123",
"decision": "allow_with_constraints",
"approved_action": "shift_traffic",
"target": "service.checkout",
"constraints": {
  "max_percentage": 20,
  "region": "us-west-2",
  "expires_in": "10m"
},
"required_evidence": [
  "pre_context_snapshot",
  "policy_decision",
  "execution_result",
  "post_verification"
]
}

Rather than relying on standing privileges, VAI derives execution identity directly from this contract. A precise contract should produce a restricted, short-lived runtime authority mapped to the approved intent. If a contract authorizes a 20% traffic shift for ten minutes in a single region, the execution adapter must prevent a 50% shift or operation in an adjacent region.

This model also supports audit replay. If an execution exceeds its contract boundaries, the system flags an enforcement failure; if the execution stays within bounds but causes an outage, the system flags a governance failure. The evidence chain helps isolate these distinct failure modes.

Execution contracts must be treated as first-class, cryptographically signed artifacts. They maintain dedicated identifiers, lifecycle states, context assertions, and expiration boundaries so policy decisions govern runtime adapters with less translation risk.

Decision Outcomes

OpenKedge normalizes policy decisions into explicit, machine-readable outcomes, avoiding brittle binary models.

An Allow outcome authorizes the intent to proceed as specified. A Deny outcome halts execution immediately due to policy violations, unsafe context, or insufficient authorization. A Constrain outcome restricts the execution to a safer subset of parameters. An Escalate outcome routes the intent to human operators. A Simulate outcome evaluates the change in a dry-run environment. A Request Context outcome pauses the pipeline until necessary telemetry is acquired, while a Defer outcome postpones execution to a safer operational window.

Downstream execution systems must ingest these outcomes directly as machine-readable inputs rather than attempting to parse natural-language rationales.

Evidence Emission

Every OpenKedge decision must emit structured evidence, including proposals that do not proceed to execution.

Denied, escalated, and constrained actions represent critical telemetry. The control plane logs intent ingestion, context snapshots, policy evaluations, risk classifications, contract generation, approvals, and rejections. These events form the pre-execution segments of the IEEC.

Recording successful executions is insufficient. Denials demonstrate where policy successfully prevented unsafe operations; escalations highlight where automated heuristics deferred to human judgment; and constraints show where the system narrowed blast radius.

This evidence trail supports auditing, compliance, replay, policy debugging, and incident forensics. It allows policy authors to test proposed rules against historical intent logs and enables operators to isolate whether an incident stemmed from agent error, telemetry failure, policy logic, or execution adapter collapse.

Evidence emission represents a core protocol invariant. If the system cannot reconstruct why it permitted a mutation, it lacks verifiable governance.

This telemetry must remain operationally visible. Operators must be able to inspect why an action is stalled in escalation, why a proposal was constrained, or why an agent is generating repeated denials. This visibility helps teams refine policies, improve agent prompting, and identify recurring anomalous proposal patterns.

OpenKedge as a Policy-Engine-Pluggable Layer

OpenKedge operates as an open, composable, and policy-neutral protocol. It does not introduce a proprietary policy language as a mandatory dependency.

Instead, OpenKedge normalizes intents, orchestrates context acquisition, structures the evaluation inputs, invokes pluggable engines, interprets the decisions, and records evidence. This allows institutions to use their existing policy investments, including Cedar, OPA/Rego, custom enterprise approval systems, or cloud-native controls.

The protocol does not replace policy engines; it provides the intent and context substrates that make autonomous intent governable by them.

This approach addresses sovereign and enterprise constraints. A national agency requires localized policy authority and formal approval workflows; a regulated enterprise requires separation of duties and compliance controls. OpenKedge integrates directly with these pre-existing control layers.

Pluggability also mitigates vendor lock-in. Models, cloud platforms, and policy engines can evolve or change while the core governance lifecycle remains stable.

To support this composition, OpenKedge defines stable, standardized adapter interfaces for policy inputs and outputs, ensuring all pluggable engines map to normalized decision outcomes and log standardized evidence.

Cloud Infrastructure Example

Consider an AI operations agent proposing to terminate a degraded compute instance. In a naive direct-execution architecture, the transaction executes as:

This path bypasses governance. Although the agent possesses the API credentials to call the command, the system has not evaluated whether the operation is safe.

Under the OpenKedge protocol, the transaction executes as:

The acceptability of the instance termination depends on active context.

The governance engine evaluates whether the instance is in production, whether it sits behind an active load balancer, whether it actively serves traffic, whether healthy replicas exist, whether a change freeze is in effect, and whether the mutation is reversible.

Based on these context attributes, OpenKedge may: allow the termination if healthy replicas exist; constrain the execution by requiring the instance to be detached from the load balancer first; escalate to an operator if the target is a critical database node; or deny the request if replica capacity is depleted.

This pattern applies equally to database failovers, firewall policy modifications, service deployments, queue draining, and budget adjustments. The technical APIs vary, but OpenKedge governs the underlying proposed mutation.

Design Requirements

OpenKedge implementations must satisfy several architectural requirements.

1. Structured intent ingestion. The protocol must ingest machine-evaluable intent objects rather than raw model tool calls.
2. Context provider abstraction. Telemetry must originate from trusted, auditable context providers and be strictly scoped to the active decision.
3. Policy-engine pluggability. The governance layer must support diverse engines, including Cedar, OPA/Rego, and enterprise approval systems.
4. Risk and blast-radius classification. The system must dynamically classify risk based on action, target, context, reversibility, and consequences.
5. Execution contract generation. Approved intents must compile into bounded contracts defining the limits of permissible execution.
6. Decision outcome normalization. Decisions must map to normalized, machine-readable outcomes: allow, deny, constrain, escalate, simulate, request context, and defer.
7. Evidence event emission. Every evaluation path must emit cryptographic evidence to the ledger.
8. Replay compatibility. The system must preserve intents, context snapshots, policy versions, decisions, and contracts to support deterministic replay.
9. Escalation paths. Ambiguous or high-risk intents must escalate to human review or dry-run simulation rather than forcing automation.
10. Cloud and domain adapter architecture. The protocol must employ adapter patterns to operate across diverse clouds, private datacenters, and public-sector workflows.

These requirements establish OpenKedge as the intent-governance engine of the Autonomous State Control Plane. SAL moves reasoning across the boundary as structured intent; OpenKedge determines admissibility. The next chapter explains how approved execution contracts compile into bounded runtime authority through VAI.