# Workspace Integrations
Generated: 2026-11-02T06:33:39.714Z
Source build: local
Canonical docs: https://teammately.ai/docs
---
id: admin-console.integrations
title: Workspace Integrations
summary: Connect messaging, repository, trace-store, and training services through their own authorization and operating controls.
kind: reference
product_area: admin_console
status: stable
updated: 2026-10-30
canonical: /docs/admin-console/integrations
---
# Workspace Integrations
## Definition
Open **Admin → Integrations** to connect workspace services. Each connection supplies a specific workflow rather than a general permission to read or write every external resource.
## Fields, states, or lifecycle rules
- Messaging connections support their configured notification and test operations.
- Repository connections discover repositories accessible to the authorizing account.
- Trace-store connections supply their supported capture/import workflow.
- Training connections are selected separately by a Benchmark preparation.
- Connection state, account authorization and a successful downstream operation remain distinct.
## Messaging
Slack and Microsoft Teams have provider-specific connection controls. For Teams, installation and a personal-message test are distinct operations. Workspace settings alone do not confirm installation or that automatic notifications are enabled.
Read provider errors as operational outcomes rather than treating a visible integration card as proof of delivery.
## Repositories and trace stores
GitHub.com, GitLab.com and Bitbucket Cloud connections discover the repositories allowed by the account and installation. Bind the intended repository through Reference Materials and inspect its indexed content.
LangSmith and Langfuse have their own connection surfaces. Keep original record identity and scope when importing material; connected access does not approve the captured behavior.
## Training and inference
Weights training selects an active service connection, supported model and compatible method. Connection checks do not certify quota, create-job permission, storage access or training quality.
Some evaluation paths require an existing callable inference deployment. A training job does not automatically allocate serving resources for every service. The deployment-to-output association can be user-reported where the adapter identifies it that way.
## Credentials and resource boundaries
For setup steps and provider-specific recovery, use the [integration guides](/docs/integrations#connection-setup-guides). Each guide distinguishes workspace connection, Project selection and a successful downstream operation.
Use the provider's owning connection flow and approved secret mechanism. Keep access scoped to the authorized account, identity and resource. Existing Vertex and Baseten training adapters do not authorize Google platform storage, ambient developer credentials or a provider fallback.
A failed service operation should remain actionable in its owning workflow rather than being hidden by a substitute local service.
## Related task pages
{% related-card-grid title="Related task pages" %}
- [Reference Materials](/docs/agent-setup/reference-materials)
- [Export, Train, and Evaluate](/docs/weights-training/exports-and-training)
- [Fieldloop](/docs/fieldloop)
- [Admin Console](/docs/admin-console)
{% /related-card-grid %}
---
id: agent-setup.reference-materials
title: Reference Materials
summary: Connect project knowledge, inspect indexing state, and verify the blocks available to Teammately agents.
kind: reference
product_area: agent_setup
status: stable
updated: 2026-10-30
canonical: /docs/agent-setup/reference-materials
---
# Reference Materials
## Definition
Reference Materials is the Agent Setup workspace for project knowledge that Teammately agents may use. **Materials** manages sources such as websites, Git repositories, and uploaded files. **Indexed Reference** shows the published reference blocks available after extraction and indexing.
Reference Materials is project understanding, not governed correctness. A manual can support an agent's reasoning or an expert Contribution without automatically becoming a policy, rubric, case, or approved statement.
## Fields, states, or lifecycle rules
- A Connection identifies a source and its ingestion or freshness state.
- Website, Git, and file connections follow source-specific discovery and processing paths.
- Indexed Reference presents published blocks rather than a second editable copy of the source.
- Publication is atomic: agents should see a coherent published generation rather than a partially updated index.
- Reconnecting, refreshing, or processing a source can create a newer indexed generation. Completed Runs and Contributions keep their own recorded snapshot boundaries.
- Removing a Connection or source does not imply that previously materialized policies, rubrics, cases, or contribution records should be silently deleted.
- File upload acceptance depends on file type, size, content verification, and the active source-processing path.
## Materials and Indexed Reference
Use Materials to answer: which sources are connected, when were they processed, and does a source need attention? Use Indexed Reference to answer: what text or blocks can agents actually retrieve now? A successful connection is not enough if the expected controlling material never appears in Indexed Reference.
When sources conflict, retain the conflict in the indexed material and resolve correctness through an expert contribution or governed policy. Do not rewrite Project Context to hide source disagreement.
{% example-demo title="Example: reference publication check" %}
A team connects a policy website and a Git repository containing operational rules. After processing, the operator opens Indexed Reference and searches for the current exception clause. The website block is current, while the repository still contains an older rule. The operator keeps both sources visible and requests an expert Contribution to establish the controlling policy.
{% /example-demo %}
## Related task pages
{% related-card-grid title="Related task pages" %}
- [Product Quickstart](/docs/quickstart)
- [Project Context](/docs/agent-setup/project-context)
- [Request an Expert Contribution](/docs/expert-contributions/request-contribution)
{% /related-card-grid %}
---
id: weights-training.exports-training
title: Export, Train, and Evaluate
summary: Prepare an exact training package, launch an authorized provider job, and inspect a separately authorized held-out evaluation.
kind: task
product_area: weights_training
status: stable
updated: 2026-10-30
canonical: /docs/weights-training/exports-and-training
---
# Export, Train, and Evaluate
Use Overview to prepare a dataset download and Results to configure connected training and evaluation. Downloading a package does not submit a training job.
## Prerequisites
- A reviewed dataset with the intended splits.
- An export profile compatible with its method.
- An active provider connection for connected training.
- An available supported model and explicit authorization to launch.
## Prepare the package
Choose **Prepare download** in Overview. Inspect the pinned dataset, profile, counts and exclusions before creating the package. A ready package provides the canonical files and manifest for that exact dataset state.
Canonical demonstration and preference exports preserve their method-specific targets. The package can include train, validation and test files where those splits have members, plus its manifest and supporting instructions/materials. A provider-specific conversion is a separate compatibility boundary.
## Train deliberately
In Results choose the provider connection, base model and supported settings. Saving configuration alone does not upload data or start a job. Launch explicitly and follow the provider job identity and state.
Provider profiles govern supported text, materials, tools, trajectories or preference formats. An unsupported feature is rejected rather than silently removed. A successful connection probe does not establish create permission, quota or successful training.
The training transfer uses train and validation as supported. Test content remains held out. Do not upload benchmark Cases or protected rubric/construction context as learner data.
## Evaluate separately
Authorize evaluation through the supported inference connection or provider path. Training does not automatically provision an inference deployment for every service. Where the deployment association is user-reported, keep that distinction visible.
Inspect actual responses, rubric outcomes, completeness and the resulting model identity. A job that completed without a confirmed model output is not a verified trained candidate.
## Object and state changes
Package creation captures the selected dataset. Launch records an authorized training operation and provider job. Cancellation and evaluation have separate operations. Existing packages and accepted results remain attributable.
## Success criteria
- Package, dataset and provider job identities agree.
- Held-out data stays out of training.
- The resulting output is identified before evaluation.
- Evaluation uses actual behavior rather than job status.
## Common failure modes
- Assuming Save starts training.
- Dropping unsupported fields to fit a provider.
- Treating training completion as correctness.
- Claiming inference resources were provisioned merely because training succeeded.
## Related reference pages
{% related-card-grid title="Related reference pages" %}
- [Weights Training](/docs/weights-training)
- [Training Datasets and Coverage](/docs/weights-training/datasets)
- [Workspace Integrations](/docs/admin-console/integrations)
- [Inspect Evaluation Results](/docs/benchmark-evaluations/inspect-results)
{% /related-card-grid %}
## Related troubleshooting pages
{% related-card-grid title="Related troubleshooting pages" %}
- [Missing Outputs](/docs/troubleshooting/missing-outputs)
- [Benchmark run troubleshooting](/docs/troubleshooting/benchmark-runs)
{% /related-card-grid %}
---
id: fieldloop.overview
title: Fieldloop
summary: Connect captured application activity to source-grounded Threads and explicit coverage or expert follow-up.
kind: concept
product_area: fieldloop
status: stable
updated: 2026-10-30
canonical: /docs/fieldloop
---
# Fieldloop
Fieldloop connects captured application activity to questions about correctness and input coverage. Open **Fieldloop → Logs** to inspect captured records and **Threads** to read the resulting inquiries.
## Definition
A source describes where logs come from and how they may be processed. A log preserves captured input, output, messages, trajectories, actions, context or feedback. A Thread presents an inquiry grounded in selected source records and the relevant project context.
A captured log is not an approved standard. A report can identify an issue worth investigating without establishing that a candidate violated an applicable Policy or that every production request was represented.
## Decision checkpoint
| Need | Open | Boundary |
| --- | --- | --- |
| Inspect what was captured | Logs | Original content and source identity |
| Manage a source or inspect intake | Source controls in Logs | Destination and processing permission |
| Read an inquiry | Threads | Report, cited sources and history |
| Act on a missing input situation | Coverage Design → Inbox | Separate adoption decision |
| Ask a specialist to resolve meaning | Expert Contributions | Explicit request and expert judgment |
## Processing and source access
Capture and durable intake precede analysis. Automatic discovery uses the source's explicit processing permission and the selected pipeline. Revoking processing permission stops further screening; it does not convert old reports into different historical facts.
The backend owns model routing. Source settings and task data do not authorize a provider switch or override platform model selection.
## Read Threads
Inspect cited source records, relevant Cases and retrieved standards. A report can retain uncertainty, contrary examples and unresolved questions. Read the exact published material behind a citation rather than interpreting fluent prose as approval.
Coverage and Contribution handoffs remain explicit user choices. Fieldloop does not automatically contact experts, approve Policies or change benchmark membership.
## Preserve the source boundary
Published logs and reports remain attributable to their original captured content. User-requested deletion and background staging cleanup are separate operations. Do not infer a general retention or erasure guarantee from a processing status.
Use Fieldloop findings alongside deliberate benchmark construction. Capture volume alone does not prove production completeness, balanced coverage or correctness.
## Related reference pages
{% related-card-grid title="Related reference pages" %}
- [Capture and Inspect Logs](/docs/fieldloop/ingest-logs)
- [Read Fieldloop Threads](/docs/fieldloop/threads)
- [Input Coverage Inbox](/docs/coverage-design/inbox)
- [API Keys and Delegated Access](/docs/admin-console/api-keys)
- [Integrations](/docs/integrations)
{% /related-card-grid %}
---
id: admin-console.overview
title: Admin Console
summary: Use Admin in the main app to manage workspace access, integrations, API keys, Lemon instructions, and usage.
kind: reference
product_area: admin_console
status: stable
updated: 2026-10-30
canonical: /docs/admin-console
---
# Admin Console
Open **Admin** in the main Teammately app for workspace administration. Project Settings manages project-specific configuration; Benchmark workspaces own datasets, Contributions, evaluation and improvement.
## Definition
Admin groups controls into Directory, Security, Insights, Organization Settings and Integrations. Current destinations include Members, Domain Control, IP Address Control, Private connectivity, Audit Log, Usage Statistics, Lemon instructions, Profile, Support Settings, Integrations and API Keys.
## Fields, states, or lifecycle rules
- Workspace membership and project access are separate boundaries.
- Project membership and an expert's assigned Contribution are separate.
- API-key scope does not make an internal endpoint a supported external contract.
- A connected provider account does not by itself authorize every training or inference operation.
- Recorded usage quantities, processing health and charges have different meanings.
## Choose the owning control
Use Members and the relevant security controls for workspace participation and allowed access. Use Project Settings → Project Members for grants to one Project.
Use Lemon instructions for workspace-level activity guidance. Project overrides take precedence where configured, and change history is automatic.
Use Integrations for messaging, repository, trace-store and training connections. Each service has its own authorization, configuration and operational result. A successful connection check is different from delivery or a completed provider job.
Use API Keys to create a credential for the intended capability. Current types include Full Access, Read Only and Fieldloop Submission. Copy a newly issued value only into the approved secret mechanism.
## Inspect usage
Usage Statistics shows recorded measurements for the chosen date range and workspace processing state. Quantities are not charges. A processing-status failure does not erase already recorded quantities.
Follow the usage guide before interpreting pending processing, credit information or a ledger entry. This surface does not create an invoice or a new retention/compliance guarantee.
## Private connectivity
Private connectivity is available as part of your Teammately deployment. In the main Teammately app, open **Admin → Security → Private connectivity** to learn about AWS PrivateLink, Azure Private Link, or equivalent connectivity for your environment.
Private networking can cover:
- **Your network to Teammately:** private access for sending data, including Fieldloop logs, to Teammately.
- **Teammately to your model endpoint:** private access for model requests and responses.
Private connectivity is arranged as part of your overall Teammately setup. [Ask us](https://teammately.ai/contact) about your deployment.
## Access and authority
Read each permission from its owning surface. A role name used in an orientation page describes responsibility; it is not an exhaustive permission matrix. Approval authority over Policies, Rubrics or Contribution decisions remains with the corresponding workflow.
## Related task pages
{% related-card-grid title="Related task pages" %}
- [API Keys and Delegated Access](/docs/admin-console/api-keys)
- [Workspace Integrations](/docs/admin-console/integrations)
- [Usage Statistics](/docs/admin-console/usage)
- [Project Members](/docs/project-settings/project-members)
- [Lemon Instructions](/docs/project-settings/lemon-instructions)
{% /related-card-grid %}