Point identity and evidence mappings to current canon owners

Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a070b5-4994-7271-bd8b-7c3dbcedec4b

docs/canon-interface-card.yaml

@@ -7,7 +7,7 @@ owner: codex
 updated: "2026-08-19"
 
 implements:
-  - identity-canon conceptual model as an implementation-facing domain facade
+  - InfoTechCanon identity/organization/access models as implementation-facing mappings
   - InfoTechCanon user-engine evaluation pack
   - small-saas user-management alignment surface
 
@@ -35,7 +35,7 @@ consumes:
   - platform audit and event sinks
 
 owned_concepts:
-  user_record: User-engine local user record mapped to identity-canon User as a convenience term.
+  user_record: User-engine local user record mapped to InfoTechCanon User as a convenience term.
   account_record: Operational account state for a user-engine scope.
   external_identity_link: Source-specific issuer and subject link to a user record.
   profile_value: Scoped profile or preference value.
@@ -86,7 +86,7 @@ required_identifiers:
   correlation_id: "operation-level audit and event correlation id"
 
 mapping_rules:
-  - Resolve source terms such as user, group, role, tenant, subject, and principal into identity-canon layers before exposing them as implementation concepts.
+  - Resolve source terms such as user, group, role, tenant, subject, and principal into InfoTechCanon identity, organization and access layers before exposing them as implementation concepts.
   - Keep account records, authenticated subjects, and authorization principals distinct even when they share issuer or subject identifiers.
   - Treat memberships as relationship facts that may produce grant-like access facts, not as final authorization decisions.
   - Preserve source system, scope, lifecycle state, and evidence reference whenever a relationship affects access, privacy, or lifecycle.
@@ -113,7 +113,16 @@ source_of_truth:
   organization_authority: NetKingdom organization or directory systems
 
 known_deviations:
-  - User remains a local implementation class even though identity-canon treats user as a non-root convenience term; mappings must state whether it represents actor-facing profile holder, account owner, or local user record.
+  - User remains a local implementation class even though InfoTechCanon treats user as a non-root convenience term; mappings must state whether it represents actor-facing profile holder, account owner, or local user record.
   - Access Grant is currently a grant-like reference derived from memberships, not a durable authorization grant table.
   - Evidence Source references currently derive from local audit records unless an external evidence exporter is supplied.
   - AccessReview, Policy, Control, Exception, and lifecycle Task are references or gaps, not first-class owned records.
+
+federation_reference_review:
+  date: "2026-09-06"
+  project_task: CFED-WP-0001-T09
+  mapping: docs/canon-mapping.md
+  canon_interfaces:
+    - info-tech-canon/infospace/interfaces/federation.yaml
+    - commerce-canon/infospace/interfaces/federation.yaml
+  disposition: Source references updated; runtime contracts and candidate conformance status unchanged.

docs/canon-mapping.md

@@ -4,12 +4,12 @@ Status: candidate
 Updated: 2026-06-05
 
 This document maps current `user-engine` implementation concepts to
-identity-canon and InfoTechCanon concepts. It is intentionally explicit about
+InfoTechCanon identity, organization, access and evidence concepts. It is intentionally explicit about
 owned facts, consumed facts, references, and gaps.
 
 ## Mapping Stance
 
-`identity-canon` treats `User` as a convenience term, not the root concept.
+`InfoTechCanon` treats `User` as a convenience term, not the root concept.
 `user-engine` keeps the existing `User` implementation class for compatibility,
 but exposes canon-facing context through `identity_context` so consumers can see
 the distinct account, actor, subject, principal, tenant, membership, profile,
@@ -101,3 +101,21 @@ They verify that:
 - cross-tenant identity context is denied without platform scope;
 - claims-enrichment context can be read without implying token issuance
   ownership.
+
+## Federation source references — 2026-09-06
+
+Current owners: [itc-ident](../../info-tech-canon/infospace/models/identity/InfoTechCanonIdentityModel.md)
+for identity, Scope and the User convenience mapping;
+[itc-org](../../info-tech-canon/infospace/models/organization/InfoTechCanonOrganizationModel.md)
+for actors and membership; [itc-access](../../info-tech-canon/infospace/models/access-control/InfoTechCanonAccessControlModel.md)
+for Subject and Principal; and [itc-evid](../../info-tech-canon/infospace/models/evidence/InfoTechCanonEvidenceModel.md)
+for Evidence assertions and addressable Evidence Source containers.
+[CommerceCanon](../../commerce-canon/infospace/models/counterparty/CommerceCanonCounterpartyModel.md)
+owns Customer, Vendor and Legal Entity semantics.
+
+This is a source-coordinate review under CFED-WP-0001-T09. Existing emitted
+labels and scenario/test identifiers remain compatibility surfaces; the older
+entity mappings above are not silently promoted to conformance with the newly
+published draft models. Evidence references do not by themselves establish an
+assertion/source distinction in every adapter. A full consumer adoption review
+remains demand-driven.

docs/contracts.md

@@ -208,8 +208,8 @@ Every mutating service operation appends an audit record and outbox event with
 the same correlation id and resolved tenant. Authorization denials are audited
 without emitting outbox events.
 
-Local audit records may be exported as identity-canon `Evidence Source`
-references. Durable platform audit custody remains outside user-engine.
+Local audit records may be exported as references to addressable Evidence Source
+containers under InfoTechCanon `itc-evid`. Durable platform audit custody remains outside user-engine.
 
 ## Durable Store Contract
 

docs/identity-domain-naming-decision.md

@@ -43,7 +43,7 @@ Revisit the name when all of the following are true:
 - consumers primarily use the identity-context API rather than only user/profile
   APIs;
 - NetKingdom IAM, authorization, audit, and evidence adapters are stable;
-- identity-canon mappings are validated by executable scenarios;
+- InfoTechCanon mappings are validated by executable scenarios;
 - docs consistently describe the repo as an identity-domain facade and not as an
   identity provider;
 - downstream consumers would be misled by the old `user-engine` name.

docs/interfaces/netkingdom-integration.md

@@ -33,7 +33,7 @@ The user-engine boundary contract remains accepted in net-kingdom
 | `MembershipFactExporter` | outbound | Export user-engine-owned membership facts as read models for authorization systems. |
 | `EventOutbox` | outbound | Publish durable lifecycle/profile/catalog/membership events after commit. |
 | `AuditWriter` | local/outbound | Persist local audit and provide redacted summaries for platform audit sinks. |
-| `EvidenceReferenceExporter` | outbound | Export local audit/review material as identity-canon evidence references without owning the platform audit system. |
+| `EvidenceReferenceExporter` | outbound | Export local audit/review material as InfoTechCanon itc-evid evidence references without owning the platform audit system. |
 | `PolicyControlReferenceResolver` | outbound | Resolve policy, control, review, exception, or waiver references for identity-domain traces. |
 | `LifecycleTaskSink` | outbound | Create or link lifecycle, review, remediation, or integration-gap work in a task system. |
 | `SecretProvider` | inbound | Load runtime secrets through environment/local config in standalone mode and scoped secret providers in platform mode. |