Durable execution
needs a time machine.
Temporal.io guarantees your workflows complete. XTDB guarantees you can prove what they consumed. Together, they close the audit gap that neither can close alone.
Compliance requires both. The Event History tells you which Activity ran and what it returned. The bitemporal record tells you whether what it read was later corrected — and when.
Your angle
The forecast that was right, then wrong, then right again.
A large retailer files a Q4 revenue forecast on October 15th. A churn prediction model scores the enterprise account base. The CFO certifies under SOX 302. The number goes to the SEC. Over the following week, four domain teams independently correct their data. On November 1st, an auditor arrives.
as medium risk
and billing all correct data
higher than forecast
Each question requires distinguishing two different kinds of "when": when the fact was true, and when the system learned about it. Most databases can only answer one. A bitemporal database answers both.
Two kinds of time, two independent axes.
The support team corrects a ticket count from 3 to 8, asserting it was 8 as of Oct 15. That business date is the valid time — when the fact was actually true, regardless of when you learned it.
The correction is entered on Oct 20. That's the system time — the moment your organisation's records changed. Both the original value (3) and the correction (8) coexist, differentiated by system time.
Both rows are preserved. FOR SYSTEM_TIME AS OF '2025-10-15' returns 3.
The same query without that clause returns 8.
Reconciliation is additive — it never destroys the pre-correction state.
Three questions, three queries.
Via XTDB's PostgreSQL wire protocol. No custom language. No separate audit database.
-- Reconstruct exact data state at decision time
SELECT support_tickets, logins, feature_usage_score, failed_payments
FROM customers
FOR VALID_TIME AS OF DATE '2025-10-15'
FOR SYSTEM_TIME AS OF TIMESTAMP '2025-10-15T23:59:59Z'
WHERE _id = 'CUST-8472'-- Same business date, all corrections now applied
SELECT support_tickets, logins, feature_usage_score, failed_payments
FROM customers
FOR VALID_TIME AS OF DATE '2025-10-15'
WHERE _id = 'CUST-8472'-- Every version and exactly when each was recorded
SELECT support_tickets, _system_from AS recorded_at
FROM customers FOR ALL SYSTEM_TIME
WHERE _id = 'CUST-8472'
ORDER BY _system_from;Three things go wrong. You need to tell them apart.
When an AI-driven forecast misses, there are three distinct failure modes. Untangling them is the core audit challenge.
Usage metrics inflated by bots. Ticket counts truncated by a sync gap. Payment failures dropped by a batch import. The model consumed bad inputs and produced a reasonable-looking score from unreasonable data.
Stale coefficients, unrepresentative training data, or a bug in the scoring formula. Bad logic even on correct inputs. Both the original and corrected predictions need to be preserved separately.
Reading from the wrong table. Applying a filter incorrectly. Skipping a step. The data and the model were both fine — the wiring between them was wrong. Only the execution trace can show this.
Temporal's Event History tells you what the model was given. XTDB's bitemporal view tells you whether what it was given was right, and when the organisation first learned otherwise. A Temporal Workflow can replay scoring logic against corrected XTDB data, compare with the original prediction, and produce a materiality report — durably executed, with every step recorded in the Event History. The three failure modes are cleanly separated.
Two systems. One clean seam.
No CDC pipeline. No event bus. No ETL. Temporal Activities read from and write to XTDB over the standard PostgreSQL wire protocol.
- › Correction Workflows run to completion — no silent partial writes
- › Event History: every Activity, its inputs, its outputs, its timestamp
- › Deterministic replay — re-execute Workflow logic against corrected data
- › Workflow ID written alongside XTDB rows — execution provenance preserved
- › Every write auto-versioned on valid time and system time — zero config
- › Corrections are additive — the pre-correction state is never destroyed
- › Standard PostgreSQL wire protocol — works with any Postgres client
- › Cross-domain temporal joins — query across team boundaries at any historical point
workflow_id
The join key. Each Activity writes its Temporal Workflow ID alongside the XTDB rows it produces.
Look up any Workflow run, find its execution timestamp, and query XTDB for the exact data environment that existed at that moment.
What you already have. What XTDB adds.
- ✓ Durable Workflow execution — no silent failures
- ✓ Event History for every run (30–90 day retention)
- ✓ Workflow History Export to S3/GCS for long-term archiving
- ✓ Audit Logs for control-plane operations (Kinesis / Pub/Sub)
- ✓ Deterministic replay — same inputs, same outputs
Your Event History records that an Activity returned support_tickets: 3.
It cannot tell you that the value was later corrected to 8, when that correction happened, or whether the correction was material to the Workflow's outcome.
The Event History captures a snapshot frozen at execution time. It has no view of the correction timeline that follows. Temporal records what the system did. It cannot record what the data became.
Point your Temporal Activities at XTDB via the standard PostgreSQL wire protocol — using whatever pg client you already use.
Every table is automatically bitemporally versioned. No triggers, no CDC, no history tables.
Write the Workflow ID as a column alongside each row your Activities produce. Now any XTDB record traces back to the Workflow Execution that wrote it, and any Workflow can be replayed against the exact data environment that existed when it ran.
Your correction workflows need durable execution.
XTDB makes corrections additive — the pre-correction state is never destroyed. But the process that writes those corrections needs its own guarantee: that it completes reliably, even when the ServiceNow API times out or the ERP batch job crashes halfway through.
A Temporal Workflow that reconciles payment records either completes fully or retries from the last successful Activity. Half-corrected records are not possible.
When a ServiceNow Activity times out, Temporal retries it. The failure, retry, and eventual success are all in the Event History. Nothing drops silently.
Write the Workflow ID alongside every corrected row in XTDB. Any data row is now traceable to the specific Workflow run — and the person or system — that produced it.
Temporal's deterministic replay, combined with XTDB's time-travel queries, lets you re-score any historical decision against corrected data — automatically, on demand.
Replace audit sprawl with two systems.
Without a dedicated solution, organisations typically assemble audit capability from six moving parts:
Each component works individually. The joins between them are where evidence gets lost — timestamps that don't align across systems, snapshots taken at the wrong moment, correction histories living in spreadsheets or Jira tickets rather than in the data layer itself.
The regulatory thread.
The same structural requirement — decisions made on data that was later corrected — appears across every major framework governing AI in regulated industries.
CEOs and CFOs certify the accuracy of financial reports. When a forecast is built on AI-driven predictions, the data feeding those predictions is part of the internal control environment. Material corrections must be identified and disclosed.
Reconstruct the exact data state at filing time via bitemporal queries. Identify when corrections were first recorded (system time). Demonstrate completion and integrity of the correction process via Temporal Event History.
High-risk AI systems must maintain logs that allow reconstruction of behaviour throughout the lifecycle. For financial applications, input data — not just output decisions — must be traceable. Agentic systems that take autonomous actions fall squarely into the high-risk category.
Full input data lineage via XTDB bitemporal history. Full execution trace via Temporal Event History. Both independently queryable, independently auditable, and composable via the Workflow ID join.
Model risk management requires back-testing that distinguishes whether prediction errors stem from model deficiency, data deficiency, or both. Each source of error must be separately attributable.
Bitemporality separates data corrections from model corrections in the same timeline. Temporal deterministic replay automates comparison across all three failure modes — data, model, and orchestration — on demand.
Banks must aggregate risk data accurately with full lineage, and explicitly reconstruct risk positions as of specific dates. Lineage must extend to source systems.
FOR VALID_TIME AS OF and FOR SYSTEM_TIME AS OF map directly to the BCBS 239 reconstruction requirement in standard SQL. Temporal Workflow IDs provide the lineage chain to source systems.
Get started.
XTDB is open source (MPL-2.0) and runs via Docker, exposing a PostgreSQL wire-compatible endpoint. Any Temporal Activity that already reads from Postgres can write to XTDB with a one-line connection string change.
docker run -p 5432:5432 ghcr.io/xtdb/xtdb