Live Verification Cleanup Automation: The Checker Was Creating What It Audits For

When one database table refers to a row in another by its identifier, the reference has to specify what happens if the referenced row is later deleted: cascade the deletion to every dependent row, block the deletion outright while any dependent row still exists, or sever the link by setting the dependent row's own reference to null while leaving the dependent row itself standing. Each choice is correct for a real, different situation — setting a reference to null on delete is often exactly right for a genuinely optional relationship, where the dependent row should clearly keep existing and simply lose one specific piece of context. The same choice becomes a liability the moment code elsewhere in the system assumes deleting the REFERENCED row is enough to clean up EVERYTHING connected to it — because the database will not raise any error, will not block anything, and will not warn that a dependent row is still sitting there, now permanently disconnected from the very thing that produced it.

A cleanup routine's own mental model of what it needs to remove is built from what it explicitly created and can explicitly name — the specific request, the specific response, the specific set of records it constructed step by step. A database trigger firing automatically in response to that activity, writing a row into a completely different table the cleanup script's own author may not have been thinking about at the moment cleanup logic was written, falls outside that mental model entirely — not because it was forgotten through carelessness, but because a trigger's side effect is, by design, not something the code that caused it necessarily has direct, obvious visibility into. The gap is not a missing DELETE statement so much as a missing AWARENESS that a DELETE statement was ever needed in the first place.

Centriu TrustOps's Gateway verification script runs directly against the live production Gateway, tagging every record it creates with a distinctive, recognizable prefix in its idempotency key specifically so its own later cleanup pass can find and remove exactly those records, and nothing else. The cleanup pass, before this fix, deleted the request, the response, the usage event, the credential, the model, the price and the vendor rows carrying that prefix, in that order, and reported success once every one of those specific deletions was confirmed.

The gap was a row the cleanup pass never directly created at all: a database trigger fires automatically on every Gateway response — verification traffic included — writing a financial cost event into TrustOps's own ledger. That cost event's foreign key back to the originating request was deliberately configured to set itself to null on delete, rather than to cascade the deletion, because for GENUINE production traffic, a cost event should absolutely survive the eventual archival or deletion of its originating request record; the cost itself remains real financial history regardless. That same design choice, applied uniformly, meant the verification script's own synthetic request could be deleted cleanly while the cost event it had triggered stayed behind indefinitely, now pointing at nothing.

The fix adds exactly one additional deletion, placed deliberately FIRST in the cleanup sequence, before the request rows it depends on are removed: deleting every cost event whose gateway-request reference still points to one of the verification script's own tagged, still-identifiable request rows. Ordering matters specifically because of the null-on-delete behavior already in place — once a request row is gone, the one remaining thread connecting an orphaned cost event back to "this came from a verification run" is already severed, and there is no longer any reliable way to distinguish a verifier's own leftover synthetic row from a genuine customer transaction. Removing the cost event while that connection is still intact is the only point at which the distinction can still be made safely.

The nine cost events that had already accumulated in production before this fix were deliberately left untouched by this same commit. Centriu TrustOps's own reasoning, preserved directly in the fix's own commit message, treats deleting an already-existing row in a real client organization's financial ledger as an operational decision that belongs to whoever operates that organization's account — not a decision an auditing or verification script gets to make unilaterally, however confident it might be about which rows are synthetic. Those nine rows were instead left for review through TrustOps's own existing integration-review queue, the same path any other reconciliation finding already goes through.

Before the fix, returning a rented car and closing out every charge tied to the rental directly — the deposit, the fuel, the mileage — still left one separate, automatically-triggered toll charge sitting on the account indefinitely, because the toll record's own link back to "which specific rental generated this" had already been cleared the moment the rental record itself was closed, with nothing else ever cross-checking for that specific kind of leftover charge. After the fix, the toll charge is settled BEFORE the rental record is closed out — at the one point where it can still be clearly tied back to the rental that generated it — so nothing is left standing once the return is complete.

Centriu TrustOps's own live-production Gateway verification no longer leaves an orphaned financial ledger row behind after each run, closing a gap where a foreign key's own correct, intentional null-on-delete behavior had been silently outliving the synthetic record it was meant to help clean up — with the fix visible in its own effect: nine pre-existing rows flagged for operator review, zero new ones created by any run since.

This automation covers specifically how Centriu TrustOps's own internal verification tooling cleans up after testing the live Gateway pipeline. It is a distinct concern from this pillar's separate pages on the Gateway pipeline's own runtime cost-tracking and idempotency behavior for genuine customer traffic — this page is about the TEST SCRIPT's own hygiene, not about how a real customer's cost is calculated or recorded in the first place.

Deleting every record a cleanup routine can explicitly name and directly created is the natural, obvious first version of any such script, and it correctly removes the overwhelming majority of what testing against a live system actually leaves behind. It systematically misses anything created as an automatic SIDE EFFECT of that activity rather than as a direct action the script itself performed — a database trigger's own write being the clearest example. Tracing a test run's full footprint by asking "what does this ACTIVITY cause, not just what does this SCRIPT directly do" is the only version of the two that reliably catches both.