utility relationships understanding of INTENT.md vs. SCOPE.md and documentation.

docs/characteristic-evidence-model.md

@@ -67,6 +67,28 @@ that show the repository provides the utility directly or intentionally exposes
 it as a facade/adapter. Mentions, dependencies, configuration, and tooling are
 context until a curator promotes them or stronger owned evidence appears.
 
+Trusted auto-approval applies the same rule. A candidate capability must have
+source references and an eligible utility relationship (`owned`, `facade`, or
+`adapter`) before it can be approved automatically. Dependency, tooling,
+configuration, and mention-only candidates remain review material. The review
+decision should explain both sides: why approved candidates were considered safe
+and why skipped candidates need curator review.
+
+`INTENT.md` may also seed intended capabilities when it contains an explicit
+capability section. These intent-derived candidates are marked as review
+required because intent says what the repository is meant to provide, not what
+has already been proven. `SCOPE.md` sections with the same wording are not
+treated as equivalent input during rebuilds, because scope is derived from the
+registry model being rebuilt.
+
+The motivating failure mode was a key-cape-like repository whose agent guidance
+and generic backend-adapter vocabulary looked superficially like LLM provider
+routing. That pattern should produce source-linked facts for the files that
+exist, but it should not become an LLM-provider capability unless there is
+provider-specific owned, facade, or adapter evidence. The scanner and generator
+should solve this by provenance and utility relationship rules, not by
+hard-coding product names.
+
 Source references point from interpreted claims back to files or facts.
 
 Evidence is support for a characteristic. It is not the same thing as an observed
@@ -98,3 +120,21 @@ without breaking existing data:
 
 The UI should make this relationship clear by presenting evidence as support
 under the characteristic it supports, not as a peer of features.
+
+## Rebuilds And Supersession
+
+Use a normal analysis rerun when the existing approved map is mostly trustworthy
+and the goal is to compare new evidence against prior candidates. Use a rebuild
+from scratch when approved characteristics are polluted by a bad extraction
+pattern, stale after a major rename, or circularly derived from old scope text.
+
+A dry-run rebuild should be the first step. It scans current source, generates a
+fresh candidate graph, and reports what approved abilities, capabilities,
+features, and evidence would be superseded. A confirmed rebuild preserves audit
+history by recording which approved IDs were superseded, then clears the current
+approved map and leaves the fresh candidate graph for review or trusted
+auto-approval.
+
+Curators should treat superseded characteristics as historical claims, not as
+deleted facts. They explain what the registry used to believe and why a rebuild
+was chosen over incremental correction.