What this sheet teaches. Every logical transaction or balance whose append-only
entrycolumn has been rewritten — the audit trail for corrected postings and balance re-statements. These systems admit revision-and-audit rather than deletion-and-rewrite, so the trail records exactly what changed and why.
The sheet opens on a strip of three KPIs across the top — Logical Keys (Transactions) with Supersession (count of distinct transaction logical keys with more than one entry), Supersession $ Exposure (the dollar magnitude of the audit surface), and Supersession Rows with No Reason (higher-entry rows whose supersedes reason is blank, target = 0). Below the strip sit two side-by-side tables: Transactions Audit (every entry of every logical transaction with multiple versions) and Daily Balances Audit (every version of every account-day cell that was re-stated). A row of controls above the tables lets you filter the transactions audit by supersedes reason, narrow to a single transaction via the Transaction ID picker or isolate the no-reason rows.
Both tables read from the BASE tables — <prefix>_transactions and <prefix>_daily_balances — not the Current views, because the whole point is to audit the prior entries that Current hides by design.
Transactions Audit table:
Reads from <prefix>_transactions filtered to logical rows (keyed by id, which becomes transaction_id in the dataset) where COUNT(*) OVER (PARTITION BY id) > 1. Each row carries:
entry — the append-only version number; higher entries supersede lower onestransaction_id — the logical transaction ID (immutable identifier for the entry chain)supersedes — the reason why this entry exists: Inflight (a pending leg was updated during bundling), BundleAssignment (a posted leg was assigned a bundle_id) or TechnicalCorrection (a correction to a prior error). NULL on entry-1 rows (no reason needed for the first entry)account_id, account_name, transfer_id, rail_name, amount_money (in dollars), amount_direction, status, posting, bundle_id — the standard transaction metadataThe l1_supersession_no_reason derived column flags each higher-entry row where supersedes IS NULL, which the right-hand KPI counts (target = 0 per the L1 (account-integrity) SPEC).
Daily Balances Audit table:
Reads from <prefix>_daily_balances filtered to logical keys (keyed by account_id, business_day_start) where COUNT(*) OVER (PARTITION BY account_id, business_day_start) > 1. Each row carries:
entry — append-only version numberaccount_id, account_name, account_role (account-role — semantic label grouping accounts by what they do) — account identitysupersedes — reason for restatement; for daily balances, this is typically TechnicalCorrection only (no bundling lifecycle on balance snapshots)business_day_start, business_day_end — the calendar day this balance covers (per account timezone)money — the stated balance in dollars; the primary thing that changes across entries is this columnKPI semantics:
transaction_id values (not row count). One logical transaction can have N entries; the left KPI answers "how many distinct transactions got revised?"SUM(|amount_money|) across all superseded transaction entries — the dollar magnitude of the audit surfacesupersedes IS NULL (not distinct transactions). A single transaction_id can have multiple no-reason rows if multiple entries lack a reason; the right KPI counts ROWS, not keys, so the unit differs from the left KPIThe Transactions Audit table, filtered by supersedes = 'TechnicalCorrection', shows many rows. These are corrections to prior errors — either posting mistakes the ledger system caught and fixed, or feed-level bugs that the ETL layer rewrote. If the volume is large and clustered on recent postings, loop the upstream feed team in immediately; this is a symptom of a feed integration bug. If it's spread thinly over time, it's normal operational noise.
Filtering by supersedes = 'Inflight' shows entries with posting dates near the same day, all in Pending or Posted status, all on the same rail. This is normal in a busy aggregating-rail bundling cadence — a pending leg fires, the rail bundles it into a clearing-house batch, and emits a higher-entry row with supersedes = 'Inflight' to mark the mid-flight update. No action needed unless the Pending age cap (rail-specific; check the rail's max_pending_age config) is being violated.
Rows with supersedes = 'BundleAssignment' are the bundler's marking up of a Posted leg with a bundle_id. This is expected on aggregating rails (ACH, wire, check clearing) and abnormal on direct rails (on-us internal transfers). If you see high BundleAssignment volume on a non-aggregating rail, check the rail's bundler configuration — the rail shouldn't be trying to bundle.
The Daily Balances Audit table has multiple entries for the same account-day, and the money column values differ. This is a re-statement of the account's end-of-day balance. If the supersedes reason is TechnicalCorrection, the institution caught a prior balance-reporting error and corrected it. If supersedes is NULL (blank), that's a data-quality violation — the system rewrote a balance without recording why. Cross to the Drift sheet (Drift) with the same account filter to see whether this balance restatement correlates with a drift-resolution.
The right KPI, Supersession Rows with No Reason, counts higher-entry rows where supersedes IS NULL. This is a violation of the L1 SPEC — every rewrite should declare its cause. Drill into the Transactions Audit table and filter by the (blank) supersedes value; each row in the result set is a row that lacks a reason and needs investigation. Either the upstream feed forgot to set the reason (ETL writer bug), or the reason got lost in a system-to-system handoff (integration gap). Either way, this is a non-zero target and a remediation flag.
A clean supersession sheet — zero rows in both audit tables — means every logical transaction and balance revision did NOT happen in the current window, OR the matview (materialized-view) is stale. To distinguish:
<prefix>_transactions and <prefix>_daily_balances tables (not a matview), so it's their row_count and latest_date columns that tell you whether fresh data has loaded since you opened the dashboard.supersedes dropdown is set to a specific reason (not "All"), you may see zero rows for that reason even though other reasons exist. Click the dropdown and reset to "All" to see the full audit trail.If App Info shows latest_date as null or the row counts as zero across the board, the ETL load didn't run. That's an ops alert, not a "clean" signal.
You usually land here from another sheet (notably Drift, Drift) and read the trail to understand what changed and why. Three row-level drills let you trace further:
No known rendering quirks on this sheet.
First time here? See the Vocabulary for L1, matview, account_role, carry-forward, and other project-specific terms.