What this sheet teaches. Chain completion status — whether every declared child of a parent transfer fired when it should have. Each row on this sheet is one parent transfer instance; Completed means all Required children appeared and XOR groups honored their cardinality; Incomplete means at least one Required child is missing or an XOR group was orphaned / duplicated.
The sheet opens on a filter bar with six controls — Date From and Date To to scope by posting date, Chain (single-select dropdown) to narrow by declared parent rail / template name, Completion (single-select dropdown) to show Completed / Incomplete status, Metadata Key (single-select dropdown) and Metadata Value (free-text input) for cascading metadata filtering. Below the filters sits a single table: Chain Instances, one row per parent transfer firing. Each row reports the parent's posted date, declared chain name, transfer ID, completion status, the count of Required children that fired and the count declared, the parent amount in dollars and the parent leg's status.
The table reads from the l2ft-chain-instances dataset, which joins the L2 (flow-tracing)'s declared chain topology to runtime parent firing counts and matched-child detection. Each row represents one distinct parent_transfer_id — a single parent transfer that fired and triggered child chains as follow-ons.
The columns on the table:
parent_posting — the business date the parent leg postedparent_chain_name — the L2-declared parent rail or transfer template nameparent_transfer_id — the unique transfer ID of the parent firingcompletion_status — one of:required_fired / required_total — two Required Children columns. required_total is the count of Required child chains the L2 declared for this parent; required_fired is how many actually posted. A chain with only XOR-sibling children declares zero Required, so a 0/0 row is normal and healthy for those parents.parent_amount_money — the posted amount in dollars (cents converted from the ledger)parent_status — the status of the parent leg (Pending / Posted / Failed)The dataset filters WHERE parent_posting >= <<date_start>> AND parent_posting <= <<date_end>> (pushdown from the Date pickers) and applies the Chain and Completion dropdowns via sentinel-guarded IN (...) clauses — clearing a dropdown reverts to "match all rows". The metadata cascade (Metadata Key + Value) applies a JSONPath IN (...) predicate on the parent's metadata JSON.
A row with completion_status='Completed', required_fired=0 and required_total=0. This parent's declared children are all XOR-group members — exactly one SHOULD fire, and the system found exactly one (or zero XOR groups entirely). A 0/0 completion is healthy, not a violation.
A row with completion_status='Incomplete' where required_fired < required_total. One or more declared Required children never posted against this parent transfer ID. This is the signature of an incomplete chain firing — the parent fired but one or more downstream legs the L2 declared never materialized. Drill down into the L2 Exceptions sheet (right-click → View in Chains) to narrow to this chain parent and see which children are orphaned. Then cross to the Rails sheet to inspect the parent's postings and metadata, confirming whether upstream conditions should have triggered the child.
A row with completion_status='Incomplete' but required_fired = required_total. The Required children count matches, but an XOR group was orphaned or duplicated — zero members of a mutually-exclusive group fired, or more than one fired. XOR groups are declared as exactly one SHOULD fire per parent instance; the SQL detects both under-fire (orphan) and over-fire (violation) cases and lumps them into Incomplete. The table doesn't distinguish the XOR failure mode (it counts cardinality mismatches, not the specific group), so compare your L2 declaration's xor_group definitions to the metadata and parent transfer ID to diagnose which group is broken.
An Incomplete row with a large parent_amount_money and low required_fired count. A substantial transfer fired but its declared downstream legs didn't follow. This pattern often indicates a configuration mismatch between the L2 declaration and the actual flow topology — the parent rail / template is real, but the child chains the L2 declared don't match what the runtime actually produces. Escalate to the L2 owner to audit the chain declarations (are the child names correct? are the parent-to-child routing rules up-to-date?).
A blank table with no Completed / Incomplete rows. Either no parent transfers fired in the date range, or the Chain / Completion filters are too narrow. Widen the date window or clear the Chain dropdown; if you still get zero rows, no declared chain parents were exercised during that period — check the Rails sheet to confirm postings exist, and confirm the parent rail / template names in your L2 declaration match the actual rail_name / template_name values in the ledger.
An empty Chain Instances table can mean several things:
chains: block is populated.latest_date to the base table's. If the matview lags behind, it hasn't been refreshed since the last ETL load — the dashboard is showing a stale state, so re-run the matview refresh and reload.First time here? See the Vocabulary for L2, matview, chain, template and the other project-specific terms.