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.