# Fieldloop Generated: 2026-11-02T06:32:31.713Z Source build: local Canonical docs: https://teammately.ai/docs --- 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: fieldloop.ingest title: Capture and Inspect Logs summary: Configure a source destination, submit captured application records, and distinguish durable admission from processing completion. kind: task product_area: fieldloop status: stable updated: 2026-10-30 canonical: /docs/fieldloop/ingest-logs --- # Capture and Inspect Logs Capture the application facts that explain a behavior question. Keep the original records until their admission is known. ## Prerequisites - The intended workspace, Project and Fieldloop source. - Authorization to submit to that destination. - Actual captured content and stable application event identities. - Explicit source processing consent where screening is enabled. ## Submit captured records Use the source's supported submission path with the configured destination. Application-library calls can submit batches and inspect receipts without installing a CLI or signing in through a browser. Follow the [Python](/docs/sdks/python), [TypeScript](/docs/sdks/typescript) or [Go](/docs/sdks/go) quickstart for a complete batch example, or use the [Fieldloop REST guide](/docs/public-api/fieldloop). Provide a Fieldloop submission credential through your application's approved secret mechanism. A newly created Fieldloop key grants that capability across its workspace; the sender still identifies the Project and source. Existing more restricted keys keep their restrictions. Preserve the exact batch content and idempotency key when recovering an uncertain request. A successful admission does not mean every row has completed processing. ## Inspect Logs Open Logs, choose the intended time range and source, then inspect the original record, relationships and processing state. Captured messages, context, trajectories and feedback remain distinct fields rather than a synthesized replacement for what happened. Read receipt counts for accepted, duplicate, conflicting and rejected rows. A processed batch can still contain row-level outcomes that need attention. ## Object and state changes Submission records durable intake and admits processing work. Processing publishes the captured log and its attributable snapshot. Further analysis can create or update Threads separately. SDK buffering can acknowledge memory before server admission. It is not a disk outbox or a guarantee of crash delivery. Caller-owned cancellation and recovery should preserve the exact source records and batch identity. ## Success criteria - Records reached the intended Project and source. - Original content and event identities are preserved. - Admission and processing outcomes are understood separately. - Credentials do not appear in logs, reports or copied tasks. ## Common failure modes - Using a key for another workspace. - Re-encoding changed content under the same retry identity. - Treating receipt polling as a new submission. - Assuming a captured record was analyzed without source consent. - Treating temporary client buffering as durable admission. ## Related reference pages {% related-card-grid title="Related reference pages" %} - [Fieldloop](/docs/fieldloop) - [Read Fieldloop Threads](/docs/fieldloop/threads) - [API Keys and Delegated Access](/docs/admin-console/api-keys) {% /related-card-grid %} ## Related troubleshooting pages {% related-card-grid title="Related troubleshooting pages" %} - [Fieldloop Intake and Processing](/docs/troubleshooting/fieldloop) - [Permissions troubleshooting](/docs/troubleshooting/permissions) {% /related-card-grid %} --- id: fieldloop.threads title: Read Fieldloop Threads summary: Inspect reports, citations, contrary examples, and explicit follow-up without treating an inquiry as an approved standard. kind: task product_area: fieldloop status: stable updated: 2026-10-30 canonical: /docs/fieldloop/threads --- # Read Fieldloop Threads A Thread is an inquiry grounded in captured application records. Read the report together with its cited source material and related project objects. ## Prerequisites - Permission to inspect the Thread and its original records. - The intended Project and source scope. - Enough retrieved context to distinguish a hypothesis from an established standard. ## Inspect the report 1. Open Fieldloop → Threads and select the inquiry. 2. Read the current report and its recorded history. 3. Follow citations to their original captured fields and versions. 4. Inspect relevant Cases, Policies or Rubrics where the report relies on them. 5. Preserve contrary examples, uncertainty and missing source context. 6. Choose an explicit follow-up only when the retrieved material supports it. A negative feedback signal alone does not overturn an expert decision. A possible model departure still needs an applicable standard and actual behavior. A source that was not retrieved cannot be inferred from a convincing summary. ## Follow up Prepared actions can route to coverage inspection, further investigation or a Contribution request. Review the destination and requested work before accepting it. Typed input-coverage discoveries can appear in Coverage Design Inbox. Correctness-only findings and arbitrary report paragraphs do not enter that flow. A prepared coverage draft and a dataset adoption decision remain separate. ## Object and state changes Reading a Thread is read-only. An accepted follow-up creates the owning work through its normal workflow. It does not automatically approve a Policy, contact an expert or add/remove Cases. A later publication can update the same inquiry while retaining source provenance and contrary material. Read the published history instead of assuming the newest report contains every earlier source in its opening summary. ## Success criteria - Important conclusions resolve to captured sources and relevant standards. - Interpretations remain distinguishable from the captured facts. - Any follow-up has a clear scope and owner. - Dataset changes receive explicit adoption decisions. ## Common failure modes - Treating report prose as governance approval. - Inferring population completeness from selected records. - Creating a Contribution without checking its intended expert and objective. - Calling an Inbox report resolved merely because generation finished. ## Related reference pages {% related-card-grid title="Related reference pages" %} - [Fieldloop](/docs/fieldloop) - [Input Coverage Inbox](/docs/coverage-design/inbox) - [Request an Expert Contribution](/docs/expert-contributions/request-contribution) {% /related-card-grid %} ## Related troubleshooting pages {% related-card-grid title="Related troubleshooting pages" %} - [Fieldloop Intake and Processing](/docs/troubleshooting/fieldloop) - [Unbalanced Coverage](/docs/troubleshooting/unbalanced-coverage) {% /related-card-grid %} --- id: coverage-design.inbox title: Input Coverage Inbox summary: Review attributable input-coverage findings and decide whether to generate, add, remove, or decline Cases. kind: task product_area: coverage_management status: stable updated: 2026-10-30 canonical: /docs/coverage-design/inbox --- # Input Coverage Inbox Use **Coverage Design → Inbox** when an expert or Fieldloop identifies an input situation that may change the Benchmark's selected Cases. ## Prerequisites - A settled source report delivered to the selected Benchmark. - Permission to manage its Cases. - Enough source context to decide whether the input need is relevant. ## Read the source Contribution reports contain effective expert-confirmed coverage observations and attributable newly synthesized Input Cases after their completion and checkpoint reconciliation. Settled results can also be retained from a cancelled Contribution. Fieldloop reports contain individually identified input-coverage discoveries tied to published sources and Benchmark references. A correctness-only report or an arbitrary paragraph does not become an Inbox item. Lemon Goal reports remain in their own feature. ## Decide each item A proposed new Case supports **Add to benchmark** or **Do not adopt**. An observation can lead to generating a new Case, adding existing Cases, removing current members, recording that no dataset change is needed, or declining adoption. Generation requests one new input under the project contract and stages it as a separate item. Inspect that Case and decide adoption. A failed generation or zero returned Cases leaves the observation open. ## Object and state changes Adoption changes editable membership and records the decision together. Retries preserve the original outcome. An already-present Case is not added twice. Items can be pending, in progress, applied, dismissed or withdrawn. Reports show **Needs review** while effective unresolved items remain and **Resolved** when none remain. Resolved does not necessarily mean the dataset changed: declined or withdrawn items can also be settled. Later attributable results can arrive in the same report. Corrected observations remain distinguishable from an older decision. A dismissed item is not reopened merely by rediscovery. ## Success criteria - Each action refers to the current source item. - Generated Cases receive a separate adoption decision. - Actual membership, rather than report viewing or generation completion, determines whether the dataset changed. - Historical Snapshots remain unchanged. ## Common failure modes - Treating a correctness concern as input coverage automatically. - Assuming generation adds a Case. - Interpreting Resolved as universal acceptance. - Repeating a settled decision because a report was refreshed. ## Related reference pages {% related-card-grid title="Related reference pages" %} - [Coverage Design](/docs/coverage-design) - [Contributed Artifacts](/docs/expert-contributions/contributed-artifacts) - [Fieldloop](/docs/fieldloop) - [Benchmark Dataset Cases](/docs/benchmark-datasets/cases) {% /related-card-grid %} ## Related troubleshooting pages {% related-card-grid title="Related troubleshooting pages" %} - [Unbalanced Coverage](/docs/troubleshooting/unbalanced-coverage) - [Expert Contribution problems](/docs/troubleshooting/expert-contributions) {% /related-card-grid %} --- id: admin-console.api-keys title: API Keys and Delegated Access summary: Choose the intended credential capability and keep workspace keys, delegated users, and browser access distinct. kind: reference product_area: admin_console status: stable updated: 2026-10-30 canonical: /docs/admin-console/api-keys --- # API Keys and Delegated Access ## Definition Use **Admin → API Keys** to manage workspace-owned credentials. A credential's base capability, optional restrictions and the destination's current permissions determine what a request can do. ## Fields, states, or lifecycle rules - The UI offers Full Access, Read Only and Fieldloop Submission. - The full key value is shown at creation; later lists use a masked value. - Renaming a key does not broaden its access. - Changing access requires issuing the intended credential. - Deleting a key removes its future credential path. - Expiry and project/action restrictions, when supplied, narrow the base capability. ## Fieldloop Submission A new Fieldloop key has the workspace-wide Fieldloop submission capability. Its application sender still specifies the intended Project and source. Current workspace, destination and source authority are rechecked by the backend. Future sources in the same workspace do not require copying the key into every source policy. Existing keys issued with narrower Project or source restrictions keep those restrictions. Supply the key through the application's approved secret mechanism. This ingestion path does not require CLI login, browser authentication or expanded login grants. ## Delegated developer access External Agents benchmark operations can also use delegated native login with explicit read/write scopes and current project read/manage permission. That user principal is different from an API-key principal. Browser cookie authentication remains the interactive app path. Do not substitute a browser cookie for a server credential or assume a delegated token is accepted on every API route. ## Scope and safe handling Use an explicit organization, Project, Benchmark and Version for the operation. Keep the key out of copied agent tasks, source files, Case materials and logs. A stable resource ID is not an authorization grant. The supported external contract defines endpoint schemas and required capability. An internal route or a visible key-management screen does not establish an unrestricted customer API. ## Related task pages {% related-card-grid title="Related task pages" %} - [Capture and Inspect Logs](/docs/fieldloop/ingest-logs) - [Work with External Agents](/docs/improve/external-agents) - [Permissions](/docs/reference/permissions) - [Admin Console](/docs/admin-console) {% /related-card-grid %} --- id: integrations.overview title: Integrations summary: Move Cases, source materials, external outputs, and benchmark results across Teammately's supported product boundaries. kind: concept product_area: data_integrations status: stable updated: 2026-10-30 canonical: /docs/integrations --- # 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 supporting information 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 supporting information 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. ## Connection setup guides | Need | Provider guides | | --- | --- | | Repository Reference Materials | [GitHub](/docs/integrations/github), [GitLab](/docs/integrations/gitlab), [Bitbucket Cloud](/docs/integrations/bitbucket) | | Select tracing inputs for Cases | [Langfuse](/docs/integrations/langfuse), [LangSmith](/docs/integrations/langsmith) | | Messaging | [Slack notifications](/docs/integrations/slack), [Microsoft Teams installation and tests](/docs/integrations/teams) | | Training or inference access | [Provider credentials, identity and checks](/docs/integrations/training-and-inference) | | Application/API automation | [Developer Guide](/docs/integrations/developer-tools), [SDKs](/docs/sdks), [CLI](/docs/cli), [REST](/docs/public-api) | ## Data movement principles 1. Read the owning product contract before transforming data. For Cases, start with Project Input Schema; for outputs, start with the immutable Benchmark Version. 2. Use backend-issued IDs as join keys and customer IDs as correlation keys. 3. Preserve versions when a downstream result depends on mutable source objects. 4. Distinguish acceptance from completion. Upload, artifact processing, evaluation, and expert work can have separate states. 5. Keep missing values missing. Do not turn unknown telemetry or incomplete evaluation into zero or false. 6. 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. {% example-demo title="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-supporting information identity. Missing cost remains absent. The Run becomes interpretable after Rubric evaluation completes; successful upload alone is not a result. {% /example-demo %} ## Private connectivity Private connectivity is available as part of your Teammately deployment for data ingestion and model inference. [Ask us](https://teammately.ai/contact) about AWS PrivateLink, Azure Private Link, or equivalent connectivity for your environment. Read [Admin Console](/docs/admin-console#private-connectivity) for the distinction between your network reaching Teammately and Teammately reaching your model endpoint. ## Fields, states, or lifecycle rules - Projects scope reusable Cases, source materials, agent configuration, and correctness governance. - 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 supporting information. - Teammately supporting information informs customer review; it does not record a customer deployment decision. ## Related task pages {% related-card-grid title="Integration workflows" %} - [Import Case Examples](/docs/integrations/import-case-examples) - [Reference Materials](/docs/agent-setup/reference-materials) - [Connect Model Outputs](/docs/integrations/connect-model-outputs) - [Expert UI](/docs/integrations/reviewer-workspace) - [Check candidate correctness](/docs/integrations/check-candidate-correctness) {% /related-card-grid %}