Decision Artifact vs Execution Receipt Governance Models

[xsa520]

Decision Artifact vs Execution Receipt Governance Models

Several recent discussions across AI agent governance projects appear to be converging on a similar architectural question:

Where should governance evidence live in the agent lifecycle?

Two complementary approaches are emerging.

---

1. Execution-Receipt-Centric Governance

In this model, governance evidence is produced after execution.

Typical pipeline:

Intent → Policy Evaluation → Execution → Execution Receipt

Execution receipts capture what actually happened at runtime.

Typical properties:

• signed execution artifacts
• runtime verification
• post-execution auditability

This model is being explored in several systems focused on cryptographic execution attestation for distributed agent runtimes.

---

2. Decision-Artifact-Centric Governance

An alternative approach is to treat the decision itself as a first-class artifact.

Pipeline:

Intent → Policy Evaluation → Decision Artifact → Execution → Receipt

Here the decision artifact records:

• intent
• actor
• policy evaluation result
• decision outcome
• timestamp
• integrity hash

before execution occurs.

This allows:

• deterministic replay of governance decisions
• detection of tampering between evaluation and execution
• auditability independent of runtime logs

The Guardian architecture explores this model.

---

Architectural Separation

These two models appear to answer different governance questions:

Layer	Question
Decision Artifact	Why was this action allowed?
Execution Receipt	What actually happened?

Rather than competing approaches, they may represent complementary governance layers.

---

Possible Interoperability

A potentially interesting direction is whether governance systems could emit compatible decision artifacts.

For example, a minimal decision record might contain fields like:
intent
actor
policy_result
decision
decision_hash
timestamp

This repository includes an exploratory schema draft:

schemas/decision_record.schema.json

The goal is not to define a standard, but to explore whether interoperable governance artifacts could make agent governance systems easier to audit across implementations.

---

Open Questions

Some open questions for governance system designers:

1. Should decision artifacts and execution receipts be separate artifacts?
2. Can governance decisions be deterministically replayed across policy engines?
3. What minimal fields are required for cross-system verification?
4. Could different governance frameworks share a common evidence format?

Interested to hear perspectives from other governance implementations.

[Jairooh]

The distinction between execution-receipt-centric and decision-artifact-centric governance maps pretty directly onto a tension we've hit in practice: receipts give you tamper-evident audit trails but don't capture why a decision was made, while decision artifacts preserve intent but can be detached from what actually executed. A hybrid approach — cryptographically binding the decision artifact (policy, context, model output) to the execution receipt via a hash chain — gives you both auditability and causal traceability without requiring a trusted third party. We ran into this same problem building AgentShield's approval gate audit logs (useagentshield.com), and ended up anchoring the pre-action risk score + context snapshot to the post-execution state so you can reconstruct the full decision lineage — happy to share notes on the schema if useful for the guardian discussion.

[xsa520]

That's a really interesting point.
The hybrid model you describe (binding the decision artifact to the execution receipt via a hash chain) seems like it could preserve both intent and execution traceability.

One thing I'm curious about from your AgentShield experience:

Did you treat the decision artifact as a first-class object in the system, or more as metadata attached to the execution record?

And when reconstructing the lineage later, was the replay driven from the decision side or from the execution receipts?

I'm especially interested in how different implementations structure that boundary, since it seems to influence how portable the governance evidence becomes across systems.

[Jairooh]

Good questions, these boundary decisions ended up mattering a lot in practice.

We treat the decision artifact as a first-class object: each approval gate event in AgentShield stores the pre-action risk score, the context snapshot (input, agent state, tool being called), and the policy that triggered the gate — all as a separate record linked to the execution span via a shared span_id. Not metadata attached to the execution record, because we found that when you need to audit why something was blocked or approved, you want to query decision artifacts independently without joining through execution records.

For lineage reconstruction, we drive it from the execution side — the span tree is the backbone, and decision artifacts hang off it. The reason: execution receipts are append-only and tamper-evident by nature (each span closes with a hash of its output), while decision artifacts can be amended (e.g., a human overrides an approval gate). Driving replay from the execution side keeps the audit trail clean even when decisions are revised.

[aeoess]

@xsa520 — we formalized the shared decision artifact idea into an RFC:

RFC: Cross-Engine Signed Execution Envelope

Your decision-artifact-centric model maps directly: the independent decision record becomes the decision block, the evidence record becomes the attestation block. The RFC includes field definitions, governance gate rules, mappings to APS/Guardian/CrewAI, and open questions on canonicalization and signature format.

The evaluation_method field (deterministic vs probabilistic) addresses the verifiability distinction you raised — deterministic decisions are independently replayable, probabilistic ones are signature-checkable only.

@Kelisi808 from crewAI#4560 independently proposed a compatible 7-field envelope. Three groups converging on the same shape is a strong signal.

Would Guardian be able to emit this envelope format? If so, we can build a cross-engine verification test.

[xsa520]

@aeoess This is a great direction — thanks for formalizing it into the RFC.

The mapping you outlined (decision → decision block, evidence → attestation block) aligns closely with how we think about decision artifacts as first-class, independently verifiable units.

I’ll respond in the RFC thread with a more concrete mapping from the Guardian side (including decision/receipt boundaries and verifier expectations) so we can keep the discussion consolidated there.

The cross-engine verification angle is especially interesting — happy to explore that once we align on the envelope shape.