Jump OS knowledge base · Execution contract
A receipt should explain what happened—not merely claim success.
A durable execution receipt connects the request, authority, worker, evidence, result, verification state, and rollback state so an enterprise can inspect work after the model call is over.
Evidence visual
A receipt connects the evidence
A durable receipt links the request, authority decision, execution attempt, evidence, verification state, and recovery path without pretending that an unverified result is complete.
Read the evidence guide →Enterprise work has too many invisible gaps.
A worker can return a success response even when the target system timed out, a policy decision was stale, a duplicate request ran twice, or nobody checked the final state. A log line may tell you that a function returned. It does not necessarily tell you who authorized the task, whether the action was in scope, or whether the intended business result exists.
Jump OS treats the receipt as a structured connection between the parts that must remain visible. It separates what was requested, what was allowed, what a worker reported, what evidence was produced, and what was independently verified.
The important fields
Task and principal
The task identifies the logical work and its idempotency key. The principal records the authenticated identity and method. Together they prevent a system from treating an anonymous or duplicate request as a new authorized intent.
Authority boundary
The receipt records the policy revision, decision, decision time, and expiry. A policy engine can contribute a decision, but it does not become the owner of the task or the source of truth for evidence and rollback.
Execution and result
The worker and lifecycle state show where the work is and how many attempts occurred. The result records outcome separately from verification. `SUCCEEDED` with `UNVERIFIED` is more honest than claiming a verified business result without checking it.
Evidence and rollback
Input and output hashes, evidence references, and rollback state connect the receipt to material that can be inspected. Rollback is a compensating operation with its own authority and evidence; it is not deletion of the original history.
What this changes for an enterprise
Receipts create a shared language between engineering, operations, security, and leadership. Instead of asking whether an AI worker is “smart,” teams can ask whether the system can prove the boundaries around a consequential action. That matters for CRM changes, finance operations, knowledge retrieval, customer support, claims, internal approvals, and any workflow that crosses systems.
The public repository includes a fictional valid receipt, an intentionally invalid receipt, and a Draft 2020-12 schema. Those are teaching artifacts, not live enterprise evidence. A real implementation must bind the contract to its authorized runtime, identity system, evidence store, verification process, and recovery procedure.
Read the canonical examples
Inspect the schema and fictional examples, then decide which fields your own implementation must make authoritative.
Open the receipt examples on GitHub →