Your Institution — Institution Tour¶
Generated from the L2 institution YAML (spec_example.yaml).
Re-run the docs build (or point QS_DOCS_L2_INSTANCE at a different
YAML) to regenerate this section against another institution.
Generic SPEC-shaped instance for cleanliness testing of the lifted common.l2.seed primitives.
At a glance¶
| What | Count |
|---|---|
| Singleton accounts (the institution's GL + external counterparties) | 7 |
| Account templates (per-customer / per-merchant shapes) | 1 |
| Rails (money-movement primitives) | 4 |
| Transfer Templates (multi-rail bundles) | 1 |
| Chains (parent → child firing rules) | 0 |
| Limit Schedules (per-account / per-rail caps) | 1 |
The diagrams below show how these pieces connect. Per-entity descriptions live on the dedicated subpages — that prose IS the source of truth for how the institution treats each entity.
Topology — accounts + rails¶
Every Rail draws an edge between its source-role account and its destination-role account. Single-leg rails draw a self-loop on the leg- role account. Internal the institution accounts are blue; external counterparties are orange.
Topology — account templates + rails¶
Same shape as the accounts view above, but the nodes are
AccountTemplate roles rather than singleton Accounts. Each template
is one role × N node (the dashed border marks "many instances at
runtime"); rail edges connect templates whose roles the rail's
source_role / destination_role / leg_role references.
Singleton-only rails (no template touched) drop out — this is the
template-shape skeleton, not the full topology.
Topology — chains (parent → child firings)¶
Chains declare that when one Rail or Transfer Template fires, another SHOULD fire too. Solid edges are required (validator catches a missing firing); dashed edges are optional. XOR groups capture "any one of these MUST fire — pick the right child by metadata".
No chains declared in spec_example.yaml
This institution declares no chains in its L2 YAML — there are no parent → child firing rules to display. Add a chains: block to your L2 instance to populate this DAG.
Topology — account hierarchy (rollup)¶
How the singleton accounts and templates roll up. Each edge points
from a child to its parent — the singleton Account whose role
matches the child's parent_role. Solid-bordered nodes are 1-of-1
singletons; dashed-bordered × N nodes are templates that
materialize many instances at runtime (e.g. one CustomerDDA per
customer, all rolling up to the DDAControl GL).
Per-entity reference¶
Pick a primitive to walk its full inventory + descriptions:
- Accounts — singletons + templates with descriptions.
- Rails — every money-movement primitive with shape, aging caps, posted requirements, metadata keys.
- Transfer templates — multi-rail bundles.
- Chains — required + optional firings.
- Limit schedules — daily flow caps.
How the dashboards read this¶
- L1 Reconciliation Dashboard — surfaces the L1 invariant violations against the data this L2 declares: drift, overdraft, limit breach (using the Limit Schedules above), stuck pending / unbundled (using the Rails' aging caps), supersession audit.
- L2 Flow Tracing — walks the Rails / Chains / Transfer Templates diagrams above against runtime activity, surfacing declared-but-never-fired rails, chain orphans, and unmatched transfer types.
- Investigation — questions over the leaf-account / external- counterparty graph above (recipient fanout, volume anomalies, money trail, account network).
- Executives — coverage / volume / money-moved scorecard rolled up across the institution's account roster.
For a per-app sheet-by-sheet walkthrough, see the Walkthroughs section.