> For the complete documentation index, see [llms.txt](https://docs.lucernahealth.com/guide/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.lucernahealth.com/guide/insights-studio/population-builder/reference-guides/data-model-root-table-and-golden-tables.md).
# Data Model, Root Table and Golden Tables
### The data model
Population Builder uses the entire data model available in Leap, including claims, encounters, rosters, demographics, appointments, and more. To explore the data model further, go to Data Hub.
Having all domains available is what lets a single query span claims, appointments, and rosters at once. It also means the field picker is searching a very large set of tables and columns, which is why how you search matters.
***
### Root table
The root table sits above the query builder panel while building or editing populations. It's the table the population is counted against, and it determines what the query returns.
Leave it alone unless you have a specific reason to change it. The default is usually correct, and switching it can change your results in ways that aren't obvious.
To change it, click the edit icon, then the menu icon, and select Root Table from the dropdown.
***
#### Simulated root table
While you're building or editing blocks, the count shown is calculated against a simulated root table. It's an estimate meant to help you understand your data as you go, not a live run.
It defaults to Dim Consumer Contact and can be changed at any time. To change it, click the edit icon, then the menu icon, and select Root Table from the dropdown.
***
### Golden tables
Working with the entire data model can be overwhelming. Golden tables narrow it down to a smaller, curated set of the most-used tables and fields.
When you search for a field, golden table fields show up first. So in most cases you type what you need and pick from the top results.
***
### Choosing the right field
Searching well is most of the work here.
* Search the concept, not the field name you're imagining**.** It's common to type what you assume a field is called, find nothing, and stop. Typing the plainest version of the idea works better.
* Expect to search more than once**.** A first search usually lands you in the right area rather than on the exact field. Searching `roster` returns roster-related fields; if you specifically need currently active members, `roster status` gets you closer.
* Check the table, not just the column**.** Each result shows a column name and the table it comes from. The column name tells you what the field is; the table tells you what it's about.
Two fields with near-identical names can mean completely different things:
| Field | What it actually means |
| -------------- | --------------------------- |
| Facility State | Where a facility is located |
| Plan State | Where the member's plan is |
* If you're building a rule about members and select Facility State, the results will be wrong in a way that's difficult to catch later. Hover the info icon next to a table name to learn more about that table before selecting.
* Search by table if you know it. If you already know which table holds the field you need, use the Search by table option instead of searching column names.
