# Capture and Inspect Logs
Generated: 2026-11-02T06:36:38.013Z
Source build: local
Canonical docs: https://teammately.ai/docs
---
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.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.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: 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.permissions
title: Permissions troubleshooting
summary: Separate Project membership from Expert Contribution assignment and readiness when an expert has no tasks available.
kind: error
product_area: troubleshooting
status: stable
updated: 2026-10-30
canonical: /docs/troubleshooting/permissions
---
# Permissions troubleshooting
Use this when project role, reviewer assignment, or approval ownership prevents someone from completing the intended work.
## Symptom
A user can access Teammately but cannot open the expected Project, or an expert reports **no tasks available** after opening their Contribution link. These symptoms belong to different owning surfaces.
## Likely causes
- The user or group is not listed under **Project Settings → Project Members**.
- The Contribution was requested for a different recipient.
- The Contribution exists but its next Task or Checkpoint is not ready.
- The current IP is blocked before Project membership is evaluated.
## Diagnostic checks
- Confirm that the user or group appears in **Project Members** for the intended Project.
- Open the Contribution from the sender-side Expert Contributions workspace and verify its recipient and status.
- Check whether the expert has an executable Task or Checkpoint, not merely whether the Contribution exists.
- If **Access Restricted** is visible, resolve the IP allowlist first.
## Fix
- Add the correct user or group under **Project Settings → Project Members** when Project access is missing.
- Correct the Contribution recipient through the owning Contribution workflow when the request went to the wrong person.
- Resolve lifecycle or readiness problems in Expert Contributions when access succeeds but no Task can be entered.
- Do not infer a permission from a role label or edit governed artifacts merely to make a control appear.
## Prevention
- Separate reviewer access from approval authority in review setup.
- Check assignments before launching a review session.
- Use a small pilot Contribution before assigning a larger specialist cohort.
- Keep project membership changes visible to review owners.
## Related task pages
{% related-card-grid title="Related task pages" %}
- [Request an Expert Contribution](/docs/expert-contributions/request-contribution)
- [Expert Contributions](/docs/expert-contributions)
- [Complete an Expert Contribution](/docs/expert-contributions/complete-contribution)
{% /related-card-grid %}
## Related reference pages
{% related-card-grid title="Related reference pages" %}
- [Permissions](/docs/reference/permissions)
- [Roles and Permissions](/docs/governance/roles-and-permissions)
- [Expert Contributions](/docs/expert-contributions)
{% /related-card-grid %}