4.9 KiB
id, title, status, consumer, created_by_workplan, source_context
| id | title | status | consumer | created_by_workplan | source_context | |||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| comparison/repo-scoping/report | Repo Scoping Canon Comparison Report | candidate | repo-scoping | ITC-WP-0009 |
|
Repo Scoping Canon Comparison Report
Summary
Repo-scoping already contains a strong domain model for repository utility:
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:
RepositoryIntentStatementRepositoryScopeProfileCharacteristicClaimEvidenceLinkSourceObservationSourceRoleUtilityRelationshipScopeFreshnessPropagationImpactScopeMdInterface
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.