Skip to content

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) 21
Transfer Templates (multi-rail bundles) 6
Chains (parent → child firing rules) 6
Limit Schedules (per-account / per-rail caps) 2

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".

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 (singleton-children) + XOR (multi-children) 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.