Document characteristic acceptance boundary

docs/acceptance-policy.md

@@ -0,0 +1,105 @@
+# 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.