Connect Model Outputs
Prerequisites
- An immutable Benchmark Version containing the Cases to evaluate.
- One externally produced output per required Case.
- Durable Case IDs from that Benchmark Version.
- A reference label that identifies the external system or candidate.
- Measured latency, usage, or cost only when the source system actually recorded it.
Before and after
| before | after |
|---|---|
| Outputs exist in an external file or system | Outputs are mapped to exact immutable Benchmark Cases |
| Candidate identity is customer-owned context | A Teammately reference Run preserves both its own ID and the external reference label |
| No Teammately evaluation state exists | Rubric evaluation proceeds as a separate Run lifecycle |
| Missing telemetry may be ambiguous | Unmeasured telemetry remains absent rather than becoming zero |
Map outputs
Connect external model outputs
- Open the intended Benchmark Version and go to Benchmark Evaluations → Runs.
- Choose Import reference outputs and name the external system or candidate clearly.
- Download the mapping template for the current Benchmark Version. Keep
case_idunchanged; use input and context columns only to verify the match. - Populate
outputfor each Case. Add latency, usage, or cost columns only for values measured by the producing system. - Upload the file and inspect unknown Case IDs, missing Benchmark Cases, duplicates, and output previews.
- Resolve every mapping error. Do not join on input text or force an output onto a similar-looking Case.
- Confirm the mapping and inspect the output-only reference Run.
- Wait for evaluation to complete before interpreting result summaries or failures.
Object and state changes
The workflow creates an ordinary output-only reference Run for one immutable Benchmark Version and associates submitted outputs with its Cases. It can also store measured telemetry supplied with those outputs.
It does not create or save a Harness Version, change Benchmark membership, mutate Cases, approve reference responses, or make the external candidate available to Improve as an executable Harness.
Success criteria
- Every output joins through the exact Case ID from the intended Benchmark Version.
- The reference label distinguishes this output set from other Runs.
- Unknown, missing, duplicate, inserted, and updated counts are understood before interpretation.
- Unmeasured telemetry is absent.
- The output-only Run is not presented as a managed Harness candidate.
- Result interpretation waits for evaluation completion.
Common failure modes
- Reusing IDs from the editable Project Case collection instead of the frozen Benchmark Version.
- Joining on input text, row order, or a customer ID without verifying the Teammately Case ID.
- Uploading outputs for two candidate versions under one reference label.
- Reporting missing latency or cost as zero.
- Treating successful mapping as successful evaluation.
- Assuming the reference Run can enter Harness Compare, Arena, or Improve as an executable candidate.
Worked example
Retrieval candidate outputs
A retrieval team evaluates a new indexing configuration outside Teammately. It exports one answer per frozen Benchmark Case and preserves its own generation ID. In the mapping template, each answer joins on case_id; the generation ID remains correlation context and measured latency is included.
The imported set becomes a reference Run. Teammately evaluates its outputs against the Benchmark Version's Policy and Rubric evidence, while the indexing configuration itself remains outside Teammately as a non-Harness system.
Related reference pages
Related troubleshooting pages
Source confidence
Code-backed: the current external-reference Run and output-mapping surfaces define the immutable Case join, template fields, reference-Run boundary, and result transition. Exact customer API serialization remains publication-gated separately.