> ## Documentation Index
> Fetch the complete documentation index at: https://docs.nekt.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Organize your Catalog
> Choose a Layer structure, organize tables, and keep your Catalog understandable as your workspace grows.
The Catalog is the central data store in Nekt. Sources write tables to it, Queries and Notebooks read and create tables in it, and Destinations and Integrations consume data from it.
A clear structure makes data easier to find, protects access boundaries, and gives people and AI agents better context. Define the first version before connecting production sources, then evolve it as real use cases appear.
Choose the top-level structure carefully. Moving tables later can require updates to permissions, Queries, Notebooks, Destinations, and context documents that reference their paths.
## Understand the hierarchy
| Resource | Use it for |
| ----------- | ------------------------------------------------------------------------------------------------------------------------------------------ |
| **Catalog** | The complete set of data available in a workspace. |
| **Layer** | The top-level storage and permission boundary. Use Layers to separate processing stages, clients, or other governance boundaries. |
| **Folder** | Visual organization inside a Layer, such as grouping tables by source, business domain, or project. Folders are not permission boundaries. |
| **Table** | A dataset created by a Source, Query, Notebook, or History. |
If two groups of users must not see the same data, separate that data with Layers or table permissions. Do not rely on Folders for access control.
## Choose a Layer model
There is no universal Layer structure. Start with the boundary that is hardest to change later—usually data ownership and access—and avoid creating more Layers than your team can maintain.
### Data from your own company
For a workspace that contains internal company data, organize Layers by processing stage:
```text theme={null}
bronze Data as it arrives from Sources
silver Cleaned, standardized, validated, and deduplicated data
gold Business-ready data for analytics, AI agents, and Destinations
```
Use these names consistently so people and AI agents can recognize the stage of each table from its path.
Use Folders inside each Layer to group tables by source or business domain:
```text theme={null}
bronze/
crm/
finance/
marketing/
gold/
revenue/
customer_success/
```
### Data from clients
For agencies, consultancies, and other service providers, client isolation is usually more important than processing stage. Start with one Layer per client:
```text theme={null}
client_acme
client_globex
client_northstar
```
Use Folders inside each client Layer to group Sources, working tables, and business-ready outputs. Grant each client or delivery team access only to the relevant Layer.
If a client has a large or complex data operation, you can create stage-specific Layers such as `acme_bronze`, `acme_silver`, and `acme_gold`. Use this structure only when the additional separation provides a clear governance or operational benefit.
### Internal and client data
For a hybrid workspace, combine the two models. Keep one Layer per client and separate Layers for your internal data lifecycle:
```text theme={null}
client_acme
client_globex
internal_bronze
internal_silver
internal_gold
```
This structure prevents your company's operational data from being mixed with client environments while preserving a clear processing flow for internal analytics.
## Name tables for humans and agents
Table names are part of the context used by your team and AI agents. A person should understand what a table contains without opening it.
* Use lowercase `snake_case` names.
* Name the business entity and, when relevant, its grain: `facebook_ads_campaign_daily` is clearer than `ads_data`.
* Keep source names when they help distinguish similar datasets: `hubspot_deals` and `erp_orders`.
* Avoid unexplained abbreviations, temporary labels, and names such as `table_1`, `new`, or `final`.
* Add descriptions to Layers, tables, and important fields, especially when a business definition is not obvious.
## Start with the minimum structure
Decide whether the workspace will contain internal data, client data, or both.
List which teams or clients must be isolated. Use those boundaries to choose the Layer model.
Create only the Layers required for the first use case. You can add more as the operation grows.
Select only the streams required for the first use case and give their output tables descriptive names.
Revisit the structure after the team has used the data. Recurring questions reveal which Silver or Gold tables should be created next.
## Avoid common mistakes
* Creating a Layer for every Source when there is no access or lifecycle reason for it.
* Using Folders as if they restricted access.
* Mixing source tables and business-ready tables without a naming or Layer convention.
* Connecting every available stream before defining the first use case.
* Creating deep Folder hierarchies that make tables harder to find.
* Renaming Layers and tables without checking dependent pipelines and context documents.
## Related documentation
Map the first source streams to tables in your Catalog.
Control which Members can access each Layer and table.
Understand how tables and pipelines depend on each other.
Learn how data moves through the Catalog.