# Fieldloop Intake and Processing Generated: 2026-11-03T06:54:05.507Z Source build: local Canonical docs: https://teammately.ai/docs --- id: troubleshooting.fieldloop title: Fieldloop Intake and Processing summary: Diagnose destination, admission, source permission, processing, and Thread gaps without resubmitting changed data or inventing findings. kind: error product_area: troubleshooting status: stable updated: 2026-10-30 canonical: /docs/troubleshooting/fieldloop --- # Fieldloop Intake and Processing ## Symptom A submission has no expected log, a batch reports rejected or conflicting rows, processing is waiting, or captured records have not produced an expected Thread. ## Likely causes - The credential, Project or source destination does not match. - The original submitter's receipt is being read from another principal. - A retry changed content while keeping the same idempotency identity. - Intake is admitted but row processing is not complete. - Source processing consent is absent or revoked. - Provider capacity or a recorded processing failure delayed analysis. - The selected records do not support an inquiry. ## Fix Inspect the original receipt and its row counts first. Confirm the workspace, Project, source and original logical request. Retry an uncertain submission only with its exact content and key. Read Logs for captured content and processing state. Check the source's current permission and the reported error through the normal controls. Keep accepted records and their provenance intact. A missing Thread is not automatically an intake failure. Analysis may legitimately publish no inquiry. Do not invent a report, change source facts or broaden provider access to force a visible result. If a typed input-coverage discovery was published, inspect its related Inbox item separately. Report publication, Case generation and dataset adoption have different outcomes. ## Prevention Retain original source records until admission is known. Keep credentials in the host secret mechanism, preserve exact retry identity and monitor row outcomes rather than HTTP success alone. Configure source permission deliberately. Revoke processing through its owning control when needed; do not treat an access change as authorization to rewrite published history. ## Related task pages {% related-card-grid title="Related task pages" %} - [Fieldloop](/docs/fieldloop) - [Capture and Inspect Logs](/docs/fieldloop/ingest-logs) - [Read Fieldloop Threads](/docs/fieldloop/threads) {% /related-card-grid %} ## Related reference pages {% related-card-grid title="Related reference pages" %} - [API Keys and Delegated Access](/docs/admin-console/api-keys) - [Input Coverage Inbox](/docs/coverage-design/inbox) {% /related-card-grid %} --- 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: 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: 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 %}