APPROACH COMPARISON
How Truth Engine Fits
Durable execution is only part of the problem. A system can persist a workflow and still face a harder question: did the external action actually occur — and what is the software justified in claiming now?
Documentation reviewed: October 2026
COVERAGE ACROSS THE ACTION-TO-TRUTH CHAIN
Different systems focus on different parts of the chain.
Truth Engine makes the full authority-to-truth path explicit.
SCOPE, NOT A SCORE
Related systems solve different boundaries.
Many systems solve durable execution. Some also explicitly model uncertain provider outcomes and reconciliation. This comparison maps documented product abstractions without treating the systems as interchangeable or declaring a winner.
Labels describe the documentation reviewed for this page. “Not documented as core” does not mean a capability is impossible to build with the product.
CAPABILITY MATRIX
Documented scope across six systems.
Desktop uses a scrollable editorial matrix. On mobile, tap a system to expand its capability notes.
| Capability | Truth Engine | Temporal | DBOS | AWS Durable Execution | AbsoluteJS | Crux |
|---|---|---|---|---|---|---|
| 01Durable workflow / execution | CORE / NATIVE — Durable consequential-action execution and recovery are part of the public model. | CORE / NATIVE — Workflow Execution, Event History, Activities and replay are first-class Temporal concepts. | CORE / NATIVE — Durable workflows and checkpointed steps are the core execution model. | CORE / NATIVE — Lambda durable functions use durable operations, checkpoints and replay. | CORE / NATIVE — Execution provides crash-safe external-effect execution; the wider agent stack adds durable runtime concerns. | CORE / NATIVE — The optional Runtime Engine makes flows/background work durable; Effects can be persisted with a Runtime store. |
| 02Crash / restart recovery | CORE / NATIVE — Recovery preserves execution history and does not manufacture authority. | CORE / NATIVE — Event History survives Worker/process failure and Workflow code replays from durable history. | CORE / NATIVE — Interrupted workflows recover from the last completed step. | CORE / NATIVE — Checkpoint/replay resumes durable functions after interruption. | CORE / NATIVE — Transactional outbox, attempt history and reconciliation/recovery surfaces are documented as crash-safe. | CORE / NATIVE — Runtime stores reconstruct durable work and Effect recovery state after process loss. |
| 03Durable retry mechanisms | CORE / NATIVE — Retry is governed by retained execution state and retry authority rather than blind repetition. | CORE / NATIVE — Retry Policies are first-class for Activities and Workflow runs. | CORE / NATIVE — Steps support configured retries and workflow recovery re-attempts unfinished steps. | CORE / NATIVE — Steps have checkpointed retry strategies and durable retry state. | CORE / NATIVE — Execution owns retries around durable effects and only re-enables effect retry after safe resolution. | CORE / NATIVE — Runtime-backed work retries durably; Effect retry policy remains a separate concern by design. |
| 04Explicit ambiguous external outcome | CORE / NATIVE — Ambiguous external effects are represented directly rather than collapsed into success/failure. | ADJACENT — Temporal documents the crash window where an Activity side effect may finish before completion is recorded, but not a first-class external-outcome object. | ADJACENT — DBOS documents the window where a step side effect may occur before checkpoint and the step may run again. | SUPPORTED / PATTERN — At-most-once step semantics surface StepInterrupted when execution may have started but no terminal checkpoint exists. | CORE / NATIVE — UnknownEffectOutcomeError moves provider ambiguity into a durable unknown/quarantined effect state. | CORE / NATIVE — EffectOutcomeUnknownError and unknown receipts explicitly represent provider ambiguity. |
| 05Explicit UNKNOWN / ambiguous-effect state | CORE / NATIVE — UNKNOWN is one of exactly three public truth states. | NOT DOCUMENTED AS CORE — The reviewed docs expose Activity task/event states and failures, not an explicit provider-effect UNKNOWN state. | NOT DOCUMENTED AS CORE — The reviewed docs expose workflow/step execution state, not an explicit ambiguous-effect state. | ADJACENT — StepInterrupted represents interrupted at-most-once work, but the docs do not define a general UNKNOWN effect state. | CORE / NATIVE — Unknown provider outcomes are quarantined until resolved. | CORE / NATIVE — Receipts can remain unknown/ambiguous until reconciled from external evidence. |
| 06Protection against blind retry after uncertain external effect | CORE / NATIVE — Retry request does not itself grant retry authority; uncertain effects are not resent blindly. | SUPPORTED / PATTERN — Retry Policies can disable retry and docs emphasize Activity idempotence for the crash-before-completion edge case. | APPLICATION-DEFINED — External steps may execute at least once; docs require such steps to be safe/idempotent across retries. | CORE / NATIVE — AtMostOncePerRetry plus a no-retry strategy is explicitly documented for non-idempotent external side effects. | CORE / NATIVE — Unknown provider outcomes are quarantined; retry is permitted only after resolution establishes that the effect was not applied. | CORE / NATIVE — Unknown Effects wait for external evidence; crash reconstruction does not silently retry ambiguous work. |
| 07Retry request separated from retry authority | CORE / NATIVE — Retry intent and retry authority are separate public concepts. | NOT DOCUMENTED AS CORE — Retry policy/attempt configuration is documented; a separate retry-authority abstraction was not found in the reviewed docs. | NOT DOCUMENTED AS CORE — Retries and recovery are documented without a separate retry-authority abstraction. | NOT DOCUMENTED AS CORE — Retry strategy and step semantics are documented without a separate retry-authority abstraction. | CORE / NATIVE — Agency authorization/execution leases and effect recovery controls separate permission to execute from a request to act again. | APPLICATION-DEFINED — Effects explicitly do not own authorization; application/runtime policy must authorize retry or recovery actions. |
| 08Read-only reconciliation / evidence lookup | CORE / NATIVE — Reconciliation performs read-only observation and does not itself create another effect. | APPLICATION-DEFINED — Applications can query external systems from Activities, but provider reconciliation is not documented as a Temporal core abstraction. | APPLICATION-DEFINED — External readback can be implemented as application steps; no dedicated reconciliation abstraction was found. | SUPPORTED / PATTERN — AWS instructs code catching StepInterrupted to check the external system before deciding how to proceed. | CORE / NATIVE — Query/webhook/operator reconciliation and provider-query runtime are documented first-class surfaces. | SUPPORTED / PATTERN — reconcileEffect() is native; the confirming provider lookup/evidence collection is supplied by the application/operator. |
| 09Durable effect / occurrence record | CORE / NATIVE — Immutable occurrence history is a distinct part of the public authority-to-truth chain. | ADJACENT — Event History durably records Temporal Activity lifecycle/results, not independently verified provider occurrence. | ADJACENT — Step outputs/checkpoints are durable execution records; they are not documented as external-provider occurrence records. | ADJACENT — Checkpoints record durable operation state/results, but are not an explicit provider-occurrence record. | CORE / NATIVE — Effect store retains attempt history, normalized results, provider references and reconciliation state. | CORE / NATIVE — Durable Effect receipts/attempts survive restarts with a configured Runtime Effects store. |
| 10Evidence modeled explicitly | CORE / NATIVE — Evidence is an explicit layer distinct from occurrence, proof and current truth. | ADJACENT — Event History is a durable audit/execution record, but provider evidence is not a distinct core abstraction in the reviewed docs. | NOT DOCUMENTED AS CORE — The reviewed DBOS docs describe checkpoints/results rather than a separate evidence model. | ADJACENT — Checkpointed results/history provide execution records, but a separate evidence abstraction was not found. | CORE / NATIVE — Execution includes explicit effect-evidence records/ingestion and normalized evidence boundaries. | CORE / NATIVE — Crux documents Effect receipt evidence, execution evidence and reconciliation audit metadata. |
| 11Proof / admissibility modeled explicitly | CORE / NATIVE — Proof and admissibility are explicit, separate stages in the public chain. | NOT DOCUMENTED AS CORE — No proof/admissibility abstraction was found in the reviewed Temporal docs. | NOT DOCUMENTED AS CORE — No proof/admissibility abstraction was found in the reviewed DBOS docs. | NOT DOCUMENTED AS CORE — No proof/admissibility abstraction was found in the reviewed AWS Durable Execution docs. | NOT DOCUMENTED AS CORE — AbsoluteJS documents evidence/certification controls, but not proof/admissibility as the action-outcome truth model used here. | NOT DOCUMENTED AS CORE — Crux documents evidence/reconciliation, but not proof/admissibility as explicit effect-truth stages. |
| 12Current justified truth modeled explicitly | CORE / NATIVE — SATISFIED, NOT_SATISFIED and UNKNOWN are current justified truth states. | NOT DOCUMENTED AS CORE — Temporal exposes workflow/activity execution state, not a separate current-justified-truth abstraction. | NOT DOCUMENTED AS CORE — DBOS exposes workflow/step status, not a separate current-justified-truth abstraction. | NOT DOCUMENTED AS CORE — Durable executions expose operation/execution state, not a separate current-justified-truth abstraction. | ADJACENT — Effect state can move from unknown to terminal after evidence/reconciliation, but the docs do not frame this as a general justified-truth layer. | ADJACENT — Receipts settle unknown outcomes after external evidence, but the docs do not define a general current-justified-truth layer. |
| 13Authorization / authority as part of the execution model | CORE / NATIVE — Authority is explicitly upstream of permitted execution and retry. | APPLICATION-DEFINED — Application/business authorization is outside the reviewed Workflow/Activity execution model. | APPLICATION-DEFINED — Business/action authorization is left to the application around DBOS workflows and steps. | APPLICATION-DEFINED — AWS IAM controls service access; business authority for a consequential external action remains application logic. | CORE / NATIVE — Agency owns exact action authorization, approvals, execution leases and receipts before Execution performs effects. | APPLICATION-DEFINED — Crux explicitly states Effects/Work identifiers are not authorization and callers must authorize application requests. |
| 14Full authority-to-truth chain as one explicit model | CORE / NATIVE — The public model explicitly spans authority, release/attempt, occurrence, evidence, proof, admissibility and current justified truth. | NOT DOCUMENTED AS CORE — The reviewed docs center durable workflow/activity execution and history rather than this full chain. | NOT DOCUMENTED AS CORE — The reviewed docs center durable workflows, steps, transactions and recovery rather than this full chain. | NOT DOCUMENTED AS CORE — The reviewed docs center checkpoints, step semantics, retries and resumable execution rather than this full chain. | NOT DOCUMENTED AS CORE — Official docs span Agency authorization, Execution uncertainty/reconciliation and evidence, but not one explicit authority→admissibility→justified-truth model. | NOT DOCUMENTED AS CORE — Official docs span durable execution, unknown Effects, evidence and reconciliation; authorization is separate and the full chain is not documented as one model. |
Truth EngineTap to view capabilities
Durable consequential-action execution and recovery are part of the public model.
Recovery preserves execution history and does not manufacture authority.
Retry is governed by retained execution state and retry authority rather than blind repetition.
Ambiguous external effects are represented directly rather than collapsed into success/failure.
UNKNOWN is one of exactly three public truth states.
Retry request does not itself grant retry authority; uncertain effects are not resent blindly.
Retry intent and retry authority are separate public concepts.
Reconciliation performs read-only observation and does not itself create another effect.
Immutable occurrence history is a distinct part of the public authority-to-truth chain.
Evidence is an explicit layer distinct from occurrence, proof and current truth.
Proof and admissibility are explicit, separate stages in the public chain.
SATISFIED, NOT_SATISFIED and UNKNOWN are current justified truth states.
Authority is explicitly upstream of permitted execution and retry.
The public model explicitly spans authority, release/attempt, occurrence, evidence, proof, admissibility and current justified truth.
TemporalTap to view capabilities
Workflow Execution, Event History, Activities and replay are first-class Temporal concepts.
Event History survives Worker/process failure and Workflow code replays from durable history.
Retry Policies are first-class for Activities and Workflow runs.
Temporal documents the crash window where an Activity side effect may finish before completion is recorded, but not a first-class external-outcome object.
The reviewed docs expose Activity task/event states and failures, not an explicit provider-effect UNKNOWN state.
Retry Policies can disable retry and docs emphasize Activity idempotence for the crash-before-completion edge case.
Retry policy/attempt configuration is documented; a separate retry-authority abstraction was not found in the reviewed docs.
Applications can query external systems from Activities, but provider reconciliation is not documented as a Temporal core abstraction.
Event History durably records Temporal Activity lifecycle/results, not independently verified provider occurrence.
Event History is a durable audit/execution record, but provider evidence is not a distinct core abstraction in the reviewed docs.
No proof/admissibility abstraction was found in the reviewed Temporal docs.
Temporal exposes workflow/activity execution state, not a separate current-justified-truth abstraction.
Application/business authorization is outside the reviewed Workflow/Activity execution model.
The reviewed docs center durable workflow/activity execution and history rather than this full chain.
DBOSTap to view capabilities
Durable workflows and checkpointed steps are the core execution model.
Interrupted workflows recover from the last completed step.
Steps support configured retries and workflow recovery re-attempts unfinished steps.
DBOS documents the window where a step side effect may occur before checkpoint and the step may run again.
The reviewed docs expose workflow/step execution state, not an explicit ambiguous-effect state.
External steps may execute at least once; docs require such steps to be safe/idempotent across retries.
Retries and recovery are documented without a separate retry-authority abstraction.
External readback can be implemented as application steps; no dedicated reconciliation abstraction was found.
Step outputs/checkpoints are durable execution records; they are not documented as external-provider occurrence records.
The reviewed DBOS docs describe checkpoints/results rather than a separate evidence model.
No proof/admissibility abstraction was found in the reviewed DBOS docs.
DBOS exposes workflow/step status, not a separate current-justified-truth abstraction.
Business/action authorization is left to the application around DBOS workflows and steps.
The reviewed docs center durable workflows, steps, transactions and recovery rather than this full chain.
AWS Durable ExecutionTap to view capabilities
Lambda durable functions use durable operations, checkpoints and replay.
Checkpoint/replay resumes durable functions after interruption.
Steps have checkpointed retry strategies and durable retry state.
At-most-once step semantics surface StepInterrupted when execution may have started but no terminal checkpoint exists.
StepInterrupted represents interrupted at-most-once work, but the docs do not define a general UNKNOWN effect state.
AtMostOncePerRetry plus a no-retry strategy is explicitly documented for non-idempotent external side effects.
Retry strategy and step semantics are documented without a separate retry-authority abstraction.
AWS instructs code catching StepInterrupted to check the external system before deciding how to proceed.
Checkpoints record durable operation state/results, but are not an explicit provider-occurrence record.
Checkpointed results/history provide execution records, but a separate evidence abstraction was not found.
No proof/admissibility abstraction was found in the reviewed AWS Durable Execution docs.
Durable executions expose operation/execution state, not a separate current-justified-truth abstraction.
AWS IAM controls service access; business authority for a consequential external action remains application logic.
The reviewed docs center checkpoints, step semantics, retries and resumable execution rather than this full chain.
AbsoluteJSTap to view capabilities
Execution provides crash-safe external-effect execution; the wider agent stack adds durable runtime concerns.
Transactional outbox, attempt history and reconciliation/recovery surfaces are documented as crash-safe.
Execution owns retries around durable effects and only re-enables effect retry after safe resolution.
UnknownEffectOutcomeError moves provider ambiguity into a durable unknown/quarantined effect state.
Unknown provider outcomes are quarantined until resolved.
Unknown provider outcomes are quarantined; retry is permitted only after resolution establishes that the effect was not applied.
Agency authorization/execution leases and effect recovery controls separate permission to execute from a request to act again.
Query/webhook/operator reconciliation and provider-query runtime are documented first-class surfaces.
Effect store retains attempt history, normalized results, provider references and reconciliation state.
Execution includes explicit effect-evidence records/ingestion and normalized evidence boundaries.
AbsoluteJS documents evidence/certification controls, but not proof/admissibility as the action-outcome truth model used here.
Effect state can move from unknown to terminal after evidence/reconciliation, but the docs do not frame this as a general justified-truth layer.
Agency owns exact action authorization, approvals, execution leases and receipts before Execution performs effects.
Official docs span Agency authorization, Execution uncertainty/reconciliation and evidence, but not one explicit authority→admissibility→justified-truth model.
CruxTap to view capabilities
The optional Runtime Engine makes flows/background work durable; Effects can be persisted with a Runtime store.
Runtime stores reconstruct durable work and Effect recovery state after process loss.
Runtime-backed work retries durably; Effect retry policy remains a separate concern by design.
EffectOutcomeUnknownError and unknown receipts explicitly represent provider ambiguity.
Receipts can remain unknown/ambiguous until reconciled from external evidence.
Unknown Effects wait for external evidence; crash reconstruction does not silently retry ambiguous work.
Effects explicitly do not own authorization; application/runtime policy must authorize retry or recovery actions.
reconcileEffect() is native; the confirming provider lookup/evidence collection is supplied by the application/operator.
Durable Effect receipts/attempts survive restarts with a configured Runtime Effects store.
Crux documents Effect receipt evidence, execution evidence and reconciliation audit metadata.
Crux documents evidence/reconciliation, but not proof/admissibility as explicit effect-truth stages.
Receipts settle unknown outcomes after external evidence, but the docs do not define a general current-justified-truth layer.
Crux explicitly states Effects/Work identifiers are not authorization and callers must authorize application requests.
Official docs span durable execution, unknown Effects, evidence and reconciliation; authorization is separate and the full chain is not documented as one model.
CLOSE COMPARISON POINTS
Uncertainty is not exclusive to Truth Engine.
Its Execution package explicitly quarantines unknown provider outcomes, supports provider-query/webhook/operator reconciliation, and pairs with Agency authorization and execution leases.
Its Effects model explicitly records unknown outcomes, waits for external evidence, reconciles receipts, and preserves ambiguous crash windows without silent re-execution. Authorization remains separate from the Effect abstraction.
At-most-once step semantics can surface an interrupted side-effecting step without re-running it. AWS then tells application code to inspect the external system before deciding what to do next.
Both are strong durable-execution systems. Their official docs also describe side-effect crash windows and retry/idempotency behavior, but the reviewed docs do not frame those concerns as the same explicit authority → evidence → admissibility → justified-truth chain.
TRUTH ENGINE'S FOCUS
End-to-end across the authority-to-truth chain.
Truth Engine is explicitly organized around what was authorized, what may have been released or attempted, what occurrence history exists, what evidence is available, what is admissible, and what the system may safely claim now.
This is a scope statement, not a claim that other systems cannot implement adjacent controls or application-specific equivalents.
METHODOLOGY
Documentation comparison, not performance benchmarking.
This comparison is based on publicly documented capabilities and product abstractions, not performance benchmarking. Products evolve; classifications describe the cited documentation reviewed for this page.
Temporal
AWS Durable Execution
AbsoluteJS
EVALUATE FOR YOURSELF
Run the difficult case.
See UNKNOWN, retry refusal and reconciliation in the real engine-backed Playground.