Skip to main content
Why a wealth starter exists at all: raw instruments and snapshots are unusable. “What’s our equity allocation?” isn’t one ticker, it’s a whole classification branch — and summing position snapshots across dates multiplies AUM. The starter pre-maps securities into asset-class and GICS groupers using public structure, pins one governed definition for contested metrics like AUM, return, and concentration, separates time-weighted from money-weighted return, and makes MNPI/PII-aware behavior the default.

​
The six layers

LayerWhereWhat
1 — Entity spineontology/schema.tql, ontology/relations/Client, Household, Account/Portfolio, Position, Security, Transaction, Advisor, Benchmark, Fee.
2 — Metricsontology/queries/Governed surfaces: AUM, net flows, time-weighted return, asset allocation, active return, concentration, advisor book, effective fee rate, attrition.
3 — Classificationontology/dimensions/, filters/, reference/terminology/The analytic layer. Asset-class taxonomy + GICS structure + FIGI identifier crosswalk as dimensions, filters & committed seeds.
4 — Governanceontology/notes/governance-mnpi-pii.md, config/org_context.mdPII roles, small-cell suppression, MNPI / information barriers, suitability, GIPS.
5 — Decision recordsontology/notes/Why each metric is defined the way it is; TWR vs MWR; grain; identity resolution; the glossary and identifier-tuple guides.
6 — Validationvalidation/validate_tql.py (every surface checked against your live schema + compiled), golden queries with pinned values, the dry-run prompt + schema-mapping overlay.
Standards alignment — STANDARDS.md maps the model to the industry standards it aligns with (FIBO, ISO 20022, OpenFIGI, GICS); SOURCES.md cites every source. The semantic layer (metrics, routing, classification) is fully separated from the physical mapping: every physical table name lives in one file, ontology/schema.tql — re-point it and the metric logic stays put. The starter is authored against a generic custody + portfolio-accounting model in ANSI SQL; MIGRATION.md is the 8-step re-point checklist and works the same on Redshift, BigQuery, Snowflake, or Databricks (budget: about a half-day with warehouse access). For a deep technical tour, read DEEP_DIVE.md.

​
✅ Checkpoint

  • You can name the six layers and find each one in the repo
  • You know which classification ships in the box vs. needs your own licensed feed (CUSIP, per-security GICS)
  • You know the default model (generic custody + portfolio-accounting, ANSI SQL) and where the schema-mapping overlay lives
Two rules for a long, live session — 1 · Checkpoint every couple of modules. Long threads have a ceiling. After every module or two, ask Ana: “Save a handoff document summarizing what we’ve built, what we decided, and what’s next — so we can continue in a new thread.” If a thread ever maxes out, you lose nothing.

2 · Pin the scope in every prompt. Name the entity and the source-of-truth tables in each prompt (“…for [entity X], using the [base] tables, not the summary table”) — otherwise Ana may drift to a convenient summary table or query every source at once.