Domains

Domains is the workspace for creating, configuring, archiving, and restoring data domains. Open Domains from the global application rail; the Settings gear does not open Domain configuration.

What's on this screen

Member changes and plugin removals use the selected item you reviewed. A change to that item can invalidate an open action even while the rest of the list stays the same. After a conflict, reload and review the selected member or plugin before trying again; Vibedata does not automatically retry the old decision.

A persistent list groups readable Domains under Pending, Active, Locked, Archived, and, when present, Archiving or Deleting. Each row also shows resource readiness as Failed, Stale, Pending, or Ready. Lifecycle and readiness are separate: a Domain can be Active while a resource needs attention.

The selected Domain shows these sections, as links in the Domain sections strip, according to your access. Each section has its own address, so you can bookmark it or open it in a new browser tab:

Section	What it contains
General	Identity, Domain instructions, budget, Import or Export, and lifecycle actions
Resources	Single-open Git repository, Data platform, and Secret store rows, each with a readiness badge, and Reconcile
Secrets	Internal secret names, properties, versions and lifecycle actions; visible after saving Internal and when you have metadata access
dbt docs	Generated documentation from the latest successful production publish
Plugins	Installed Plugin assignments for the Domain
Automations	Domain jobs, schedules, and run history
Usage	Read-only usage estimates for the selected Domain

Human Domain access is managed only under Organization Settings Users. Intents, including retained deleted Intents, remain in the Intent workspace. The Domains workspace has no Sources or Intents section and no Organization Settings shortcut.

When you open Domains, a landing page lets you select a Domain from the sidebar or start a new one. An empty workspace prompts you to create your first Domain. Direct links to a Domain still open that Domain.

Use Hide Domains navigation on the left side of the header to give the selected page more room, and Show Domains navigation to restore the Domain list. Cmd+B (Mac) / Ctrl+B (Windows/Linux) invokes the same control. While the navigation is hidden, the narrow strip keeps Add domain and Search domains actions; Search domains expands the sidebar and focuses the search field.

How to create a Domain

1. Open Domains and select Add domain, or choose an example card to prefill an editable name, icon, and description. Add domain starts blank. The Demo domain card instead provisions a ready-made sample Domain; see Data platforms.
2. On the Create domain page, complete the steps Basics, Data platform, and Secret store. Basics includes the repository; Data platform includes Workspace. Back and selecting a step directly preserve the draft. A finished step reads Complete.
3. Once all three steps are complete, select Create from any step. Vibedata creates the Domain once, selects it, and opens General.

There is no default-branch field or Add Resource action. Vibedata binds the repository's existing default branch and the selected platform resources.

Leaving creation after changing the draft asks Discard unsaved changes?: choose Keep editing to stay or Discard changes to leave. An untouched draft closes immediately. Clicking outside the form or pressing Escape does not close it. Changing the Data platform type preserves Basics and resets platform-specific authentication and resource fields.

Basics

Enter Name, choose an icon, and optionally add Description. After creation, you can add Domain instructions in General using a plain multiline text field. Both optional fields are compact and resizable. Slug (cannot be changed after creation) appears beside Name and is derived from it; you cannot edit it separately.

Choose Account / organization and Repository, then select Continue to data platform. If all three steps are already complete, this button shows Create instead. Review the live Domain summary beside the form. If an edit makes the draft incomplete, the button returns to Continue; on Secret store, Create becomes disabled. Unchosen resources read Not configured; this is not a validation failure.

Data platform and Workspace

Choose Data platform type, User authentication, and the displayed service authentication option. OAuth/OIDC choices list only Identity Providers already connected under User settings → Data platforms; creation does not start OAuth. If none is available, the picker names the cause and its fix: connect your own account under User settings → Data platforms; otherwise, configure a compatible provider under Org settings → Identity providers when you can manage that section, or ask a Vibedata Owner to do it.

Service authentication offers two cards, each with a short description, for Microsoft Fabric. Other platforms, such as Databricks, offer only their own service principal; a Domain saved earlier with reuse shows a repair message until one is entered. Client ID and Client secret appear only for Dedicated identity. Reuse user identity provider uses the selected provider without separate credential entry. Select Continue to workspace to collapse authentication and open the resource choices. Reopen a section by selecting its header.

In Workspace, select a listed resource or explicitly choose the exact-identifier option where the dropdown supports it. Typing a filter alone does not select it. All applicable resource fields are visible when you open Workspace. A dependent field stays disabled until you choose its prerequisites; its hint names what is missing. Your selections enable the existing fields in place. Resolved identifiers and endpoints appear as read-only text beneath the resource they describe. Changing a parent clears incompatible dependent selections. Fabric lets you choose an existing Workspace and Lakehouse or Warehouse, then a Schema and Ephemeral workspace capacity. A Warehouse Domain also needs a Paired Lakehouse in the same workspace, which holds the files its production loads stage and the code its notebooks read; the create form refuses a Warehouse without one. A Warehouse Domain created before this was required shows a Paired Lakehouse picker in its Data platform settings. Choose one and save: it is set once and cannot be changed afterwards. Until you set one, that Domain's production loads run row by row. MotherDuck lets you choose a Database and Schema. Activation is owner-only: the Domain's connected identities must directly own the chosen database. There is no Share to select — MotherDuck gives Vibedata no way to prove a Share's source database without attaching it, so Vibedata does not offer one as an alternate clone source. DuckDB Local lets you choose an existing Database, create a managed database file, or upload one existing DuckDB database, then a Schema. Workspace and Lakehouse creation are not available here.

