prj-canon-federation/workplans/CFED-WP-0001-foundation.md

---
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-08-16"
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: wait
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.

## Rename identity-canon to commerce-canon

```task
id: CFED-WP-0001-T03
status: wait
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.

## Scaffold commerce-canon to the canon layout standard

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

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

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

## Publish cross-canon interface cards

```task
id: CFED-WP-0001-T08
status: wait
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.

## Sweep fleet references

```task
id: CFED-WP-0001-T09
status: wait
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.

## Land the evidence model in InfoTechCanon

```task
id: CFED-WP-0001-T11
status: wait
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`.

## Extend itc-org with social collectives

```task
id: CFED-WP-0001-T12
status: wait
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.

## Seed the Family concept area

```task
id: CFED-WP-0001-T13
status: wait
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.

## Record open residuals

```task
id: CFED-WP-0001-T10
status: wait
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.