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.
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:
The modes, who may set them and what each needs are on Warehouse Builder and Lake Builder. Two more rules apply:
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.
A build is not called done because it should work. Each step is checked with a read of the real thing:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.