Consequential Execution

Consequential Execution is the Evidence Bridge target for state-changing system actions, backed by cer.consequential.execution.v1 with outcome rules, whole-field disclosure policy and terms-digest validation.

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

Consequential Execution is the Evidence Bridge evidence target for consequential system actions, and is the label used in the Bridge interface. Earlier documentation called this category Operational Execution. 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.

Evidence inclusion

Mapping a value does not automatically place every supported optional field in the final CER. Optional evidence such as request and result is preserved only when the profile explicitly includes it; otherwise it remains unbound. The Bridge warns when supported mapped evidence would otherwise be omitted. Use Preview to confirm exactly what enters the resulting CER. Changing inclusion requires a new profile revision.

Disclosure policy: Protected and Readable execution evidence

Disclosure is configured per whole top-level field. Supported fields:

request
preState
action
appliedChange
result
postState
target
decisionRefs

outcome is not a configurable Readable or Protected field.

Protected execution evidence

The CER contains an HMAC commitment. The original value is not publicly disclosed, and selective verification requires a valid opening. HMAC is a commitment mechanism, not encryption.

Readable execution evidence

The complete top-level field value appears directly in the CER and is certificate-bound. Disclosure applies to the entire field, not to individual nested properties. For example, request = Readable means the complete request object is readable. A nested property such as request.termsHash cannot be made readable on its own.

A Consequential CER may therefore contain Protected fields, Readable fields, or a mixture of both. Disclosure is part of CER construction and can change the certificate hash.

Public and private execution evidence

Visibility controls who can retrieve the Node-attested record. Disclosure controls what the CER reveals.

Public. The record may be resolved through the Node's public proof endpoints.
Private. The record is not available through anonymous public resolution. The owner can retrieve it through authenticated access. A private CER remains portable cryptographic evidence: any holder of the artifact can still verify it independently. Private does not mean cryptographically unverifiable.

Public or Private is Node operational publication metadata. It does not alter the CER, the certificate hash, the receipt signature or the verification-envelope signature. No combination of visibility and disclosure is more cryptographically valid than another.

Terms evidence validation

A profile may configure:

Exact terms text path
Submitted SHA-256 digest path
Terms version path    (optional)
Terms reference path  (optional)

Validation rule

exact supplied application string
-> UTF-8 bytes
-> SHA-256
-> lowercase sha256:<hex>

The Bridge does not normalize whitespace, line endings, Unicode, JSON or HTML. If the computed digest does not match the submitted digest, ingestion returns 422 TERMS_DIGEST_MISMATCH, no CER is created and no Node attestation occurs.

The terms text is used for validation and does not need to be retained in the CER. The validated digest, version and reference can be preserved in a Readable request.

A matching digest establishes that the recorded digest corresponds to the exact terms content supplied for that execution. It does not prove that a person saw, understood or accepted the terms, that the terms are legally enforceable, or that the source system was truthful.

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. Continue with the Integration guide and Verify evidence.