# Scope

## Project authority

This repository owns the cross-repository goal, concept-ownership boundary,
sequencing, dependency map, migration ledger, risks, acceptance gates, and
consolidated evidence for the canon federation effort.

It does not own canon content. Concepts live in the canons themselves.

## Participating repositories

- `the-custodian` — `ADR-006`; durable decisions and standards
- `info-tech-canon` — receives the identity model (`itc-ident`)
- `identity-canon` → `commerce-canon` — renamed in place; retains commercial content
- `state-hub` — repo slug rename, registration, agent-instruction regeneration

Downstream consumers (`fin-hub`, `target-revenue`, `adaptive-pricing`,
`qonto-assistant`) are **not** participants. They may pull from CommerceCanon
later via demand signal; their adoption is not a gate of this project.

## In scope

- Concept-ownership boundary across Custodian canon, InfoTechCanon, CommerceCanon.
- Resolution of the six ownership collisions listed in `ADR-006`.
- The `identity-canon` → `commerce-canon` rename and all fleet references to it.
- Landing `itc-ident` in InfoTechCanon with imports, not redefinitions.
- Bringing CommerceCanon to `InfoTechCanonRepositoryLayoutStandard` structure.
- Distributing the research corpus as provenance.
- Cross-canon interface cards.

## Out of scope

- Hosting canon content in this repository.
- Authoring new commercial concepts beyond what already exists in the glossary.
  CommerceCanon grows by demand signal after the federation is in place.
- Building CommerceCanon's service surface (CLI/JSON/API). InfoTechCanon has one;
  whether CommerceCanon needs one is a later, evidence-driven decision.
- Moving the Federated Organization Standard out of Custodian canon.
- Extending `itc-org` with social collectives (`Community`, `Family Or
  Household`) beyond recording the recommendation — that is an InfoTechCanon
  workplan if adopted.
- Consumer adoption of either canon.
- Retiring or deleting any repository.

## Work-record rule

This project records milestones, dependencies, gates, decisions, and cross-repo
acceptance. Each participating repository owns its own implementation workplan
and evidence. Project records link those workplans by stable identifier rather
than copying their task lists.