FER/1 — Execution Receipts and Evidence (Core Semantics)

Status: Draft Owner: Architecture Version: 0.1.0 SoT: Yes Last Updated: 2026-02-21 Linked Phase Pack: PH07 Tags: [evidence, receipt, deterministic, execution]

Document ID: FER/1 Layer: L2 — Evidence receipts over PEL/1 execution

Depends on (normative):

ASL/1-CORE v0.4.x — value model (Artifact, Reference)
PEL/1-SURF v0.2.x — surface execution results
TGK/1-CORE v0.7.x — trace graph kernel
ENC/FER1-RECEIPT/1 — canonical receipt encoding
DDS (FER/1 layout and validation rules)

0. Purpose & Scope

FER/1 defines receipt semantics for deterministic execution evidence. It standardizes the logical fields of execution receipts and the minimal execution artifacts that higher layers can rely on, while delegating concrete encodings to ENC/FER1-RECEIPT/1 and DDS.

FER/1 does not define policy, intent, authority, or certification rules (those belong to FCT/1 and higher layers).

1. Core Concepts

1.1 Execution Artifacts (logical schemas)

FER/1 uses four logical artifact shapes. Each is an ASL/1 Artifact whose encoding is profile-defined (not specified here).

ExecutionIntent — records the inputs and environment for a run:

ExecutionIntent {
  function_ref          : Reference   // FCS/1 descriptor or equivalent
  program_ref           : Reference   // program artifact (scheme-specific)
  input_manifest_ref    : Reference   // GS/1 manifest (ordered, deduped)
  params_ref            : optional Reference
  snapshot_id           : uint64      // snapshot identity (0 if absent)
  execution_config_ref  : optional Reference // snapshot-scoped config
  environment_ref       : Reference   // environment capsule (ICD/1 / PH03)
}

ExecutionOutput — binds outputs to a run (used when outputs are multiple or need explicit naming):

ExecutionOutput {
  output_refs     : list<Reference>   // ordered
  result_ref      : Reference         // surface ExecutionResult artifact
  trace_ref       : optional Reference
}

ExecutionReceipt — evidence of a run (canonical encoding in ENC/FER1-RECEIPT/1):

ExecutionReceipt {
  function_ref         : Reference
  input_manifest_ref   : Reference
  environment_ref      : Reference
  evaluator_id         : bytes
  output_ref           : Reference
  executor_refs        : list<Reference>
  parity_entries       : list<ParityEntry>
  started_at           : uint64
  completed_at         : uint64
  // optional fields per FER/1 v1.1 (DDS): executor_fingerprint, logs,
  // determinism_level, rng_seed, limits, parent, context, witnesses, run_id,
  // signature, signature_ext
}

ExecutionObservation — optional, typed evidence produced alongside a run:

ExecutionObservation {
  kind        : enum        // e.g. stderr, stdout, metrics, trace
  payload_ref : Reference   // artifact containing the observation payload
  payload_sha256 : bytes[32]
}

1.2 Program and input conventions

function_ref MUST reference the function descriptor used for evaluation (e.g., FCS/1 descriptor).
program_ref MUST reference the program artifact used by that descriptor.
input_manifest_ref MUST reference a canonical manifest artifact that enumerates inputs in deterministic order.
params_ref, when present, MUST be an immutable artifact included in the input manifest.

1.3 Snapshot binding

All receipts are snapshot-bound:

snapshot_id in the intent MUST be the snapshot identity used for input resolution (0 when absent).
Receipts and outputs are interpreted relative to that snapshot.

2. Output Reference Fallback

ExecutionReceipt.output_ref is a single reference. The value MUST resolve as:

The sole output artifact, if the run produces exactly one output; or
An ExecutionOutput artifact when there are multiple outputs; or
The surface ExecutionResult artifact, only if outputs are empty and the result is the only durable artifact.

This rule keeps receipts stable while supporting multi-output runs and zero-output executions.

3. TGK Traceability Edges (FER/1 profile)

When ingesting receipts, a TGK/FER/1 profile SHOULD emit traceability edges using TGK edge artifacts. Edge type assignments are defined by the profile; the semantics are:

EDGE_EXECUTION: program_ref -> output_ref
EDGE_CONSUMED_BY: input_ref -> output_ref
EDGE_PRODUCED_BY: output_ref -> receipt_ref
EDGE_REALIZES: receipt_ref -> function_ref
EDGE_OBSERVED_BY: output_ref -> observation_ref (optional)

Edges MUST be derivable solely from receipt content and referenced artifacts.

4. Determinism & Validation (FER/1 v1.1)

FER/1 v1.1 receipts are parity-first and deterministic. Implementations MUST enforce the DDS validation rules, including:

Strict TLV order and no unknown tags.
executor_set and parity_vector ordered byte-lexicographically and aligned.
parity_entries[i].output_ref equals the top-level output_ref.
started_at <= completed_at and monotonic time envelope.
Determinism level defaults to D1_bit_exact; any other level requires an explicit rng_seed.
run_id, when present, MUST equal the deterministic hash over {function_ref, input_manifest_ref, environment_ref, executor_fingerprint}.
Receipts MUST NOT encode policy, intent, or authority metadata.

The canonical binary layout for receipts is defined in ENC/FER1-RECEIPT/1 and DDS.

5. Interactions

PEL/1-SURF provides the surface ExecutionResult artifact referenced by ExecutionOutput.result_ref.
FCT/1 binds policy, authority, and certification to one or more FER/1 receipts.

6. Conformance

An implementation is FER/1–conformant if it:

Produces receipts that validate under ENC/FER1-RECEIPT/1 and DDS rules.
Uses the output reference fallback rules in §2.
Emits TGK edges (when enabled) that are derivable from receipt content.

5.9 KiB Raw Permalink Blame History Unescape Escape