VDF AI Data

Governance and admin

How workspace admins manage settings, audit access, and keep VDF AI Data healthy across teams — without getting into the weeds of internals.

3 min read
On this page

A short guide for workspace admins

Most of the VDF AI Data documentation is written for the people using it day-to-day. This page is for the people responsible for keeping it well-run.

If you’re a workspace admin, the things you care about are slightly different. You’re not asking “how do I connect a source?” — you’re asking “are our connections healthy?” Not “how do I run EDA?” — but “is our team using this in the ways we expected?”

This page is the short tour of what you can see and adjust.

Good admin habits aren't heavy. Twenty minutes a month — a glance at settings, a review of recent activity, a quick audit of shared connections — keeps your VDF AI Data area healthy. The teams that get the most out of the product are the ones whose admins make small, regular passes.

Who has admin powers

Admin permissions are scoped at the workspace. Two roles are most common:

  • Workspace admin — full control over settings, connections, and team membership for one workspace.
  • Superadmin — platform-wide control across all workspaces, usually held by a small platform or IT team.

Most of what’s below applies to workspace admins. The few superadmin-only features are flagged clearly.

What you can see and adjust

Platform settings

The settings area is the single place where workspace defaults live. You’ll find groups for:

  • Defaults for new connections. Default visibility, default scope settings, default tags.
  • Defaults for new indexes and datasets. Default chunking, default models, default export formats.
  • Refresh cadence policies. Workspace-wide rules about how often connections should be re-tested.
  • Notification settings. Who gets pinged when a connection moves to “needs attention.”

Most teams don’t touch these on day one. After a month of real use, three or four settings usually want to be tuned to match how your team actually works.

Audit and activity logs

Every meaningful action in VDF AI Data — connections created, indexes built, datasets exported, searches run, settings changed — is logged. Admins can scroll the log directly, filter it by user, by source, by action, or by date range.

Three things audit logs are good for:

  • Investigating a surprise. “Who connected this source? When?”
  • Confirming a deletion. “Was the old connection actually removed, or just paused?”
  • Reviewing usage. “Which sources are getting used? Which are sitting idle?”

A weekly skim is enough for most teams. Save the deep dives for when something specific prompts them.

Error logs (superadmin)

Beyond audit, superadmins can see a platform-wide error log. This is the deeper signal — connection failures, build errors, refresh hiccups — that helps the platform team catch issues before users feel them.

The interface lets you filter by severity, source, time, and keyword. Most days, this log is quiet. The days it isn’t, you’ll be glad it’s there.

What stays private, what’s shared

A common question: who can see what an admin can see?

The honest answer: admins can see usage and activity, not content. That distinction matters.

  • An admin can see that a user built a vector index. They cannot see the contents of the chunks in it.
  • An admin can see that a user exported a fine-tuning dataset. They cannot see the prompt/completion pairs.
  • An admin can see that a user searched an index. They cannot see what came back.

What admins can control is access — who has permission to connect a source, build an index, export a dataset, see another user’s connections. That’s the right lever for governance.

Multi-tenant isolation, in plain language

Multi-tenant is a technical phrase for a simple idea: one team’s data is not another team’s data.

In VDF AI Data:

  • Every source is owned by a specific user or workspace.
  • A connection in one workspace cannot be referenced by another workspace.
  • An index in one workspace cannot be searched from another workspace.
  • A dataset in one workspace cannot be exported by another workspace.

For organizations running multiple workspaces — for example, one workspace per business unit — this is how the platform keeps things separate.

For organizations running a single workspace, this isolation still applies at the user level: personal sources stay personal unless explicitly shared.

For the full picture, see Privacy & Security.

Habits that keep VDF AI Data healthy

A short list of things to do on a calendar.

Weekly

  • Glance at the activity log. Any surprises? Anything new since last week worth noting?
  • Check the connections list. Any in “needs attention”? Fix or escalate.

Monthly

  • Review shared connections. Are they all still in use? Are they scoped narrowly enough?
  • Review default settings. Do they still match how the team actually works?
  • Run discovery on golden sources. A fresh discovery keeps tags and quality scores current.

Quarterly

  • Audit team membership. People who left should not still have access.
  • Audit indexes and datasets. Old indexes that no one uses are noise. Archive or delete.
  • Talk to your power users. A 15-minute conversation with someone using VDF AI Data heavily will reveal more than a hundred dashboard reviews.

When to escalate to the platform team

A few signals worth a ticket to whoever runs your VDF AI platform:

  • A connection keeps failing. If credentials and network checks pass and it still fails, that’s a platform question.
  • An index build keeps timing out. Usually a sign the source is much larger than the platform’s defaults expect.
  • You see error log entries you don’t recognize. Better to ask early than guess.
  • A regulation changed. New compliance requirements often need a small adjustment in platform settings.

A friendly note on changing settings

Resist the urge to tweak settings just because you can. The defaults are tuned for typical teams. The good moment to change a setting is when you’ve observed something specific — your team consistently builds smaller indexes than the default, your team rebuilds connections more often than the default expects — and a small tweak makes a real difference.

A change log on settings is a good practice. Even a one-line “raised default chunk size from X to Y because most of our text is shorter than expected” saves a future admin a confused afternoon.

Where to go next