# Resolve conflicting correctness evidence Generated: 2026-09-13T04:39:39.423Z Source build: local Canonical docs: https://teammately.ai/docs --- id: governance.conflict-resolution title: Resolve conflicting correctness evidence summary: Reconcile disagreement without hiding the Cases, expert judgments, sources, or versions that produced it. kind: task product_area: governance status: stable updated: 2026-08-23 canonical: /docs/governance/conflict-resolution --- # Resolve conflicting correctness evidence ## When a conflict needs resolution Resolve a conflict when experts reach different conclusions from the same Case, when governed Policies contradict one another, when a Rubric tests a broader or narrower rule than its Policy, or when new source evidence changes the standard that earlier Benchmark Versions used. Disagreement is not automatically a reviewer-quality problem. It often exposes missing context, mixed applicability, an unresolved source hierarchy, or two legitimate product boundaries that should be modeled separately. ## Prerequisites - Name the exact Case versions, outputs, Policies, Rubrics, expert responses, and sources in conflict. - Preserve attribution and timestamps. Do not collapse opposing judgments into an unattributed summary. - Separate factual disagreement from scope disagreement and from differences in desired product behavior. - Identify the accountable owner for any governed object that may change. ### Task steps: Resolve a correctness conflict 1. Open the affected governed object or Contribution and collect the linked Cases, expert rationale, source material, and activity history. 2. Reconstruct each position in its strongest form: what evidence it uses, which situations it covers, and which outcome it recommends. 3. Test whether the conflict disappears when applicability, target-system context, user segment, source authority, or time boundary is made explicit. 4. If one position lacks required evidence, record that finding without erasing the original contribution. 5. If both positions are valid in different contexts, split or refine the Policy, applicability, Rubric, Case, or coverage facet that conflated them. 6. Have the accountable owner approve the resulting governed change. Expert participation alone does not approve it. 7. Mark affected current evidence for follow-up, create new versions or a Snapshot where required, and preserve older Runs under their original boundary. ## Object and state changes - Correct the **Case** when required context or the judged output is wrong. - Correct the **Policy** when the behavioral rule or its scope is wrong. - Correct the **Rubric** when the test does not faithfully check the Policy. - Correct **coverage facets or membership** when the benchmark over- or under-represents a boundary. - Create a new **Benchmark Version** when the governed evaluation boundary changes. - Keep an unresolved observation explicit when the source evidence cannot yet support a decision. ## Success criteria - A reviewer can see the original positions and the evidence behind each. - The resolution names the artifact and version that changed. - Approval authority is explicit. - Downstream Case selection, standards, Snapshots, Runs, or customer-owned human review context are either still valid under a named boundary or routed for refresh. - The team did not manufacture agreement by deleting dissenting evidence. ## Common failure modes - Voting before reconstructing the evidence and applicability behind each position. - Editing a downstream Rubric when the conflict belongs to a Case or Policy boundary. - Treating expert participation as approval of a governed object. - Erasing dissent or historical versions after a resolution is approved. {% example-demo title="Two valid refund rules" %} One specialist rejects every refund exception; another approves exceptions for enterprise accounts. Their Cases reveal that both followed different authoritative programs. The team adds an account-program applicability boundary, revises the Policy and linked Rubrics, records the approval in activity history, and creates a new Benchmark Version. The earlier expert responses remain attributable evidence for why the split was needed. {% /example-demo %} ## Source confidence Code-backed: Policy and Rubric detail routes expose governed objects, linked Cases, approval, and activity history, while Contribution review results preserve attributable expert learning. The evidence-reconciliation method is doctrine-backed; no single product screen automatically adjudicates every cross-object conflict. ## Related reference pages {% related-card-grid title="Related workflows" %} - [Human Approval Boundaries](/docs/governance/human-approval-boundaries) - [Versions, staleness, and resolution](/docs/object-model/versions-staleness-and-resolution) - [Approval History and Reviewer Activity](/docs/governance/approval-history-and-reviewer-activity) {% /related-card-grid %} ## Related troubleshooting pages {% related-card-grid title="Diagnose disagreement" %} - [Low expert agreement](/docs/troubleshooting/low-expert-agreement) - [Unclear Cases](/docs/troubleshooting/unclear-cases) - [Overlapping Rubrics](/docs/troubleshooting/overlapping-rubrics) {% /related-card-grid %} --- 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.artifacts title: Contributed Artifacts summary: Inspect policies, rubrics, cases, and coverage observations produced through attributable expert contribution work. kind: reference product_area: expert_contributions status: stable updated: 2026-09-07 canonical: /docs/expert-contributions/contributed-artifacts --- # Contributed Artifacts ## Definition Contributed Artifacts is the benchmark workspace for inspecting durable material produced through Expert Contributions. It organizes contributed **Policies**, **Rubrics**, **Cases**, and **new coverage observations** while preserving their relationship to the Contribution and expert work that produced them. The view is a provenance and reconciliation surface. The final owner of a materialized artifact remains Correctness Governance, Assets, or Coverage Management according to artifact type. ## Fields, states, or lifecycle rules - Policy contributions represent expert-grounded behavior rules or revisions. - Rubric contributions represent proposed or accepted evaluation criteria tied to specialist judgment. - Case contributions represent situations supplied or corrected through expert work. - Coverage observations identify missing, thin, conflicting, or newly important benchmark behavior. - A coverage observation preserves its source, proposed facet applications, and application status so an operator can distinguish a recorded observation from one incorporated into coverage structure. - Each artifact should remain traceable to the Contribution, expert, selected evidence, task responses, and checkpoints that support it. - Contribution completion and artifact governance are separate transitions. Inspect the artifact's owning surface before treating it as active policy, active rubric, benchmark dataset membership, or resolved coverage. - Reconciliation can accept, revise, route, or leave material unresolved according to the active workflow. ## Interpreting contributed material Use the artifact type to choose the next surface. A contributed policy or rubric belongs in Correctness Governance. A contributed case belongs in the project Assets pool before benchmark selection. A coverage observation belongs in Coverage Management and may motivate a Coverage Story, case construction, or another focused Contribution. Preserve disagreements. Two experts can contribute conflicting Policy interpretations, and the artifact view should help an operator trace each interpretation rather than merge them into an invented consensus. Materialization should keep the Contribution, activity, checkpoint, expert, and scoped evidence links needed to explain why the artifact exists. {% example-demo title="Example: contribution provenance" %} An expert contributes a policy limiting compatibility claims, a rubric for explicit uncertainty, and a new case involving an unsupported adapter. The policy and rubric move to Correctness Governance for their lifecycle. The case enters Assets and is later selected into a benchmark dataset snapshot. All three retain the Contribution as their provenance. {% /example-demo %} ## Source confidence Code-backed: the active Contributed Artifacts workspace exposes policy, rubric, case, and new-coverage groupings. This page preserves the separation between contribution provenance and the lifecycle of each owning artifact. ## Related task pages {% related-card-grid title="Related task pages" %} - [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 %} --- id: object-model.versions-staleness-resolution title: Versions, staleness, and resolution summary: Track how correctness objects evolve and how teams resolve conflicting evidence. kind: reference product_area: object_model status: stable updated: 2026-08-23 canonical: /docs/object-model/versions-staleness-and-resolution --- # Versions, staleness, and resolution ## Definition Versions, staleness, and resolution describe how correctness artifacts evolve without making old evidence ambiguous. Cases, Policies, Rubrics, Benchmark Versions, supported Case-scoped reference outputs, and customer-owned review context can change at different times; version boundaries explain which evidence belongs to which state. Use this reference when a result changed unexpectedly, a policy was revised, a case was refreshed, or reviewers need to know whether older benchmark evidence still applies. ## Fields, states, or lifecycle rules - Versions preserve what changed and what evidence was produced before the change. - Staleness means older evidence may no longer reflect the current case, standard, coverage, or candidate boundary. - Resolution work should name whether the fix belongs to a case, output, policy, rubric, coverage plan, benchmark version, or run metadata. - Comparisons are weak when artifact versions are hidden. - This page describes public object semantics, not retention, audit-log completeness, or compliance guarantees. ## Related objects Versions, staleness, and resolution should be read with [Versioning and Staleness](/docs/governance/versioning-and-staleness), [Benchmark versioning](/docs/governance/benchmark-versioning), [Case versioning](/docs/governance/case-versioning), and [Policy Conflicts and Revisions](/docs/governance/conflict-resolution). {% example-demo title="Versions, staleness, and resolution boundary" %} State change: Reviewers revise a compatibility policy after finding unsupported-claim failures. Benchmark evidence: Runs against the old policy remain interpretable, but they should not be summarized as current evidence without naming the old policy version. Interpretation: The resolution note explains whether to rerun, revise the benchmark version, or preserve the old result as historical context. {% /example-demo %} ## Source confidence Code-backed: Benchmark, Policy, and Rubric types carry version facts; Benchmark Datasets → Snapshots and Policy activity preserve named historical boundaries. Cross-object staleness and conflict resolution are explicit review decisions rather than a universal automatic state. ## Related task pages {% related-card-grid title="Related task pages" %} - [Versioning and Staleness](/docs/governance/versioning-and-staleness) - [Conflict Resolution](/docs/governance/conflict-resolution) - [Product quickstart](/docs/quickstart) - [Task index](/docs/operating-manual/task-index) {% /related-card-grid %}