> ## Documentation Index
> Fetch the complete documentation index at: https://docs.textql.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Module 0 · The Six Layers

> 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 summin… (~15 min)

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

<table>
  <tr><th>Layer</th><th>Where</th><th>What</th></tr>
  <tr><td>**1 — Entity spine**</td><td>`ontology/schema.tql`, `ontology/relations/`</td><td>Client, Household, Account/Portfolio, Position, Security, Transaction, Advisor, Benchmark, Fee.</td></tr>
  <tr><td>**2 — Metrics**</td><td>`ontology/queries/`</td><td>Governed surfaces: AUM, net flows, time-weighted return, asset allocation, active return, concentration, advisor book, effective fee rate, attrition.</td></tr>
  <tr><td>**3 — Classification**</td><td>`ontology/dimensions/`, `filters/`, `reference/terminology/`</td><td>**The analytic layer.** Asset-class taxonomy + GICS structure + FIGI identifier crosswalk as dimensions, filters & committed seeds.</td></tr>
  <tr><td>**4 — Governance**</td><td>`ontology/notes/governance-mnpi-pii.md`, `config/org_context.md`</td><td>PII roles, small-cell suppression, MNPI / information barriers, suitability, GIPS.</td></tr>
  <tr><td>**5 — Decision records**</td><td>`ontology/notes/`</td><td>Why each metric is defined the way it is; TWR vs MWR; grain; identity resolution; the glossary and identifier-tuple guides.</td></tr>
  <tr><td>**6 — Validation**</td><td>`validation/`</td><td>`validate_tql.py` (every surface checked against your live schema + compiled), golden queries with pinned values, the dry-run prompt + schema-mapping overlay.</td></tr>
</table>

<Note>
  **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`.
</Note>

### ✅ 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

<Note>
  **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.<br /><br />
  **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.
</Note>