Design Discussion: Immutable Audit Logs and Rollback Strategy for Write Operations

[PrzemyslawKlys]

Context

For regulated/enterprise scenarios, execution visibility is not enough—we need strong audit guarantees and practical rollback capability for write operations.

Current logging is useful, but we should define a formal model for:

• immutable/append-only evidence
• operation identity and traceability
• connector-specific rollback contracts

Problem

As write support expands, risks include:

• non-repudiation gaps in logs
• limited forensic trust in local mutable storage
• inconsistent or missing rollback paths across connectors

Goal

Design a write-operation model with:

1. Immutable audit trail (append-only / tamper-evident)
2. Operation contract (who/what/when/why/target/before-after)
3. Rollback semantics defined per connector/action
4. Approval and policy gates for high-risk writes
5. Evidence bundle export for compliance reviews

Key Design Elements

1) Operation envelope

• operationId, actor, correlationId
• intent + parameters hash
• target identity
• policy decision snapshot

2) Tamper-evident logging

• append-only store
• hash chaining (record N includes hash of N-1)
• optional timestamp/signature anchoring

3) Write lifecycle states

• planned -> validated -> approved (optional) -> executed -> verified -> closed
• explicit failure and compensation states

4) Rollback contract per connector

• canRollback
• rollback method type (inverse op / snapshot restore / partial compensate)
• rollback window + limitations

5) Dry-run equivalence

• same validation and policy path as real run
• only side-effect commit step omitted

Option Space

Option A: SQLite + hash chain (fast MVP)

• Pros: quick adoption
• Cons: local trust boundary

Option B: Central SQL store + append-only discipline

• Pros: better central governance/reporting
• Cons: infra dependency

Option C: WORM/object storage + signed manifests

• Pros: strongest immutability posture
• Cons: most operational complexity

Suggested Phased Plan

Phase 1 (MVP)

• operation envelope for all writes
• hash-chained append-only log records
• capability matrix: supportsDryRun / supportsRollback

Phase 2

• connector rollback adapters
• approval gates for sensitive operations
• evidence bundle generation

Phase 3

• centralized immutable backend
• retention, legal hold, and compliance reporting profiles

Open Questions

1. What compliance baseline are we targeting first (SOC2-like, ISO, internal only)?
2. Is rollback mandatory for every write, or only high-impact categories?
3. How do we handle irreversible actions (compensation-only)?
4. Which events must be signed/timestamp-anchored from day one?
5. What is the minimal viable approval model?

Success Criteria

• traceable, tamper-evident write history
• clear rollback/compensation behavior per connector
• policy-driven approvals for sensitive actions
• auditable evidence suitable for enterprise review