# Approval History and Reviewer Activity Generated: 2026-09-13T04:43:21.444Z Source build: local Canonical docs: https://teammately.ai/docs --- id: governance.approval-history-reviewer-activity title: Approval History and Reviewer Activity summary: Understand how approvals and reviewer actions support explainable correctness decisions. kind: reference product_area: governance status: stable updated: 2026-08-23 canonical: /docs/governance/approval-history-and-reviewer-activity --- # Approval History and Reviewer Activity ## Definition Approval history records attributable decisions about a governed artifact. Reviewer activity records observable actions such as contribution progress, edits, comments, Checkpoint decisions, or materialization. They answer different questions: history explains which decision established the current governed state, while activity explains what work occurred around it. Neither should be inferred from a final label alone. A Policy marked approved does not reveal every preceding suggestion, and activity does not become approval merely because an expert performed it. ## Fields, states, or lifecycle rules - Approval belongs to the exact artifact or version shown by its owning surface. - A Checkpoint decision can authorize Contribution progress or materialization without approving every related project object. - Comments, interviews, task answers, and agent suggestions remain inputs until the owning workflow records an accepted or approved result. - Current state and chronological activity should be read together; an older approval does not automatically govern a newer version. - Reviewer identity, timestamps, and rationale are useful only when the product exposes them. Do not reconstruct missing history from private memory or internal logs. - This documentation does not promise audit-log completeness, retention, export, or compliance behavior. ## Related objects Read this page with [Contribution Lifecycle and Status](/docs/expert-contributions/lifecycle-and-status) for Contribution state, [Contributed Artifacts](/docs/expert-contributions/contributed-artifacts) for materialized learning, and [Human Approval Boundaries](/docs/governance/human-approval-boundaries) for accountable decisions. Policy and Rubric detail pages remain the authority for their current governed state. {% example-demo title="Contribution work versus policy approval" %} An expert completes an interview, edits a proposed exception, and approves a Contribution Checkpoint. The Contribution activity shows that work and the Checkpoint decision. When the accepted statement materializes as a Policy, its Policy detail records the governed version and approval context. A later reader can distinguish the expert's working history from the Policy version that actually entered benchmark evidence. {% /example-demo %} ## Source confidence Code-backed: Policy detail exposes approval and activity sections, while Contribution detail exposes lifecycle and Checkpoint state. These surfaces support attributable current-state interpretation, not a general compliance or audit-retention guarantee. ## Related task pages {% related-card-grid title="Related task pages" %} - [Using Checkpoints](/docs/expert-contributions/complete-contribution) - [Human Approval Boundaries](/docs/governance/human-approval-boundaries) - [Expert Contributions](/docs/expert-contributions) - [Product quickstart](/docs/quickstart) - [Task index](/docs/operating-manual/task-index) {% /related-card-grid %} --- 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: 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 %} --- id: expert-contributions.overview title: Expert Contributions summary: Coordinate benchmark-scoped expert work, attributable judgment, governed artifacts, and the decisions that move correctness forward. kind: concept product_area: expert_contributions status: stable updated: 2026-09-07 canonical: /docs/expert-contributions --- # Expert Contributions Expert Contributions is the benchmark-scoped workspace for requesting, conducting, and materializing specialist work. It coordinates the expert, objective, selected evidence, task sequence, checkpoints, attributable responses, and contributed artifacts needed to move a benchmark forward. ## Definition The administrator workspace contains **Overview**, **Contributions**, **Contributed Artifacts**, and **Logs & Status**. **Request Contribution** opens the composer for a new contribution. The expert follows a contribution-specific experience that can contain form, chat, interview, and case-review tasks, along with checkpoints and completion states. A Contribution is the unit of requested expert effort. It replaces broad workflow configuration with a bounded statement of what this benchmark needs from this expert now. The work can result in contributed policies, rubrics, cases, or coverage observations without flattening all expert activity into one generic approval record. ## Decision checkpoint | Need | Contribution element | Result to inspect | | --- | --- | --- | | Resolve a specific benchmark question | Contribution statement and scoped objectives | The expert can explain the requested decision | | Ground work in concrete behavior | Selected or designated cases | Case-level responses remain attributable | | Supply supporting knowledge | Attachments and scoped statements | The expert sees the relevant source boundary | | Choose the right interaction | Form, chat, interview, or case review task | Task output matches the kind of judgment needed | | Confirm consequential learning | Checkpoint | Accepted, revised, or unresolved state is explicit | | Reuse the result | Contributed Artifacts | Policies, rubrics, cases, and coverage observations retain provenance | ## Lifecycle and status The durable Contribution statuses are `PREPARING_DIRECTION`, `AWAITING_DIRECTION_ALIGNMENT`, `MATERIALIZING_TASKS`, `READY`, `IN_PROGRESS`, `COMPLETED`, and `CANCELLED`. The interface presents these as planning direction, waiting for alignment, preparing tasks, ready, active, completed, or cancelled. The exact task sequence can vary by Contribution. Realtime updates and durable transitions help the administrator and expert see current progress without inventing completion. A waiting state, checkpoint, or finalization step should be shown as such. Completing the expert experience does not imply that every proposed artifact has been accepted into its project-level owner. ## Contribution evidence Logs & Status exposes operational and engagement records. Contributed Artifacts organizes materialized or contributed cases, policies, rubrics, and new coverage observations. Correctness Governance, Assets, or Coverage Management owns the resulting project or benchmark artifact after materialization. This model improves return on expert effort. Agents prepare focused work from project context, indexed material, benchmark cases, and unresolved questions. The expert supplies the authority; the result can be reused across standards, coverage, evaluation, and improvement. {% example-demo title="Resolve source authority" %} A benchmark contains cases where an operational runbook conflicts with a newer policy page. The operator requests a Contribution from the policy owner, selects the conflicting cases, attaches both sources, and uses case review plus a checkpoint. The expert establishes which source controls, contributes a scoped policy and rubric, and records one coverage observation for an unrepresented exception. {% /example-demo %} ## Related workflows {% related-card-grid title="Related workflows" %} - [Request an Expert Contribution](/docs/expert-contributions/request-contribution) - [Complete an Expert Contribution](/docs/expert-contributions/complete-contribution) - [Build policies and rubrics](/docs/operating-manual/build-policies-and-rubrics) {% /related-card-grid %} ## Related reference pages {% related-card-grid title="Related reference pages" %} - [Contributed Artifacts](/docs/expert-contributions/contributed-artifacts) - [Contribution lifecycle and status](/docs/expert-contributions/lifecycle-and-status) - [Logs & Status](/docs/expert-contributions/logs-and-status) - [Agent Setup](/docs/agent-setup) - [Human Approval Boundaries](/docs/governance/human-approval-boundaries) {% /related-card-grid %} ## Source confidence Code-backed: the active benchmark workspace, Contribution dashboard, composer, administrator detail, and expert routes support the scope, task, status, and artifact model described here.