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.

[pshkv]

The decision-artifact vs execution-receipt framing @xsa520 laid out here maps directly to a design choice we made in SINT Protocol's EvidenceLedger — sharing as another data point.

SINT's hybrid approach:

Rather than choosing between receipt-centric and decision-artifact-centric, we bind both in a single chained entry. The key insight @Jairooh mentions — "binding the decision artifact to the execution receipt via hash chain" — is exactly how our ledger works:

LedgerEntry(n).prevHash = SHA-256(LedgerEntry(n-1))
LedgerEntry(n).inputHash = SHA-256(toolCallPayload)
LedgerEntry(n).signature = Ed25519(agentKey, entry)

This means:

• The decision (tier, policy, which token authorized it) and the receipt (what actually ran) are in the same signed object
• The chain prevents retroactive insertion of a "the agent approved this" decision artifact after the fact
• Any verifier can walk the chain and confirm both that a decision was made and that the same decision led to this execution

On the independent verifiability point:

@xsa520 — your observation that decision artifacts should be "independently verifiable" without depending on the execution system is important. In SINT's model, we achieve this by making the ledger a first-class artifact: it's exported as a JSONL file that any verifier can replay without the PolicyGateway being online.

Would be interested in aligning SINT's ledger format with Guardian's governance evidence format. Are there minimum fields you'd want in a cross-compatible governance entry?

Repo: https://github.com/sint-ai/sint-protocol

[xsa520]

This is converging nicely — especially the separation of:

• action_ref → request identity
• compound_digest → decision identity
• envelope → equivalence boundary (as currently framed)

One subtle invariant I want to sanity-check as we move toward a minimum cross-compatible schema:

Are we assuming the envelope is semantically self-sufficient, or only cryptographically self-contained?

For example:

• Fields like tier, policy, or even tokenId → passportId mappings ultimately rely on external interpretation (policy semantics, trust registries, delegation models).
• Two systems could produce byte-identical envelopes but still disagree on the meaning or trustworthiness of the decision.

So while equivalence over compound_digest gives us a stable identity, it doesn't necessarily guarantee semantic equivalence across systems.

It might help to make explicit which layer the spec is standardizing:

• decision identity (hash-level equivalence), or
• decision semantics (cross-system interpretability)?

That boundary seems important if we're aiming for true cross-engine verification rather than just reproducibility.

[aeoess]

@xsa520 — the identity vs semantics distinction is the right question and it's one we just formalized.

We shipped computeActionRef() in SDK v1.33.0 this week. It produces a SHA-256 hash of (agentId + actionType + scope + normalizedTimestamp) — deterministic, reproducible, content-addressed. Two systems computing the same action_ref for the same request proves they're talking about the same action. That's the identity layer.

But you're right that identity alone isn't enough. Two systems can agree "this is the same action" and still disagree on whether it should be allowed.

How we handle the semantic layer: the PolicyReceipt chain separates identity from interpretation.

action_ref (identity)     → what action is this?
  └─ intent signature     → the agent says "I want to do X"
  └─ evaluator signature  → the gateway says "X is allowed because {policy, delegation, constraints}"
  └─ receipt signature    → the system says "X was executed at time T"

Each signature carrier interprets the same action_ref from their own semantic context. The intent signer declares scope. The evaluator interprets scope against policy. The receipt records execution. They share the action_ref as a join key, but their meanings are independent and independently verifiable.

So the answer to your question: the spec should standardize decision identity (hash-level equivalence via action_ref / compound_digest). Decision semantics are deliberately left to each system's policy layer — because forcing semantic equivalence would require a universal policy language, which doesn't exist and probably shouldn't.

The cross-engine verification story becomes: "we agree this is the same action (identity), and each system's evaluator independently produced a signed judgment about it (semantics). If the judgments agree, you have convergent validation. If they disagree, you have a dispute with signed evidence on both sides."

This maps to @pshkv's SINT ledger entries cleanly — the inputHash provides identity, the tier/policy fields provide semantics, and the chain prevents retroactive reinterpretation.

[xsa520]

This separation between identity (shared) and semantics (local) makes sense, and I agree that forcing semantic equivalence across systems is likely intractable.

One question this leaves open for me is what structure a “dispute” actually has in this model.

If two systems:
– agree on action_ref (identity),
– but produce different signed judgments (semantics),

what makes those judgments comparable rather than just co-existing?

In other words, is there any invariant that defines when two evaluations are “about the same decision” in a way that allows meaningful comparison?

Without that, “convergent validation” seems well-defined, but “dispute” risks collapsing into:
two independently valid but non-comparable interpretations.

Curious how you're thinking about that boundary.

[aeoess]

@xsa520 — the invariant that makes two evaluations "about the same decision" is the action_ref.

action_ref = sha256(agentId + actionType + scope + timestamp)

Two evaluations share an action_ref if and only if they evaluated the same agent attempting the same action at the same time. That's identity, not semantics. It's computed from the inputs to the decision, not the decision itself.

When two systems produce signed judgments on the same action_ref and those judgments disagree, the dispute is structurally comparable because:

1. Inputs are identical — both evaluators saw the same (agent, action, scope, time) tuple.
2. Outputs are independently signed — each evaluator's Ed25519 signature commits to their specific judgment.
3. The divergence is localized — the disagreement MUST be in the policy interpretation, not the action identity. If the inputs were different, the action_ref would be different, and there's no dispute — just two independent evaluations.

The dispute artifact itself is a third signed object:

{
  action_ref: "sha256:abc...",
  evaluation_a: { evaluator, verdict, signature },
  evaluation_b: { evaluator, verdict, signature },
  divergence_reason: "policy_interpretation",
  resolution: "pending" | "a_upheld" | "b_upheld" | "both_valid"
}

The key design choice: disputes are modeled as a defeasible overlay, not a correction mechanism. Neither evaluation is modified. The dispute artifact says "these two valid evaluations disagree about this action, and here's the signed evidence from both sides." Resolution is a separate process (could be human arbitration, could be a meta-evaluator, could be left as a permanent record of disagreement).

This avoids the collapse you identified. Two independently valid but non-comparable interpretations CAN'T share an action_ref — if they're evaluating different things, the hash diverges. If they DO share an action_ref, they're necessarily about the same decision, and the disagreement is meaningful.

The SDK ships this: computeActionRef() produces the identity, fileDataDispute() creates the dispute artifact. The dispute is signed by the party filing it, referencing both evaluations by their receipt IDs.

[pshkv]

Love this thread. The action_ref invariant is exactly the seam where teams can compare governance outcomes without forcing semantic lockstep.

Practical proposal:

• keep Decision Artifact and Execution Receipt split,
• require a shared action_ref + canonical envelope hash,
• allow local policy engines to differ while preserving audit comparability.

CTA: we can contribute a minimal JSON schema + replay fixture from sint-ai/sint-protocol so other projects can test equivalence across implementations. If you're open, we’ll open a PR with fixture vectors and validation tooling.

[pshkv]

Really like the way this thread separates decision semantics from execution receipts.

Action-ref feels like the key bridge primitive: shared comparability without forcing semantic lockstep across systems. That gives teams room to innovate locally while still supporting dispute and audit workflows across boundaries.

If useful, we can contribute a small open fixture pack (JSON vectors plus validator) so different implementations can verify they are evaluating the same decision in a reproducible way.