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

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.