# Read Fieldloop Threads
Generated: 2026-11-02T05:40:16.708Z
Source build: local
Canonical docs: https://teammately.ai/docs
---
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: 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: 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: expert-contributions.request
title: Request an Expert Contribution
summary: Write a focused request, choose an expert, attach relevant project context, and inspect the prepared plan before requesting review.
kind: task
product_area: expert_contributions
status: stable
updated: 2026-10-30
canonical: /docs/expert-contributions/request-contribution
---
# Request an Expert Contribution
Use the Contribution composer to explain what specialist judgment the Benchmark needs. The request blueprint supplies context; the prepared plan makes the resulting work inspectable.
## Prerequisites
- A selected Project and Benchmark.
- An eligible expert.
- A concrete objective or unresolved question.
- Relevant Cases or source context when the question depends on them.
## Steps
1. Open **Expert Contributions → Contributions** and create a request.
2. Write the objective or mission in the request blueprint.
3. Type **@** to attach relevant context or **/** to choose available skills. Use attachments to identify the intended objects rather than relying on similar titles.
4. Choose the expert and inspect the displayed recommendations or activity where useful.
5. Attach the Cases, standards and review assets needed to explain the judgment.
6. Submit the request for planning.
7. Inspect the prepared direction, scope and activities before **Request expert review**.
8. Follow attributable responses, decisions and completion through the Contribution.
## Context and review assets
The composer can include Policies, Rubrics, Dimensions and ontology values, Topics and Topic Groups, Scenarios, Benchmark Cases, Comparison Directions, a Review Screen and Fieldloop Threads.
Choose one Review Screen. Comparison Directions guide alternatives; review-component selections express the kinds of work the planner can prepare. They do not approve the resulting content or force one conversational sequence.
Cases are included when the question needs them. Do not attach unrelated examples merely to fill a quota. A case-free expert question still needs enough authorized source context to be answerable.
## Object and state changes
Creation records the request, selected expert and contextual scope. Planning prepares the direction and activities; alignment authorizes the intended work. Assignment, visible task progress, artifact decisions and final Contribution completion remain separate.
Already accepted or completed work is not silently replaced by a later planning or settings edit.
## Success criteria
- The expert's requested judgment is clear.
- Attached objects and source context match that judgment.
- The prepared plan stays within the request.
- Review presentation and response alternatives have the intended scope.
## Common failure modes
- Following obsolete wizard steps instead of the request blueprint.
- Treating a comparison asset as an approved standard.
- Attaching more than one Review Screen.
- Using a persistent instruction for a one-time question.
- Assuming task completion approves every contributed artifact.
## Related reference pages
{% related-card-grid title="Related reference pages" %}
- [Complete an Expert Contribution](/docs/expert-contributions/complete-contribution)
- [Contributed Artifacts](/docs/expert-contributions/contributed-artifacts)
- [Review Screens](/docs/assets/review-screens)
- [Comparison Directions](/docs/assets/comparison-directions)
{% /related-card-grid %}
## Related troubleshooting pages
{% related-card-grid title="Related troubleshooting pages" %}
- [Expert Contribution problems](/docs/troubleshooting/expert-contributions)
- [Permissions troubleshooting](/docs/troubleshooting/permissions)
{% /related-card-grid %}
---
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: troubleshooting.unbalanced-coverage
title: Unbalanced Coverage
summary: Fix benchmarks that overrepresent easy or common cases while missing important behavior.
kind: error
product_area: troubleshooting
status: stable
updated: 2026-10-30
canonical: /docs/troubleshooting/unbalanced-coverage
---
# Unbalanced Coverage
Use this when benchmark results overrepresents some behavior and misses other behavior that matters before human review.
## Symptom
A benchmark looks strong in aggregate but reviewers or product owners identify important behavior areas with too few cases. Results may be dominated by common easy cases while rare or boundary cases are absent.
## Likely causes
- Case import mirrored production volume instead of product risk.
- Dimensions or metadata do not represent the behavior areas that matter.
- Synthetic cases were added in one area but not reviewed across the full risk boundary.
- Coverage was not refreshed after new signals, policy changes, or failures.
## Diagnostic checks
- Inspect **Benchmark Datasets → Representation** and the Coverage Design overview by the configured Coverage Facets.
- Look for policies or rubrics with very few applicable cases.
- Compare production or expert signals with benchmark case distribution.
- Inspect whether new cases are candidate-only or actually in use.
## Fix
- Add representative, boundary, or adversarial cases for undercovered areas.
- Refresh dimensions or metadata before judging balance.
- Review and promote candidate cases into the benchmark only after context is complete.
- Record remaining gaps as Coverage Stories or explicit benchmark coverage guidance.
## Prevention
- Define coverage targets before benchmark runs.
- Track candidate and in-use cases separately.
- Review coverage after policy, rubric, or product behavior changes.
- Do not use aggregate scores without a coverage note.
## Related task pages
{% related-card-grid title="Related task pages" %}
- [Dataset Representation](/docs/benchmark-datasets/representation)
- [Coverage Design Settings](/docs/coverage-design/settings)
- [Coverage Stories](/docs/coverage-design/coverage-stories)
{% /related-card-grid %}
## Related reference pages
{% related-card-grid title="Related reference pages" %}
- [Case Pool surface](/docs/object-model/case-pool)
- [Coverage dimensions](/docs/object-model/coverage-dimensions)
- [Benchmarks](/docs/object-model/benchmarks)
{% /related-card-grid %}