---
id: CFED-WP-0001
type: workplan
title: "Canon federation foundation: boundary, rename, and model placement"
domain: infotech
repo: prj-canon-federation
status: active
owner: codex
topic_slug: canon-federation
created: "2026-08-16"
updated: "2026-09-06"
state_hub_workstream_id: "1c5615fc-03b7-5648-ba58-e828b8c0cb0f"
---

# 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: done
priority: high
state_hub_task_id: "39a2c720-b923-4c5b-aa0c-2991e54a6e3b"
```

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`.

**Result (2026-08-17):** `ADR-006` accepted. Seven resolutions recorded — the
six above plus R7, raised by the R3 reframing.

- **R1** `Scope` → `itc-ident`. No head-on collision existed: `itc-access` owns
  the narrower `ResourceScope`, not a general `Scope`.
- **R2** `Assurance Level` → `itc-ident`, distinct from `itc-gov`
  `AssuranceCase`/`AssuranceConclusion`. A shared English word, not a shared
  concept.
- **R3** `Evidence` and `Evidence Source` are a **general pair**, not rival
  definitions: the source is an addressable information container (URI-
  identifiable document or artifact); the evidence is a distinct assertion drawn
  from it. Invoice case: the signed PDF is the source; amount, issuer, and due
  date are separate evidence items. Neither belongs to commerce. `itc-gov` no
  longer owns `Evidence`.
- **R4** `Relationship Tuple` → `itc-access`, where it is already modelled
  (`:549`). No decision needed; a duplicate avoided.
- **R5** `Adjudication Outcome` follows R3 — general, not commerce-owned, and
  structurally *Evidence* sourced from a judgment document. `assurance_tier`
  splits: general strength dimension in the evidence model, `Counterparty
  Assurance Gradient` stays commerce as its named four-tier application.
- **R6** `Community` and `Household` extend `itc-org` under `CollectiveActor`;
  `Family` is rejected as a collective actor and gets its own seeded concept
  area. identity-canon's combined "Family Or Household" entry is split.
- **R7** the evidence pair lives in a dedicated model, **`itc-evid`**, imported
  by `itc-gov`, `itc-ident`, and `commerce-canon`.

Scope consequences: T11–T13 added below. `itc-org` extension promoted from
residual to scope; `Family` seeded but explicitly not authored.

## Build the concept-ownership ledger

```task
id: CFED-WP-0001-T02
status: done
priority: high
state_hub_task_id: "9c5ba080-e304-52cd-86d5-749a5a642387"
```

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), `split` (one entry becomes two, as with
"Family Or Household" under R6), or `retire` (dropped, with rationale).

Owning models are `itc-ident`, `itc-evid`, `itc-org`, `itc-access`, `itc-gov`,
the `Family` area, and `commerce-canon`, per `ADR-006` decision 4 and R1–R7.

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.

**Result (2026-09-05):** [Ledger](../ledger/README.md) complete: all 60
project-start source entries mapped to 61 destinations (one Family/Household
split), plus two ADR-required evidence concepts. Pinned donor-blob verification
and ownership validation pass: zero unowned and zero multiply owned
destinations. [Evidence](../docs/evidence/2026-09-05-ownership-ledger.md) records
verification and publication limits. T03 is ready to execute (`todo`).

## Rename identity-canon to commerce-canon

```task
id: CFED-WP-0001-T03
status: done
priority: high
state_hub_task_id: "57092ca3-e1a8-5469-83be-d0338a78c150"
```

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.

**2026-09-05 preparation:** Local and Forge head match at
`43c5c21a7a7e273241d9c7622db4e926ac9aadfa`; Forge repository ID 46 is now
verified through State Hub on existing UUID
`8c82baea-bb40-435d-ac42-ec7a7c20dbb8`. Repository-owned implementation plan:
[IDENTITY-WP-0004](../../commerce-canon/workplans/IDENTITY-WP-0004-commerce-rename.md).
The [metadata patch](../docs/evidence/2026-09-05-commerce-metadata.patch) passes
`git apply --check` and is reserved for post-rebind application. It retains the
research classification category, assigns financials primary with government
and infotech secondary, and preserves all finished plans. New post-rename plans
will use COMMERCE-WP; the pre-cutover rename plan keeps its existing ID.

