Change one record and the chain breaks. That includes us.
Every live decision is hash-chained, and a signed checkpoint of that chain is held outside the deployment: by your own archive, an auditor or a counterparty. Edit a decision afterwards, or roll the whole database back to an earlier copy, and the records stop matching the checkpoint they hold. Swiftward runs on your hardware and we never receive a copy of the records, so we could not edit them either.
Built into the Swiftward service you run.
What one decision looks like
event_id evt_01J9Z4T2K8 event_type transfer_intent entity_id wallet_7f31c2 verdict rejected winning_rule daily_volume_exceeded matched_rules_count 3 signals.day_total_after_this 51420.00 signals.sanctions_hit false ruleset_code web3-wallet ruleset_version_code v7 (frozen) finished_at 2026-07-14T09:22:41Z duration_ms 20 chain_key web3-wallet prev_record_hash sha256:4f2a...c118 record_hash sha256:9d07...ab63 leaf_index 2841
winning_rulenames the rule that decided, so "why was this blocked?" is answered with a rule name.matched_rules_countshows that three rules matched this event and one of them decided.ruleset_version_codepoints at a frozen version, which cannot be changed, so the rules behind this decision are the rules you can read today.
Three records, and the question each one answers
| Question | Record |
|---|---|
| Who did what? | the operations audit — every operation, the caller behind it, what it touched |
| What changed in the data? | the changes audit — the row before and after, so an overwritten value is recoverable |
| What was decided? | the decision record above, one per evaluated event |
A reviewer's decision is recorded against the case, with the person and their note. If your deployment sends that decision back through the engine, it lands as its own event with its own record.
Where the records go
A rule sends a decision to your SIEM over syslog in RFC 5424, or to anything else over a webhook. The records stay in your own databases: Postgres, and ClickHouse for the archive.
You choose what is tamper-evident
Tamper-evidence is switched on per table. It covers a row from the moment the row stops changing.
Four kinds of record have it out of the box: the operations audit, the changes audit, decision records on live traffic (nobody needs to prove a backtest), and review cases once they are decided. After a reviewer decides a case, the application refuses any further edit to it, and an edit made directly in the database is detected.
You can switch it on for any other table, ours or your own. You write the condition for when a row stops changing, for example when an order has settled.
Proof your auditor checks without us
The checkpoint is a Merkle root over everything recorded for one tenant, signed at a set interval. It is small enough to send in an email, and it carries none of your data.
The signing key is yours. The private key stays in your environment, outside the database. You give the public key to your auditor, and they verify the checkpoint without us.
Verification runs over the records and the period you choose. It tells a record deleted under your retention periods apart from a record missing for any other reason.