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.

docs/terminology.md

@@ -57,15 +57,40 @@ normalization.
   `implementation_source`, `dependency_declaration`, `configuration`,
   `ci_tooling`, `test_evidence`, or `agent_guidance`.
 - Utility relationship: metadata describing how a fact relates to repository
-  utility, such as `owned`, `facade`, `adapter`, `configure`, `dependency`,
-  `tooling`, or `mention`. Only owned/facade/adapter relationships should be
-  promoted directly into provided capabilities.
+  utility. Only `owned`, `facade`, and explicit `adapter` relationships should
+  be promoted directly into provided capabilities or trusted auto-approval.
+- Owned capability: utility the repository provides through its own product
+  behavior, source, interface, or documented intent.
+- Facade capability: utility intentionally exposed through this repository even
+  though important work is delegated elsewhere. Public wrapper APIs, CLI
+  commands, or product documentation should make the facade role explicit.
+- Adapter capability: utility that connects callers to another implementation
+  through repository-owned adapter code. Generic use of the word adapter is not
+  enough; the adapter needs source-linked evidence for the capability being
+  exposed.
+- Consumer/configuration relationship: evidence that the repository uses or
+  configures something, such as an environment variable or client dependency,
+  without itself providing that utility.
+- Dependency relationship: evidence from manifests, imports, lockfiles, or
+  package metadata. Dependencies belong in evidence or "How It Fits" context
+  unless a curator promotes them.
+- Tooling-context relationship: build, CI, release, or agent-operating context.
+  Tooling can explain how the repository is worked on, but should not define
+  product capabilities by itself.
+- Mention relationship: ambient text that names a provider, framework, sibling
+  repo, or product concept without showing that the repository provides it.
 - Candidate: proposed characteristic or evidence from deterministic heuristics
   or optional LLM assistance. Candidates are review inputs, not registry truth.
 - Approved: curated registry truth that appears in ability maps, search, exports,
   and SCOPE generation.
 - Rejected: a candidate judged false or irrelevant. Rejected entries are hidden
   by default but retained for audit and recovery.
+- Rebuild from scratch: an explicit operation that regenerates candidates from
+  current source after approved characteristics have become polluted or stale.
+  Dry-run first; confirmed rebuilds preserve audit history.
+- Supersede: mark prior approved characteristics as replaced by a rebuild or
+  review correction. Superseded entries explain historical registry state rather
+  than disappearing.
 - Classification: a main type plus optional additional attributes that help
   users filter and orient without forcing every item into a single rigid box.