repo-scoping/docs/acceptance-policy.md

Characteristic Acceptance Policy Boundary

Policy version: acceptance-policy/v1

repo-scoping separates fact generation, quality gating, and acceptance judgement. This boundary exists so deterministic automation can stay useful and fast without silently promoting weak or non-native claims into registry truth.

Boundary

Deterministic scanners and extractors may create observed facts, source refs, content chunks, candidate abilities, candidate capabilities, candidate features, and candidate evidence. They may also run transparent quality gates.

Deterministic quality gates may reject, invalidate, downgrade, merge, flag, or require review when a criterion is formally expressible. They must record the criterion identifier, outcome, rationale, and affected candidate element.

Deterministic quality gates must not approve candidate characteristics. No deterministic rule, scanner result, fixture match, vocabulary match, confidence threshold, source-role score, or duplicate check may mark a candidate as approved registry truth.

Human reviewers may approve candidate characteristics.

Trusted agentic reviewers may approve candidate characteristics only after inspecting the evidence, applying the active quality criteria, and recording a rationale tied to those criteria and source refs.

All automated review outcomes must be inspectable, reversible, and auditable.

Allowed Deterministic Outcomes

• pass: no formal criterion blocked the candidate; judgement is still pending.
• requires_review: a criterion found ambiguity that needs reviewer judgement.
• downgraded: the candidate remains visible but loses trust or native-utility strength until a reviewer overrides or edits it.
• rejected: the candidate should not be accepted as stated, but remains auditable with reason codes.
• invalidated: the candidate is structurally or evidentially unusable.
• merged: the candidate was folded into a better-supported equivalent.
• flagged: the candidate remains pending with a warning attached.

These outcomes may prepare a candidate for review. They do not approve it.

Allowed Human Outcomes

• approve: accept the candidate as registry truth.
• approve_with_edits: accept after reviewer edits, relinks, or merges.
• reject: reject the candidate as a matter of judgement.
• downgrade: preserve the candidate but reduce its standing or native claim.
• request_changes: ask for edited wording, source refs, hierarchy placement, or evidence.
• request_human_review: defer to another curator or domain owner.

Allowed Agentic Outcomes

• approve: accept only with evidence-linked rationale and criteria version.
• approve_with_edits: accept after proposed edits, relinks, or merges are recorded.
• reject: reject with cited criteria and evidence.
• downgrade: keep visible but lower trust or native-utility standing.
• request_human_review: stop automation when evidence or intent is ambiguous.
• propose_edit: suggest wording, hierarchy, source-ref, or merge changes without approving.

Agentic approval requires:

• reviewer identity or configuration
• criteria version
• prompt or policy version when applicable
• evidence inspected
• rationale
• exact candidate elements affected

Legacy Auto-Approval Terminology

trusted_auto_approve_candidate_graph and UI labels such as "Trusted auto-populate" are legacy terminology. They describe an existing migration-era behavior, not an accepted policy direction. Future implementation must replace that path with agentic review or leave candidates pending human review.

Until the migration in RREG-WP-0014 is complete, any artifacts produced by the legacy path must be identifiable in review decisions and self-scoping assessment artifacts. They should be treated as review debt, not as evidence that deterministic approval is allowed.

Quality Criteria Relationship

The quality criteria registry defines the formal checks deterministic gates may apply. Criteria should be versioned, reviewable, and specific enough to explain why a candidate was rejected, downgraded, invalidated, merged, flagged, or sent to review.

Examples of criteria families:

• source-role quality
• native utility versus dependency, tooling, fixture, or mention-only context
• hierarchy fit between capability and feature
• evidence sufficiency
• circularity from generated SCOPE.md
• fixture and schema-example contamination

Criteria can block bad output before judgement. They cannot stand in for judgement.