Workspaces & members

A workspace is your company's container in Tattva. It holds members and projects. Members of the workspace get access to projects unless project-level permissions narrow that scope.

The five roles

Role	What it can do
Owner	Everything in the workspace, including renaming, member management, deletion. There is at least one owner per workspace.
Admin	Invite and remove members, manage projects, view the audit log, manage integrations. Cannot transfer or delete the workspace.
Member	Create projects, upload sources, ask questions, save decisions, run skills. The day-to-day role.
Viewer	Read-only access. Can see answers, reports and trackers but cannot upload sources, save decisions or change settings.
Ontology Admin (the DA role)	Parallel role granting authority over the Workspace Library — promoting sources, approving metric definitions, curating the company-wide ontology. This is the role your Data Analysts get. Grant it only to people you trust to set company-wide definitions.

Ontology Admin is not in the linear hierarchy — it's an extra capability granted independently. A user can be a Member + Ontology Admin, an Admin + Ontology Admin, etc. Outside the canonical ontology surface, an Ontology Admin behaves like a Member.

What a Data Analyst (DA / Ontology Admin) actually does day-to-day

The DA role is the one that maintains the Workspace Library — the company-wide layer of canonical metrics, conventions, sources, and glossary terms that every project inherits from. Concretely, a DA:

Reviews promotion requests. When an end user in a regular project says "this source / metric / definition should be canonical," it lands in the Promotion Inbox (/ontology/promotion). The DA approves, rejects, or defers — each call is audited.
Updates canonical metric definitions. When the company's definition of "Net Revenue" or "New Customer" evolves, the DA edits the canonical atom; every project picks up the new definition automatically.
Maintains the canonical source catalog. New master tables (SKU master, customer roster, geo dimension), version updates, deprecations.
Adjudicates conflicts. When two sources disagree, or two definitions exist for what should be one concept, the DA decides.
Manages overrides drift. When a project diverges from canonical, the DA watches for drift and proactively reconciles.

DAs don't typically run reasoning queries, create trackers, or log decisions — those are the day-to-day for Members. The DA's leverage is in making sure everyone else's queries return defensible answers.

Superadmin (platform-level, not a workspace role)

There's also a separate is_superadmin user flag for platform operators. Superadmins:

Bypass all workspace and project permission checks.
See the __canonical__ project ("Workspace Library") directly in the project switcher.
Are provisioned via SQL only — there's no in-app UI to grant or revoke.

This is for platform operators handling support and incident response, not regular roles in your team.

Where to find this

Open the workspace switcher (top-left) → click the gear icon, or go directly to /settings/workspace.

What's on the Workspace settings screen

Header — workspace name (e.g. "Kapiva") + stats line ("4 members · 16 projects").
General section — editable fields:
- NAME — the workspace's display name.
- SLUG — URL slug.
- Save button (disabled until a field changes).
Members section:
- Invite form at the top: email input + role dropdown (defaults to Member) + + Invite button (disabled until you enter an email).
- Member list below. Each row shows: avatar with initials, user ID (or email for newer accounts), role badge (OWNER / ADMIN / MEMBER / VIEWER / ONTOLOGY ADMIN), joined date, and a trash icon to remove.

Note: existing members may appear as user IDs (3bccd17d-d9f6-4cd1-…) rather than names/emails depending on when the account was provisioned. New invitations show the entered email.

Inviting a member

Note for the team: the current invite UI accepts an email address but does not yet send invitation emails. A user must already have signed in (via Google) for the invite to attach. A full email-invite flow is on the roadmap. End-users will see a "user not found" error if they try to invite someone who hasn't signed in yet.

To add someone:

Open Settings → Workspace.
Click Invite member.
Enter their email and pick a role.
Confirm.

If the user has signed in before, they appear in the members list immediately.

Changing a role

Open Settings → Workspace. Find the member. Use the role dropdown.

Only owners can promote someone to owner. Admins can change member ↔ viewer, member ↔ ontology admin, etc.

Removing a member

Click the trash icon next to the member's row and confirm.

Note for the team: the trash icon currently doesn't have a wired-up handler in the v1 UI. The DELETE endpoint exists. Confirm this with engineering before publishing the docs.

Removing a member revokes their session immediately and removes them from every project in the workspace.

Workspace lifecycle

Created when the first user signs up (Google OAuth flow).
Renamed from Settings → Workspace.
Deleted only by an owner.

Tips

Keep at least two owners for resilience.
Default new hires to Member. Promote to Admin when they need to manage other people.
Viewer is the right role for stakeholders who shouldn't be modifying state.
Only grant Ontology admin to the person responsible for company-wide metric definitions.

Permissions — what each role can actually do.
Audit log — who did what.

On this page