Data handling
Definition
Customer content includes more than uploaded Cases. Project instructions, Reference Materials, expert contributions, files, candidate responses, and captured tool activity can all contain business information. Synthetic experiments process and retain the selected context, constructed inputs, and resulting activity according to the chosen workflow.
Fields, states, or lifecycle rules
| Workflow | Information processed | What to review |
|---|---|---|
| Project setup and expert work | Entered instructions, materials, comments, answers, and supported recordings | Which information participants supply and who can access it |
| Case synthesis | Coverage requirements, supplied context, generation instructions, and generated Cases or materials | Whether every source is suitable for the intended processing |
| Managed Trialground execution | Selected Case inputs, materials, saved Harness, outputs, and captured trajectory events | Tools, granted credentials, model calls, returned data, and retained records |
| External execution and output submission | Benchmark Cases and criteria held in Teammately, plus submitted responses, failures, and any included trajectories | What remains in your environment and what the submission transmits |
| Connected integrations | Data selected for the specific connection and operation | Provider, access scope, processing location, and applicable terms |
Follow the information through the workflow
For a synthetic experiment, permitted Project context and fictional requirements feed Case and material generation. The selected Cases, materials and saved Harness then enter managed execution, or your own execution environment. Submitted responses and captured activity enter assessment and the resulting Run records.
| Information | Where it enters or remains | Selection and access responsibility |
|---|---|---|
| Project Agent Brief and coverage definitions | Context for construction and other selected AI workflows | Review the Brief and relevant Dimensions, Topics, Scenarios, and source descriptions |
| Sample Cases and source material | Generation context when the selected operation includes them | Remove unapproved samples before preparation; new synthesis and source exclusion are different choices |
| Inputs, generated materials and candidate code | Benchmark assets and the selected execution | Project permissions and candidate selection govern use |
| Tool requests and returned content | The Harness's configured services and supported captured activity | Endpoints, resource permissions, credential grants, and capture configuration |
| Responses and recorded execution | Run, Results, and supported execution records | Review content before external submission and apply the intended access scope |
| AI-service state | The model feature requested by the owning workflow | Provider terms, feature configuration, processing location, and retention scope |
Private ingestion and inference provide private transport for agreed paths. Review the submitted information and each service's processing location alongside that network configuration. See Network Controls and Isolation.
Core services and processing locations
The Trust Center lists Microsoft Azure for application hosting, databases, storage, backups, and AI processing; Auth0 for authentication; and Cloudflare for proxied traffic and delivery. Core Azure hosting is in Central US. Model services and traffic delivery have their own processing geographies, described below and in the Trust Center.
Teammately's platform AI processing uses Azure OpenAI or Microsoft Foundry. Global model deployments may process prompts and responses across supported geographies. Customer-selected Harness endpoints and integrations have their own processing scope.
Model training and service storage
Teammately does not use customer workspace data to train shared generative models without the customer's express written agreement. This commitment is separate from processing content for a requested service or retaining operational records. Customer-requested weights training is a separate workflow with its own selected dataset and provider.
Model-service storage follows the selected API feature and workflow. Managed execution retains outputs and captured trajectory events outside the sandbox, where they remain available after execution ends under the applicable retention arrangements. Review Microsoft's AI data-processing terms alongside the features and integrations you select.
Retention, deletion, and recovery
Your requirements should distinguish active application records, files, model-service data, logs, and backups. The applicable agreement and selected workflows determine the retention and deletion commitments. Storage soft deletion and backup recovery periods describe recovery protection. Permanent-erasure timelines apply to the agreed records and stores in the deletion scope.
The Privacy Policy and Trust Center describe privacy-request handling. Customer-controlled workspace content is handled on the customer's documented instructions, with identity and authority checks where appropriate.
| Record category | Retention or deletion scope to establish |
|---|---|
| Active Project and Benchmark records | The selected objects, permitted use, historical versions, and applicable agreement |
| Files, generated artifacts and supported recordings | Originals, derivatives, versions, and references held by the workflow |
| Model-service records | Uploaded content and stored state requested by the selected feature |
| Application and audit logs | The relevant event collection and its retention; infrastructure-log retention is separate |
| Backups and recovery copies | Recovery windows, expiration, and the handling of previously deleted content after restoration |
Use the privacy-request process to identify the authorized objects and stores in a deletion request. Record the agreed completion criteria and treatment of historical or recovery copies. Review active records, retained execution data, and recovery copies as distinct parts of that scope.
Recovery objectives
Teammately's published controls describe database backup and restoration procedures, storage versioning, and soft-deletion protections. Review those protections alongside the required recovery point and recovery time, then define the applicable objectives for the agreed deployment and workflows.