Google BigQuery lets you choose a Domain project from the projects your Google identity can see, then an Ephemeral project, then a Schema from the Domain project's existing datasets. With sign-in on, the lists show what your own linked Google account can see; you can also type a project or dataset. Vibedata never creates a dataset in the Domain project, so create the dataset in BigQuery first if the list is empty. The Ephemeral project must differ from the Domain project; Vibedata keeps each Intent's working datasets there. Another Domain may use the same Ephemeral project: the list says also used by Domain "…" next to it, and both Domains must use the same location. Each environment's queries run in, and bill to, its own project: production reads in the Domain project, Ephemeral jobs in the Ephemeral project, so grant the service account roles/bigquery.jobUser in both (and each person who runs Intents under sign-in a custom role holding only bigquery.datasets.create and bigquery.jobs.create on the Ephemeral project; Open names anyone who lacks it). Location is filled from the dataset you choose and cannot be changed after the Domain is created. A Domain created before this change that billed to a separate compute project shows a Reconcile advisory that its billing has moved. Datasets whose names start with ephm_, or that carry Vibedata's vd-instance, vd-domain, or vd-intent label, are Vibedata's own and never appear in the list.

On a local deployment without sign-in, Vibedata uses this machine's gcloud Application Default Credentials. Run gcloud auth application-default login --scopes=https://www.googleapis.com/auth/bigquery,https://www.googleapis.com/auth/cloud-platform before creating the Domain. The host identity must be able to run BigQuery jobs in both the Domain project and the Ephemeral project. An ambient Domain created earlier can become blocked at its next Reconcile if the host identity lacks roles/bigquery.jobUser (or a custom role holding bigquery.jobs.create) on the Ephemeral project; grant it that role and Reconcile again. With sign-in enabled, each person links their own Google account instead, and the Domain also needs a service account (workload identity impersonation or a key). Each Intent gets its own dataset in the Ephemeral project.

