---
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 %}