--- id: CFED-WP-0001 type: workplan title: "Canon federation foundation: boundary, rename, and model placement" domain: infotech repo: prj-canon-federation status: ready owner: codex topic_slug: canon-federation created: "2026-08-16" updated: "2026-08-16" --- # Canon federation foundation: boundary, rename, and model placement ## Goal Establish the concept-ownership boundary, then execute the `identity-canon` split: identity to InfoTechCanon as `itc-ident`, commercial content retained in the same repository renamed to `commerce-canon`. Every concept ends with exactly one owner. Governed by `ADR-006` in the Custodian canon. No content moves before T01. ## Resolve the boundary and accept ADR-006 ```task id: CFED-WP-0001-T01 status: todo priority: high ``` Resolve the six open ownership questions in `ADR-006` and move it to `accepted`. This is a human review gate — every later task depends on it. 1. `Scope` — `itc-ident` or `itc-access`? identity-canon P3 makes it first-class; `itc-access` uses "access scope" throughout. 2. `Assurance Level` vs `itc-gov` `Assurance` — specialization or distinct concept? `Counterparty Assurance Gradient` builds on whichever wins. 3. `Evidence Source` vs `itc-gov` `Evidence` — likely an `itc-gov` specialization rather than identity-owned. 4. `Relationship Tuple` — reads as a Zanzibar/OpenFGA-style authorization primitive, so plausibly `itc-access` rather than `itc-ident`. 5. `Adjudication Outcome` — three candidate owners: `itc-access` `AuthorizationDecision`, `itc-gov` `Decision`, or commerce. 6. `Community` / `Family Or Household` — absent from `itc-org`, which covers enterprise structures only. Recommendation is to extend `itc-org` rather than place them in `itc-ident`; confirm or overrule. Record each resolution with rationale in `ADR-006`, then set its status to `accepted`. ## Build the concept-ownership ledger ```task id: CFED-WP-0001-T02 status: wait priority: high ``` Produce a machine-readable ledger under `ledger/` mapping every concept in `identity-canon/canon/CanonicalGlossary.md` (as of project start) to exactly one owning canon and model, with disposition: `import` (defined upstream, referenced here), `own` (moves and stays owned), or `retire` (dropped, with rationale). Include a validation pass that reports concepts with zero owners and concepts with two. Zero of both is gate **G2**. This ledger is the migration's source of truth — T05 and T06 execute from it rather than from prose. ## Rename identity-canon to commerce-canon ```task id: CFED-WP-0001-T03 status: wait priority: high ``` Rename the repository in place, preserving git history: - forge repo rename on Forgejo (`coulomb/identity-canon` → `coulomb/commerce-canon`); - local directory and every git remote; - State Hub repo slug and registered local path (`make register-path`); - `.repo-classification.yaml` — slug, `domain` (revisit `infotech` → likely `financials` with `government` secondary), capability tags; - regenerate agent instructions (`make update-agent-instructions`); - `GOAL.md`/`INTENT.md`, `SCOPE.md`, `README.md`, `AGENTS.md` prose; - workplan prefix decision: keep finished `IDENTITY-WP-*` files unchanged as provenance, use a commerce prefix for new plans. Add a migration note to `history/` in the renamed repo per the `prj-` standard's slug-rename rule. ## Scaffold commerce-canon to the canon layout standard ```task id: CFED-WP-0001-T04 status: wait priority: medium ``` Bring the renamed repository up to `InfoTechCanonRepositoryLayoutStandard`: `canon.yaml` (repository, title, status, version, classification, kernel/models/ standards registries) and an `infospace/` tree with `kernel/`, `models/`, `standards/`, `assimilation/`, `mappings/`, `concepts/`, `profiles/`, `patterns/`, `validation/`. Write the CommerceCanon kernel document, including the ownership boundary against `itc-org`, `itc-gov`, and `itc-ident` — specifically `Organization`, `Ownership`, `Obligation`, `Decision`, `Evidence`, and `Assurance`, which are already owned upstream. Do **not** build a service surface. Whether CommerceCanon needs CLI/JSON/API is a later evidence-driven decision (`SCOPE.md`, out of scope). ## Land the identity model in InfoTechCanon ```task id: CFED-WP-0001-T05 status: wait priority: high ``` Create `info-tech-canon/infospace/models/identity/InfoTechCanonIdentityModel.md` (`itc-ident`) from the ledger: - owned concepts per `ADR-006` decision 4 plus T01 resolutions; - imports declared explicitly — `Actor`, `Person`, `Agent`, `Organization`, `Group`, `Role`, `Membership` from `itc-org`; `Subject`, `Principal` from `itc-access`; - carry over identity-canon's design principles P1–P13 where they survive the boundary, dropping those that only made sense in a standalone canon; - register in `canon.yaml` under `models:` and add to the kernel map; - update `InfoTechCanonAccessControlModel:214` so the identity boundary now points at `itc-ident` instead of declaring the area unowned. Verification for gate **G4**: `itc-ident` defines no concept owned by `itc-org` or `itc-access`. ## Land the counterparty model in CommerceCanon ```task id: CFED-WP-0001-T06 status: wait priority: high ``` Create the counterparty/commercial model in `commerce-canon` from the ledger's `own` entries — `Legal Entity`, `Legal Person`, `Beneficial Owner` and its relationship/exemption concepts, `Customer`, `Vendor`, `Commercial Relationship`, `Commercial Commitment`, `Payment Instrument Reference`, `Payment Mandate`, `Pipeline Pursuit`, `Commercial Record`, `Counterparty Assurance Gradient`, `Reputation Signal`, `Performance Evidence`, `Adjudication Outcome`, `Registry Identifier`, `Proxy Commercial Identifier`. Model identifier subtypes as the worked example of the import pattern: `itc-ident` owns `Identifier`; CommerceCanon owns `Registry Identifier` and `Proxy Commercial Identifier` as specializations of it. Carry over design principles P14 ("Separate Commercial Records From Accounts") and P15 ("Model Commercial Binding Explicitly"), which are commerce-side. ## Distribute the research corpus as provenance ```task id: CFED-WP-0001-T07 status: wait priority: medium ``` Route `research/` (8 subject areas + `CorpusIndex.md`), `terminology/` (`TerminologyInventory.md`, `TerminologyConflictMap.md`), and `scenarios/ ScenarioTests.md` into the `assimilation/` tree of whichever canon inherited the concepts each supports. Split where a corpus area serves both. Preserve provenance — this is research that already ran; it is not re-derived. Record the disposition so gate **G6** is checkable. ## Publish cross-canon interface cards ```task id: CFED-WP-0001-T08 status: wait priority: medium ``` Each canon publishes a Canon Interface Card naming what it imports from and exports to the others, per `InfoTechCanonCore`'s interface-card mechanism. Add the reciprocal references so the zero-cross-reference condition that motivated this project no longer holds (gate **G7**). Include Custodian canon in the map — it governs both domain canons and holds `ADR-006`, but owns no domain semantics. ## Sweep fleet references ```task id: CFED-WP-0001-T09 status: wait priority: medium ``` Find and fix every live reference to `identity-canon` across the fleet: repo docs, hub records, MCP registrations, `.custodian-brief.md` files, capability registries, and `reuse-surface` entries. Deliberate historical provenance (genesis notes, completion records, finished workplans) stays. Gate **G8** is a clean sweep. ## Record open residuals ```task id: CFED-WP-0001-T10 status: wait priority: low ``` Before this workplan is set to `finished`, every actionable leftover becomes a live work record outside this repository, per `work-record-types_v0.1.md` § Residuals. Expected residuals: - `itc-org` extension for social collectives (`Community`, `Family Or Household`), if T01 confirms the recommendation — an InfoTechCanon workplan; - CommerceCanon service-surface decision, if demand appears; - consumer adoption by `fin-hub`, `target-revenue`, `adaptive-pricing`, `qonto-assistant` — demand-signal driven, explicitly not a gate here.