generated from coulomb/repo-seed
125 lines
4.9 KiB
Markdown
125 lines
4.9 KiB
Markdown
---
|
|
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.
|