Integrations
Definition
An integration connects customer-owned data or execution systems to a specific Teammately workflow. The useful boundary is not “send arbitrary records.” It is preserving enough identity, context, and version information for imported material to remain reviewable and for exported evidence to remain interpretable.
Choose the boundary
| need | Teammately boundary | preserve |
|---|---|---|
| Bring behavior examples into a Project | Assets Cases or the Case import workflow | source identity, input, materials, attributes, current Project Input Schema |
| Give agents Project knowledge | Agent Setup → Reference Materials | source document identity, indexing state, intended use |
| Evaluate outputs produced elsewhere | Benchmark Evaluations → Import reference outputs | immutable Benchmark Version, exact Case IDs, output identity, measured telemetry |
| Send work to specialists | Expert Contributions and Expert UI | assignment, task context, Contribution state, Checkpoint, provenance |
| Use evidence in another system | Run and Case result context | Run, Benchmark Version, Case version, Policy version, Rubric version, incomplete states |
Each pattern has a different lifecycle. Reference Materials are not Case materials. An external response is neither a Case-scoped reference output nor a Harness Version. A Contribution assignment is not a generic notification integration.
Data movement principles
- Read the owning product contract before transforming data. For Cases, start with Project Input Schema; for outputs, start with the immutable Benchmark Version.
- Use backend-issued IDs as join keys and customer IDs as correlation keys.
- Preserve versions when a downstream result depends on mutable source objects.
- Distinguish acceptance from completion. Upload, artifact processing, evaluation, and expert work can have separate states.
- Keep missing values missing. Do not turn unknown telemetry or incomplete evaluation into zero or false.
- Reconcile a small sample before moving a full collection.
Product UI and API boundaries
The product UI owns interactive setup, mapping, preview, conflict resolution, and human decisions. Automated integrations should use only a supported external contract that preserves the same object and version boundaries.
Internal browser endpoints, event payloads, database shapes, and service-to-service handlers are not customer integration contracts. Their presence in source code does not make them stable or safe to automate against.
Worked example
External candidate evaluation
A team produces assistant outputs in its own evaluation pipeline. It selects an immutable Benchmark Version, downloads the exact Case IDs, and maps one output to each Case. The imported output set becomes an output-only reference Run.
The team retains its own generation ID as correlation metadata while using the Teammately Run, Benchmark Version, and Case IDs as correctness-evidence identity. Missing cost remains absent. The Run becomes interpretable after Rubric evaluation completes; successful upload alone is not a result.
Fields, states, or lifecycle rules
- Projects scope reusable Cases, Project Context, Reference Materials, Harness assets, and correctness governance. Contribution-specific agent behavior and direction selection belong to benchmark-scoped Contributions.
- Benchmark Versions freeze the Case and evaluator boundary used by a Run.
- API keys belong to organization administration and do not replace Project permissions.
- Imports and evaluations can be asynchronous.
- External outputs create non-Harness reference evidence.
- Teammately evidence informs customer review; it does not record a customer deployment decision.
Source confidence
Code-backed: current Case, Reference Materials, Expert Contributions, and Benchmark Evaluation output-mapping surfaces prove the product data-movement boundaries described here. Exact Public API serialization remains separately publication-gated until the refreshed external service implements its contract.