# Roles and Permissions
Generated: 2026-09-13T04:43:11.538Z
Source build: local
Canonical docs: https://teammately.ai/docs
---
id: governance.roles-permissions
title: Roles and Permissions
summary: Use roles and permissions to route ownership, review, and approval work clearly.
kind: reference
product_area: governance
status: stable
updated: 2026-09-07
canonical: /docs/governance/roles-and-permissions
---
# Roles and Permissions
## Definition
Roles and Permissions covers the access controls visible in the current product source. It is not a generic enterprise RBAC promise.
The main product exposes project permission management for users and groups. The Admin Console exposes workspace role management and permission keys. Orientation pages may describe common personas such as product owner, reviewer, expert, AI engineer, or administrator, but those personas are not exact permission values unless a code-backed source says so.
Use the roles table for organization access claims, and use project permission pages for project-level access claims.
## Fields, states, or lifecycle rules
- Main-product project permissions use user or group subjects and code-backed `ADMIN` or `MEMBER` project roles.
- Admin Console roles are workspace roles with permission keys managed through the admin app.
- Reviewer assignments and review ownership are workflow concepts; they should not be treated as workspace role names.
- Approval actions require accountable ownership; AI suggestions do not approve themselves.
## Related objects
Related objects may include workspace users, workspace groups, workspace roles, permission keys, project permission assignments, reviewer assignments, review sessions, approvals, and the correctness artifacts those users can access.
{% example-demo title="Human approval boundary" %}
A domain expert receives a Contribution and can complete its assigned Tasks. The same person is also a member of one Project, so they can inspect that Project's permitted surfaces. Neither fact makes them an organization administrator or grants authority to approve every governed artifact. Read access, Contribution assignment, artifact approval, and Workspace administration from their owning surfaces.
{% /example-demo %}
## Source confidence
Code-backed: this page is grounded in the main product project permission routes and Admin Console role management source listed in source_refs.
## Related task pages
{% related-card-grid title="Related task pages" %}
- [Request an Expert Contribution](/docs/expert-contributions/request-contribution)
- [Build policies and rubrics](/docs/operating-manual/build-policies-and-rubrics)
- [Manage Project Members](/docs/project-settings/project-members)
{% /related-card-grid %}
---
id: admin-console.overview
title: Admin Console
summary: Understand the organization-level administration surfaces available at admin.teammately.ai.
kind: reference
product_area: admin_console
status: stable
updated: 2026-09-07
canonical: /docs/admin-console
---
# Admin Console
The current Teammately product exposes the Admin Console as a workspace-administration mode under `/admin`. Use this page to distinguish organization-level administration from project-level correctness work in the project workspace. The shared product shell switches between project navigation and workspace administration while preserving the organization-level boundary.
> Administration boundary
>
> Use the Admin Console for organization controls. Use project and benchmark workspace docs for Cases, Expert Contributions, Policies, Rubrics, coverage, evaluations, and improvement evidence.
## Definition
The Admin Console groups organization administration into Directory, Security, Insights, and Organization Settings. The code-backed navigation includes Members, Groups, Roles & Permissions, Domain Control, IP Address Control, Audit Log, Usage Statistics, Profile, Support Settings, Integrations, and API Keys.
This page documents that those surfaces exist. It does not claim detailed compliance, billing, deployment, rate-limit, or security behavior unless a linked source file exposes that behavior directly.
The Admin Console is the organization administration surface. Group management is separate from project-level correctness work.
The Integrations screen shows notification and partner connection surfaces that belong to organization administration. Visible contact-support states should not be documented as self-serve integrations.
API Keys are managed in the Admin Console and should be documented as an organization administration surface, separate from project correctness artifacts.
> API key boundary
>
> Creating an API key establishes a credential; it does not make every internal endpoint a supported customer API. Endpoint availability, bearer authentication, required scopes, request and response schemas, and error behavior belong to the versioned Public API contract.
## Fields, states, or lifecycle rules
- Members and Groups are organization directory surfaces. Project-level membership and project permissions remain separate surfaces in the main product.
- Roles & Permissions in the Admin Console manage workspace roles and permission keys exposed by the admin application. Do not treat role names in orientation pages as exact permission contracts.
- Domain Control stores whether domain enforcement is enabled and which email domains are allowed for invitation.
- IP Address Control stores whether IP limiting is enabled and the configured allowlist.
- API Keys can be listed, created, copied at creation time, scoped, and deleted from the admin app surface. Treat the full value as a secret and create separate keys for separate integration boundaries.
- Slack is the currently clickable self-serve notification integration in the Admin Console. Microsoft Teams and the other listed partners are visible as contact-support or coming-soon surfaces in the current integrations index, so these docs should not describe them as self-serve integrations.
- Audit Log and Usage Statistics appear as admin console surfaces, but this page does not promise exact event schemas, retention periods, analytics definitions, or export behavior.
Domain Control and IP Address Control are organization-level security settings. They should not be described as project review or benchmark approval mechanisms.
IP Address Control exposes enforcement settings and should be documented only as an admin access-control surface.
## Product boundary
Use the Admin Console when the question is about organization access, security controls, API keys, notification integrations, or organization-level activity. Use project settings and product-area docs when the question is about cases, reviews, policies, rubrics, benchmarks, and project-specific permissions.
A reviewer persona, a Project member, a Workspace role, and an organization administrator are related but not identical. Read each access or authority claim from its owning surface.
Likewise, an API key, its Project access, and an endpoint's action scope are related but not identical. Key administration belongs here; the external service contract must define what a caller can actually do.
## Source confidence
Code-backed: this page is grounded in the current `/admin` workspace route, shared navigation mode, admin directory, integrations index, and representative admin route implementations listed in the frontmatter source_refs.
## Related task pages
{% related-card-grid title="Related task pages" %}
- [Manage Project Members](/docs/project-settings/project-members)
- [Resolve an IP access restriction](/docs/troubleshooting/authentication)
- [Troubleshoot permissions](/docs/troubleshooting/permissions)
{% /related-card-grid %}
## Related reference pages
{% related-card-grid title="Related reference pages" %}
- [Workspace administration](/docs/governance/workspace-administration)
- [Roles and permissions](/docs/governance/roles-and-permissions)
- [Permissions](/docs/reference/permissions)
{% /related-card-grid %}
---
id: reference.permissions
title: Permissions
summary: Understand the user-facing permission boundaries for projects, reviewers, settings, and expert UI access.
kind: reference
product_area: reference
status: stable
updated: 2026-09-07
canonical: /docs/reference/permissions
---
# Permissions
## Definition
Permissions describe the user-facing access boundaries that affect projects, reviewer work, settings, Expert UI access, and organization administration. Use this page to decide which access surface to inspect before diagnosing a blocked workflow.
This reference does not turn role labels into a complete public permission matrix. Exact permission behavior should stay tied to source-backed pages and the admin or project surfaces that expose it.
## Fields, states, or lifecycle rules
- Project access affects cases, standards, coverage, benchmark work, and project settings.
- Reviewer access affects assigned expert work and reviewer-facing surfaces.
- Organization administration affects members, groups, roles, security controls, API keys, and integrations.
- Role labels in docs should be treated as understandable operating labels, not as exhaustive permission contracts.
- Do not infer auth, security, compliance, tenant isolation, or billing guarantees from this reference.
## Related objects
Permissions should be read with [Admin Console](/docs/admin-console), [Workspaces and projects](/docs/concepts/workspaces-projects), [Permissions troubleshooting](/docs/troubleshooting/permissions), and [Reviewer and project access](/docs/governance/reviewer-and-project-access).
{% example-demo title="Permissions boundary" %}
Symptom: A reviewer can sign in but cannot complete assigned case review.
Permission boundary: The issue may be reviewer assignment, project access, Expert UI routing, or missing case context.
Interpretation: Diagnose access and assignment before changing cases, standards, or benchmark evidence.
{% /example-demo %}
## Source confidence
Code-backed: Project, user, and workspace types plus Project Permissions and Members surfaces support the user-facing boundaries described here. They do not form an exhaustive authorization matrix; assignment, organization administration, and object approval remain separate product states.
## Related task pages
{% related-card-grid title="Related task pages" %}
- [Admin Console](/docs/admin-console)
- [Workspaces and projects](/docs/concepts/workspaces-projects)
- [Permissions troubleshooting](/docs/troubleshooting/permissions)
- [Expert UI](/docs/integrations/reviewer-workspace)
- [Product quickstart](/docs/quickstart)
{% /related-card-grid %}
---
id: orientation.user-roles
title: User roles
summary: Understand the responsibilities of project operators, domain experts, AI engineers, accountable owners, and organization administrators.
kind: reference
product_area: reference
status: stable
updated: 2026-08-22
canonical: /docs/getting-oriented/user-roles
---
# User roles
## Definition
Teammately work is coordinated across responsibilities rather than one universal operator. A **project operator** maintains reusable context, assets, standards, and benchmark work. A **domain expert** supplies specialist judgment through Contributions. An **AI engineer** owns candidate Harness behavior and evaluation interpretation. An **accountable owner** decides how customer-owned downstream processes use the evidence. An **organization administrator** manages membership and organizational controls.
Product roles and permissions determine access, but responsibility can still vary by team. The important rule is to preserve who supplied judgment, who changed an artifact, and who owns the next action.
## Fields, states, or lifecycle rules
- Project operators configure Agent Setup, Project Input Schema, Coverage Facets, Assets, and benchmark work according to their access.
- Domain experts use the focused Contribution experience and do not require the full project workbench to complete assigned work.
- Expert profiles are global rather than a project-specific roster; a Contribution selects an appropriate expert for its application domain.
- AI engineers save Harness versions, start or inspect Benchmark Evaluations, and participate in Improvement Sessions.
- Accountable owners inspect versioned evidence and retain authority over downstream product, governance, or operational choices.
- Organization administrators manage organization-level access and controls without becoming the automatic approver of every policy, rubric, or Contribution.
- AI agents prepare and coordinate work but do not inherit human authority.
## Responsibility handoffs
An operator can prepare a Contribution, but the expert owns the specialist judgment. The resulting material can be reconciled into Correctness Governance, Assets, or Coverage Management. An AI engineer can change the Harness and produce new Runs, but cannot rewrite the expert provenance behind a rubric. An accountable owner can act on the evidence without turning that action into a Teammately artifact unless a source-backed workflow exists.
{% example-demo title="Example: role handoff" %}
A project operator requests a grounding Contribution from the policy owner. The expert confirms source authority and contributes a rubric. The operator reconciles it in Correctness Governance. An AI engineer evaluates a saved Harness version and starts an Improvement Session from the failures. The accountable product owner later decides what downstream action to take from the evidence.
{% /example-demo %}
## Source confidence
Code-backed: current project navigation, Contribution expert routes, and administration surfaces support these responsibility boundaries. Exact permissions remain governed by the active role configuration.
## Related task pages
{% related-card-grid title="Related task pages" %}
- [Request an Expert Contribution](/docs/expert-contributions/request-contribution)
- [Complete an Expert Contribution](/docs/expert-contributions/complete-contribution)
- [Run a Benchmark Evaluation](/docs/benchmark-evaluations/run-evaluation)
{% /related-card-grid %}
---
id: expert-contributions.overview
title: Expert Contributions
summary: Coordinate benchmark-scoped expert work, attributable judgment, governed artifacts, and the decisions that move correctness forward.
kind: concept
product_area: expert_contributions
status: stable
updated: 2026-09-07
canonical: /docs/expert-contributions
---
# Expert Contributions
Expert Contributions is the benchmark-scoped workspace for requesting, conducting, and materializing specialist work. It coordinates the expert, objective, selected evidence, task sequence, checkpoints, attributable responses, and contributed artifacts needed to move a benchmark forward.
## Definition
The administrator workspace contains **Overview**, **Contributions**, **Contributed Artifacts**, and **Logs & Status**. **Request Contribution** opens the composer for a new contribution. The expert follows a contribution-specific experience that can contain form, chat, interview, and case-review tasks, along with checkpoints and completion states.
A Contribution is the unit of requested expert effort. It replaces broad workflow configuration with a bounded statement of what this benchmark needs from this expert now. The work can result in contributed policies, rubrics, cases, or coverage observations without flattening all expert activity into one generic approval record.
## Decision checkpoint
| Need | Contribution element | Result to inspect |
| --- | --- | --- |
| Resolve a specific benchmark question | Contribution statement and scoped objectives | The expert can explain the requested decision |
| Ground work in concrete behavior | Selected or designated cases | Case-level responses remain attributable |
| Supply supporting knowledge | Attachments and scoped statements | The expert sees the relevant source boundary |
| Choose the right interaction | Form, chat, interview, or case review task | Task output matches the kind of judgment needed |
| Confirm consequential learning | Checkpoint | Accepted, revised, or unresolved state is explicit |
| Reuse the result | Contributed Artifacts | Policies, rubrics, cases, and coverage observations retain provenance |
## Lifecycle and status
The durable Contribution statuses are `PREPARING_DIRECTION`, `AWAITING_DIRECTION_ALIGNMENT`, `MATERIALIZING_TASKS`, `READY`, `IN_PROGRESS`, `COMPLETED`, and `CANCELLED`. The interface presents these as planning direction, waiting for alignment, preparing tasks, ready, active, completed, or cancelled. The exact task sequence can vary by Contribution.
Realtime updates and durable transitions help the administrator and expert see current progress without inventing completion. A waiting state, checkpoint, or finalization step should be shown as such. Completing the expert experience does not imply that every proposed artifact has been accepted into its project-level owner.
## Contribution evidence
Logs & Status exposes operational and engagement records. Contributed Artifacts organizes materialized or contributed cases, policies, rubrics, and new coverage observations. Correctness Governance, Assets, or Coverage Management owns the resulting project or benchmark artifact after materialization.
This model improves return on expert effort. Agents prepare focused work from project context, indexed material, benchmark cases, and unresolved questions. The expert supplies the authority; the result can be reused across standards, coverage, evaluation, and improvement.
{% example-demo title="Resolve source authority" %}
A benchmark contains cases where an operational runbook conflicts with a newer policy page. The operator requests a Contribution from the policy owner, selects the conflicting cases, attaches both sources, and uses case review plus a checkpoint. The expert establishes which source controls, contributes a scoped policy and rubric, and records one coverage observation for an unrepresented exception.
{% /example-demo %}
## Related workflows
{% related-card-grid title="Related workflows" %}
- [Request an Expert Contribution](/docs/expert-contributions/request-contribution)
- [Complete an Expert Contribution](/docs/expert-contributions/complete-contribution)
- [Build policies and rubrics](/docs/operating-manual/build-policies-and-rubrics)
{% /related-card-grid %}
## Related reference pages
{% related-card-grid title="Related reference pages" %}
- [Contributed Artifacts](/docs/expert-contributions/contributed-artifacts)
- [Contribution lifecycle and status](/docs/expert-contributions/lifecycle-and-status)
- [Logs & Status](/docs/expert-contributions/logs-and-status)
- [Agent Setup](/docs/agent-setup)
- [Human Approval Boundaries](/docs/governance/human-approval-boundaries)
{% /related-card-grid %}
## Source confidence
Code-backed: the active benchmark workspace, Contribution dashboard, composer, administrator detail, and expert routes support the scope, task, status, and artifact model described here.