The Lake Builder Mind does an import for you the way a Lake Administrator does it by hand, with the same steps and the same checks. It reads your source, imports the tables you choose, sets them up and loads them. You supervise every build: anything that touches the running Lake waits for your decision.
How a build runs, step by step
Reuse the connector. It looks for a connector that already covers the source, reads it and works from there. It never creates one; you add the data source first, on Add a data source. Before it imports, it proves the connection with a read from one of the connector's tables.
Read the source and propose the tables. It walks the source's structure, sizes the candidate tables and proposes the list that fits your request, before anything is imported. It judges each table by its columns and its size, never by its name (see below), and names every table it leaves out.
Import the tables. Importing registers each table in the Lake; no data is loaded yet. One import takes at most 1,000 tables. See Import tables.
Save comments and primary keys. It proposes a primary key and column comments from what the source shows, and saves what you settle on. Deploying needs at least one primary key.
Assign personal-data domains. With the Mind's Force Mind to Assign PII Domains to lake tables setting on, it assigns PII domains after the keys and before anything is deployed or loaded, starting with the tables that hold rows. A column that no domain fits stays unassigned, and the report says so. With the setting off, it assigns a domain only when you ask in a message. See Warehouse Builder and Lake Builder.
Deploy. It deploys each table once its key is in place. See Deploy a table.
Set the load pattern. The starting point is Full Reload (Truncate Insert), the same name the Sync Type list shows. It chooses from what you ask for, never moves a table to an incremental pattern on its own, and uses a snapshot pattern only when someone asks for one. See Choose a sync type.
Set the workflow. It places the tables in the workflow that runs their loads. See Workflows in the Lake.
Run and verify. It starts a load and waits for the run to finish, then checks the result in its own reads (see below). Runs and their logs live on Run, stop and troubleshoot loads.
Hand the schedule to you. It reads the workflow back and tells you whether the workflow and its schedule are on and when it runs. When either is off, it says the Lake will not refresh by itself and asks you to switch it on in the Lake: that is a person's step. The build ends with the final report described below.
How it chooses the tables
Columns and size decide, never the name. It reads each candidate's columns and its estimated size. A table with business columns, such as a product, a customer, a store, an amount, a price or a business date, is data to load even when its name sounds like a log or an archive. Only a table whose columns are all technical, such as messages, stack traces or audit stamps, counts as a log.
Every table left out is named. It leaves out logs and empty tables by default and lists each one with its reason, so nothing disappears silently.
It asks before guessing. When a table you named is empty, two tables look like the same data, or a table it would leave out holds business columns, it asks you with a question card, listing those tables with their columns and size; see Questions from a Mind. It changes nothing the answer affects until you reply.
What it asks before it acts
While a step waits for a decision, the chat shows Awaiting human approval. This action has NOT been executed., and the build continues only after you decide. Reject the card and nothing is executed: the call then reports that an administrator rejected it (A Datawarehouse Administrator rejected this action). The cards themselves are on Change approval in a builder chat.
Which steps wait is set by the chat's mode:
Manual waits on every change.
Auto-accept applies ordinary changes and still asks for destructive ones.
A scheduled run never uses Unrestricted; a task is Manual or Auto-accept. See Scheduled tasks.
A change to where or how a connector connects stays refused in the higher modes: in Auto-accept and Unrestricted the Mind asks you to make it in the connector form instead. See Manage connectors from a chat.
Outside Unrestricted, a step that removes rows or objects is asked for alone: it reads the target first and states what would be lost before its card appears. It never asks for permission in the chat text itself; the approval card is how it asks.
What stays with you
Creating the connector. A new connector is yours to make, in the Lake's own form; the Lake Builder never creates one and never asks you for a password or a key in the chat. See Add a data source and Connector secrets.
Approving hosts and grants. A new host or a data access grant is approved by a person with the admin role, in the connector's Hosts list and its Data access section. The Mind can revoke an approved host; approving one is not its step. See Hosts, streams and data access and Data access grants.
Schedules. Switching a workflow or its schedule on or off stays a person's step in the Lake. See Workflows in the Lake.
Row-level security. RLS is configured by hand in the table's RLS step. The Mind does not read or change it, and it never reports RLS as set. See Conditions and row-level security.
How the result is checked
A build is not called done because it should work. Each step is checked with a read of the real thing:
A connection is called broken only after a read from one of the connector's tables fails. A source tree that will not open, or a connector with no stored secrets, proves nothing on its own: a database connector keeps its sign-in in its connection. When the read does fail, the Mind reports the error and the one fix, such as the login or the database in the connector form.
After a deploy, the table's deployed state is read back.
After a load, the run is read once it has finished, and the loaded rows are counted from the table itself.
The saved key is checked for uniqueness in the loaded data; when it is not unique, the report says so.
When everything checks out, the build is reported as done, with the tables, their state and what is left for you. Anything less is reported as still running, waiting on you, or stopped by something you need to clear.
If a load fails, the Mind reads the failure first and changes one thing at a time. A cause inside the connector goes to the connector's own Mind, and that fix counts as done only when its report arrives and the reload and checks here pass. The same error that survives three attempts ends the attempt and comes back to you as a question with what was found.
What the final report says
Every turn that changed the Lake ends with a report in plain words, also a turn that continues after a swarm report or a connector Mind's report. A turn that pauses for your approval, your answer, running sub-agents or a connector Mind's work does not end with one; the turn that finishes the work does. The report carries the items that apply:
The tables that loaded with rows and the tables that ran empty, with exact counts.
Every table that was not loaded, whether left out, blocked or skipped, by name, with its reason and the next step.
Every primary key the Mind chose itself.
Personal data: the PII domains it assigned, or why it assigned none.
The workflow, linked: whether the workflow and its schedule are on, when it runs, and what you need to switch on.
Every figure comes from a read made in that conversation, copied as it is: empty tables are counted as empty, never rounded into "loaded", and nothing is called resolved before the read that failed succeeds.
Questions, answered
How do I start an import with the Lake Builder?
Open a chat with the Lake Builder Mind and describe what you want in the Lake. It reads the source first, states back what it understood and asks for one confirmation before it builds. See Warehouse Builder and Lake Builder.
Why does it ask me to confirm the tables before it builds?
So a wrong reading is caught before anything is imported. It states the task back with concrete choices, such as Correct, build it, Different tables or Different connector. When your message already leaves no doubt, it goes ahead.
Can it create a new connector for me?
No. You create the connector in the Lake, and credentials go into its form, never into the chat. It works from a connector that exists and imports the tables from it. If a connector needs work of its own, such as a custom connector or an API recipe, the task is handed to that connector's own Mind. See Manage connectors from a chat.
What does "Awaiting human approval. This action has NOT been executed." mean?
A step is waiting on its approval card, and nothing has run. Decide on the card: approve it and the step runs as you; reject it and the change is not made, with the call reporting that an administrator rejected it (A Datawarehouse Administrator rejected this action). See Change approval in a builder chat.
Which load pattern will it choose for a table?
It starts from Full Reload (Truncate Insert) and picks from what you ask for: a rolling window that must accumulate leads to an upsert, a one-off load to Onetime. It never moves a table to an incremental pattern on its own, and snapshot patterns are used only when you ask for one. All the patterns are on Choose a sync type.
Why did the Lake Builder leave some of my tables out?
It leaves out tables whose columns show a log or a technical artefact, and empty tables, and it names each one with its reason in its proposal and in the final report. A table's name never decides: one with business columns, such as an amount or a price, is proposed for loading whatever it is called. When it is unsure, it asks you before it leaves a table out. To load a table it left out, ask for it by name.
Why does the Lake Builder say my connector cannot connect?
Because a read from one of the connector's tables failed. It does not decide that from a source tree that will not open or from a connector with no stored secrets; a database connector keeps its sign-in in its connection. Its message names the error and the fix, such as the login or the database, which you change in the connector form. See Connect a SQL database.
How do I know a build is finished and its load worked?
It checks before it reports: the deployed state is read back, the run is read once it has finished, and the rows are counted from the table itself. A build is reported as done only when every step is met, including the verified load; anything less says what is still running or waiting for you.
What happens when a load fails?
It reads the failure first and changes one thing at a time, then loads and checks again. If the cause is in the connector, the connector's own Mind takes that work, and the fix counts as done only after its report and a clean reload here. When the same error survives three attempts, the Mind stops and comes back to you with what it found.
Can it approve a new host or a table grant?
No. Approving a host or a data access grant is a person's decision, made with the admin role in the connector's Hosts list or its Data access section. The Mind can revoke an approved host, but it cannot approve one. See Hosts, streams and data access.
Can it set up row-level security?
No. RLS is configured by hand in the table's RLS step, and the Mind neither reads nor changes it; it also never reports a table as having RLS set. See Conditions and row-level security.
Does it notice rows deleted in the source?
No. No sync type detects a source deletion, and the Mind never offers delete detection. What happens to a deleted row depends on the table's pattern, and the Mind says so plainly before it relies on an incremental pattern. See Choose a sync type.