improved scanner

docs/characteristic-evidence-model.md

@@ -58,6 +58,15 @@ new intent file with a clear provenance note. After that bootstrap, the files
 should diverge naturally: `INTENT.md` remains design intent, while `SCOPE.md`
 remains generated or curated current scope.
 
+Provider, dependency, and tooling facts should also carry a utility
+relationship. A provider mentioned in documentation is usually a `mention`; an
+environment variable is usually `configure`; a manifest entry is usually
+`dependency`; implementation code under provider or adapter modules may be
+`owned` or `adapter`. Candidate generation should promote only relationships
+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.
+
 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

docs/terminology.md

@@ -56,6 +56,10 @@ normalization.
   `intent_summary`, `derived_scope`, `product_documentation`,
   `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.
 - 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,