# Evidence, authority, and receipts

> Evidence describes what was observed. A proposal describes intended work. An authority decision records whether a specific actor approved that exact intent. A handoff identifies who or what received the work. Execution evidence records what was later observed to run. A receipt closes the review with the identities of those artifacts. None of these is interchangeable with another.

- Author: [Celest](https://celest.dev/)
- Published: 2026-07-27
- Last materially updated: 2026-07-27
- Evidence level: Celest-authored control model grounded in implemented lifecycle contracts and cited authorization guidance.
- Canonical URL: https://celest.dev/learn/evidence-authority-and-receipts
- Source revision: `sha256:0400cb977f9cc1cf0a1de4a543219bfe56d30505bf38d618d8da4a06f2cf1906`

**Scope:** This is Celest's control model for consequential agent work. The bounded review and receipt contracts are implemented and tested as dependency-free domain contracts. Microsoft-facing Estate Review remains read-only; provider execution and fresh-state reconciliation are later capabilities and are not claimed as current commercial execution.

## The one-sentence rule

> **Control rule:** Never let an artifact claim the state of the next artifact in the chain.

A finding cannot approve its own remedy. Approval cannot prove that work started. A handoff cannot prove that work completed. A successful provider response cannot prove that the intended state now exists. Each boundary requires a new artifact created from the evidence available at that boundary.

## The artifact chain

_Seven artifacts with seven different claims_

| Artifact | What it may claim | What it must never imply |
| --- | --- | --- |
| Evidence context | What source-qualified state was observed and with what limitations | That a problem exists or an action is justified |
| Finding | What a versioned rule concluded from sufficient evidence | That the proposed response is approved |
| Proposal | What bounded work is suggested, with consequences and alternatives | That it carries authority or a provider command |
| Authority decision | What an identified principal decided about the exact proposal | That execution began or succeeded |
| Handoff | Which actor or work boundary received the approved intent | That the receiver acknowledged or performed it |
| Execution evidence | What reduced observation indicates ran, failed, succeeded, or remains unknown | That the desired postcondition was independently verified |
| Receipt | Which correlated artifacts terminally close this review | More evidence than the referenced artifacts establish |

The chain uses stable identities and one correlation identifier so a reviewer can determine exactly which evidence, proposal, decision, handoff, acknowledgement, and execution observation belong together. The receipt contains those identities rather than duplicating source payloads or manufacturing a more optimistic story.

## Authority is data

Runtime authorization answers whether a request may reach a protected resource. The Model Context Protocol authorization specification, for example, requires protected servers to validate access tokens and ensure they were issued for the server. That is necessary, but operating authority also needs a durable answer to a different question: who decided that this exact work, against this exact scope, should happen now? [[mcp-authorization]](#source-mcp-authorization)

In Celest's review contract, an authority decision identifies the principal, the correlated review, the outcome, the rationale, and the decision time. Approval is only one outcome. Reject, defer, request changes, and request more evidence are equally real decisions and must not be squeezed into a binary approval field.

> **Important distinction:** Possessing a credential is runtime capability. Recording an authority decision is organizational accountability. A safe system often needs both.

## A decision attempt is terminal

One review records at most one authority decision. If the decision requests changes or more evidence, that decision closes the attempt. A later approval must occur in a successor review that satisfies the terminal request: request_changes requires a new proposal, while request_more_evidence requires a newly observed collection and snapshot. Editing history in place would make it impossible to know what was actually reviewed.

_Decision outcomes and honest next states_

| Outcome | Meaning | Permitted next state |
| --- | --- | --- |
| approve | The identified principal accepts this exact proposal | Bounded handoff may be created |
| reject | The proposal is not authorized | Close with a decision receipt |
| defer | No current authority to proceed | Close; revisit through a new review |
| request_changes | The proposal itself must change | Create a successor with a new proposal |
| request_more_evidence | The evidence context is insufficient | Create a successor grounded in fresh evidence |

## Handoff is not execution

A work item, queue message, or external-executor request proves only that work crossed a boundary. The receiver's acknowledgement is a separate fact. Observation that work ran is another separate fact. This separation matters most when systems are asynchronous, retryable, distributed, or operated by another team.

- A created ticket is not acknowledged work.
- An acknowledged ticket is not executed work.
- An accepted API request is not a completed change.
- A completed provider operation is not an independently verified postcondition.
- A receipt is not permission to invent any missing link.

## What a receipt proves

A receipt is an immutable terminal projection of the review. A decision-closed receipt proves that a specific authority decision closed the review. An execution-recorded receipt additionally correlates the handoff, acknowledgement, and reduced execution evidence. It does not retain raw provider responses, tenant secrets, or duplicate evidence.

_Receipt outcomes_

| Outcome | Required identities | Bounded claim |
| --- | --- | --- |
| decision_closed | Review, correlation, authority decision | A terminal decision occurred for this review |
| execution_recorded | Review, decision, handoff, acknowledgement, execution evidence | Separate work was observed and correlated |
| Fresh-state reconciliation | Not yet represented by the current focused-review receipt | Future proof that the desired estate state was independently observed |

> **Current boundary:** The implemented focused-review receipt can correlate the identity of reduced execution evidence stored on the review; it does not contain that evidence. It is not yet the final fresh-state ExecutionReceipt envisioned by the full control-plane lifecycle.

## What collapses when the boundaries collapse

_Common state-collapsing failures_

| Shortcut | False implication | Control response |
| --- | --- | --- |
| Finding auto-creates a mutation | Diagnosis grants authority | Require a separate proposal and decision |
| Approval button invokes provider directly | UI identity equals bounded execution authority | Bind decision, scope, actor, and adapter separately |
| HTTP 200 closes the finding | Transport acceptance equals desired outcome | Observe execution and later reconcile fresh state |
| Proposal is edited after approval | The approved digest still describes the work | Invalidate approval and create a successor review |
| Receipt copies a success message | Provider prose is durable proof | Reference reduced, validated evidence identities |

## What Celest has proved today

Celest's dependency-free contracts and tests model bounded evidence grounding, proposals without commands or authority, five terminal decision outcomes, successor-review lineage, handoff, acknowledgement, reduced execution evidence, and terminal receipts. They reject mismatched correlations and artifact chronology that would imply work without proof.

The Microsoft-facing Estate Review API remains read-only. These contracts establish the control vocabulary and state machine; they do not claim that Celest currently executes Microsoft lifecycle mutations as a commercial production capability. The next honest proof is an inspect-only lifecycle plan, followed later by separately authorized execution and fresh-state reconciliation.

## Limitations

- An immutable receipt can preserve a false conclusion if its upstream evidence or validation policy is unsound; immutability is not truth by itself.
- The current focused-review execution evidence is a reduced observation, not full independent postcondition verification.
- Authority semantics must be adapted to the organization's identity, delegation, policy, and regulatory model.
- The contract does not grant provider credentials or execution authority.
- Customer-estate mutation remains outside the current commercial Estate Review boundary.

## Sources

<a id="source-mcp-authorization"></a>1. [Model Context Protocol authorization specification](https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization) — Model Context Protocol. Accessed 2026-07-27. Protected-resource token validation and audience binding; used here only for the runtime-authorization distinction.