Skip to main content
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

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:
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:

​
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:
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:
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

1

Identify data ownership

Decide whether the workspace will contain internal data, client data, or both.
2

Define access boundaries

List which teams or clients must be isolated. Use those boundaries to choose the Layer model.
3

Create the first Layers

Create only the Layers required for the first use case. You can add more as the operation grows.
4

Map the first source

Select only the streams required for the first use case and give their output tables descriptive names.
5

Review after real usage

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.

Connect a data source

Map the first source streams to tables in your Catalog.

Permissions

Control which Members can access each Layer and table.

Lineage

Understand how tables and pipelines depend on each other.

Catalog overview

Learn how data moves through the Catalog.