# Running Expert Contributions for an Enterprise Assistant
Generated: 2026-09-13T04:43:13.846Z
Source build: local
Canonical docs: https://teammately.ai/docs
---
id: playbooks.enterprise-assistant-review
title: Running Expert Contributions for an Enterprise Assistant
summary: Collect expert judgment for assistants that must follow product, domain, and policy expectations.
kind: recipe
product_area: playbooks
status: stable
updated: 2026-08-23
canonical: /docs/playbooks/running-expert-contributions-enterprise-assistant
---
# Running Expert Contributions for an Enterprise Assistant
Use this playbook when an enterprise assistant needs domain experts to judge outputs before the team turns that judgment into standards and benchmarks.
## Contribution boundary
Use this when a named specialist must resolve a bounded correctness question that prepared Cases and source context cannot answer automatically. Do not use a Contribution as a general request to “review the assistant.”
## Request and complete the work
1. Name the decision the expert owns and select the smallest set of Cases that exposes it.
2. Prepare the Project Agent Brief, source material, Case context, questions, and allowed response form before sending the request.
3. In the Benchmark's **Expert Contributions** workspace, choose the recipient, Tasks, materials, and any Checkpoints required to confirm progress or handoff.
4. Pilot the Contribution with one specialist and verify that the recipient can enter the executable Task and has enough context to answer.
5. Preserve expert responses, rationale, unresolved questions, and Checkpoint state as Contribution provenance.
6. Inspect **Contributed Artifacts** and reconcile candidate Policies, Rubrics, Cases, or coverage observations into their owning project surfaces.
7. Apply the owning approval and version controls. Contribution completion does not automatically approve a Policy, Rubric, reference response, or Dataset membership change.
## Contribution is complete when
The required Tasks and Checkpoints have reached their terminal states, the expert's attributable answer is preserved, and every contributed artifact is either reconciled, rejected through its owning workflow, or left explicitly unresolved.
{% example-demo title="Procurement assistant review" %}
A procurement specialist receives five Cases that differ by spend authority, vendor category, and contract status. The Contribution asks one bounded question: who must approve each purchase, and what source controls that answer? The specialist completes the Tasks, explains two exceptions, and confirms the proposed boundary at a Checkpoint. Contributed Policies and Rubrics retain that provenance but become governed only after the accountable owner approves them in Correctness Governance.
{% /example-demo %}
## Evidence to collect
- Cases, candidate outputs, Project Agent Brief, source context, and constraints shown to reviewers.
- Checkpoint or interview records that capture reviewer rationale.
- Attributable expert answers, rationale, unresolved concerns, and Checkpoint state.
- Contributed artifacts and their reconciliation into Cases, Policies, Rubrics, or coverage observations.
- Benchmark coverage and run results produced after standards are approved.
## Related docs
{% related-card-grid title="Related docs" %}
- [Request an Expert Contribution](/docs/expert-contributions/request-contribution)
- [Complete an Expert Contribution](/docs/expert-contributions/complete-contribution)
- [Inspect Contributed Artifacts](/docs/expert-contributions/contributed-artifacts)
- [Read run results](/docs/benchmark-evaluations/inspect-results)
- [Run a benchmark](/docs/benchmark-evaluations/run-evaluation)
- [Importing cases](/docs/operating-manual/import-and-prepare-cases)
{% /related-card-grid %}
## Source confidence
Doctrine-backed: the approved product model treats expert work as attributable contribution rather than automatic approval. Linked code-backed pages define request composition, executable Tasks, Checkpoints, lifecycle, and contributed-artifact reconciliation.
---
id: expert-contributions.complete
title: Complete an Expert Contribution
summary: Work through form, chat, interview, case-review, and checkpoint tasks while keeping specialist judgment attributable.
kind: task
product_area: expert_contributions
status: stable
updated: 2026-08-22
canonical: /docs/expert-contributions/complete-contribution
---
# Complete an Expert Contribution
Complete a Contribution by following its prepared task sequence and making the requested specialist judgments from the evidence shown. The expert experience can adapt between structured forms, agent chat, interviews, case review, and checkpoints.
## Prerequisites
- A valid Contribution link or authenticated expert entry point.
- Access to the Contribution and its assigned tasks.
- Enough source and case context to explain each answer.
- A stable connection when the task uses realtime agent interaction.
## Steps
1. Open the Contribution and read its objective, selected cases, and expected components before answering.
2. Complete each task according to its type. Planned activities can be Case Review, Form, Chat, or Interview; Curation, Comparative, and Trajectory components shape the prepared work those activities present.
3. Use attachments and visible case materials as the evidence boundary. State uncertainty when the supplied material does not resolve the question.
4. At a checkpoint, inspect the proposed summary or artifact meaning. Checkpoints prepare and reconcile requirements, consolidator or Policy statements, interview requests or records, and Rubrics. Confirm only what matches your judgment; retry, revise, or leave unresolved anything that does not.
5. Continue through the task handoff until the Contribution reaches its final step.
6. Review the completion state. If the experience shows a waiting, retry, or synchronization state, do not assume the administrator has received final evidence until the product confirms it.
## Object and state changes
Answers create durable task responses and can advance task sessions, checkpoints, handoffs, and Contribution status. Chat or interview activity can produce transcripts and structured learning. Case review can attach judgment to selected cases. Completion makes the contribution available for reconciliation and materialization but does not itself make every proposed artifact governed.
Review tasks can be `PREPARING`, `BLOCKED`, `READY`, `IN_PROGRESS`, `COMPLETED`, `SKIPPED`, or `SUPERSEDED`. The expert runtime can be `PREPARING`, `READY`, `ACTIVE`, `FINAL_CHECKPOINT`, `COMPLETED`, or `EXHAUSTED`. Checkpoints can be preparing, ready, or reconciled, with individual requirements pending, retryable, materialized, empty, or failed. These layered states explain why a Contribution can be active while one task is blocked or a final checkpoint is still pending.
## Success criteria
- Every answer addresses the Contribution objective and cites the visible evidence where needed.
- Case-level judgments remain connected to the relevant case.
- Checkpoints distinguish accepted, revised, and unresolved meaning.
- The final state is visibly complete rather than inferred from navigation.
- Uncertainty or source conflict remains explicit for the administrator.
## Common failure modes
- Answering from private background without identifying that the supplied evidence is incomplete.
- Treating an agent summary as accurate without checking the checkpoint.
- Leaving a form or chat task in a local unsynchronized state.
- Continuing after a stale task handoff instead of following the current Contribution route.
- Assuming that completion directly changes policies, rubrics, cases, or coverage.
{% example-demo title="Example: checkpoint correction" %}
An interview summary says that every expired agreement should be ignored. The expert corrects the checkpoint: expired agreements may still be relevant when the current agreement explicitly incorporates them. The corrected statement remains attributable and prevents an overbroad policy from being materialized.
{% /example-demo %}
## Related reference pages
{% related-card-grid title="Related reference pages" %}
- [Expert Contributions](/docs/expert-contributions)
- [Contributed Artifacts](/docs/expert-contributions/contributed-artifacts)
- [Human Approval Boundaries](/docs/governance/human-approval-boundaries)
{% /related-card-grid %}
## Related troubleshooting pages
{% related-card-grid title="Related troubleshooting pages" %}
- [Expert Contribution problems](/docs/troubleshooting/expert-contributions)
- [Permissions](/docs/troubleshooting/permissions)
- [Authentication](/docs/troubleshooting/authentication)
{% /related-card-grid %}
## Source confidence
Code-backed: the current expert experience supports form, chat, interview, case-review, checkpoint, completion, waiting, and task-handoff routes with durable command and reconciliation behavior.
---
id: expert-contributions.request
title: Request an Expert Contribution
summary: Create a focused benchmark contribution with an accountable expert, clear objectives, selected cases, attachments, and appropriate task components.
kind: task
product_area: expert_contributions
status: stable
updated: 2026-09-07
canonical: /docs/expert-contributions/request-contribution
---
# Request an Expert Contribution
Request a Contribution when a benchmark needs a bounded piece of specialist judgment. The request should make the expert's decision clear, prepare the relevant evidence, and choose only the task components needed to obtain an attributable answer.
## Prerequisites
- A selected project and benchmark.
- An expert eligible for the contribution domain.
- A concrete contribution statement or unresolved correctness question.
- Selected cases, attachments, or scoped statements when the question depends on them.
- Project Context and Reference Materials prepared in Agent Setup; use **Assets → Review Screens** when the Contribution needs reusable expert-facing presentation.
## Steps
1. Open the benchmark and select **Expert Contributions → Contributions**.
2. Choose **Request Contribution**.
3. Complete **Objectives & Missions**. State the decision or knowledge the benchmark needs and select the application domain: Coverage Model, Benchmark Setup, or Evaluation Validation.
4. Complete **Choose Experts** and confirm that each selected expert has the right authority for the mission.
5. Complete **Contribution Components**. Available components are Curation, Comparative, Trajectory, Form, Chat, and Interview. Choose conservative, balanced, or exploratory agent behavior; Comparative accepts two to five candidates and can allow improvement.
6. Designate the relevant Cases. Select exact Case IDs and decide whether the contribution may add Cases beyond that set.
7. Add attachments and scoped statements only when they help resolve the mission. Supported attachment scopes include completed Contributions, Policies, Rubrics, Dimensions, ontology values, Project Topics or Groups, Construction Patterns, and Case candidates.
8. Review the captured attachment snapshot version and hash, generated activities, and checkpoints. Confirm that controlling evidence is frozen and consequential meaning will be reconciled.
9. Send the request and follow its state through Overview, Contributions, or Logs & Status.
## Object and state changes
This task creates a benchmark-scoped Contribution, associates experts, and records missions, application domain, Case designation, attachments, scoped statements, component behavior, and improvement permission. Planning materializes activities such as Case Review, Form, Chat, and Interview. Sending or starting work moves the Contribution toward `READY` or `IN_PROGRESS`; cancellation preserves the record.
## Success criteria
- The Contribution asks one coherent specialist question.
- The selected expert and application domain are appropriate.
- Every case or attachment is relevant to the objective.
- The chosen task types match the judgment required.
- Checkpoints protect decisions that should not be silently inferred.
- Attachment identities, scope statements, snapshot version, and hash are visible.
- The administrator can tell what artifacts may result and where they will be governed.
## Common failure modes
- Asking for general review without a materializable objective.
- Selecting many cases that do not illuminate the same decision.
- Leaving one-time behavior directions outside the Contribution objective, components, or scoped statements.
- Omitting the source or case material needed to explain a judgment.
- Assuming that task completion automatically approves contributed policies or rubrics.
{% example-demo title="Example: focused coverage contribution" %}
The objective asks an expert to decide whether source-freshness and customer-impact should form a distinct coverage slice. The operator selects six cases spanning those facets, attaches the controlling policy, and chooses case review plus a final checkpoint. The request can yield a coverage observation and a scoped rubric without asking the expert to redesign the entire benchmark.
{% /example-demo %}
## Related reference pages
{% related-card-grid title="Related reference pages" %}
- [Expert Contributions](/docs/expert-contributions)
- [Contributed Artifacts](/docs/expert-contributions/contributed-artifacts)
- [Review Screen](/docs/assets/review-screens)
{% /related-card-grid %}
## Related troubleshooting pages
{% related-card-grid title="Related troubleshooting pages" %}
- [Expert Contribution problems](/docs/troubleshooting/expert-contributions)
- [Permissions](/docs/troubleshooting/permissions)
- [Low expert agreement](/docs/troubleshooting/low-expert-agreement)
{% /related-card-grid %}
## Source confidence
Code-backed: the active Contribution composer defines expert selection, objectives, cases, attachments, statements, settings, and contribution components. Exact available components can depend on project and benchmark context.
---
id: governance.human-approval-boundaries
title: Human Approval Boundaries
summary: Define which AI-assisted suggestions require accountable human review before becoming standards.
kind: reference
product_area: governance
status: stable
updated: 2026-09-07
canonical: /docs/governance/human-approval-boundaries
---
# Human Approval Boundaries
## Definition
Human approval boundaries separate preparation from governed correctness evidence. A suggestion, reviewer comment, interview answer, or draft standard can inform the loop, but it should not govern benchmark interpretation until the relevant human approval state is clear.
Use this page when prepared or contributed material is about to become a governed Policy, Rubric, Case-scoped reference output, or selected Benchmark Dataset evidence.
Comparison Directions are a narrower configuration object, not a governed standard. An AI-suggested Comparison Direction can be active without a separate approval step, but generated Cases, Benchmark membership, Policies, Rubrics, and reference outputs still follow their owning review or approval boundaries. A customer-owned human review packet is assembled from evidence; it is not a Teammately approval state.
> Approval is a state transition
>
> AI-assisted suggestions do not become governed standards until an accountable human approves the relevant artifact.
## Fields, states, or lifecycle rules
- Draft suggestions and reviewer notes are preparation material.
- Approved Policies and Rubrics, reviewed Case changes, selected Dataset membership, and supported Case-scoped reference outputs can affect governed evidence.
- AI-suggested Comparison Directions can affect future variant generation as active directions, but they do not approve the generated cases or standards they help explore.
- Approval should name the artifact being approved, not only the discussion that produced it.
- Stale or superseded approvals should be visible before older benchmark evidence is reused.
- This page does not claim external compliance approval, legal signoff, or production deployment authorization.
## Related objects
Read this with [What AI Features Can and Cannot Do](/docs/governance/what-ai-features-can-and-cannot-do), [Comparison Directions](/docs/assets/comparison-directions), [Approving Suggested Policies](/docs/correctness-governance/policies-and-rubrics), [Editing Suggested Rubrics](/docs/correctness-governance/policies-and-rubrics), and [Approval History and Reviewer Activity](/docs/governance/approval-history-and-reviewer-activity).
{% example-demo title="Human Approval Boundaries boundary" %}
Reviewer context: Several experts reject unsupported refund exceptions.
Suggested policy: The system proposes a policy that exceptions require approved support.
Approval boundary: The suggestion becomes governed only when a human owner approves the policy and its applicability.
Benchmark interpretation: Runs should cite the approved policy, not the unapproved suggestion that preceded it.
{% /example-demo %}
## Source confidence
Code-backed: Policy approval and activity components expose accountable approval state and history; contributed-artifact types keep expert learning distinct from materialized governed objects. Comparison Directions deliberately use active, archived, and advisory-stale behavior instead of the Policy approval lifecycle.
## Related task pages
{% related-card-grid title="Related task pages" %}
- [What AI Features Can and Cannot Do](/docs/governance/what-ai-features-can-and-cannot-do)
- [Comparison Directions](/docs/assets/comparison-directions)
- [Review Policies and Rubrics](/docs/correctness-governance/policies-and-rubrics)
- [Product quickstart](/docs/quickstart)
- [Task index](/docs/operating-manual/task-index)
{% /related-card-grid %}