Execution records what actually occurred when the requested mutation ran.

Primary Fields

  • status: outcome (succeeded, failed, partial, cancelled, etc.).
  • runId: control-plane/runtime correlation ID.
  • backend: execution backend metadata (type, version, optional details).
  • timing: duration metrics for queue/execute/verify phases.

Optional Evidence

  • state: before/after references and optional diff summary.
  • error: structured failure code/message/remediation hints.
  • retries: retry count, max, and reasons.
  • details: provider-specific structured metadata.

Presence Rules

  • Execution MAY be omitted for pre-execution intent receipts.
  • Execution SHOULD be present after a mutation attempt finishes.
  • If status is non-success, include error when available.
  • If status is failed or cancelled, state.after SHOULD be absent unless partial state capture is intentionally recorded.

Modeling Advice

  • Keep backend details machine-readable (avoid free-form blobs when possible).
  • Use stable error codes for alerting and analytics.
  • Use state.before/state.after references to bind evidence artifacts.

Schema: v1/schema/execution.json