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

id	type	title	domain	repo	status	owner	topic_slug	created	updated	state_hub_workstream_id
CFED-WP-0001	workplan	Canon federation foundation: boundary, rename, and model placement	infotech	prj-canon-federation	active	codex	canon-federation	2026-08-16	2026-08-16	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

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

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

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

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

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

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

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

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

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

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

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

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

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.