**Preparation blocker (resolved later on 2026-09-05):** deployed State Hub has no `REPOSITORY_RENAME_PREFLIGHT_SECRET`;
preflight returns `preflight_signing_unavailable`. Existing platform handoff
`cd52ba10-de41-46ce-aa8b-9b44050da8f7` (STATE-WP-0085-T09, also blocking
FLEX-WP-0020) owns this provisioning dependency. The user already authorized
proceeding; repeated rename permission is not the blocker. No operation journal,
forge rename, local path move, or metadata patch application has occurred.
The second registered host also requires a verified checkout disposition before
completion. See [preparation evidence](../docs/evidence/2026-09-05-rename-preparation.md).


## Scaffold commerce-canon to the canon layout standard

```task
id: CFED-WP-0001-T04
status: done
priority: medium
state_hub_task_id: "1be7aa81-4fc8-5a5a-8451-e288e660a326"
```

Establish core documentation conformance to `InfoTechCanonRepositoryLayoutStandard`
(INTENT/SCOPE, demand, workplans, docs). Separately establish the canon-content
layout required by this project, following InfoTechCanon’s current layout family:
`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`, `itc-ident`, and `itc-evid`. Organization and
Ownership belong to itc-org; Obligation and Decision to itc-gov. Evidence transfers
to itc-evid under T11. Distinguish identity Assurance Level, governance
AssuranceCase/AssuranceConclusion, and commerce Counterparty Assurance Gradient.

Do **not** build a service surface. Whether CommerceCanon needs CLI/JSON/API is
a later evidence-driven decision (`SCOPE.md`, out of scope).

**Result (2026-09-05):** Native [COMMERCE-WP-0001](../../commerce-canon/workplans/COMMERCE-WP-0001-foundation-layout.md)
implements the draft kernel, registry, nine infospace categories, and core
documentation layout. Empty model/standard registries accurately retain the
publication gates. [Validation evidence](../docs/evidence/2026-09-05-commerce-layout.md)
records 26 checked links and 52 unchanged legacy files. Full documentation
conformance is not claimed; historical naming and finished-plan placement are
explicit provenance exceptions. T11 evidence is the next upstream prerequisite.


## Land the identity model in InfoTechCanon

```task
id: CFED-WP-0001-T05
status: done
priority: high
state_hub_task_id: "700a0c89-1b17-5993-a76e-7ef22b5847d9"
```

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.

**Publication prerequisite (2026-09-05):** reconcile actor-linking
`Delegation Relationship` assigned here by ADR-006 with existing itc-org section
10.18 `Delegation`. Do not duplicate the same semantics under a different name.
Resolve through destination canon review; amend ADR-006 if ownership changes.

Verification for gate **G4**: `itc-ident` defines no concept owned by `itc-org`
or `itc-access`.

**Result (2026-09-05):** [INFO-WP-0021](../../info-tech-canon/workplans/INFO-WP-0021-identity-model.md)
registers draft itc-ident 0.1.0 with exact ledger coverage and upstream imports.
Destination review consolidates Delegation into the accepted identity owner;
Organization retains an import. Identifier follows the same transfer from
Information Space. No ADR owner changes. [Evidence](../docs/evidence/2026-09-05-identity-model.md)
records 45 passing tests, 34 unchanged protected files, and the explicit exact
reciprocal-import cycle review. G4 passes; T06 is now todo.


## Land the counterparty model in CommerceCanon

