Governance Overview
Use Governance when the reader needs to know whether correctness evidence is accountable: who approved it, which version was used, whether it is stale, and whether the user has the right access to act.
What this area is
Governance covers human approval boundaries, versioning, staleness, reviewer activity, project access, roles, permissions, conflict resolution, reproducibility, and data-handling expectations for AI-assisted features. It is about the correctness artifact graph: who approved what, which version was used, when an artifact became stale, and what context is needed to repeat or explain a benchmark result.
This page does not promise compliance, retention, billing, deployment, tenant-isolation, or security guarantees beyond the code-backed product surfaces cited in the source refs. Use the Admin Console page for organization administration and the permissions references for exact access boundaries where they are source-backed.
Decision checkpoint
| Governance question | Inspect | Do not infer |
|---|---|---|
| Can this standard govern evidence? | Human approval boundary | Suggested or AI-drafted text is approved. |
| Why did evidence change? | Case, policy, rubric, benchmark, and run versions | Score movement is only candidate behavior. |
| Who can act? | Project access, reviewer access, and admin references | Role label equals permission. |
| Is the artifact stale? | Staleness and versioning pages | Old benchmark evidence still reflects current standards. |
| Is this an enterprise trust claim? | Source-backed admin/security docs | Compliance, retention, or deployment guarantees. |
Who uses it
Project owners use Governance to keep artifact ownership clear. Experts rely on it to know when their judgment has become an approved standard. AI engineers use it to avoid comparing stale or mismatched versions. Organization administrators use adjacent admin surfaces for members, roles, security controls, integrations, and API keys.
Interpret people through the surface they are using: Project member, Contribution recipient, accountable artifact owner, or organization administrator. A descriptive persona such as AI engineer or domain expert explains work but does not grant permission.
Artifacts created or changed
Governance affects approval records, policy and rubric versions, case versions, benchmark versions, reviewer activity, access records, conflict-resolution notes, stale-state handling, and reproducibility context. It can also constrain whether AI-generated suggestions are allowed to become approved artifacts.
These surfaces do not establish compliance certification, retention guarantees, tenant isolation, audit-log completeness, or a general security posture. Organization controls belong to the separately bounded Admin Console.
What governance protects
Governance protects the line between suggestion and approval. AI assistance can draft, classify, summarize, or propose changes, but a suggestion becomes a governed standard only through the owning artifact's accountable approval state. Governance also protects version boundaries: a benchmark result is interpretable only when the Case set, governed evaluators, saved Harness Version, settings, published Regime Version, and benchmark-level run fields are clear.
When a benchmark changes unexpectedly, Governance asks which artifact changed. When experts disagree, it asks how the decision was resolved. When a reviewer lacks access, it asks whether the user is a project participant, reviewer, workspace member, or organization administrator. These distinctions keep the product trustworthy without inventing unsupported enterprise claims.
Before using a result in human review, inspect approval, version, access, staleness, and source-confidence boundaries. Hold the interpretation when any required boundary is unknown.
Governance readiness check
| Evidence is ready for accountable review when... | Hold the decision when... |
|---|---|
| Approved policies and rubrics are separated from suggestions and drafts. | Any governing standard is unapproved, stale, or ambiguous. |
| Benchmark evidence names case, standard, benchmark, run, and candidate versions. | A score is detached from version boundaries. |
| Access and reviewer roles are checked against source-backed permission pages. | A role label is used as a permission guarantee. |
| Unsupported enterprise claims are left out or routed to source-backed docs. | The page implies compliance, retention, security, billing, or deployment behavior without evidence. |
Common starting tasks
Related reference pages
Related troubleshooting pages
Worked example
Human approval boundary
An Expert Contribution produces a suggested refund Policy and a candidate binary Rubric. The Contribution preserves who supplied the judgment, but the suggestion does not govern evaluation yet. The accountable owner reviews and approves the Policy and Rubric in Correctness Governance, then the team creates the Benchmark Version that uses those governed objects. Earlier Runs remain attached to their original boundary.
Source confidence
Code-backed: Project Members, Policy and Rubric detail, Policy activity, Dataset Snapshots, and Evaluation Run detail expose the access, approval, version, and evidence boundaries summarized here. Linked pages provide narrower object-specific behavior.