# Operational Execution

URL: https://docs.nexart.io/docs/evidence-bridge/operational-execution

Operational Execution is the Evidence Bridge category for consequential system actions, backed by the cer.consequential.execution.v1 evidence family with outcome-sensitive applied-change rules.

Canonical evidence family: Consequential Execution V1 (`cer.consequential.execution.v1`).

Operational Execution is the user-facing Evidence Bridge category for consequential system actions. The canonical NexArt evidence family underneath it is `cer.consequential.execution.v1` at protocol `1.3.1`, produced by `@nexart/consequential-execution`.

It is designed for executions where a system reports that it attempted an action against a target and records the resulting outcome.

## Semantic model

```
executionId
occurredAt
producer
actionType
target
request OR preState
action
outcome
result OR postState
```

Outcome is one of:

```
applied
partial
failed
```

## Action versus applied change

Outcome-sensitive rule

```
applied  -> appliedChange required
partial  -> appliedChange required
failed   -> appliedChange forbidden
```

action describes what the execution attempted to do. appliedChange describes the change the producer reports was actually applied. This distinction prevents a failed execution from falsely implying that a state change occurred.

## Example

Source payload

```
{
  "execution_id": "exec_9f83a1d04b7e",
  "execution_timestamp": "2026-09-08T20:14:02.115Z",
  "component": "sre/remediator",
  "action_type": "NODE_ISOLATION",
  "target_resource": "node_03",
  "pre_state": {
    "status": "ONLINE",
    "latency_ms": 312.45,
    "slo_threshold_ms": 250
  },
  "action_applied": {
    "command": "ISOLATE",
    "route_shift": "drain_ingress_traffic"
  },
  "outcome": "APPLIED",
  "post_state": {
    "status": "ISOLATED",
    "health_status": "DEGRADED_FAILOVER"
  },
  "proposal_id": "prop_a712f9b8c340",
  "consensus_seal": "opaque-source-seal"
}
```

Conceptual mapping

```
execution_id         -> executionId
execution_timestamp  -> occurredAt
component            -> producer component
NODE_ISOLATION       -> example:node-isolation
target_resource      -> target
pre_state            -> preState
action_applied       -> action
action_applied       -> appliedChange
APPLIED              -> applied
post_state           -> postState
proposal_id          -> decision reference
consensus_seal       -> opaque external seal/reference
```

Evidence Bridge does not infer cryptographic algorithms from the appearance of source values. A 64-character hexadecimal seal is not automatically declared to be SHA-256 unless the source explicitly defines it that way.

## Consequential claim boundary

A valid Consequential Execution record establishes the integrity of a producer-reported execution claim. It can cryptographically bind:

- what execution was identified
- when the producer reported it occurred
- which producer or component reported it
- what action was attempted
- which target was involved
- what pre-state or request was captured
- what change the producer reports was applied
- what outcome was reported
- what result or post-state was captured
- which external decision or governance references were attached

Verification does not independently prove:

- that the physical action actually occurred
- that the producer was honest
- that the action was authorized
- that governance was valid
- that the action complied with policy
- that the action was legally compliant
- that the action caused the reported post-state
- that the record represents the complete system history

Producer identity assurance is currently represented as CLAIM_ONLY unless a separate cryptographic identity mechanism establishes stronger producer authentication.

## Authorization is not execution

This payload is not sufficient to create Consequential Execution evidence:

```
{
  "proposal_id": "prop_123",
  "status": "AUTHORIZED"
}
```

Neither is this, because it does not prove that the tool actually executed:

```
{
  "tool": "delete_user",
  "arguments": {
    "id": "123"
  }
}
```

The source must contain execution-stage semantics such as:

- execution identity
- target
- attempted action
- outcome
- result or observed post-state

This is an important NexArt trust boundary. See Security and trust boundaries.