Swipe or scroll to view all columns →
| Term | Meaning in this documentation |
|---|---|
| Task | One customer request and the complete set of its attempts |
| Attempt | One execution opportunity with its own identity and history |
| Workload profile | Versioned execution method and input and output constraints |
| Acceptance profile | Evaluation rules frozen before execution |
| Lease | Time-limited authority to perform a scoped execution |
| Fencing token | Monotonic generation used to reject stale executors |
| Idempotency | Repeated requests do not repeat the defined business effect |
| Receipt | An executor's record or claim about a delivery |
| Digest | A cryptographic summary of explicitly defined bytes |
| Attestation | Evidence about stated properties under a defined trust root |
| TEE | Trusted execution environment; guarantees depend on the hardware and threat model |
| Settlement | Payment confirmation under the selected channel's conditions |
| SLO | Service level objective with a metric, window and target |
| JCS | JSON canonicalization defined by RFC 8785 |
For application developers#
Read the overview, run the local reference, then inspect the local task, result and error contracts. Review the network task and API chapters before designing a future integration; their availability remains Proposed specification.
For operators and reviewers#
Operators should focus on admission, resource claims, leases and incident recovery. Security reviewers should inspect roles, signature binding, verification order and isolation. Technical diligence should begin with release status, artifact identity, recorded tests and the evidence required for the next release stage.
Use Task for the logical request and Attempt for an individual execution. Reserve accepted for the explicitly named context: executor acceptance or delivery acceptance. Use payment confirmed only when independent channel evidence is present.