Reference

Execution receipts

Understand decision identity, enforcement identity and terminal outcome without mixing them with workload output.

Execution receipt v1

EXECUTION RECEIPTMediated build

{
  "schema": "maelys.execution-receipt/v1",
  "invocationId": "build-2026-08-24-001",
  "decisionDigest": "94d14d6aece6e3a0cdf1409d9a92695b8591fe7016ae56ebad221fcd49ba8bc3",
  "planDigest": "cf14f5b4eff7f425b140948c9c1d53f905c73e7ad6504aaa1d3e04490f812535",
  "mediator": "maelys-netd/proxy-v1",
  "backend": {
    "name": "bubblewrap",
    "version": "0.9.0"
  },
  "capabilities": {
    "required": 16415,
    "backend": 24575
  },
  "network": {
    "mode": "mediated",
    "frontend": "netd-proxy"
  },
  "startedUnixMs": 1787541910254,
  "forcedStopAttempted": false,
  "completed": true,
  "outcome": {
    "exitCode": 0,
    "termSignal": 0
  }
}

Field meaning

Field	Meaning
`decisionDigest`	SHA-256 identity of the canonical portable MIR decision
`planDigest`	SHA-256 identity of the resolved mechanical Executor plan
`backend`	selected enforcement implementation and version
`capabilities`	guarantees required by the plan and advertised by the backend
`network`	ambient, none, fd4 or Netd proxy delivery path
`outcome`	exactly one terminal exit or signal outcome

When it can be written

A complete receipt requires the terminal outcome, so the normal CLI writes it after wait completes. An application may snapshot partial lifecycle information internally, but must not label that snapshot as a completed execution receipt.

Network receipts

Netd emits separate JSONL connection receipts containing the authorized destination, policy identity, byte counts and closure result. Execution and network evidence stay separate because they have different cardinality: one process execution may open many network connections.