id: comparison/repo-scoping/extension-candidates
title: Repo Scoping Canon Extension Candidates
status: candidate
consumer: repo-scoping
comparison_report: comparison/repo-scoping/report
candidate_set_status: review-required
candidates:
  - id: extension/repository-intent-statement
    title: RepositoryIntentStatement
    proposed_owner: model/purpose-demand-extension
    change_type: new-concept
    problem: Intent is currently generic; repo-scoping needs a design-time repository utility statement that can seed but not prove current scope.
    proposed_definition: A design-time statement of expected repository utility, distinct from current scope and consumer purpose.
    review_question: Should this be a specialization of Intent or a repository-scoping profile concept?
  - id: extension/repository-scope-profile
    title: RepositoryScopeProfile
    proposed_owner: model/information-space
    change_type: new-profile
    problem: Generic Scope does not capture source-linked current-state repository utility and SCOPE.md generation ownership.
    proposed_definition: A current-state, source-linked profile describing what a repository is useful for, when it is relevant, and which approved claims support it.
    review_question: Should this be a profile of Information Space, Governance, or a cross-model application profile?
  - id: extension/characteristic-claim
    title: CharacteristicClaim
    proposed_owner: model/governance
    change_type: new-concept
    problem: Repo-scoping uses Scope, Ability, Capability, and Feature as reviewable claims rather than merely descriptive tags.
    proposed_definition: An interpreted, reviewable claim about a repository at a declared abstraction level with confidence, evidence, provenance, and review status.
    review_question: Should Ability, Capability, and Feature be levels of CharacteristicClaim or separate profile concepts?
  - id: extension/evidence-link
    title: EvidenceLink
    proposed_owner: model/information-space
    change_type: new-concept
    problem: Governance Evidence is too coarse for support links that target observed facts, content chunks, files, and lower-level characteristics.
    proposed_definition: A typed support relation from a claim to a source observation, content chunk, artifact, or lower-level claim.
    review_question: Should EvidenceLink live in Information Space while Evidence remains Governance/Observability owned?
  - id: extension/source-observation
    title: SourceObservation
    proposed_owner: model/information-space
    change_type: new-concept
    problem: Observed facts are deterministic scanner outputs and should not become evidence or truth claims without interpretation.
    proposed_definition: A source-linked observation extracted from repository content, metadata, or execution results, before review or promotion.
    review_question: How should SourceObservation relate to Observability signals and Information Space chunks?
  - id: extension/source-role
    title: SourceRole
    proposed_owner: standard/tagging
    change_type: new-taxonomy
    problem: Repo-scoping needs stable labels such as intent_summary, derived_scope, product_documentation, implementation_source, dependency_declaration, and agent_guidance.
    proposed_definition: A tag or classification describing the role a source artifact plays in repository utility evaluation.
    review_question: Should SourceRole be a tagging profile or part of Information Space provenance?
  - id: extension/utility-relationship
    title: UtilityRelationship
    proposed_owner: model/governance
    change_type: new-taxonomy
    problem: Provider, dependency, tooling, mention, owned, facade, and adapter relationships decide whether evidence can become a provided capability.
    proposed_definition: A classification of how source evidence relates to claimed repository utility.
    review_question: Should these labels become governance decision criteria for approving capability claims?
  - id: extension/scope-freshness
    title: ScopeFreshness
    proposed_owner: model/task
    change_type: new-concept
    problem: Repo-scoping tracks stale downstream claims when observed facts change, but the canon lacks freshness semantics for repository scope.
    proposed_definition: A state describing whether a scope claim is current, stale, needs recalculation, needs review, superseded, or rejected.
    review_question: Should freshness be task state, governance review state, or a profile-specific quality signal?
  - id: extension/propagation-impact
    title: PropagationImpact
    proposed_owner: model/task
    change_type: new-concept
    problem: Repo-scoping measures propagation breadth and depth from changed facts to approved scope claims.
    proposed_definition: A traceable impact result showing which claims may be stale because upstream evidence changed.
    review_question: Can this generalize to other evidence-driven canon consumers?
  - id: extension/scope-md-interface
    title: ScopeMdInterface
    proposed_owner: model/information-space
    change_type: new-interface-profile
    problem: SCOPE.md has a stable section contract and machine-readable capability blocks that should be reusable.
    proposed_definition: A markdown interface profile for repository orientation, generated sections, curator-owned sections, and provided capability blocks.
    review_question: Should this become an interface-card specialization?
disposition:
  recommended_next_step: Create a dedicated Repository Scope Profile workplan after repo-scoping consumer adoption begins.
  immediate_standard_changes: []
  hold_for_review:
    - extension/repository-intent-statement
    - extension/repository-scope-profile
    - extension/characteristic-claim
    - extension/evidence-link
    - extension/source-observation
    - extension/source-role
    - extension/utility-relationship
    - extension/scope-freshness
    - extension/propagation-impact
    - extension/scope-md-interface