# Activity history
Generated: 2026-11-13T08:01:24.687Z
Source build: local
Canonical docs: https://teammately.ai/docs
---
id: security.audit-activity
title: Activity history
summary: Inspect workspace activity, export filtered audit records, and distinguish those records from approval history, runtime credential events, and captured execution.
kind: reference
product_area: security
status: stable
updated: 2026-11-11
canonical: /docs/security/audit-activity
---
# Activity history
## Definition
The workspace Audit Log records supported application events with their actor and action context. An artifact's history records its own changes and decisions. Trialground records candidate behavior captured by supported instrumentation. Use the surface that owns the question you are investigating.
## Fields, states, or lifecycle rules
| Question | Surface | Scope |
| --- | --- | --- |
| Who performed a recorded workspace action? | Admin → Insights → Audit Log | Events available to the authorized workspace reader |
| Who approved or changed a Policy or other governed artifact? | The artifact's activity or approval history | The particular object and version |
| What did this candidate do? | Benchmark Evaluations → Results and recorded steps | Captured requests, responses, tool activity, and capture status |
| Which credential resolution was allowed or denied? | Runtime credential-access records | The credential service's execution context; separate from universal audit coverage |
### Inspect workspace events
Open **Admin → Insights → Audit Log**. Workspace audit access requires the `activitylogs:read_all` capability, granted separately from sign-in access and expert assignments.
Choose the date range and use the available actor, action, and IP filters. Inspect the action description and its Project or object context. When investigating missing results, check the selected range, filters, access, and the event types recorded by the operation.
### Export a filtered CSV
Use **Download first 1K records** to download the first 1,000 matching records with the selected filters. The export includes timestamp in UTC, user, action type, description, Project ID, and IP where recorded. It is separate from the currently displayed page size.
For a review requiring more than the exported population, narrow the date range and retain the filter and range context with each file. Confirm coverage of the review period rather than treating a 1,000-row file as a complete workspace history. Handle the download as workspace information under your organization's access and retention requirements.
### Interpret the records
Application events, infrastructure logs, approval history, and execution trajectories have distinct collection and retention scopes. The operational Log Analytics retention described in the Trust Center is not an Audit Log retention promise.
Captured execution records show the supported instrumentation and reported capture state. Interpret recorded actions alongside that capture state, and use the artifact's approval history to identify approved Policy versions and reviewer decisions.
The CSV export contains the matching application events described above. Review required event coverage, retention, delivery, storage, and integration needs as part of your security review, including any requirements for continuous delivery, immutable storage, or data-read records.
## Related task pages
{% related-card-grid title="Inspect the owning record" %}
- [Admin Console](/docs/admin-console)
- [Approval History and Reviewer Activity](/docs/governance/approval-history-and-reviewer-activity)
- [Trialground](/docs/concepts/trialground)
- [Security Review and Assurance](/docs/security/assurance)
{% /related-card-grid %}
---
id: security.overview
title: Security and Data
summary: Understand Teammately's security controls, customer-data flows, and the option to evaluate with synthetic Cases without uploading production records.
kind: concept
product_area: security
status: stable
updated: 2026-11-09
canonical: /docs/security
---
# Security and Data
You can develop and evaluate AI in Teammately without uploading your production Cases, customer conversations, or business records. Use synthetic Cases and fictional supporting materials to exercise the behavior your team needs. Configure the candidate's tools and credentials for a separate test environment.
Teammately also supports workflows using customer-supplied content. The data you enter, connect, generate, execute, and submit determines what each workflow processes.
## Decision checkpoint
| Your question | Read | What it explains |
| --- | --- | --- |
| Can we keep actual records outside the experiment? | [Synthetic Evaluation](/docs/security/synthetic-evaluation) | Constructed Cases, test-only environments, and what to inspect |
| What reaches Teammately and model services? | [Data Handling and AI Processing](/docs/security/data-handling) | Inputs, outputs, providers, storage, and geographic scope |
| Who can access our work? | [Access Control](/docs/security/access-control) | Workspace, Project, reviewer, artifact, and credential boundaries |
| How do we restrict network access? | [Network Controls and Isolation](/docs/security/network-isolation) | IP restrictions, private ingestion and inference, and execution boundaries |
| Which actions can we inspect or export? | [Audit Logs and Activity](/docs/security/audit-activity) | Workspace events, filtered CSV export, and artifact-specific history |
| Which security commitments apply? | [Trust Center](https://teammately.ai/trust) | Published controls, assessment status, providers, and agreement requirements |
| What should procurement review? | [Security Review and Assurance](/docs/security/assurance) | Independent assessment status and workflow-specific requirements |
| How can we explain a result later? | [Reproducibility](/docs/governance/reproducibility) | The Cases, criteria, and candidate versions used for assessment |
## Security controls and commitments
| Protection | How it works | Scope |
| --- | --- | --- |
| Customer files and backups | Azure Blob Storage encryption at rest with Microsoft-managed keys; public Blob access disabled | Customer and PostgreSQL backup storage accounts |
| Database storage | Platform-managed encryption for database-cluster disks | Database-cluster storage |
| Workspace and Project access | Server-side permissions, including direct user and workspace-group Project grants | The selected workspace, Project, and action |
| Protected files and previews | Authenticated workspace, Project access, and deletion checks | Access requires an authenticated, authorized request |
| Network access | Workspace IP restrictions and deployment-specific private connectivity | Inbound app access, ingestion, and model inference have distinct controls |
| Runtime credentials | Separate workspace secrets and explicit Harness grants | The selected Harness and its authorized execution context |
| Reviewable activity | Workspace Audit Log, artifact history, and recorded execution activity | Each surface records its own event types and scope |
| Recovery | Backup procedures, storage versioning, and soft deletion | Recovery protection and permanent erasure have different lifecycles |
The [Trust Center](https://teammately.ai/trust) gives the individual control descriptions, assessment methods, and dates. Core hosting location, model-processing geography, and traffic delivery are separate considerations.
Teammately does not use customer workspace data to train shared generative models without express written agreement. Providing a requested AI service can still involve processing and retaining content. Review the selected workflow and provider terms separately.
## Compliance and procurement
Use the Trust Center for Teammately's assessment and audit status, and the applicable agreement for contractual commitments. Each assessment identifies the organization and services it covers. Review the controls and agreement that apply to your intended workflows.
Teammately's security program follows the SOC 2 Security criteria, with controls assessed internally. An independent SOC 2 Type II audit is in progress. [Security Review and Assurance](/docs/security/assurance) explains how to review the assessment status and the scope of your intended workflows.
HIPAA-compliant deployments require a signed Business Associate Agreement and deployment approval before protected health information is submitted. The approved services, workflows, integrations, and data categories define that scope.
Retention, deletion, recovery, and processing requirements should cover the intended workflow, including model-service records, logs, files, and backups. A recovery window is separate from a permanent-erasure timeline.
## Related guides
{% related-card-grid title="Understand your data flow" %}
- [Data Handling and AI Processing](/docs/security/data-handling)
- [Access Control](/docs/security/access-control)
- [Synthetic Evaluation](/docs/security/synthetic-evaluation)
- [Network Controls and Isolation](/docs/security/network-isolation)
- [Audit Logs and Activity](/docs/security/audit-activity)
- [Security Review and Assurance](/docs/security/assurance)
{% /related-card-grid %}
---
id: security.access-control
title: Access Control
summary: Understand workspace and Project access, reviewer assignments, protected artifacts, and credentials granted to evaluation Harnesses.
kind: reference
product_area: security
status: stable
updated: 2026-11-09
canonical: /docs/security/access-control
---
# Access Control
## Definition
Authentication identifies the account. Workspace and Project permissions determine access to work. Reviewer assignments identify expert tasks. Harness secret grants authorize runtime credential use. These controls serve different purposes and should be reviewed separately.
## Fields, states, or lifecycle rules
| Access need | Owning control | What the control establishes |
| --- | --- | --- |
| Sign in to the intended workspace | The organization's configured authentication flow | Account identity and workspace context |
| Assign workspace responsibilities | Admin → Directory → Members | Workspace role assignments; separate from direct Project membership |
| Admit members from approved domains | Admin → Security → Domain Control | Domain restrictions on invitations when enabled |
| Restrict incoming workspace access | Admin → Security → IP Address Control | Enabled, nonempty IP allowlist at authenticated workspace access |
| Work with a Project | Project permissions assigned to users or workspace groups | The actions authorized for the selected Project |
| Complete assigned expert work | Contribution and reviewer assignment | The scoped reviewer work; separate from workspace administration |
| Read files, previews or thumbnails | Artifact authorization | Workspace and Project access plus deletion status |
| Use a credential from a Harness | Project secret access and the Harness grant | Runtime resolution for the identified candidate and execution context |
| Inspect workspace audit events | Audit Log read capability | Authorized workspace event access |
Required capabilities are action-specific. For example, updating Domain Control or IP Address Control requires `users:manage`, while workspace Audit Log access requires `activitylogs:read_all`. Check the assigned capabilities and the owning workflow's approval permissions for the action you intend to perform.
- Project permissions can be assigned to individual users or workspace groups. Check direct grants, group membership, and workspace roles when determining effective access.
- **Admin → Directory → Members** exposes workspace role assignments. **Project Settings → Project Members** exposes individual Project memberships.
- A reviewer being assigned a task is distinct from administering the Project or accessing every Project artifact.
- File, preview, and thumbnail access requires an authenticated request with the appropriate workspace and Project permissions, and a check of the artifact's deletion status.
- Workspace secrets are managed separately from Harness source. Management responses show metadata and masked hints. Runtime credential resolution checks the execution context, expiration, and active grants.
- Personnel infrastructure access is distinct from application permission checks. The security policy requires an authorized business purpose for personnel access to customer content.
### Identity and invitations
Sign-in uses the configured authentication flow for the intended organization. Review the enabled sign-in methods, MFA policy, account lifecycle, and session settings against your identity requirements as part of [Security Review and Assurance](/docs/security/assurance).
In **Admin → Security → Domain Control**, add the approved email domains, enable the invitation restriction, and save it. The control applies to invitations. Review existing Members and their roles separately when changing who should retain access.
### Credentials and the execution boundary
Grant a Harness only the credentials its selected experiment needs. For an experiment that keeps actual production data separate, use test-only identities and endpoints with no access to production records. Keep secret values out of Case content, source files, Run Metadata, and outputs.
The saved Harness, connected endpoints, and granted access determine what tools can retrieve alongside the synthetic Case. Review returned content and captured tool arguments or results as part of the experiment.
Runtime grants are tied to the selected candidate and execution context. A credential for one customer's endpoint is not replaced by a Teammately platform credential when that endpoint rejects it. Configure the matching endpoint and test-only customer credential together.
The [Permissions reference](/docs/reference/permissions) and object-specific guides explain operating access. The [Trust Center](https://teammately.ai/trust) describes the published security controls and their individual scope.
## Related task pages
{% related-card-grid title="Inspect the relevant access" %}
- [Reviewer and Project Access](/docs/governance/reviewer-and-project-access)
- [Permissions Troubleshooting](/docs/troubleshooting/permissions)
- [Harnesses](/docs/assets/harnesses)
- [Synthetic Evaluation](/docs/security/synthetic-evaluation)
- [Network Controls and Isolation](/docs/security/network-isolation)
- [Audit Logs and Activity](/docs/security/audit-activity)
{% /related-card-grid %}
---
id: governance.approval-history-reviewer-activity
title: Review and approve proposed standards
summary: Understand how approvals and reviewer actions support explainable correctness decisions.
kind: reference
product_area: governance
status: stable
updated: 2026-11-11
canonical: /docs/governance/approval-history-and-reviewer-activity
---
# Review and approve proposed standards
## Definition
Approval history records attributable decisions about a governed artifact. Reviewer activity records observable actions such as contribution progress, edits, comments, Checkpoint decisions, or materialization. They answer different questions: history explains which decision established the current governed state, while activity explains what work occurred around it.
Neither should be inferred from a final label alone. A Policy marked approved does not reveal every preceding suggestion, and activity does not become approval merely because an expert performed it.
## Fields, states, or lifecycle rules
- Approval belongs to the exact artifact or version shown by its owning surface.
- A Checkpoint decision can authorize Contribution progress or materialization without approving every related project object.
- Comments, interviews, task answers, and agent suggestions remain inputs until the owning workflow records an accepted or approved result.
- Current state and chronological activity should be read together; an older approval does not automatically govern a newer version.
- Reviewer identity, timestamps, and rationale are useful only when the product exposes them. Do not reconstruct missing history from private memory or internal logs.
- Use **Admin → Insights → Audit Log** for workspace events and the artifact's own activity view for its decisions and changes.
## Related objects
Read this page with [Contribution Lifecycle and Status](/docs/expert-contributions/lifecycle-and-status) for Contribution state, [Contributed Artifacts](/docs/expert-contributions/contributed-artifacts) for materialized learning, and [Human Approval Boundaries](/docs/governance/human-approval-boundaries) for accountable decisions. Policy and Rubric detail pages remain the authority for their current governed state.
{% example-demo title="Contribution work versus policy approval" %}
An expert completes an interview, edits a proposed exception, and approves a Contribution Checkpoint. The Contribution activity shows that work and the Checkpoint decision. When the accepted statement materializes as a Policy, its Policy detail records the governed version and approval context. A later reader can distinguish the expert's working history from the Policy version that actually entered benchmark results.
{% /example-demo %}
## Related task pages
{% related-card-grid title="Related task pages" %}
- [Complete an Expert Contribution](/docs/expert-contributions/complete-contribution)
- [Human Approval Boundaries](/docs/governance/human-approval-boundaries)
- [Expert Contributions](/docs/expert-contributions)
- [Complete your first alignment loop](/docs/quickstart)
- [Choose your starting point](/docs)
{% /related-card-grid %}
---
id: concepts.trialground
title: Trialground
summary: Execute saved Harnesses in managed sandboxes and assess recorded behavior against expert rubrics.
kind: concept
product_area: trialground
status: stable
updated: 2026-11-09
canonical: /docs/concepts/trialground
---
# Trialground
Trialground connects Harness execution with rubric evaluation. Your engineers can try candidate implementations across the situations in a benchmark and inspect how they behaved.
A change to retrieval, instructions, tool use, or orchestration becomes a concrete experiment with recorded inputs, responses, and judgments.
## Definition
Managed execution runs an exact saved Python Harness Version with its declared dependencies and selected benchmark inputs. Trialground prepares the dependency environment, manages execution, and retains outputs and captured trajectory events outside the sandbox.
**Benchmark Evaluations** provides **Runs**, **Results**, and **Dashboard**. A Run contains its planned Trials; each Trial exercises the candidate across the recorded Case population.
You can also submit externally executed responses, failures, and supported trajectories for assessment against the selected benchmark.
## Decision checkpoint
| Your question | Open | What to inspect |
| --- | --- | --- |
| Which candidate will execute? | Runs | Saved Version, machine, and Trial count |
| What did the agent do? | Results | Response, captured trajectory, and capture status |
| Why did it receive that score? | Results | Applicable rubrics, points, penalties, and gates |
| How do candidates compare? | Results and Dashboard | Comparable settings and complete populations |
| What happened across repetitions? | Run history | Independent Runs and the Run used for score |
## Prepare and run the experiment
Publish the intended Harness Version and grant the credentials it needs. Declared Python dependencies form the prepared execution image. Select the machine and Trials when launching an evaluation.
The Harness defines model calls, tools, task behavior, and state handling. An execution job can process several inputs in one process and workspace. Configure per-Case state and World reset behavior as part of the experiment.
Use synthetic Cases, fictional materials, and test-only endpoints and credentials to keep actual production records outside an experiment. A managed sandbox does not itself prevent a Harness from retrieving data through its configured tools. Outputs and captured activity remain part of the Run after execution ends. [Synthetic Evaluation](/docs/security/synthetic-evaluation) and [Data Handling and AI Processing](/docs/security/data-handling) explain these choices.
Use a saved-Harness debug run to try supplied inputs during development. Use a Benchmark Version to assess the candidate against a fixed Case population and criteria.
## Read recorded behavior and judgments
Captured trajectories make instrumented actions and tool use inspectable. Capture status identifies the recorded material available for assessment. Preserve any other execution files through the configured persistence path when the task needs them.
From **Results**, choose **Inspect recorded steps** for a Case or an individual Trial judgment. Recorded model requests and responses, tool arguments and results, and agent delegations retain their execution references. Supported instrumentation determines which actions are captured. Partial, unsupported, failed and unknown capture remain explicit; missing capture does not establish that an action was omitted.
Trajectory criteria assess recorded behavior. Response criteria assess the submitted answer. A saved judgment observation view preserves what its evaluator received, while the associated execution record supports investigation of the candidate. These records are separate from Lemon Goal's session narration and private model reasoning.
Rubric judgments feed the project Regime. Positive points reward passing conditions; penalties deduct for failures; mandatory gates express requirements that must pass. Incomplete judgments remain visible across the full population.
## Investigate the next change
Run evaluation reopens matching existing work. Use **Run again** for an independent repetition. **Used for score** identifies the Run chosen before its results were known.
Follow a failure into a Harness change, a coverage question, or clarification of the standard. Engineers can compare the proposed intervention against the same benchmark that motivated it.
## Related workflows
{% related-card-grid title="Run and inspect a candidate" %}
- [Run a Benchmark Evaluation](/docs/benchmark-evaluations/run-evaluation)
- [Evaluation Results](/docs/benchmark-evaluations/results)
- [Import External Evaluation Outputs](/docs/benchmark-evaluations/output-mapping)
{% /related-card-grid %}
## Related reference pages
{% related-card-grid title="Understand the experiment" %}
- [Harnesses](/docs/assets/harnesses)
- [Rubric Points and Benchmark Scores](/docs/correctness-governance/scoring)
- [Run Details and Metadata](/docs/benchmark-evaluations/run-details)
{% /related-card-grid %}