Add repo-scoping comparison assets

infospace/evaluations/repo-scoping/comparison-report.md

@@ -0,0 +1,124 @@
+---
+id: comparison/repo-scoping/report
+title: Repo Scoping Canon Comparison Report
+status: candidate
+consumer: repo-scoping
+created_by_workplan: ITC-WP-0009
+source_context:
+  - repo-scoping/INTENT.md
+  - repo-scoping/SCOPE.md
+  - repo-scoping/docs/terminology.md
+  - repo-scoping/docs/scope-md-spec.md
+  - repo-scoping/docs/characteristic-evidence-model.md
+  - repo-scoping/docs/dependency-aware-scope-propagation.md
+  - repo-scoping/docs/self-scoping/README.md
+---
+
+# Repo Scoping Canon Comparison Report
+
+## Summary
+
+Repo-scoping already contains a strong domain model for repository utility:
+
+```text
+Scope -> Ability -> Capability -> Feature -> Evidence -> Observed Fact
+```
+
+InfoTechCanon can help repo-scoping by giving this model clearer boundaries
+around INTENT, SCOPE, PURPOSES, governance decisions, evidence, tasks, source
+roles, and interface cards.
+
+The comparison also exposes canon gaps. The canon has generic concepts for
+Scope, Purpose, Evidence, Decision, Task, and Profile, but it does not yet have
+precise repository-scoping concepts for source-linked current scope, reviewable
+utility claims, evidence links, source observations, utility relationships,
+scope freshness, or SCOPE.md as a markdown interface profile.
+
+## Direct Fit
+
+| Repo-scoping surface | Canon fit | Notes |
+| --- | --- | --- |
+| `INTENT.md` | INTENT / RepositoryIntentStatement candidate | Intent should seed candidate generation but not prove current scope. |
+| `SCOPE.md` | RepositoryScopeProfile candidate | Current-state utility profile derived from evidence and approved claims. |
+| Review decisions | Governance Decision / Review | Acceptance, rejection, edits, overrides, and rationale map cleanly to governance. |
+| Evidence and source references | EvidenceLink candidate / Information Space provenance | Needs typed support links, not just generic evidence. |
+| Expectation gaps | Issue / ScopePressure / EvolutionRequest | Gaps may be defects, exclusions, or requests for future scope. |
+| Self-scoping assessments | Profile / Evidence / Review | Golden profiles and challenger assessments are reusable evaluation patterns. |
+
+## Important Distinctions
+
+### INTENT vs SCOPE
+
+Repo-scoping explicitly treats intent as design-time expected utility and scope
+as derived current-state utility. This is a strong match for the canon
+INTENT/SCOPE/PURPOSES distinction.
+
+The comparison suggests the canon should add a repository-specific
+`RepositoryIntentStatement` candidate so repositories can declare what they are
+trying to provide without making that declaration current truth.
+
+### Evidence vs Observed Fact
+
+Repo-scoping correctly avoids treating deterministic facts as the same thing as
+evidence. A fact is observed source material. Evidence is support for an
+interpreted characteristic. This suggests a canon `SourceObservation` and
+`EvidenceLink` pair.
+
+### Candidate vs Approved Truth
+
+Repo-scoping has a review boundary: candidates are proposals; approved
+characteristics are registry truth. This maps naturally to Governance Decision
+and Review, but the canon should add `CharacteristicClaim` or a profile-specific
+claim concept to preserve the abstraction level.
+
+### Current Scope vs Future Scope
+
+Expectation gaps and self-scoping outcomes can create scope pressure, but they
+should not alter current scope directly. They should create reviewable
+EvolutionRequests or tasks.
+
+## Benefit To Repo-Scoping
+
+Repo-scoping can benefit from the canon by:
+
+- using Canon Interface Cards to declare repo-scoping intent, scope, purposes,
+  produced concepts, consumed concepts, validation expectations, and requested
+  extensions,
+- mapping Scope, Ability, Capability, Feature, Evidence, and Observed Fact to
+  canon-owned or candidate concepts,
+- using Governance Decision and Evidence concepts to make review outcomes more
+  portable,
+- using PURPOSES to capture consumers such as State Hub, agents, managed repos,
+  and humans,
+- using Task and Governance concepts to separate recalculation, review, rebuild,
+  and adoption work,
+- feeding SourceRole and UtilityRelationship as candidate extensions back into
+  the canon.
+
+## Canon Extension Candidates
+
+The candidate set is recorded in
+`evaluations/repo-scoping/extension-candidates.yaml`.
+
+Highest-value candidates:
+
+- `RepositoryIntentStatement`
+- `RepositoryScopeProfile`
+- `CharacteristicClaim`
+- `EvidenceLink`
+- `SourceObservation`
+- `SourceRole`
+- `UtilityRelationship`
+- `ScopeFreshness`
+- `PropagationImpact`
+- `ScopeMdInterface`
+
+These should remain review candidates for now. They are useful enough to guide
+repo-scoping adoption, but they should be hardened through a consumer workplan
+in the repo-scoping repository before changing stable standards.
+
+## Recommended Next Move
+
+Create the actual adoption workplan in repo-scoping. It should complete a Canon
+Interface Card, map repo-scoping concepts to the comparison artifacts, and
+identify which extension candidates are proven by implementation pressure.