Snowflake binds one account, Production warehouse, Ephemeral warehouse, production database and Primary Schema. Enter Account identifier (<organization>-<account>) first. Vibedata then lists the databases and warehouses your Snowflake identity can see, and you pick Production database, Production warehouse and Ephemeral warehouse from searchable lists, then Primary Schema. To use a name that is not listed, type it into the picker and choose Use ... name. The Ephemeral warehouse is the compute for everything inside an Intent (dbt and dlt runs and the agent's queries, production reads included); Reconcile and other Domain-level work use the production warehouse. It is never filled in from the production warehouse and may be the same warehouse. Account host is optional and only for private connectivity or a legacy account-locator URL; it must end in .snowflakecomputing.com. Names must be unquoted Snowflake identifiers. Vibedata never creates a schema in the production database, so the Primary Schema must already exist. See Bind a Snowflake Domain.

Amazon Redshift binds one provisioned cluster or Serverless workgroup, one database and a Primary Schema. On a local deployment without sign-in, Vibedata lists what the AWS identity of this machine's aws CLI login can see. Choose a Cluster or workgroup from the list (it covers the regions every AWS account has enabled, and each entry shows its region); choosing one fills the endpoint host, port and the cluster identifier or workgroup name. Then choose a Database and a Primary Schema from dropdowns. System databases and Vibedata's own ephm_ databases are left out, and Vibedata never creates a schema in the Domain's database, so the schema must already exist. A provisioned cluster needs the Database user entered before its databases can be listed; if you have not, the form asks for it and a Retry button lists again. On a deployment with sign-in enabled the Redshift form is manual: enter the endpoint, port, database and Primary Schema yourself. The list would need a role that is assumed for you per Domain, and your Domain does not exist yet while you fill in the form.

If your AWS identity may not list, the form says which IAM action is missing (for example redshift:DescribeClusters, redshift-serverless:ListWorkgroups, redshift-data:ListDatabases or redshift-data:ListSchemas) and you can still type each value by hand. A region you have opted into but that is not enabled by default is not searched; enter that endpoint manually.

Databricks binds a Production workspace, Production SQL warehouse and Production catalog, and its own Ephemeral workspace, Ephemeral SQL warehouse and Ephemeral catalog, then a Primary Schema. Production workspace and Ephemeral workspace are typed URLs: a bare host such as adb-123.4.azuredatabricks.net is enough, and Vibedata validates it as you type. The workspace must be on the same cloud as the Databricks Identity Provider the Domain uses; there is no cloud field on the Domain. The Account ID, Workspace ID and Ephemeral workspace ID fill in read-only from the workspaces; you never type them. The warehouse, catalog and schema fields are dropdowns listed from your own access in that workspace: the warehouse and catalog of each side follow its workspace, then the Primary Schema from the production catalog's existing schemas. Vibedata never creates a schema in the production catalog, and another Domain's production catalog is listed but cannot be chosen as an Ephemeral catalog. Choosing a catalog another Domain already uses as its Ephemeral catalog is allowed and means sharing it; the dropdown names that Domain (or counts it, if you cannot read it). There is no sharing switch. If Databricks refuses you with a 403 while you pick, you may not be assigned to the workspace you are picking from or may lack SQL access: ask a workspace admin to add you to that workspace and grant SQL access. After you create the Domain, the settings page shows these coordinates read-only.

The Ephemeral workspace and warehouse are required and are never filled in from production: choose them on purpose. They may be the same workspace and warehouse as production, which is the usual choice when you have one workspace. A different Ephemeral workspace must be in the same Databricks account and share the production workspace's Unity Catalog metastore, and it must be able to see the production catalog. Intents work entirely in the Ephemeral workspace and warehouse and read production tables through Unity Catalog there, so a separate metastore, or a production catalog the Ephemeral workspace cannot see, leaves them unable to read production, and Reconcile reports it. Only Domain-level reads, such as previewing production tables, use the production workspace. The service principal must exist and hold CAN_USE on the warehouse in each workspace; Reconcile checks them one workspace at a time and names the workspace in any failure. The Ephemeral workspace, Ephemeral catalog, and the production side cannot be changed after the Domain is created. A warehouse can be changed through the API, though no screen offers it.

The service lane is a service principal created in the Databricks account console (a Databricks-managed service principal), assigned to each workspace the Domain binds, with an OAuth secret generated there. Enter its application ID and that secret.

To upload a DuckDB database:

1. In Workspace, select Upload file to open its dialog. Under Choose DuckDB file, drop one non-empty .duckdb file on the area or choose it there ("Drop a file here or choose one").
2. Confirm the filename and size, then select Upload file. Files can be up to 1 GB. A file with another extension is refused with "Choose a .duckdb file.", an empty file with "Choose a file that is not empty." and a larger file with "Choose a file that is 1 GB or smaller."; the file you already chose stays and its upload is not stopped. While a transfer runs you cannot choose another file. If the transfer is interrupted, Vibedata keeps its saved progress for 24 hours and resumes from that progress when you retry.
3. Wait for Validating database. Vibedata checks that the file is a readable DuckDB database, closes the dialog, and selects the uploaded file.
4. Select or create the Schema, then continue creating the Domain.

Vibedata never replaces a managed database file with the same name. If that name is already in use, choose a differently named file. Select Cancel to clear the selected file and stop an unfinished upload.

Searchable lists filter by any case-insensitive part of the visible name without changing the selection. No matching options means only that the filter found no match; it is different from loading, empty, failed, or truncated results.

New schema and New file open dialogs with a name field and Create / Cancel. The workspace form keeps its position beneath the dialog. Choose the parent resource before creating a schema. A successful creation selects the new resource. Canceling Domain creation does not delete a file or schema already created. Closing Upload file with Cancel, Escape, or its backdrop uses the same confirmation when a transfer has started or has saved progress.

Secret Store

Choose the Secret Store your Data Platform offers: Local File or Internal for DuckDB-local, Azure Key Vault for Fabric, and each other platform's own store (see Secret Stores). Local File needs no configuration in this form; secrets are supplied outside Vibedata, which never creates or edits that secret file.

Internal needs no external identity or vault configuration. Save the Domain, then open Secrets to manage its inventory. The Agent can discover active names without receiving their values. Switching to another store hides Secrets and retains Internal names and version history. See Secret Stores.

For Azure Key Vault, complete Authentication, then expand Vault. Only one detailed section stays open. User connection and service identity are independent choices. Reuse data platform connection appears only when the requirements are compatible. Separate service credentials appear only for Dedicated identity. If none is available, the Identity Provider picker names the cause: connect your own account under User settings → Data platforms, or ask a Vibedata Owner to configure a compatible provider under Org settings → Identity providers. In ambient mode, the form uses the host Azure identity and asks for Azure tenant ID, not delegated credentials. Select a listed vault or explicitly commit its supported Resource ID in the same dropdown; the resolved vault URL is read-only. Vibedata never displays saved secret values.

For Google Secret Manager, User authentication and Service authentication offer Reuse data platform connection only when the Data Platform can supply that identity. When it cannot, the form says what the Data Platform step needs: a connected Google identity provider for user authentication, or a Google service account (or a reused Google identity provider) for service authentication.

For AWS Secrets Manager, enter the Account ID, Region and Secret name prefix. The prefix starts as vibedata/<domain-slug>/ and stays editable; secrets under it belong to this Domain, and another Domain cannot reserve an overlapping prefix. KMS key ARN is optional and informational: it appears in the setup guidance, and the role's own KMS permissions decide access. User authentication offers Reuse data platform connection or an AWS Identity Center provider with a User session role ARN. Service authentication offers Reuse data platform connection (only when the Data Platform names its own service role), Cloud IAM role, or Configure later; a Cloud IAM role needs a Service role ARN, because the store cannot be scoped to its prefix without one. Ambient host identity appears only where the deployment has no per-user sign-in. Choosing an existing secret from a list is not available.

Before the first Save, Test or Reconcile, create the sentinel secret under the prefix. The Setup guidance panel shows the command with your values:

aws secretsmanager create-secret --name 'vibedata/sales/.studio/sentinel' --secret-string 'x' --region us-east-1

Vibedata reads the sentinel to prove access and discards the value. The External ID is generated when the Domain is created, so it is not shown on the create form. Open the Domain's Secret store settings to copy it, then require it in the service role's trust policy. The test result lists AWS service session, List secret names and Read the sentinel; a missing sentinel reads The sentinel does not exist. Create the sentinel named … and repeats the command.

Repository in Basics

GitHub must already be connected on User settings → Profile → Repository access, under GitHub. If no usable GitHub provider is configured, the panel asks a Vibedata Owner to register and install the App under Org settings → GitHub, or, when saved credentials are incomplete, to re-save them there. If the App is installed but your account is not in an organization it is installed on, it asks an organization owner to install the App on your organization or add you to one that has it. Choose the account or organization and repository, then review the safe summary. The summary never includes secrets, tokens, or raw credential data.

If creation fails, your entries are preserved. Vibedata opens the first step with an identified error in Basics, Data platform, Secret store order and focuses the affected field. Every affected step reads Invalid; select it to read its messages. A step reads Invalid only after a Continue or Create attempt fails. Errors without a known step remain where you selected Create. Correct the inputs and retry; editing alone does not clear the previous attempt's markers.

How to configure a Domain

1. Select a Domain from the persistent list.
2. Open the relevant section. Use General for identity, instructions, budget, and lifecycle actions. Use Resources for resource configuration and readiness.
3. Under Resources, expand Git repository, Data platform, or Secret store. Expanding one closes the previous row.
4. Change the available fields and select Save.
5. Select the Domain-wide Reconcile action above the resource rows when you need fresh saved readiness results.

The Git repository and Data Platform resource identity are read-only after creation. The Git row also holds Sync to GitHub Actions and, for some platforms, the CI identity form; see GitHub. The Git row shows organization and repository, but no default branch. Data Platform retains mutable service authentication and supported deployment-capacity selection. Secret Store can switch resource or type where your role permits; Vibedata does not copy secret values when it changes.

For Azure Key Vault, use Authentication and Vault just as during creation. The Key Vault dropdown shows the saved vault without rediscovery. Select a listed vault or enter its exact Resource ID in that dropdown; its URL is derived. There is no separate manual-entry mode. Use Save to apply an edit.

Fabric groups its resource details and capacity under Workspace. The collapsed row shows names and schema; expand it for the SQL endpoint and provider links. DuckDB shows Database and Schema name read-only, with no Save button when there is nothing editable.

Bind a Snowflake Domain

A Snowflake Domain reads production through each person's own Snowflake account and runs Vibedata's own work as one service user.

Before you start, a Snowflake administrator needs to:

• create a service user (TYPE = SERVICE) and a service role, and grant the role USAGE on both warehouses, read access to the production database, and the account-level CREATE ROLE right. Do not grant it ACCOUNTADMIN, SECURITYADMIN, SYSADMIN or MANAGE GRANTS. Under sign-in the service role does not need CREATE DATABASE; without sign-in (your own Snowflake login) the login's role does;
• for sign-in deployments, create a creator role that holds the account-level CREATE DATABASE right, grant it directly to each person who will open Intents, and enter it as the creator role when you create the Domain. It cannot be ACCOUNTADMIN, ORGADMIN, GLOBALORGADMIN or SECURITYADMIN, or start with VD_EPHM__ or VD_PROBE_. Do not grant it to the service role. It can create databases outside Vibedata's prefix, which Snowflake cannot prevent. The setup SQL is in the Snowflake permissions proposal (docs/proposals/snowflake/permissions.md, section 4a);
• own the service user with a role an OAuth session can take (for example USERADMIN), so Vibedata can confirm you control it when you save;
• for sign-in deployments, register a Snowflake Identity Provider (see Identity Providers) and connect your own Snowflake account under User settings → Data platforms.

Which sign-in mode applies depends on the deployment. With sign-in enabled, User authentication is OAuth/OIDC through a Snowflake Identity Provider, each person reads production as themselves, and the service lane is a service user. Without sign-in, Vibedata uses the default connection in this machine's Snowflake connections.toml for both lanes; that one login creates every Intent database, so an Intent can read another Intent's database. A Snowflake Domain cannot use the local connection on a deployment with sign-in enabled.

Service credential. Choose Key pair and enter the Service user, the Private key (PKCS#8 PEM) and, if the key is encrypted, the Private key passphrase. Paste the whole key, including the BEGIN and END lines. Vibedata proves the key by connecting with it before saving and never shows it again. Keyless workload identity federation is not offered until it is certified for your hosting; the key pair is the only service credential.

Which key slot to set. Snowflake keeps two public keys per user. Register the key's public half in RSA_PUBLIC_KEY the first time:

ALTER USER <service user> SET RSA_PUBLIC_KEY = '<public key, PEM body only>';

Rotate the Snowflake service key

Rotate without a gap by using the other slot:

1. Generate a new key pair and set the new public key in the unused slot: ALTER USER <service user> SET RSA_PUBLIC_KEY_2 = '<new public key>';
2. In Resources, expand Data platform, paste the new private key and select Save.
3. Select Reconcile and confirm Data Platform is Ready.
4. Remove the old key: ALTER USER <service user> UNSET RSA_PUBLIC_KEY;

When the saved key is more than 180 days old, Reconcile still passes but Data Platform shows Ready, with an advisory and the code snowflake_key_pair_stale.

Reconcile results for a Snowflake Domain

Reconcile changes nothing in your account; it briefly creates and drops one VD_PROBE_ role to prove the right to create roles (and, under ambient sign-in only, one VD_PROBE_ database). It reads the creator role's grants without creating anything. The blocking checks run in order and stop at the first failure, whose message names the grant to add:

Check	Proves	Code when it fails
R1	The service user signs in and is the bound user.	snowflake_service_key_rejected, snowflake_service_identity_mismatch and similar.
R2	The warehouse and the Ephemeral warehouse run queries.	snowflake_warehouse_usage_missing
R3	The production database and Primary Schema are readable.	snowflake_domain_read_baseline_missing
R4	Ambient only: the host's Snowflake login can create databases.	snowflake_create_database_missing
R4b	The creator role exists, holds CREATE DATABASE on the account and is not a blocked or Vibedata-reserved name.	snowflake_creator_role_missing_object, snowflake_creator_role_lacks_create_database, snowflake_creator_role_blocked, snowflake_creator_role_missing
R5	The service role can create roles (sign-in deployments).	snowflake_create_role_missing

R6 and R7 are advisories and never block. They cover retained Intent databases and roles that no longer resolve or are held by someone Vibedata did not grant them to (R6), and a service role that is over-broad, objects it owns outside Vibedata's prefixes, or a key older than 180 days (R7). When several apply, the row lists each as its own item, most urgent first, as described under Advisories.

The per-Intent Snowflake database

Each Intent gets its own empty database named VD_EPHM__<DOMAIN>__<INTENT>, with the Primary Schema pre-created, and a role of the same name. Schemas the Intent builds keep their production names, so a model reads production through source() and writes into the Intent's database. At your first Driving Open of an Intent, Vibedata checks your access to both warehouses and the production database and grants you the Intent's role. You see only the Intent databases whose role you hold, and you cannot write to production. A shared member is granted at their own first Driving Open, and unsharing revokes nothing. Deleting the Intent drops the database and role.

On a Snowflake Intent the agent runs SQL, dbt and dlt as you, through your own Snowflake session, so it can read what your roles can read and write only into the Intent's database. lakehouse_query and lakehouse_schema cover queries and schema inventory; table detail and object description are not available for Snowflake. load_tabular_to_ephemeral loads a file into the Intent's database through your own session; on an ambient Intent it reports that the Intent credential is unavailable.

Do not grant your own roles privileges on VD_EPHM__ databases; Reconcile reports it. If you reconnect your Snowflake account under a different user name, the next Driving Open grants the Intent roles again.

If creating an Intent fails, the error's code is one of these:

Code	What to do
snowflake_create_database_missing	Ambient only: grant CREATE DATABASE on the account to the role the host's Snowflake login runs as.
snowflake_creator_role_lacks_create_database	Grant CREATE DATABASE on the account to the Domain's creator role.
snowflake_create_role_missing	Grant CREATE ROLE on the account to the service role.
snowflake_ephemeral_name_taken	A database or role of that name exists that Vibedata did not create; rename or drop it.
snowflake_ephemeral_failed	Snowflake refused another step; the message relays Snowflake's own error. Retry or repair.

Download a DuckDB file

Only users who can edit a DuckDB Local Domain can download its managed database file. In Resources, expand Data platform, select Download file, then select Confirm lock and download. Select Download file again to save the browser download. Vibedata streams the existing managed database to the browser and keeps the Domain locked until the transfer finishes, is cancelled, or fails; select Cancel before downloading if you do not want to continue. This action is not shown for Fabric or MotherDuck Domains.

Ephemeral workspace capacity choices begin loading when Resources opens. While loading, the saved name or ID remains visible and disabled; a failure leaves it intact and offers Retry. This selects an Azure Fabric capacity, not a concurrent-workspace limit. Manage instance-wide concurrency limits under Org settings → Capacity.

Opening Domains or expanding a resource does not validate anything. A dirty form must be saved before Reconcile. Changing Domains, sections, resources, or leaving the workspace while a form is dirty asks Discard unsaved changes? (Keep editing or Discard changes). While an operation is still running, leaving shows Operation in progress with Stay on this page. If it succeeds and no unsaved changes remain, navigation continues by itself. If it fails, you stay on the current page with its error; choose another destination after reviewing it.

How to review Domain usage

1. Select a Domain and open Usage.
2. Read Budget standing first. With a budget configured for this Domain it reads On track, Near limit, or Exhausted, states spend to date, burn rate, and the projected month-end total, and shows either the remaining headroom or how far spend is over the limit — an exhausted budget also offers a Raise the limit link back to this Domain's own General section. With no Domain budget configured it instead reads No monthly budget set — spend is unlimited and offers a Set a limit link to the same place.
3. Choose Last 7 days, Last 30 days, or Last 90 days — the tab opens on the last 7 days, and every section except Budget standing follows that choice. Budget standing always reports the current calendar month.
4. Review the Intent ledger, listing every Intent in this Domain with recorded spend in the window, sortable by Cost, Turns, or Last active, and paged. It is open by default, and collapses to a count of the Intents it covers.
5. Expand Cost by LLM profile for one row per profile: the model it mostly ran, the sessions and turns it took, the tokens it consumed and how those divided between new input, output, cache and reasoning, and what it cost. It is collapsed by default, and says while collapsed which profile leads and by how much of the window's spend.
6. There is no refresh control: the tab reads a durable ledger that is always current. If loading fails, select Retry.

The section always stays fixed to the selected Domain. A Domain Owner can review a Domain they own; a Vibedata Owner can review any Domain. Domain Contributors and User Access Administrators do not receive usage access from those roles.

When the selected Domain has no recorded usage, the overview shows No usage yet — The overview populates after an agent session records consumption. Values are usage estimates, not a billing ledger.

How to read readiness

Resource rows show the last persisted result:

State	Meaning
Failed	At least one saved check failed. Open the resource to see which identity could not reach it and why.
Stale	Configuration changed after a successful check.
Pending	A check is incomplete, running, or required configuration is missing.
Ready	Every required check is ready and all other checks are not required.

Each resource's own message and code appear once, at the top of its expanded row and above its settings. A resource with nothing to report shows only its status.

Blue, underlined resource links open the matching provider page in a new tab.

A Failed resource

A Failed resource explains itself in one callout at the top of its expanded row. It says that the Domain's service identity could not use that resource, repeats the provider's own message, and shows the code. The message is whatever the provider reported, so its wording differs by platform.

To recover, grant the Domain's service identity access to the resource in your data platform, secret store, or repository, then select Reconcile to re-check. Until the check passes, Intents cannot be created or driven and unattended automation is blocked.

Advisories

A Ready Data Platform can still have advisories: findings from the last Reconcile that do not stop automation, such as a broad project role, a long-lived key, or a check that stopped at its cap. They appear in one box on the Data Platform row, headed Service readiness: Ready, with an advisory or Ready, with N advisories. Each bullet is one advisory: its message, followed by its own code. The order is the order the platform ranks them.

An advisory is not an error. A Failed, Pending, Stale or Not configured resource shows its own message and code in a single callout and lists no advisories; the next Reconcile that passes reports them again. To clear an advisory, make the change its message describes in your data platform, then select Reconcile. The full list of advisories, with when each is raised, is in the readiness advisory catalogue.

Missing readiness information is never shown as Ready. Generic provisioning warnings appear once above the resource table. Repair personal provider connections under User settings → Data platforms, return to Resources, save any configuration changes, and select the Domain-wide Reconcile action. GitHub App configuration remains under Org settings → GitHub.

Lifecycle feedback and recovery

Under General → Lifecycle, Import, Export, and Archive have separate action rows. Progress, completion details, and errors appear below the relevant action. Expand Technical details to read the actual safe error returned by Vibedata. Recovery guidance accompanies that error; a generic fallback appears only when no safe diagnostic is available.

If Vibedata cannot confirm an unlock, select Refresh status before starting another operation. A failed request alone does not establish whether the Domain is locked or unlocked. Archive failures keep the confirmation open so you can review the error before retrying or cancelling.

How to export a Domain

1. Open the Domain's General section and select Export under Lifecycle. Export is available for an active supported Domain, including one with no Intents.
2. Review Domain configuration and Resources. These are always included.
3. Under Choose contents, check or clear each optional item. An item you cannot choose is shown unavailable with its reason in words. Options start selected unless noted:
   • Intents includes metadata, redacted conversations, and branch snapshots. Fabric and MotherDuck Intents do not export database contents.
   • Intent databases includes each Intent's working DuckDB database. It appears only on DuckDB Domains and lists each database with its size. You can select it only while Intents is selected and at least one Intent has a working database. Clear it when an Intent's database is too large to export: the Intents still export, and import gives each of them a fresh copy of the importing Domain's database.
   • DuckDB database includes the Domain database. It appears only on DuckDB Domains and is independent of Intents and Intent databases. If the database is over the 1 GiB export limit, the option shows its size, is unselected and disabled, and the rest of the Domain still exports. Download the database file from domain settings instead.
   • Automations includes each Custom Automation in the Domain, with its optional schedule. The row shows the Custom Automation count, or None when the Domain has none. If Vibedata cannot count them, the row offers Retry and export stays unavailable until the count loads. See What Automation export includes.
   • Secrets exports secret names only, each with the secret store it came from. Values are never exported. An Azure Key Vault Domain exports every non-certificate secret name in its vault, not only the names the Domain uses, and needs a signed-in user; a service principal cannot export them.
   • dbt docs starts cleared and shows Published, Not published, or Could not check. You can select it only when it is Published.
   • Plugins includes the Domain's Plugin availability. With nothing to export it shows None and stays selected but unavailable.
4. If the selected databases add up to more than the 272 MiB export limit on disk, a warning names each one with its size and suggests clearing Intent databases or DuckDB database. Export stays available, because the exported data can be smaller than the file on disk.
5. Review the inline notice about locking and any active Intent edit leases, then select Lock and export. Vibedata releases those leases, starts the export, and returns to Domain settings to show progress.

An empty category shows None and cannot be selected. Turning off all available options still exports Domain configuration and Resources. Select Back to domain settings or Cancel to leave; if you changed the selections, Vibedata asks whether to discard them. If Vibedata cannot confirm whether export started, your selections remain. Select Refresh domain status to check the current state before retrying; this action does not release the lock. Review the actual safe error in Technical details. If Domain activity changed, select Refresh contents to update the counts without resetting your choices. While the lock is held, retry with those selections or select Cancel to release the lock before choosing different contents. If Vibedata has already released the lock after a failed start, your choices remain available for another attempt. If another operation now holds the lock, select View domain status to return to its progress and recovery controls.

During Export in progress, Domain and Intent changes are unavailable. Other open tabs update when the Domain locks or unlocks. Authorized users can select Unlock domain, then Confirm unlock, to cancel and restore editing. Recovery remains available after reload, backend restart, or a change of authorized user.

Success shows Domain exported successfully and the bundle's relative location. If missing conversation history forced Vibedata to omit an Intent, it shows Domain exported with omissions and names every omission. An Intent with nothing to export may be listed without making the bundle incomplete. Contents you chose to exclude are not reported as failed omissions. If a conversation cannot be read for another reason, export fails, names the Intent, and states that no bundle was produced. Other failed runs show their stored failure message when available. An export that exceeds a size limit names the largest contents with their sizes, including each Intent involved, and which options to clear before exporting again.

If DuckDB cannot recreate a view or other object of a database being exported, the export fails and names the database (the Domain database or the Intent), the object, and why: a database it references that is not part of the export, a DuckDB extension it needs, or an object it depends on that does not exist. Export stops at the first such object, so others may also fail on the next attempt. If the object belongs to the Domain database, Vibedata does not change that file and rebuilding sandbox models does not fix it; clear DuckDB database to export the rest of the Domain. If it belongs to an Intent, update or remove the object in that Intent, or clear Intent databases, and export again.

What Automation export includes

For each Custom Automation, the bundle records:

• the display name
• the Agent and its Resources choice
• the skill or command it runs
• the timeout
• the LLM Profile, by name, provider, and model
• its schedule (cron expression and timezone), if it has one

The bundle never includes bundled Automations, schedule overrides for bundled Automations, run history, queued work, linked Intents, the identity of the person who owned the Automation, or credentials. Schedule overrides are the changes you made to a bundled Automation's schedule.

Vibedata leaves out a Custom Automation that cannot be exported as a complete, importable definition, and the import result then names it. The reasons are:

• The definition exceeded the export size limit. A field of the definition (such as its name or timeout) is outside the allowed size or range, or the Domain has more Custom Automations than one bundle can hold.
• The definition was incomplete at export. Vibedata could not read everything it needs to recreate the Automation, for example when it runs from a repository path or a session profile that an importing Domain cannot recreate.
• The Automation had no LLM Profile at export. Bind a profile to the Automation, then export again.

How to import Domain Intents and Automations

On a Domain with no non-deleted Intents, open General and select Import. The full-page form asks for Source domain slug and Export run ID. Select Review import, review any named active leases, and confirm. Vibedata returns to Domain settings and locks the Domain while it reconciles each bundle Intent by slug. It does not overwrite an existing branch or database file. The terminal notice reports created, restored, unchanged, skipped, and warning counts; any skipped bundle Intent produces a warning rather than a plain success. The result remains visible after newly imported Intents appear.

The import confirmation always states: "Imported Automations will be owned by you and run with your permissions." You become the owner of every Automation the import creates or updates, even if another person owned it in the source Domain. You need permission to manage Automations in the target Domain, or the import fails before it changes anything. Import never starts a run: an Automation that had no schedule stays unscheduled, and one that had a schedule is registered on its schedule only.

What an Automation needs in the target Domain

Vibedata never installs a Plugin, creates an LLM Profile, or substitutes a different one. Each Automation is imported only if the target Domain already has:

• the same Agent
• the same skill or command
• an LLM Profile with the same name, provider, and model that you can select

An Automation that misses one of these is skipped, and the other Automations and Intents still import. The import result lists each skipped Automation with a reason:

Reason code	What it means	What to do
automation_agent_unavailable	The Automation's Agent is not available in this Domain.	Make the Agent available, then import again.
automation_artifact_unavailable	The skill or command is not available in this Domain.	Install the Plugin or add the file that provides it, then import again.
automation_artifact_ambiguous	The skill or command matches more than one Artifact in this Domain.	Remove the duplicate so only one matches, then import again.
automation_llm_profile_unavailable	The exact LLM Profile is not available to you.	Create or share a profile with the same name, provider, and model.
automation_schedule_restore_failed	The schedule could not be registered. It is retried on the next import of the bundle.	Import the same bundle again.

If the export left an Automation out, the import result also shows a warning naming it and the reason from What Automation export includes. The warning does not change the counts.

The terminal notice reports Automations created, updated, unchanged, and skipped, separately from Intents. The import is not all-or-nothing: Automations and Intents that imported stay imported when others are skipped.

If the bundle was exported with the source domain's database, the result also tells you that import does not apply it and that this domain's existing database is unchanged. This is informational: the import still completes. To use that data in this domain, download the database from the source domain's settings.

If the bundle was exported without Intent databases, the result notes that data that existed only in the source Intents' workspaces was not carried. Each imported DuckDB Intent without a workspace here starts from this domain's database; an Intent that already has a usable workspace keeps it. This note is informational and does not count as a warning.

Importing the same bundle again

Import the same bundle again to fix skipped Automations after their dependencies exist. Vibedata matches each Automation to the one it imported before, never by display name, so a re-import updates that Automation instead of creating a duplicate. It leaves other Automations in the Domain alone, including one with the same name. A re-import also makes you the owner, so a different Domain Owner can repeat the import. Restoring a bundle into the Domain it came from reuses the existing Automation rather than duplicating it.

While Vibedata finishes registering an imported Automation's schedule, its row shows Converging on the Jobs tab. Run now, edit, and delete are unavailable until that finishes, and changing or removing its schedule is refused. See Custom Automations.

Secrets in a bundle

If the bundle includes Secrets, import records each secret name and the store it came from; no values are imported. Names from Internal become empty entries in the Domain's Internal Secrets that you must fill in. An Internal name that already has an entry is left untouched, along with its value and history. Names from other stores are kept as requirements, and the result lists them under Imported secret names as created, preserved, or retained. If the bundle's secret store differs from the store this Domain uses, Vibedata shows a warning and continues. Names are not translated or written to the other store. Vibedata does not check whether the names exist in an external store, so create them there before the Domain needs them.

Before submission, Back to domain settings or Cancel leaves the form; Vibedata asks before discarding a changed draft. A failed attempt keeps your source entries and shows the actual safe error in Technical details. If Vibedata cannot confirm whether import started, select Refresh status before retrying; an interrupted response does not establish whether the request took effect.

Selecting Unlock domain, then confirming, requests cancellation and restores editing. Import recovery remains available after reload, backend restart, or a change of an authorized user.

How to archive or restore a Domain

Open General and select Archive when authorized. During Archiving, Vibedata prevents new work while it closes or archives Intents. If a running turn blocks the operation, Vibedata names the Intent and restores the prior Domain state.

If a child Intent has an invalid lifecycle state, the archive error names the Intent and explains the failed condition. Repair its resources if possible, or close that Intent from its workspace, then retry Archive. A runtime cleanup failure also identifies the affected Intent in Technical details. Automatic reconciliation continues unfinished runtime cleanup; retry archive after it settles. A failed archive leaves the Domain in its previous lifecycle state.

Archived, locked, archiving, and deleting Domains are read-only. Select an archived Domain and choose Unarchive in General when authorized. A successful Unarchive returns the Domain to Pending while readiness is re-established.

A deleting Domain's General section shows only its read-only details and a notice that the Domain is being deleted. Budget and lifecycle actions are hidden. Wait for the deletion to finish; the Domain then disappears from the list. If the Domain stays in Deleting, ask an administrator to resume the deletion through the API.

Quick reference

Action	Where
Create a Domain	Global rail Domains → Add domain
Edit identity or budget	Domain → General → Save
Configure a resource	Domain → Resources → resource row → Save
Refresh readiness	Domain → Resources → Reconcile
Review usage estimates	Domain → Usage
Export or import	Domain → General
Manage human access	Organization Settings → Users
Manage retained deleted Intents	Intent workspace