Separate identifiers prevent retries, checks and payments from being counted as additional customer tasks. Identifiers are opaque and scoped by the service. Clients MUST NOT derive authorization or ordering from their textual format.
Swipe or scroll to view all columns →
| Object | Purpose | Required relationship |
|---|---|---|
| Task | One logical customer request | Owns its attempts and frozen contract |
| Attempt | One execution opportunity | Belongs to exactly one task |
| Lease | Temporary execution authority | Binds attempt, node, generation and expiry |
| DeliveryReceipt | Executor statement about an output | Binds attempt, input, output and runtime |
| AcceptanceRecord | Evaluation of a delivery | Binds receipt, rule version and checker |
| UsageRecord | Measured or claimed consumption | Binds attempt, meter and deduplication key |
| SettlementRecord | Evidence of a payment outcome | Binds invoice, channel and external identifier |
| DisputeCase | Investigation or adjustment | References original records without replacing them |
Immutable and mutable data#
A task contract freezes execution inputs and commercial conditions. Operational fields, such as the active attempt and current state version, change through ordered events. A change to a frozen field MUST create a new task or an explicitly versioned amendment; it MUST NOT silently rewrite a request that has already been accepted.
Records use explicit units. Resource quantities are integers in named units, such as bytes. Amounts use a declared decimal scale or integer minor units. Timestamps identify UTC and their source. Digests identify both the algorithm and the exact bytes being hashed.
Relationship invariants#
OBJ-01 A task has at most one attempt authorized to produce its current delivery. OBJ-02 An accepted delivery has one primary acceptance outcome under the frozen profile. OBJ-03 Repeated notifications MUST NOT create additional charges or payments. Review and reversal records are appended to the original evidence chain.