Spellbook & autonomy guardrails

Onboarding the agents gets you verified connections. Onboarding the Spellbook Data Catalog is a different kind of step: it’s where your team decides how much initiative the platform gets, and writes those decisions down as guardrails. This page is that leg of the journey, run with your onboarding engineer during day 0 — but the decisions in it belong to your team, not ours.

Step 1 — Stand up the console

npm config set //registry.npmjs.org/:_authToken=<your-customer-token>
npx @dataworkersproj/agent-console@latest serve --local-ui

Browse the estate your verified connections produced; register and Test connection any remaining systems. (A data steward without a dev setup pairs with an engineer in a shared session today — that’s honest, not ideal, and it’s what research preview graduates out of.)

Checkpoint: console ✓ Connected, estate browsable, every registered connector tested.

Step 2 — Write the no-touch list

Before any autonomy is enabled, your team names what the platform must never touch on its own: specific schemas (finance close tables, regulated datasets), systems, or operations. The no-touch list is recorded in your workspace and honored by the Conductor and every write path.

One rule holds even with no list written: the platform can never spend money, change access, or delete data without a human approving that action. That floor is enforced in code, not judgment, and no configuration removes it.

Checkpoint: no-touch list written down, even if it’s short — an explicit empty list is a decision; an unasked question isn’t.

Step 3 — Choose the Conductor’s operating mode

Two modes, chosen per workspace, switchable any time in one click:

Approve-edits (start here, always): the Conductor proposes every change — you see the exact edit and its blast radius, and click approve or reject. Nothing happens without a click.
Auto: the Conductor performs reversible upkeep itself — descriptions, tags, re-runs, things you can undo — and tells you after. Irreversible actions still always ask first, in both modes.

The practical definition your team should repeat: reversible means you can undo it; if you can’t undo it, it always asks.

Checkpoint: mode recorded (Approve-edits on day 0), and everyone who’ll see proposals knows what the two modes mean.

Step 4 — Name the approvers

Decide who clicks approve, for what:

Agent writes (pipeline deploys, fixes, provisioning): which engineers approve.
Context promotions (a fact becoming authoritative in the graph): which data owners approve — promotion always requires a named human.
Access changes: always human-approved (floor), and on Enterprise, behind your configured approval gate with the audit receipt naming the approver.

Checkpoint: approvers named per category and recorded in the onboarding report.

Step 5 — Watch it work before you widen it

Run a week in Approve-edits and then read the Conductor’s track record together — changes proposed, approved, rejected, undone — on your own tables, not a demo. That record is the honest basis for the graduation decision:

Graduate to Auto when a steady run of proposals has been approved unchanged, nothing in the record surprised you, and the no-touch list has held. Stay in Approve-edits when proposals still get edited or rejected regularly — that’s the mode doing its job, not a failure. Flipping back is one click and loses nothing.

Checkpoint: a dated follow-up (typically the week-2 check-in) where the track record gets read and the mode decision gets made — by your team.