Celest Learn · Operating model
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.
The one-sentence rule
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
| 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.
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.
| 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.
| 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 |
What collapses when the boundaries collapse
| 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
External claims on this page use the primary sources below. Celest-authored definitions and design criteria are identified as our operating model.
- Author
- Celest
- Source revision
sha256:0400cb977f9cc1cf0a1de4a543219bfe56d30505bf38d618d8da4a06f2cf1906