dot-iu-cutter v0.5 — Leg-B Rollback / Compensation Status

doc 6 of 7 · 2026-05-20 · M1 macro

rollback_required        : NO
compensation_required    : NO
reason                   : COMMIT succeeded ; all 126 inserts atomic ;
                           G6 verification PASS ; no unintended mutation

1. Why no rollback / compensation is needed

atomicity :
  · The recorder executes all 126 inserts inside a single caller-owned
    transaction. The runner wraps record() in BEGIN → recorder.record →
    COMMIT (or ROLLBACK on exception in the same except clause).
  · COMMIT returned no error ; psycopg2 returned the row counts the
    recorder expected ; no SQL produced any abortive condition.
  · Pre-COMMIT smoke (rollback-only-smoke) had previously exercised the
    same exact INSERT path against the same exact live constraints (NOT
    NULL / UNIQUE / CHECK) and DB state stayed byte-identical after
    ROLLBACK — i.e. the constraint-pass was empirically demonstrated
    before any durable write.

verification :
  · G6 (doc 5) confirms every cross-reference resolves correctly.
  · No row outside the leg-B scope was modified.
  · No deploy / restart / merge happened.

2. If a future macro needs to compensate this leg-B

preferred path (sovereign-gated ; NOT this macro) :
  · A subsequent governance event SHOULD be recorded as a FORWARD
    compensation row, never as a hard-delete.
  · cut_change_set has rollback_reason + rollback_initiated_by columns
    designed for this. To roll back :
      UPDATE cutter_governance.cut_change_set
         SET state                = 'rolled_back',
             rolled_back_at        = now(),
             rollback_reason       = '<sovereign-authored reason>',
             rollback_initiated_by = '<approver-id>'
       WHERE change_set_id        = '456c6830-a747-4b53-ac2f-665e25e12cd0';
  · This is an UPDATE on a column with NOT NULL constraints already
    satisfied ; no INSERT/DELETE.
  · The compensation step itself should be recorded as a follow-up
    cut_change_set row referencing this one via prior_change_set_id-style
    lineage (no such column exists in current schema ; payload_summary +
    review_decision are the lineage-bearing slots).

hard-delete : FORBIDDEN (per the original prompt's "no hard-delete" rule).

3. Idempotency_key as future-rerun safeguard (G-LEG-B-ONCE)

recorded_idempotency_key :
  ick:canonical:constitution-first:
    d99a31d4a4be907c510ae15965e9f7bb3387e9e28676e9f32adf463828b1aa28

cut_change_set.idempotency_key UNIQUE : YES (PRIMARY UNIQUE in schema)

future_invocation_behavior :
  · Re-running the runner against the same canonical CUT will hit the
    G-LEG-B-ONCE pre-write probe (`SELECT count(*) … WHERE idempotency_key
    = <ick>`) returning ≥ 1 → recorder raises LegBAlreadyRecorded → no
    SQL writes attempted.
  · Even if the pre-write probe were bypassed, the INSERT itself would
    fail with unique_violation on the cut_change_set.idempotency_key
    UNIQUE constraint → whole txn rolls back → no partial write.

4. Disposition

status                            : NO ROLLBACK / NO COMPENSATION REQUIRED
prod_mutation_this_phase          : NONE (read-only)
follow_up                         : a future write-VERIFY macro will INSERT
                                    into cutter_governance.verify_result
                                    with change_set_id =
                                    456c6830-a747-4b53-ac2f-665e25e12cd0
                                    and a DOT-992 verifier signature.

doc 6 of 7.