```task
id: CFED-WP-0001-T06
status: done
priority: high
state_hub_task_id: "6bdb96c9-0524-5d3c-89e0-7c91df7ee56c"
```

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`,
`Registry Identifier`, `Proxy Commercial Identifier`.

Import `Adjudication Outcome`, `Evidence`, and `Evidence Source` from
`itc-evid` per R3/R5/R7. Rewrite the old Evidence Source subtype wording in
Reputation Signal, Performance Evidence, and Beneficial Ownership Exemption
to distinguish assertions from their sources. T11 must establish the shared
evidence model before these imports can be verified.

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.

**Result (2026-09-05):** Native [COMMERCE-WP-0002](../../commerce-canon/workplans/COMMERCE-WP-0002-counterparty-model.md)
registers draft commerce-counterparty 0.1.0: 18 owned concepts, two convenience
mappings and 25 explicit imports from four pinned upstream models. P14/P15 and
assertion/source corrections are implemented. [Evidence](../docs/evidence/2026-09-05-counterparty-model.md)
records exact ledger coverage and 53 unchanged protected files. T12 is next
to establish social-collective destinations before corpus distribution.


## Distribute the research corpus as provenance

```task
id: CFED-WP-0001-T07
status: done
priority: medium
state_hub_task_id: "26a96020-49bb-5a5e-97d1-c478b83bffd0"
```

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.

**Result (2026-09-06):** [INFO-WP-0024](../../info-tech-canon/workplans/INFO-WP-0024-corpus-provenance.md)
and [COMMERCE-WP-0003](../../commerce-canon/workplans/COMMERCE-WP-0003-corpus-provenance.md)
distribute 45 source files into 69 frozen snapshots, with per-model reading
indexes and 153 exact shared fragments. [Distribution ledger](../ledger/corpus-distribution.json)
and [G6 evidence](../docs/evidence/2026-09-06-corpus-distribution.md) verify complete
coverage, hashes and 479 links. Originals remain unchanged; disposition observe
does not promote historical assertions. G6 passes; T08 is now todo.


## Publish cross-canon interface cards

```task
id: CFED-WP-0001-T08
status: done
priority: medium
state_hub_task_id: "e0558c32-415f-5563-bca2-438b35fa6b53"
```

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.

After T12/T13, review CommerceCanon’s pinned organization source and update current
kernel references that still mark upstream extensions pending. Keep historical
import revisions verifiable; do not silently adopt new upstream definitions.


**Result (2026-09-06):** Native INFO-WP-0025, COMMERCE-WP-0004 and THE-WP-0001
publish reciprocal interface cards in all three canons. [G7 evidence](../docs/evidence/2026-09-06-interface-cards.md)
verifies three schema-valid cards, six reciprocal links, all ledger concept/seed
assignments and 25 unchanged imports. Commerce advances its reviewed upstream
pin with the previous manifest preserved; kernel references acknowledge T12/T13.
InfoTechCanon checks pass (46 tests); project rejection/ownership tests pass (13).
Custodian's historical projection failures and conflicting generated prefix
instructions have live residual [CUST-IN-0017](../../the-custodian/intakes.md).
G7 passes; T09 is now todo. Whole-fleet consistency is not claimed by this gate.


## Sweep fleet references

```task
id: CFED-WP-0001-T09
status: done
priority: medium
state_hub_task_id: "42ebf476-6a45-5e23-b507-eb90bc4f5c07"
```

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.

**Result (2026-09-06):** [G8 evidence](../docs/evidence/2026-09-06-reference-sweep.md)
records eight published owner updates, 141 scanned local Git repositories,
133 checked State Hub records and a verified live reuse-service handover.
The [exception ledger](../ledger/reference-sweep.json) fingerprints deliberate
provenance and stable test/scenario names; zero unreviewed references remain.
Two existing capability ids/vectors and repository identity are preserved.
REUSE-WP-0021-T01 is done; its T02 retains the unrelated archived-binding repair
as live waiting work. CUST-IN-0017 retains prior Custodian consistency debt.
G8 passes; T10 is now todo. Overall progress: 12/13 tasks complete.


## Land the evidence model in InfoTechCanon

```task
id: CFED-WP-0001-T11
status: done
priority: high
state_hub_task_id: "526843be-1dfa-5cd0-ba0c-123ea37d0f63"
```

Create `info-tech-canon/infospace/models/evidence/` (`itc-evid`) per R3, R5, R7,
owning `Evidence`, `Evidence Source`, `Adjudication Outcome`, and the general
evidence-strength dimension.

Model the pair explicitly: `Evidence Source` as an addressable information
container (URI-identifiable), `Evidence` as a distinct assertion drawn from a
source, with a containment/derivation relation between them. Both may carry
commentary. Which evidence is captured from a source depends on the interest
being served — the model must not presume a fixed extraction.

Use the invoice case as the worked example, including the electronic-invoicing
pattern of a signed PDF carrying an XML embedding, which is evidence
pre-extracted and bound to its source so the extraction is tamper-evident.

Then rework `itc-gov`: remove `Evidence` from its owned concepts, add the import,
and re-express the Policy-Control-Evidence chain pattern (`:1391`) over imported
concepts. `AssuranceCase`, `AssuranceConclusion`, and `Audit` stay with `itc-gov`.

Register in `canon.yaml` and the kernel map. Verification: exactly one model
defines `Evidence`.

**Result (2026-09-05):** Native [INFO-WP-0020](../../info-tech-canon/workplans/INFO-WP-0020-shared-evidence-model.md)
registers draft itc-evid 0.1.0, transfers governance ownership to imports, and
updates live consumer boundaries and generated retrieval surfaces. EvidenceBasis
remains the unchanged quantity-origin application. [Evidence](../docs/evidence/2026-09-05-shared-evidence-model.md)
records 38 passing tests and 34 unchanged protected files. Model registration
does not assert stable promotion or adoption. T05 is now todo, retaining its
delegation-boundary review prerequisite.


## Extend itc-org with social collectives

```task
id: CFED-WP-0001-T12
status: done
priority: medium
state_hub_task_id: "f82385e9-5735-5147-aab6-d86653f33e26"
```

Add `Community` and `Household` to `InfoTechCanonOrganizationModel` under the
existing `CollectiveActor` (`:363`), per R6.

This widens `itc-org` from enterprise structures into social ones — a real and
deliberate scope broadening, to be stated in the model rather than slipped in.
P4 ("Model Collective Actors Without Collapsing Them") governs: `Community`,
`Household`, `Team`, and `Group` remain distinct.

**Result (2026-09-05):** [INFO-WP-0022](../../info-tech-canon/workplans/INFO-WP-0022-social-collectives.md)
adds draft Community/Household definitions under CollectiveActor, explicit social
scope, P4 boundary cases and generated ownership entries. Family is excluded.
[Evidence](../docs/evidence/2026-09-05-social-collectives.md) records 46 passing
tests and 37 unchanged protected files. T13 is now todo.


## Seed the Family concept area

```task
id: CFED-WP-0001-T13
status: done
priority: medium
state_hub_task_id: "b6d097a3-1abc-584b-ab23-7a05c969670d"
```

Split identity-canon's combined "Family Or Household" entry. `Household` goes to
`itc-org` (T12); `Family` becomes its own concept area — **seeded, not
authored**.

Record only: the concept, its distinguishing structure (kinship, guardianship,
dependency, care, and legal, biological, and social parenthood, changing over
time and open to interpretation), the privacy sensitivity already flagged in
identity-canon ("may have legal implications outside the canon's scope"), and the
open modelling questions.

Do not build it out. Modelling family as one more collective actor is the
specific mistake most family-oriented software makes, and the reason such
software generally models families badly; authoring it speculatively here would
repeat that mistake at canon level. It grows on demand signal like any other
canon content.

**Result (2026-09-05):** Native [INFO-WP-0023](../../info-tech-canon/workplans/INFO-WP-0023-family-seed.md)
registers Family as a separate concept-area seed with distinguishing structure,
privacy sensitivity and unanswered modeling questions. No Family domain model
or CollectiveActor subtype is authored. [Evidence](../docs/evidence/2026-09-05-family-seed.md)
records 46 passing tests, unchanged domain-model count and 38 preserved files.
T07 is now todo; destination concept areas are established for corpus routing.

## Record open residuals

```task
id: CFED-WP-0001-T10
status: todo
priority: low
state_hub_task_id: "2faeb8fb-58cc-5ea8-b5a8-ea0ed9583b30"
```

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:

- build-out of the `Family` concept area beyond the T13 seed — demand-signal
  driven, and deliberately out of scope here;
- 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.


## T03 cutover continuation — 2026-09-05

Signing is provisioned (RPF-WP-0035-T04 done). The donor preparation is committed
and pushed at `40d5792fafbb2de778eabb56cfeaf00aecd058e1`. Operation
`615e7b44-d84e-4feb-92c5-1708feaf1e65` started with a passing fresh preflight.
The operator credential route performed the exact Forge rename; repository 46
is now `commerce-canon` at that same head. State Hub had no Forge write token,
so the runbook's operator-side rename/reconcile path was used with contained
OIDC and automatic session revocation.

State Hub reconciliation exposed a 307 redirect handling defect before rebind.
[STATE-WP-0089](../../state-hub/workplans/STATE-WP-0089-rename-redirect-recovery.md)
owns the fix, regression tests, image promotion and journal recovery. No direct
DB change, replacement journal, or weakening of immutable identity checks is
allowed. Both checkouts remain at the old path until rebind is verified.


## T03 completed — 2026-09-05

[Rename evidence](../docs/evidence/2026-09-05-rename-completed.json) records the
completed operation on the same Forge ID 46 and State Hub UUID. Both registered
checkouts are now commerce-canon with canonical remotes; the old State Hub slug
is a protected alias. Metadata, financials classification and agent instructions
are published at commerce-canon commit `c7002cf`. Three finished historical plans
remain byte-for-byte unchanged and the ledger still verifies its pinned source.

STATE-WP-0089 fixed and proved redirect recovery: 46 tests pass; deployed image
main-fe6b8d9, Helm revision 60; same journal resumed and completed. No direct DB
repair or replacement identity was used.

Live remaining work: REUSE-WP-0021 owns federation source/roster/cache updates;
T09 retains fleet-wide reference and projection acceptance. T04 is now todo.
The rename gate is complete; the canon layout, model moves and G8 fleet sweep
are not claimed complete by this result.