Check evidence against an independent ledger
An optional verified ledger adds an integrity check beside the application’s audit store. Wildo can send events to immudb, retain a verification anchor and reconcile missed writes using the same event identities.
Example — Check evidence against an independent ledger
An operator investigates a disputed record using its matching event in the ledger. Verification checks the ledger history against its recorded anchor instead of relying only on application permissions.
For engineers
Wonder Todos enables EngineCapability.COMPLIANCE_AUDIT_TRAIL and declares this provider in its backend provider scope:
Selected source from wildo.saas.config.ts:
immudb: {
engineCapabilities: [EngineCapability.COMPLIANCE_AUDIT_TRAIL],
providerCapabilities: ['COMPLIANCE_AUDIT_TRAIL'],
protocols: [],
},
This is a selected provider entry from wildo.saas.config.ts. Provision the immudb backing service and signing material, synchronize provider/runtime configuration and start the responsible backend runtime. The composite sink resolves the declared provider; capability enablement alone is not a connection.
Preserve a stable verification basis
The verified client checks cryptographic proofs and maintains a durable anchor. Retain that anchor across restarts so verification can compare history over time. A proven integrity failure, an unusable verification configuration and degraded assurance have different diagnostics and should drive different operational responses.
Provider failure is isolated from the primary audit write and from other sinks. Monitor the destination’s state as well as the application’s health.
Reconcile using the primary trail
The scheduled reconciler replays events by eventId. Its cursor combines creation time with the event identity, so several events sharing a timestamp are not skipped. Repeated writes are idempotent at the sink.
This gives the operator a recovery path for missed inline deliveries while the authoritative records remain available. It is not a blanket guarantee that every direct database alteration is automatically discovered: use the ledger’s proofs, reconciliation outcomes and retained anchors together when checking a particular event or interval.
Provision the verifier separately from the server
| Setting | Provision on the emitting runtime | What it establishes |
|---|---|---|
IMMUDB_STATE_DIR | An absolute, access-protected path backed by durable storage; mount that same storage after restart | Continuity with the last verified root; an ephemeral directory loses cross-restart rollback detection |
IMMUDB_STATE_PUBLIC_KEY | The trusted server signing public key, SPKI PEM, ECDSA P-256 | State-signature verification; the server must use its matching private signing key via --signingKey |
IMMUDB_EXPECTED_SERVER_UUID | The expected stable server UUID, where known | Detects accidental replacement; a server-asserted UUID does not replace the cryptographic public-key pin |
These provider secret-contract entries feed stateDir, statePublicKeyPem and expectedServerUuid in the verified client. Supply them through the provider configuration channel; never put the server’s private signing key into the verifier. A local example path for the state directory is /application/.wildo-saas/local_data/immudb-verifier; a container must mount durable storage there.
Once the sink is configured, an application-side verification caller can inspect an individual event. Usage excerpt with the already-resolved sink and event identity:
const verification = await sink.verifyAuditEvent(eventId);
const { verified, status, detail } = verification;
The result distinguishes Verified, Absent, Tampered and Unverifiable. Inspect the status and diagnostic together: successful inclusion of one event does not prove that every expected event was delivered. Check durable-state and signature-pinning diagnostics as well; a successful read with those protections absent establishes less than a pinned, continuous history.